Re: Global PKI on DNS?

At 7:12 PM -0700 6/17/02, Ed Gerck wrote:
> 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.
Your example does not require cross-certification. It only requires 
that the relying parties be members of, or have access to the (CA) 
credentials for, the communities to which the individuals belong. 
Cross certification is one way to accomplish this, but it is not the 
only way.
> > <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).
Ultimately, DNS is not the focus of security, even for DNSSEC. If we 
implemented DNSSEC and did not use crypto-secure protocols to protect 
connections we would still be vulnerable to spoofing of those 
connections. We need to use protocols like IPsec or TLS to effect 
secure communications. But, if we had certs tied to DNS names, we 
would not require DNSSEC as a separate mechanism for this purpose, 
although it would serve some other security purposes.
> 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?
yes, it is much easier to just use DNS to store certs from some set 
of CAs, but without an answer about who those CAs are, we have just 
postponed the problem, not solved it. The old DNSSEC design was 
flawed re where the records were stored, but that problem does not 
arise if one stores certs, so let's not go down that rat hole. 
DNSSEC also does not address revocation very well, but if one stored 
certs in the DNS, then oue could also store CRLs, which addresses the 
revocation question you raise.
> 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?
You keep asserting that a single root does not permit scaling, but I 
have yet to see a good argument supporting that assertion. In part 
this seems to result from your approach to defining a PKI, a 
definition not consistent with most others in the literature. In 
response to your concrete question, yes, if the organization 
controlling a TLD changed, then new certs would have to be issued to 
the next tier of domains. But, this can be done unilaterally, by the 
new TLD operator. Yes, it would take effort, but we're not talking 
about a sudden, unexpected change.
> 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.
I agree that one could do that with the DNS, and we have had specs 
for how to do it for some time. But, it does not address the harder 
problems we face re secure identification of DNS-named entities.
Steve