[cryptography] Diginotar Lessons Learned (long)

Peter Gutmann 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?

Peter.



More information about the cryptography mailing list