The best way to codify it is at the CAB forum since the CAB Forum language is 
the one that causes the problem (imo). We made a mistake by defining a 
precertificate as “not a certificate” when the intent was mostly to allow CAs 
to issue precertificates that had serial numbers duplicative with the actual 
certificate. I was thinking we should remove overly broad language and replace 
it with language that is more restrictive – something like all certificates 
must confirm to 5280 except precertificates which must conform to 6962. Needs 
work of course, but that was my initial idea.

From: Ryan Sleevi <>
Sent: Friday, August 30, 2019 12:58 PM
To: Jeremy Rowley <>
Cc: Jacob Hoffman-Andrews <>;
Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” 
for Some Precertificates

On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy 
Is our answer right though? I wasn't sure. I said "Good" because "a promise to 
issue a cert" could be considered the same issued. In that case the BRs say you 
must respond good.

Citation needed ;-)

However, if "a promise to issue a certificate" is not the same as issuance, the 
BRs don't apply to the OCSP until the certificate issues and the correct 
response is "Revoked" per the RFC.

That would be... inadvisable, as you'd be unrevoking a certificate, which would 
definitely Be An Issue (e.g. )

I definitely want to make sure any confusion is resolved. Can you point to any 
Mozilla policies or comms that use the phrase "promise to issue a certificate" 
so we can clarify? It's unclear to me if it's being used as an unfortunate 
shorthand (and special apologies if I've contributed to that).

RFC 6962, Section 3.1, phrases it as such:
   "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)."

(Some past discussion at

In various discussions, this has been attempted to be further clarified: If a 
precertificate exists, for all intents and purposes of all policy obligations, 
an equivalent certificate is presumed to exist, as the CA has signaled a 
binding intent to do so. As a consequence, regardless of whether or not we 
"see" the certificate, it should be presumed to exist, and the OCSP status and 
any other certificate services, databases, or other should be presumed to exist.

The BRs apply for sure to the contents, but do they apply to the OCSP responses 
in the time period between when the pre-cert is logged and the cert is signed.

Seems like a nice simple rule is that the promise to issue is issuance 
regardless of what the BRs say and that you should respond good. This was our 
logic and why we decided on "Good". However, a very strict reading of the RFC 
and BR interaction means you need to respond "Revoked" until the cert issues. I 
don't like that outcome because it's complicated and leads to confusion.

Agreed that it's nonsense, but I don't see how the strict reading can lead to 
that conclusion. There's more statuses than the binary Good/Revoked, and that's 
extremely relevant (and the BRs Have Opinions on which statuses you can and 
should use for certs you don't know about)

Despite all of the writing above, I'm too lazy to copy/paste my comment from 
the Let's Encrypt issue, but I would hope any CA contemplating things should 
look at in terms of a 
possible 'ideal' flow, and to share concerns or considerations with that. Even 
better would be CAs that have suggestions on how best to codify and memorialize 
that suggestion, if it's sensible and correct.
dev-security-policy mailing list

Reply via email to