On 2010-10-03, at 13:31, Eric Rescorla wrote:
> I'm asking because I'm pretty familiar with cryptography and I know that keys
> don't suddenly become
> worthless just because they get past their intended use lifetime. The
> semantics of signature
> security of old keys is a lot more complicated
On Sun, Oct 3, 2010 at 10:18 AM, Joe Abley wrote:
>
> On 2010-10-03, at 12:32, Eric Rescorla wrote:
>
> > Why?
>
> Are you asking because you've reviewed those discussions and have issues
> with them, or because you didn't review those discussions?
>
I'm asking because I'm pretty familiar with
On 2010-10-03, at 12:32, Eric Rescorla wrote:
> Why?
Are you asking because you've reviewed those discussions and have issues with
them, or because you didn't review those discussions?
I'm not entirely sure the answer shouldn't be "because we manage the keys, and
we say so" actually.
Joe
__
Why?
Ekr
On Oct 3, 2010, at 8:54, Joe Abley wrote:
>
> On 2010-10-03, at 07:59, Tony Finch wrote:
>
>> On 3 Oct 2010, at 08:27, Jakob Schlyter wrote:
>>> On 1 okt 2010, at 20.59, Tony Finch wrote:
Right, so it's aimed at human consumption rather than automatic tools?
>>>
>>> Give
On 3 Oct 2010, at 16:14, Phillip Hallam-Baker wrote:
>
> Moving from a market based solution with multiple CAs to a monopoly with one
> trust provider does not help at all. It makes the situation much worse
> because there is now no possibility of choice in the future.
It has the advantage of
On 2010-10-03, at 07:59, Tony Finch wrote:
> On 3 Oct 2010, at 08:27, Jakob Schlyter wrote:
>> On 1 okt 2010, at 20.59, Tony Finch wrote:
>>>
>>> Right, so it's aimed at human consumption rather than automatic tools?
>>
>> Given the historical information (together with old DNSKEY), you could
If the problem is the lack of checks and balances, the solution should be to
introduce checks and balances.
Moving from a market based solution with multiple CAs to a monopoly with one
trust provider does not help at all. It makes the situation much worse
because there is now no possibility of cho
On 3 Oct 2010, at 02:49, Marsh Ray wrote:
>
> In the meantime, we'd end up with the DNS root effectively having the power
> of yet another CA. Except that it's not, because the various arms of ICANN
> and VeriSign/Symantec are probably already trusted many times over.
I agree with your points
On 3 Oct 2010, at 08:27, Jakob Schlyter wrote:
> On 1 okt 2010, at 20.59, Tony Finch wrote:
>>
>> Right, so it's aimed at human consumption rather than automatic tools?
>
> Given the historical information (together with old DNSKEY), you could build
> a trust anchor history zone.
Not really, s
Phillip Hallam-Baker writes:
>The attack surface is the number of paths that are open to an attacker.
>
>In the current model there is only one trust path, the PKIX path.
Which isn't so much a path as a twelve-lane motorway with elevated cloverleaf
interchanges, twenty-four-hour drive-through ca
On 10/02/2010 03:16 PM, Ben Laurie wrote:
On 1 October 2010 16:15, Phillip Hallam-Baker wrote:
The problem with that approach is that the attacker now has two
infrastructures that they can attack rather than just one.
If I deploy the DNS solution, stating that DNS is authoritative, then
my a
On 1 okt 2010, at 20.59, Tony Finch wrote:
> On Fri, 1 Oct 2010, Joe Abley wrote:
>> On 2010-10-01, at 06:58, Tony Finch wrote:
>>
>>> What is the purpose of the historical information in the XML TA file?
>>
>> Debugging, context, historical record.
>
> Right, so it's aimed at human consumption
On 30 sep 2010, at 18.51, Stephan Lagerholm wrote:
> It is not clear if the validUntil time is referring to the time when the
> key is expected to be rolled into RFC 5011 revoked state or when it is
> expected to be removed from the zone.
Once the key is revoked, it is no longer valid and cannot
13 matches
Mail list logo
