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


To: "RL 'Bob' Morgan" <rlmorgan@washington.edu>
cc: Eric Rescorla <ekr@rtfm.com>, openssl-users@openssl.org, ietf <ietf@ietf.org>, isdf@isoc.org, Key Distribution <keydist@cafax.se>
From: Keith Moore <moore@cs.utk.edu>
Date: Wed, 12 Jun 2002 12:19:17 -0400
In-reply-to: (Your message of "Wed, 12 Jun 2002 08:11:07 PDT.") <Pine.LNX.4.44.0206120759270.13466-100000@perx.cac.washington.edu>
Sender: owner-keydist@cafax.se
Subject: Re: Global PKI on DNS?

> > Nearly all of the major IETF security protocols (TLS, IPsec, OpenPGP)
> > already have their own certificate discovery mechanism and therefore
> > have no need to have certificates in the DNS. TLS, in particular,
> > wouldn't know what to do with them if they were there.
> 
> This is missing the point.  Sure, TLS provides the ability for both
> clients and servers to send certificate chains to their peers as part of
> session startup.  But what happens if I'm a client, and the chain the
> server sends me ends in a cert that I don't know about?  I *might* be able
> to construct a path from one of my trusted roots to one of the certs in
> the path it sends me, and hence be able to validate the whole chain and
> hence successfully start the session, instead of failing.  But I can do
> this only if I can discover certs that *aren't* either in the set it hands
> me or in my local set, and TLS says nothing about how to do this.  That's
> the problem that people would like to solve to enable more scalable PKI;
> it can't be handwaved away.  I'm not particularly a fan of using DNS for
> this, but discovery remains important.

I don't want to discount the importance of cert discovery, but I do
think it's a stretch to believe that you're going to be willing to 
trust all of the certs that you discover in a chain of significant
length, for a significant set of purposes.

Keith

Home | Date list | Subject list