[email protected] writes: > | It has been suggested that we need a kind of meta-CA or CA for CAs (CACA). > | Then the browser vendors could code CACA into the browsers, and we'd all be > | trusting in CACA. > | > | Or maybe we already are. > >Peter (or anyone) -- would you comment on the existence and practice of >"bridge CAs" please?
I thought I'd already done that :-). A slightly longer discussion (unfortunately without some of the diagrams that point out the issues) is: Even without resorting to such extreme cases, this simple process can become almost intractable in the presence of something called cross-certification in which CAs in disjoint hierarchies cross-certify each other [ ]. What this means in practical terms is that CA1 signs CA2.s key and CA2 signs CA1.s key. This creates a serious problem because X.509 was designed as a strict hierarchy with each certificate having exactly one issuer, only now it has two, the original issuing CA and the new cross-certifying CA (or even multiple cross-certifying CAs). As a result of this cross-linking there can now be multiple certificate paths leading from a given leaf certificate, all with different semantics. Certificate paths can now contain loops, and in extreme cases the semantics of a certificate can change across different iterations of the loop [ ] (whether certificate paths are Turing-complete is an open problem). Cross- certification turns the hierarchy of trust into the spaghetti of doubt, with multiple certificate paths possible from leaf to roots, as shown in Figure 153. Unfortunately the use of cross-certificates is currently being advocated as a means of tying together disparate PKI projects [ ][ ][ ][ ]. An alternative to cross-certification called bridge CAs [ ], initially known as overseer CAs when they were developed for the Automotive Network Exchange (ANX) program and which were in turn based on even earlier pre-PKI work on inter-realm authentication [ ][ ][ ][ ], avoids this problem to some degree by adding a single super-root that bridges two or more root CAs. A far more pragmatic solution, adopted by virtually all PKIs (with a few notable exceptions like US federal PKI designs, which were driven by PKI theoreticians who were happy to have a well-funded customer to experiment on) is to avoid this like the plague and only use a single hierarchy. >Extra credit (as in "thank you") for its plausible role in public clouds. If you avoid it like the plague, you should be OK. Do I get my biscuit now? Peter. _______________________________________________ cryptography mailing list [email protected] http://lists.randombit.net/mailman/listinfo/cryptography
