[cryptography] Diginotar Lessons Learned (long)
pgut001 at cs.auckland.ac.nz
Fri Sep 9 20:49:01 EDT 2011
dan at geer.org 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?
More information about the cryptography