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.
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).
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.
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.
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.