>From RFC6962:

“As above, the Precertificate submission MUST be accompanied by the 
Precertificate Signing Certificate, if used, and all additional certificates 
required to verify the chain up to an accepted root certificate.  The signature 
on the TBSCertificate indicates the certificate authority's intent to issue a 
certificate.  This intent is considered binding (i.e., misissuance of the 
Precertificate is considered equal to misissuance of the final certificate).  
Each log verifies the Precertificate signature chain and issues a Signed 
Certificate Timestamp on the corresponding TBSCertificate.”

>From of the baseline requirements:
“For purposes of clarification, a Precertificate, as described in RFC 6962 – 
Certificate Transparency, shall not be considered to be a “certificate” subject 
to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure 
Certificate and Certificate Revocation List (CRL) Profile under these Baseline 

>From 6960:
   The "good" state indicates a positive response to the status inquiry.  At a 
minimum, this positive response indicates that no certificate with the 
requested certificate serial number currently within its validity interval is 
revoked.  This state does not necessarily mean that the certificate was ever 
issued or that the time at which the response was produced is within the 
certificate's validity interval. Response extensions may be used to convey 
additional information on assertions made by the responder regarding the status 
of the certificate, such as a positive statement about issuance, validity, etc.

   The "revoked" state indicates that the certificate has been revoked, either 
temporarily (the revocation reason is certificateHold) or permanently.  This 
state MAY also be returned if the associated CA has no record of ever having 
issued a certificate with the certificate serial number in the request, using 
any current or previous issuing key (referred to as a "non-issued" certificate 
in this document).

   The "unknown" state indicates that the responder doesn't know about the 
certificate being requested, usually because the request indicates an 
unrecognized issuer that is not served by this responder.”

Mozilla Policy:

1.  Does not define a precertificate. Instead Mozilla policy covers everything 
with serverAuth (1.1)

2.  Requires functioning OCSP if the certificate contains an AIA (5.2)

3.  Must provide revocation information via the AIA for the cert (6)

Argument for responding “Good”:
A pre-certificate is a certificate and contains an AIA. Per the Mozilla policy, 
the CA must provide services. Providing revoked or unknown is incorrect because 
the pre-cert did issue. Although the BRs define the pre-cert as out of scope of 
the BRs for CRLs and 5280, that just means the serial number can repeat. 
Responding anything other than good would provide wrong information about the 
status of the pre-cert.

Argument for responding “Revoked”, “Unknown”, or “Invalid”:
A pre-certificate is not a cert. The BRs define it as a not a cert as does RFC 
6962. A pre-cert is an intent to issue a certificate. RFC6960 specifically 
calls out that the CA may use revoke as a response for certificates without a 
record of being issued and unknown where there isn’t a status yet. Although the 
Mozilla policy is silent on the status of whether a pre-cert is a certificate, 
section 2.3 incorporates the baseline requirements. As such, the Mozilla policy 
implicitly defines a precertificate as “not a certificate”. Because it’s not a 
certificate the OCSP service does not know how to respond so any response is 
okay because there is no certificate with that serial number until the ‘intent 
to issue’ is fulfilled.

Note that even if you argue that “revoked”, “invalid”, or “unknown” are 
appropriate, the RFC still permits “good” as a response because no certificates 
with that serial number are revoked. Good is the safe answer.

From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on 
behalf of Tomas Gustavsson via dev-security-policy 
Sent: Saturday, August 31, 2019 5:01:42 AM
To: mozilla-dev-security-pol...@lists.mozilla.org 
Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates


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
dev-security-policy mailing list

Reply via email to