Re: Global PKI on DNS?

[Greg Hudson <ghudson@MIT.EDU>]

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.

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?

I'm not sure if the right answer to this problem is to paper over it
with a DNS lookup service ("I don't like this certificate, I'll go look
for a new one") or if that can even work.  But there certainly is a
problem.

(S/MIME has a similar problem in a world with multiple roots.  If I'm an
organization like CERT and I'm certified to hell and back, do I send out
all of my certificates with every mail message?  That's prohibitive.  As
you've noted, though, it's not clear whether it's worth solving problems
in S/MIME.)