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
