[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

[Erwann ABALEA]

2011/9/6 Peter Gutmann <pgut001 at cs.auckland.ac.nz>:
> Erwann ABALEA <erwann at abalea.com> writes:
>
>>This RFC *is* broken.
>
> It's broken in more ways than just that,

Yes, identifying an issuer by the hash of its DN (considering X.5xx
name comparison rules) or the hash of its public key (often
misunderstood as the SKI of the issuer certificate) is also a wrong
idea, and absolutely not in accordance with X.509. On that point, I
doubt it can be considered "an expression of X.509 dogma".

> and then the brokenness got extended
> by Verisign's "high-performance OCSP" (since adopted by pretty much every
> other CA) which allows the CA to replay an old response to the client.

But the client can include a nonce in the request and compare it with
the response (I haven't tested a lot of CAs for OCSP compliance, so I
don't know how many of them follow RFC5119 -TODO: check the RFC
number- and suppress the nonce in the response). The client can also
look at the date of the answer, and decide if it's too old for it to
be acceptable.
Caching the responses is a good thing, to limit DOS attacks.

Before 2004 (I don't know after this date, as I don't operate their
software anymore), VeriSign software didn't produce CRL based OCSP
answers, but only database based ones. Maybe its still the case and
the reason why it answers "unauthorized" when checking the expired
"www.ietf.org" certificate, by lack of an "expired" status code.

> So you
> don't even need to directly attack OCSP any more, just grab a "not-revoked"
> response, impersonate the CA to the client, and whenever they ask for a
> status, replay the old not-revoked response.

And if it doesn't fit the client request, or not within the client
"good timeframe", this response will be discarded. Then, depending on
the client, this will be a hard fail, or a switch to CRLs.

>>The idea is good, though.
>
> Not really.  It's based on such a toxic combination of broken ideas
> (blacklisting, muddled, non-orthogonal status codes, inapprorpriate cert IDs,
> not authenticating parts of the response, a schizophrenic trust model, etc
> etc) that you'd really need to start again in order to get it right.

The main idea is to have light revocation responses. Having worked
with *big* CAs with *big* CRLs, I know it's not workable at all.
Following X.509, if you want to have smaller CRLs, you either have to
partition the CRL (different methods) and hope the relying party will
support this, or partition the CAs.

-- 
Erwann.