I find and hear a few non conclusive, sometimes contradictory, messages about 
OCSP responder handling of pre-certificates without final certificates. Reading 
this thread I don't find a firm conclusion either (albeit I may have missed it).
I'm not saying anything others have not said before, so I don't claim to say 
anything new, just to summarize what I believe to be a safe behavior.

(I'm merely interested in the technical behavior of an OCSP responder)

My position dates back to 2013 during CT implementation. Discussions back then:
"a Precertificate is arguably not a Certificate".
as well as:
"The precertificate contains a critical extension that no verifier should 
understand, and therefore will not verify."

In combination with RFC6960 (introduction):
"The Online Certificate Status Protocol (OCSP) enables applications to 
determine the (revocation) state of identified certificates."

and Ballot 80:

For an OCSP server a query is neither for a "pre certificate" nor a 
"certificate", the OCSP responder just sees an issuer (hash) and a serial 
number. It's a query for revocation status about the issuer and serial number 
pair passed in the request.

>From this my conclusion was, and still is:
- A pre certificate is not an issued certificate in the Web PKI. As such an 
OCSP responder should answer "anything but good" for this issuer/serialnumber 
combination if a "real" certificate has not been (yet) issued.

>From a RP perspective, any RP that queries OCSP during an attempt, with 
>intent, to use a pre certificate (with poison extension) is broken and the 
>only safe goal is to try to prevent this RP from using the pre certificate. 
>Again my conclusion is that the safe way is to answer "anything but good".

For OCSP there are at least two corner cases here:
1. A pre certificate has been issued, but the real certificate has not and 
never will be
2. There is a time gap period between the issuance of the pre certificate and 
the real certificate

For 1, the "intended to be issued" certificate should be revoked asap in any 
case, so "anything but good" is the proper answer.
For 2, there is a short period where someone monitoring log servers may 
discover the pre certificate and poison any OCSP response cache by querying for 
this issuer/serial (getting a "anything but good" for the not yet issued real 
certificate). After cache expiry the response will be good. The same can happen 
by shotgunning the OCSP responder with random serials, albeit it's hard to hit 
a "real" upcoming serial number in the >64bit random serial number space, or if 
there is a delay between releasing the real certificate and fully distributing 
it to OCSP responders. When direct updates to OCSP is used this periods is 
measured in seconds maximum, and milliseconds optimally.

Making a long story short:
- I belive answering "anything but good" is a proper answer for pre 
certificates (issuer/serialno) where no real certificate was issued or 

Did I miss anything?

dev-security-policy mailing list

Reply via email to