Stephen Kent wrote:
At 10:53 AM -0700 6/17/02, Ed Gerck wrote:
Stephen Kent wrote:
<snip>
If I am a member of multiple communities, and if I have a cert issued by
each community for use in its context, I don't need to communicate AMONG
the communities, just within them.
Why restrict how you/I/we can communicate? The technical system should not
pass its limitations as features.
We're not talking about a communication restriction. We're talking about
whether credentials that attest to my identity in one community are
meaningful in another community. I have an ISOC member card. It identifies
me uniquely via my member number. So does my ACM card. So does my video
rental card. None of these ID numbers is useful outside the community in
which it was issued. The same would be true for certs issued by these folks
acting as CAs for their respective communities.
There is value in cross-identification and in mulit-identification. To get into
a private plane,
today, most people show their state issued driver'license. To open a bank
account, you
need to have two different IDs -- which are not even issued by the bank. There
is also
value in cross-communication. IMO, isolated communities of interest are a
PKI-bug, not a
communication feature.
<snip>
But, my point is that a DNS name is just what it is, nothing more, and we
rely on these names every day, for better or worse. So, why not make this
reliance more secure?
I thought we were talking about using the DNS to host a PKI, not about making
the DNS more secure. These are two separate issues.
Making the DNS more secure needs IMO to address a whole different, and
thornier, set of issues. In this regard, I find the DNSSEC
approach to be insufficient because you cannot build a safe superstructure on a
faulty infrastructure (the DNS itself).
It is a lot simpler to propose using the DNS for authenticated public key
distribution -- and this has been done before [RFC 2065].
But key distribution, unlike key certification, requires notions of revocation,
compromise recovery, and management of risk to
compensate for inadequate or costly procedures of key distribution -- which
questions are not even considered. And it is awkward to
have the key and the parent's signature residing in the child's zone; this may
lead to very complicated procedures for large TLD's
and over time. An alternative scheme has been proposed in which the parent zone
stores the parent's signature over the child's
key and also a copy of the child's key itself, but how about revocation?
Additional questions arise, as I was trying to motivate. For example, PKI
cannot scale under a single root, which is what the DNS model
has to offer. To work as an infrastructure (beyond your club's solipsistic
needs) , a PKI needs to work with multiple roots. So, what PKI
needs DNS cannot offer. Also, DNS names form an ontology where a child's zone
can and does change independently of the parent's
control, whereas PKI's path discovery relies on top-down control. Using the
example noted by Eric Hall some postings before, having
different registries controlling domains in the same TLD at any given moment
brings a whole new set of issues. If the registry operator
for a TLD domain changes, would the private key linked to the TLD also need to
be changed?
IMO, the DNS can be used with great care and no reliable revocation as a
distributed locator for a self-signed or PKI root certificate
associated with a domain. Just like anything we can put in the TXT record.
But the DNS cannot be used as basis for a PKI --
with an "I" for infrastructure.
Just my opinion.
Cheers,
Ed Gerck