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

[Rob Stradling]

On Friday 09 Sep 2011 10:44:05 Erwann ABALEA wrote:
> 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.

I think "Good" would be the best match.  There would need to be a note to 
explain that the profile reinterprets "Good" as "Not Revoked; Has Known Serial 
Number".

> True, asking for revocation status for an expired certificate is stupid.

For Server Authentication Certs, yes, it's a bit stupid.  You generally only 
care if the cert is revoked right now.

For certain other types of cert (e.g. Code Signing Certs), no, it's not 
stupid.  You might want to know if the certificate (now expired) was revoked at 
some particular time in the past (before it had expired).

<snip>
> >  - 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? :)

Sure.  So perhaps my suggested "profile" I-D should have an increased scope of 
"Hardened Revocation Checking for the Internet".

<snip>
> >   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?

I understood Peter's definition of "blatant violation" to be disallowing 
anything that RFC2560 allows.  RFC2560 allows non-SHA-1 algorithms for 
issuerName/KeyHash; RFC5019 doesn't.

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online