"RL 'Bob' Morgan" <rlmorgan(_at_)washington(_dot_)edu> writes:
On 12 Jun 2002, Eric Rescorla wrote:
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.
Yes, because it's an edge case. TLS certificate chains almost always
end either implicitly or explicitly in self-signed certs, which you
either trust or you don't. Trying to chain to some other root is highly
unlikely to work.
We barely have any PKI at all, I think it's a little early to start
worrying about cross-certification.
-Ekr
--
[Eric Rescorla ekr(_at_)rtfm(_dot_)com]
http://www.rtfm.com/