On Mon, Sep 16, 2019 at 5:02 AM Rob Stradling <r...@sectigo.com> wrote:
> On 14/09/2019 00:27, Andrew Ayer via dev-security-policy wrote: > <snip> > > 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). > > 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) 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. 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] - 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: > '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 > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
