On 16/09/2019 23:58, Wayne Thayer wrote: > On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling wrote: <snip> > 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). > > If I'm reading BR 4.9.10 correctly, the situation is worse because it > goes on to state "Effective 1 August 2013, OCSP responders for CAs which > are not Technically Constrained in line with Section 7.1.5 MUST NOT > respond with a "good" status for such certificates." (referring to > 'certificates that have not been issued' from the prior paragraph)
Thanks Wayne. You're right. (I read the "SHOULD NOT" requirement, forgot it had been superseded, and didn't read further. I wonder if it would be reasonable to remove the superseded requirement from the BRs now, given that it was superseded over 6 years ago?) > If the desired outcome is for CAs to respond "good" to a precertificate > without a corresponding certificate, we could override the BRs in > Mozilla policy, but I'd want to get the BRs updated quickly as Rob > suggested to avoid audit findings. +1 > The other piece of this policy that's still unclear to me relates to the > "unknown" OCSP status. Specifically, Is it currently forbidden for a CA > to provide an "unknown" OCSP response for an issued certificate? If not, > should it be? The implication here would be that CAs responding > "unknown" to precertificates without corresponding certificates are > doing the right thing, despite prior precedent indicating that this is a > violation. [1] This is making my brain hurt. > - Wayne > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1551390 > > 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 7.1.2.5 > <http://7.1.2.5>: > '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 7.1.2.5, as written, is decidedly unhelpful and should > be revised to have a much smaller scope. Surely only the serial number > uniqueness requirement (RFC5280 section 4.1.2.2) 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 <mailto:r...@sectigo.com> > -- Rob Stradling Senior Research & Development Scientist Email: r...@sectigo.com Bradford, UK Office: +441274024707 Sectigo Limited This message and any files associated with it may contain legally privileged, confidential, or proprietary information. If you are not the intended recipient, you are not permitted to use, copy, or forward it, in whole or in part without the express consent of the sender. Please notify the sender by reply email, disregard the foregoing messages, and delete it immediately. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
