[cryptography] PKI "fixes" that don't fix PKI (part II)

Ian G iang at iang.org
Thu Sep 8 09:49:23 EDT 2011


Hi, Lucky, good to see some perspective!

On 08/09/2011, at 8:52, Lucky Green <shamrock at cypherpunks.to> wrote:
> o Changes to OCSP
.....
> The
> problem was that the top three CA vendors at the time, RSA Security,
> VeriSign, and Netscape didn't have a comprehensive database of
> certificates issued by their software and were only able to generate
> blacklist-based CRLs. During the IETF process, OCSP was therefore
> redesigned as a bug-compatible front end to be fed by those CRLs.

Influence on institutional lines, or design on security lines?

Now, there is some merit in this, in that turning OCSP into an oracle of the certificate database has privacy and security consequences. But, read on...

> 
> But that's the best the majority of CA vendor products architecturally
> could provide at the time, which caused the IETF process to arrive at
> the "rough consensus" that became known as OCSP. The consequences of that decision are hounding us to this day. OCSP needs a redesign.

In this conclusion, I disagree, or at least wish to propose another conclusion & implied question.

IMO, it is revocation that needs a redesign. Not OCSP, and here's a small hint of evidence:

> Quoting myself here from those days: "learning in 80 ms that the
> certificate was good as of a week ago and to not hope for fresher
> information for another week seems of limited, if any, utility to us or
> our customers".


(order rearranged ;)

> o Static lists of trusted CAs

(I think I've noted elsewhere, this is revocation, but at a higher layer. Whatever we decide there, applies here. And, read on...)


> o Gobal CA

Yeah, but the train has already left that station.

In the beginning, vendors ran a "list" of roots. CAs applied and were added, no problem. It was just a list, right?

Over time, this migrated to a fully fledged governance operation with policies, reviews, contracts, liabilities, bureaucracies, delays, costs and recently, *revocation* .

In short, vendors are the new meta-CAs. They just haven't agreed to that as yet. However, IMO, this situation is embedded and developing, unstoppable. The train will reach that station soon enough.

> Also known as meta-CA, CA-CA, single trusted root, and "the turtle on
> which all other turtles stand",

Yes, we lack an agreed term.

(with a nod to peter's sense of humor, I  suspect the europeans and latin americans will find that CACA smalls ... )

> Until the next episode of "PKI "fixes" that don't fix PKI",

Thanks!


> --Lucky Green


Iang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20110908/cba7132b/attachment.html>


More information about the cryptography mailing list