I have gone ahead and added a section titled "Precertificates" [1] to the Required Practices wiki page.
I have also updated a policy issue [2] suggesting that this be moved into the Root Store policy, and added a new issue [3] suggesting that we clarify the acceptable use of the "unknown" OCSP response. I plan to sponsor a CAB Forum ballot to resolve the inconsistency with BR 7.1.2.5. - Wayne [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates [2] https://github.com/mozilla/pkipolicy/issues/138 [3] https://github.com/mozilla/pkipolicy/issues/189 On Tue, Sep 17, 2019 at 6:10 PM Wayne Thayer <wtha...@mozilla.com> wrote: > Version 3 of my proposal replaces Jeremy's suggested examples with Andrew > and Ryan's: > > The current implementation of Certificate Transparency does not provide >> any way for Relying Parties to determine if a certificate corresponding to >> a given precertificate has or has not been issued. It is only safe to >> assume that a certificate corresponding to every precertificate exists. >> >> RFC 6962 states “The signature on the TBSCertificate indicates the >> certificate authority's intent to issue a certificate. This intent is >> considered binding (i.e., misissuance of the Precertificate is considered >> equal to misissuance of the final certificate).” >> >> However, BR 7.1.2.5 states “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 - Internet X.509 Public Key Infrastructure Certificate and Certificate >> Revocation List (CRL) Profile under these Baseline Requirements.” >> >> Mozilla interprets the BR language as a specific exception allowing CAs >> to issue a precertificate containing the same serial number as the >> subsequent certificate [1]. Otherwise, Mozilla infers from the existence of >> a precertificate that a corresponding certificate has been issued. >> >> This means, for example, that: >> >> * 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 >> * 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. >> * If any corresponding certificate with the same serial number and issuer >> exists, and can not be verified to match the precertificate using the >> algorithms in RFC 6962, it will be considered misissued. >> * In examining historical issuance, the CA must consider both final >> certificates and precertificates, even if the precertificate did not >> ultimately result in the issuance of a certificate. >> > > I propose adding this language to our "Required Practices" wiki page [2], > then introducing a CAB Forum ballot that limits the scope of BR 7.1.2.5 to > serial numbers. That still leaves some uncertainty about the use of the > "unknown" response for precertificates (and in general), although Ryan made > some good points about why using this status beyond the very narrow scope > described in RFC 6960 section 2.2 is a bad idea. > > Once again, I will greatly appreciate your feedback on this topic. Since > this is a practice and not official policy, I'll go ahead and update the > wiki when I sense that we're in agreement here. > > - Wayne > > [1] https://cabforum.org/pipermail/public/2014-January/002694.html > [2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices > > On Tue, Sep 17, 2019 at 8:28 AM Neil Dunbar via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> >> >> > On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> > >> > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy < >> > dev-security-policy@lists.mozilla.org <mailto: >> dev-security-policy@lists.mozilla.org>> wrote: >> > >> >> >> >> >> >>> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy < >> >> dev-security-policy@lists.mozilla.org> wrote: >> >>> >> >>> Hi Kurt. I agree, hence why I proposed: >> >>> >> >>> "- 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.’" >> >> >> >> I suppose one issue there is for CAs which allocate the serial number >> very >> >> early on in the issuance workflow - signing a dummy certificate with an >> >> untrusted key, for instance, but not committing the CA to actually >> >> producing either a pre-certificate or certificate (e.g, because the >> >> applicant has insufficient funds to complete the process). It would not >> >> seem correct to start answering (affirmatively) OCSP requests where no >> >> artefact has been signed by a trusted key. >> >> >> > >> > Why does a CA need to sign something to allocate a serial? Could you >> expand >> > a bit more on that? >> > >> >> Yes - on further consideration, I could have been a lot clearer. I didn’t >> mean that a CA _has_ to sign something to allocate a serial in some >> internal database; merely that the allocation of a serial number, in >> itself, isn’t the trigger (in my opinion, of course) for any OCSP server to >> start responding to the (Issuer, Serial Number) request with successful >> response codes. >> >> What I meant was that some workflows allocate a serial number, sign a >> dummy certificate containing that serial number (with an untrusted key), >> which then flows through with linting checks, and so on. But the decision >> to sign the said certificate with a trusted key has not yet been made >> (officially). But when any object (precertificate, certificate) containing >> that allocated serial number gets signed with a trusted key, it is a >> reasonable expectation for relying parties to be able to query OCSP >> services and not get a “Never heard of it” answer (whether that’s a RFC >> 6960 4.4.8 response, or an “unauthorized”, or whatever). >> >> In other words, Rob’s original language which refers purely to the >> (CA-internal) allocation of the serial number as the triggering event seems >> not to cover all relevant cases. Not that I’ve been able to come up with >> any better language, I should add. >> >> Regards, >> >> Neil >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
