Stephen Kent wrote:
> At 2:29 PM -0700 6/14/02, Ed Gerck wrote:
> >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 ;-)
>
> I anticipate belonging to a lot of communities (PKIs), just as I do today.
and you anticipate having the same problems to communicate among them ;-)
Instead, why not solve the problems ...
>
>
> > >
> >> 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.
>
> right
>
> >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..
>
> I don't understand this. Because certs are signed, distribution is
> relatively easy, e.g., I can store them and transmit them with
> relative ease. I don't need to issue certs just to distribute keys.
> Even for revocation this is true, if one uses CRLs.
Yes, it does look easy doesn't it? But what the text above asks is
what is the merit/value of key distribution if notions of revocation,
compromise recovery, and management of risk are NOT taken into
account.
>
> >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.
>
> Oh, let's not bring legal issues into this. I don't consult my
> general counsel about the length of passwords or the mandated
> frequency of change, etc. when we're putting in place systems to
> authenticate users. If we refrain from trying to make too much out of
> a PKI, we ought to be able to do the same thing.
There are no legal issues. Note the double quotes -- what is meant
here is that there really is a need for evidence supporting the assertion.
>
> >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.
>
> I don't agree. I looked briefly at your reference (cited below) and
> it begins by arguing about the difficulty of naming things uniquely
> in the Internet. But in the DNS context, this is a solved problem, so
> I don't think the extensive analysis you provide is applicable here.
;-) there is not such beginning. Either you did not reach the correct
site/paper or you need to read it.
> >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.
>
> Huh? Both DNS and X.500 use hierarchic names allocated in a
> distributed fashion from a singly rooted tree. We have a convention
> for how to map DNS names to DNs, using the DC attribute. I do not
> understand the phrase "there are no neccessarily [sic] hierarchical
> dependencies, just hierarchical placements"
Apparently, you believe that DNS names are X.500 names are somehow
similar ("use hierarchic names allocated in a distributed fashion from a
singly rooted tree'). They are not -- DNS names do not to a hierarchy
belong.
Cheers,
Ed Gerck