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

[Erwann ABALEA]

2011/9/9 Rob Stradling <rob.stradling at comodo.com>:
[...]
> If it's not been done already, it might be an interesting exercise to write an
> I-D called something like "The Hardened OCSP Profile for the Internet".  This
> I-D could say things like:
>  - Responders MUST NOT report "good" for a serial number that is not known to
> have been put into a legitimate certificate.

What can be answered to a request for an expired but not revoked
certificate? "Good" or "Revoked" are unacceptable, "Unknown" is also
false (the CA *knows* the state), and every other answer is not
signed. True, asking for revocation status for an expired certificate
is stupid. But such a request can be done, so an answer must be
provided.

>  - Clients MUST hard-fail when they cannot obtain signed certificate status
> information.

"certificate status information" is not only an OCSP answer, a
fallback to CRL is acceptable. After all, if we can't trust X.509
certificates and X.509 CRLs, then why bother with X.509 anyway? :)

>  - Responders MUST include a hash of each certificate in a newly defined
> SingleReponse Extension.

I'll add an item:

 - Responders MUST NOT provide a response without a nonce if the
request contained a nonce

[...]
> [1] Here are a few of the "blatant violations" of RFC2560 that are present in
> RFC5019 (The Lightweight OCSP Profile for High-Volume Environments):
[...]
>   Clients MUST use SHA1 as the hashing algorithm for the
>   CertID.issuerNameHash and the CertID.issuerKeyHash values.

Well. This is not really a "blatant violation". What if the client
chooses some unusual hash algorithm? Should the responder have a list
of all possible issuerKeyHash and issuerNameHash under different hash
algorithms?

-- 
Erwann.