Re: Global PKI on DNS?

At 11:30 AM -0700 6/14/02, Ed Gerck wrote:
> Stephen Kent wrote:
>
> >  <snip>
> >  Could you elaborate, perhaps privately, with why you believe a "true
> >  PKI" needs multiple roots?
> >
> >  <snip>
> >  My view is that too many
> >  folks have tried to get too much out of any single PKI, and that has
> >  caused a lot of our headaches. if we admit to the need for many PKIs,
> >  each serving a well-defined user community, then I think each of
> >  these PKIS would be easier to create, manage, and deal with from a
> >  liability standpoint.
> Steve:
>
> You have answered your own question above. As you say,  folks have
> tried too much out of a single PKI and failed. That is why a true PKI (ie,
> one that works as an infrastructure) would need to include many PKIs.
> Each one of these "many PKIs" represents one root, with multiple
> PKIs creating multiple roots. Now, unless you want each one of these
> many PKIs to be isolated -- and not create an infrastructure --  there
> is a need for cross-certification allowing users of one PKI community
> to talk to users of another PKi community. In DNS parlance, you need to
> find AND validate routes among multiple roots.
I see what you mean by a "true" PKI, but I don't want one :-)

My examples of disjoint credential spaces in the physical world are 
not unified and they ought not be.  There usually is no incentive for 
the issuers to cross certify in most cases for these separate roots, 
and it creates new liability concerns, and raises trust issues.
>  > if I look in my wallet, I have a lot of credentials, each issued by a
> >  different organization. Each is useful only in certain contexts. Each
> >  tends to uniquely identify me via a number of some sort and often
> >  that number is meaningful only in the context for which the
> >  credential was developed. We would be in pretty good shape if we had
> >  PKIs that parallel these paper and plastic credentials.
> Agreed. The fundamental problem is that the PKI architecture cannot
> directly provide mutiple root functionality. You need to overlay bridge
> CAs and other artifacts in order to create the paths.  Now, imagine a
> different mathematical structure, one that is not based on a hierarchy
> and yet works with hierarchical systems (as well as non-hierarchical
> systems liek a peer-to-peer network). Such structure could allow paths
> to be found, and validated, from one hierarchy (PKI, DNS) to another
> (PKI, DNS).
I disagree; PKIs can accommodate multiple roots. Mesh certification 
is and old concept (intrinsic in X.509), but it is way too complex 
for most (if not all) folks to comprehend and manage. I always point 
to the inability of people to program VCRs as an example of a lower 
bound for people's tolerance of complexity. Mesh PKIs go way beyond 
VCR programming.
> Someone may add that the DNS is not really a hierarchy, it is just an
> ontology.  My argument still holds for ontologies and also applies
> to how names are used in PKI certificates (as I have discussed
> elsewhere, see google). A certificate is just an authenticated assertion
> made within the context of a name space. The name space in a PKI
> forms an ontology and that ontology  is defined by name space
> ownership, just like in the DNS.
I don't know who would argue that the DNS is other than a singly 
rooted tree, but I think we are in agreement re what a cert is.
>  > The security
> >  would be better and with good software, the convenience would be
> >  better for users.  Trying to create a single PKI that issues a cert
> >  that replaces all of these credentials is just not going to work.
> Agreed again. What we may see, because it is the only thing that will
> work, are small PKIs using the DNS as a "directory".  These PKIs do
> not need to interoperate and so they will be useful.  But one will not
> see a single PKI that issues certs for all the DNS space.  For that we
> would need a different beast.
I don't think you've substantiated the last part of the above assertion.


> Cheers,
> Ed Gerck
>
> PS: IMO the PKI market has been grossly exaggerated.  There are only
> 30,000 servers worldwide that can do SSL -- which limits PKI server certs
> to that number worldwide, with a factor for virtual server usage. PKI
> client certs have the private key problem, that cannot be solved by
> PKI, and has not really taken off (except for military apps, with smart
> cards controlling access to the private key).  And I am not the only
> saying that PKI is at a dead end.  Which is good -- because now
> perhaps some serious consideration will be given to solutions.
> PKI is not dead, though. It is just at a dead end.
I used to be CTO for a PKI product/service vendor and my recollection 
is that there were many more certs issued for a variety of 
applications than the number of server certs you allude to above. SSL 
is not the only game in town. Also, my biggest problem with client 
certs for SSL is the lack of easy means of synchronizing them among 
my destop at work,  at home, and my laptop. Compared to the 
alternative of using passwords for the many web sites that require me 
to login, I see no need to go beyond software protection of these 
private keys.