Keith Moore 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. 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.
We're already trusting chains of signficant length (i.e. DNS delegation)
with no decent verification at all. I presume I'd be prepared to trust
certificate chains of that kind of length for those kind of purposes
even more than I trust the current system.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html http://www.thebunker.net/
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff