You’re right. It could be any of the responses under RFC 6960.

From: Alex Cohn <>
Sent: Friday, August 30, 2019 7:22 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 10: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. 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.

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.

It seems reasonable to me to assume that if the contents of a precertificate 
are in-scope for the BRs, the OCSP responses would be likewise in-scope.

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".

I agree. A CA cannot prove they didn't issue the final certificate. Given 
existence of a pre-certificate, it is reasonable for a relying party to assume 
that the final certificate exists and therefore that OCSP services will be 
functional. I personally would view arguments such as "we didn't actually issue 
that, so we don't need to provide sane OCSP responses" with a great deal of 
skepticism, especially from CAs that do not automatically CT log their final 
certificates (nudge nudge DigiCert, Amazon, Entrust).

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.

Looking at sections 2.2 of RFC6960 and 4.9.10 of the BRs, I don't see the 
requirement to respond "revoked" for unknown or non-issued certificates - can 
you explain further? 4.9.10 forbids replying "good" for non-issued 
certificates, but I don't see any stipulations surrounding replying "unknown." 
The certificateHold + 1970-1-1 revocation date method of indicating a 
non-issued certificate in 6960 2.2 might be forbidden by an especially strict 
reading of BRs 4.9.13, but it's not mandated by 6960. In the absence of a 
precertificate signing certificate, OCSP queries for precertificate and 
certificate are identical, so it could be argued that the precertificate itself 
means it's not a "non-issued" certificate?

From a RP's perspective, I can easily envision problems resulting from an OCSP 
response for a given serial number transitioning from revoked to good, 
especially if the response is cached by the relying party or a proxy.

It also occurred to me that CAs using a precertificate signing certificate 
(e.g. Trustwave or NetLock) would be able to differentiate OCSP requests for 
precertificates from final certificates. How do these CAs handle OCSP for 
precertificates? Trustwave appears to always answer 
"unauthorized<>" and NetLock 
"malformed<>", which is...curious.

dev-security-policy mailing list

Reply via email to