> > 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