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