At 1:43 PM -0400 6/13/02, Keith Moore wrote: > > A PKI modeled on the DNS would parallel >> the existing hierarchy and merely codify the relationships expressed >> by it in the form of public key certs. > >so what you're saying is that the cert would mean something like: > >"we certify that this key was supplied by a party who gave us money >in exchange for our assigning domain name x.y to it. we have no >idea who that party really is, whether it is trustworthy, and >in particular whether that party can be trusted to manage its keys >in such a way as to make compromise unlikely. for that matter, >we're not even entirely sure whether the party that gave us money >for this domain last time it was renewed was the same as the party >that gave us money for the domain in the past. for that matter, >we didn't get the money directly from that party, we got it from >a registrar who you may or may not be able to trust either. you're putting words in my mouth, and they're not especially good words :-). >and for that matter, you have no idea whether we are trustworthy. >we could be making all of this up, and in fact we're so large and >control the trust relationships to so many domains that there is >a fair amount of incentive for us to do exactly that under some >conditions, but we won't tell you want those are but you should >trust us anyway, because we said so" Why does everyone keep thinking that explicit trust is an essential element of every PKI? A CA that attests to the accurate binding of a DNS name to an entity is making NO assertions about the trustworthiness of that entity! It is just asserting that the private key corresponding to the public key in the cert is held by the entity, period. Whether that entity does a good job of protecting the private key is not known to the CA (that's generally true in ANY PKI anyway). A modest, realistic ambition for a DNS-based PKI would be to improve the security of the binding between DNS entries and the associated machines. That would help with the deployment of all major security protocols that use certs: TLS/SSL, S/MIME, and IPsec. It would enable organizations to more readily create extranets and intranets using these security protocols. Note that, with the possible exception of S/MIME, the other protocols do not support non-repudiation, and so some of the stickier legal issues associated with the use of certs do not necessarily arise. Even for S/MIME, one can distinguish between messages signed for authentication vs. for NR purposes. Steve