[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Greg Hudson <ghudson@MIT.EDU>
cc: Key Distribution <keydist@cafax.se>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 12 Jun 2002 15:12:46 -0700
In-reply-to: Your message of "12 Jun 2002 17:56:26 EDT." <1023918986.595.436.camel@error-messages.mit.edu>
Sender: owner-keydist@cafax.se
Subject: Re: Global PKI on DNS?

> On Wed, 2002-06-12 at 13:37, Eric Rescorla wrote:
> > IKE and TLS both have slots in the protocols for the peers to pass out
> > the certificates. That's how it's supposed to be done. There's no reason
> > in either case for you go outside the protocol to get the key.
>
> TLS has a slot in the protocol for a server to pass out its certificate,
> but the server has no idea what CAs the client respects.  This works
> fine in a world where servers never have a reason to have certificates
> from more than one CA (as is the case with the web server PKI), but it's
> kind of limiting in a world with multiple viable authentication roots.
Sure. In practice, of course, servers are lucky to have even one
third party certificate, let alone multiples.

> I always found it kind of odd that TLS was asymmetric in this respect.
> Clients are told what CAs the server respects, but not the other way
> around.  What kind of allegedly generic security protocol makes the
> assumption that the client might need to know a fact about the server
> but not the other way around?
Yes, it is odd. In fact, I complained about this before TLS was
standardized :)

Anyway, one of the proposed extensions to TLS allows this kind of
signalling.

-Ekr




Home | Date list | Subject list