Stephen Kent wrote:
> 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.
OTOH, it is a problem if you want to talk outside of your gopher hole ;-)
>
> Ed Gerck wrote:
> 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.
Certainly, as well as the explanation why "mesh certification" does not work.
To begin, consider that a certified end-user key exists to establish assurance
in the authenticty of the keying material; certification is the process for
effecting such assurances.
However, more generally, a certification chain can exist whose purpose
is to 'distribute the (asymmetric) key". 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..
In such a simple theory, key certification validity is not a overly-variable
quantity: the degree of variability is limited to the "legal fact" (affirmative
fact exists, or does not exist) established when a using party ("relying
party"?) *accepts* it, or not, as useful.
The systemic purpose of key distribution is to provide a "metric space"
whereby many procedures, which handle certification chain(s), may be
(multiply) used to measure whether a given asymmetric key pertaining to
an end-user is indeed useful, or not. The metric is an expression of
relative certainity for a specific security problem, and application
context, given all available knowlege of the operational vulnerablities.
Try www.mcg.org.br/cie.htm , which uses such a geometric model for
certification to show that PKI certification must depend on an external
reference *even though* the external reference "cancels out" in the final
result.
> >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,
The DNS names do not have the same hierarchy that one associates
per X.509/X.500 witth a DN. The DNS is less than a single rooted tree
because there are no neccessarily hierarchical dependencies, just
hierarchical placements.
> 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.
For a theory, see the reference cie.htm above. But let me try by a negative
example. There is not a single example of a PKI -- even on paper -- that can
work with multiple, *indepedent* CA roots. Of course, if the CA roots
are not independent then they are not multiple.
>
> Ed Gerck wrote:
> >
> >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.
Eric already allowed me to stress that the number I cited was given for
"servers" and not for web sites. For web sites, the number was
over 140,000 in October 2001. Now, should we discuss whether $1/day
is much better than $0.1/day for a person to live on, or should we just
say that both are far too small? Likewise, the number of SSL servers
out there is far too small to support so many CAs and much hype.
Cheers,
Ed Gerck