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