On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote: <snip> > Here's some suggested wording for the last paragraph: > >> This means, for example, that (i) a CA must provide OCSP services >> and responses in accordance with Mozilla policy for all certificates >> presumed to exist based on the presence of a Precertificate, even if the >> certificate does not actually exist, and (ii) a CA must be able to revoke >> a certificate presumed to exist, if revocation of the certificate is required >> under Mozilla policy, even if the certificate does not actually exist.
[Speaking only for myself] Wayne, Andrew, Please treat this message as a sincere attempt both to understand what the current requirements actually are and to seek to clarify what the requirements should be. ISTM that this "certificate presumed to exist" concept doesn't play nicely with the current wording of BR 4.9.10: 'If the OCSP responder receives a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status.' If a certificate (with embedded SCTs and no CT poison extension) is "presumed to exist" but the CA has not actually issued it, then to my mind that's a "certificate that has not been issued"; and therefore, the OCSP 'responder SHOULD NOT respond with a "good" status'. However, this is Schrödinger's "certificate that has not been issued", because a Precertificate has been issued that has the same serial number (as the "certificate presumed to exist" that doesn't actually exist). And so at this point ISTM that the OCSP responder is expected to implement two conflicting requirements for the serial number in question: (1) MUST respond "good", because an unrevoked/unexpired precertificate exists (and because BR 4.9.9 mandates a signed OCSP response). (2) SHOULD NOT respond "good" (see BR 4.9.10). Clearly that's impossible, which leads to the question: Which of these two conflicting requirements should a CA ignore in order to be as un-non-compliant as possible? Which leads me to BR 220.127.116.11: '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' Since the first mention of "certificates" in the OCSP Protocol Overview (RFC6960 section 2) cross-references RFC5280, I believe that this 'shall not be considered to be a "certificate"' declaration can be assumed to extend to the OCSP requirements too. And therefore, the balance tilts in favour of implementing 'SHOULD NOT respond "good"' and ignoring 'MUST respond "good"'. I can't say I like this conclusion, but nonetheless it is the conclusion that my reading of the BRs forces me to reach. I realize that what the BRs actually say may not reflect precisely what was intended by CABForum; nonetheless, CAs are measured by what the BRs actually say. IDEAS FOR FIXING IT: Long-term: - In CT v2 (6962-bis), precertificates are not X.509 certificates, which removes Schrödinger from the equation. :-) Short-term: - I think BR 18.104.22.168, as written, is decidedly unhelpful and should be revised to have a much smaller scope. Surely only the serial number uniqueness requirement (RFC5280 section 22.214.171.124) needs to be relaxed, not the entirety of RFC5280? - I would also like to see BR 4.9.10 revised to say something roughly along these lines: 'If the OCSP responder receives a status request for a serial number that has not been allocated by the CA, then the responder SHOULD NOT respond with a "good" status.' P.S. Full disclosure: Sectigo currently provides an (unsigned) "unauthorized" OCSP response when a precert exists but the corresponding cert doesn't, but in all honesty I'm not currently persuaded that an Incident Report is warranted. -- Rob Stradling Senior Research & Development Scientist Email: r...@sectigo.com _______________________________________________ dev-security-policy mailing list email@example.com https://lists.mozilla.org/listinfo/dev-security-policy