You’re right. It could be any of the responses under RFC 6960. From: Alex Cohn <a...@alexcohn.com> Sent: Friday, August 30, 2019 7:22 PM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: Jacob Hoffman-Andrews <j...@letsencrypt.org>; mozilla-dev-security-pol...@lists.mozilla.org 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 <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: 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<https://crt.sh/?id=1827579322&opt=ocsp>" and NetLock "malformed<https://crt.sh/?id=1826448700&opt=ocsp>", which is...curious. Alex _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
