Stephen Kent wrote:
At 10:53 AM -0700 6/17/02, Ed Gerck wrote:There is value in cross-identification and in mulit-identification. To get into a private plane,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.
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>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.
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?
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