Mozilla has, to-date, not published policies related to Certificate Transparency, but this is a case where a clarification would be helpful. I propose adding the following language to our "Required Practices" wiki page [1]:
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 state “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 [2]. Mozilla recognizes a precertificate as proof that a > corresponding certificate has been issued. > > This means, for example, that the requirements for OCSP for end-entity > certificates apply even when a CA has issued a precertificate without > issuing a corresponding certificate. > I plan to add this to the wiki next week. I also plan to include this in in a future update to our Root Store Policy. I will greatly appreciate your constructive feedback on this proposal. - Wayne [1] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices [2] https://cabforum.org/pipermail/public/2014-January/002694.html On Thu, Aug 29, 2019 at 12:53 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Let me try that again since I didn't explain my original post very well. > Totally worth it since I got a sweet Yu-gi-oh reference out of fit. > > What happened at DigiCert is that the OCSP service failed to return a > signed response for a certificate where a pre-certificate existed by a > certificate had not issued for whatever reason. The question asked was what > type of OCSP services are required for a pre-cert if there is no other > certificate. The answer we came up with is it should respond "GOOD" based > on the Mozilla policy, not Unknown or any other response. Note that this > was a bug in the DigiCert system but it lead to a fun internal discussion. > What I'm sharing is the outcome of the internal discussion - it's only > tangentially related to the bug, not the cause or remediation of it. > > Summary: Pre-certs require a standard OCSP response as if the pre-cert was > a normal cert. In fact, it's a mistake to ever think of pre-certs as > anything other than TLS certs, even if the poison extension exists. > > The question comes up because the BRs don't cover pre-certs. However, as > Ryan points out, the browsers sort-of cover this as does the Mozilla > policy. The browser say this is a promise to issue the cert and > mis-issuance of a pre-cert is the same as mis-issuance of a cert. Although > this isn't mis-issuance in the traditional profile sense, the lack of OCSP > services for the pre-cert is a violation of the Mozilla policy. I couldn't > figure out if it's a violation of the Chrome policy since Chrome says it's > a promise to issue a cert. If the cert hasn't issued, then I'm not sure > where that puts the OCSP service for Chrome. Regardless, according to > Mozilla's policy, the requirement is that regardless of how long the cert > takes to issue, the CA must provide OCSP services for the pre-cert. The > reason is Mozilla requires an OCSP for each end-entity certificate listing > an AIA in the certificate. Pre-certs are end-entity certificates. > > Jeremy > > -----Original Message----- > From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> > On Behalf Of Jeremy Rowley via dev-security-policy > Sent: Thursday, August 29, 2019 11:55 AM > To: Peter Bowen <pzbo...@gmail.com>; Ryan Sleevi <r...@sleevi.com> > Cc: Curt Spann <csp...@apple.com>; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: DigiCert OCSP services returns 1 byte > > Yes. That was the point of my post. There is a requirement fo return an > ocsp repsonse for a pre cert where the cert hasn't issued because of the > Mozilla policy. Hence our failure was a Mozilla policy violation even if no > practical system can use the response because no actual cert (without a > posion extension) exists. > ________________________________ > From: Peter Bowen <pzbo...@gmail.com> > Sent: Thursday, August 29, 2019 11:44:11 AM > To: Ryan Sleevi <r...@sleevi.com> > Cc: Jeremy Rowley <jeremy.row...@digicert.com>; Curt Spann < > csp...@apple.com>; mozilla-dev-security-pol...@lists.mozilla.org < > mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: DigiCert OCSP services returns 1 byte > > > > On Thu, Aug 29, 2019 at 10:38 AM Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org<mailto: > dev-security-policy@lists.mozilla.org>> wrote: > On Thu, Aug 29, 2019 at 1:15 PM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org<mailto: > dev-security-policy@lists.mozilla.org>> wrote: > > > Thanks for posting this Curt. We investigated and posted an incident > > report on Bugzilla. The root cause was related to pre-certs and an > > error in generating certificates for them. We're fixing the issue > > (should be done shortly). I figured it'd be good to document here why > > pre-certs fall under the requirement so there's no confusion for other > CAs. > > > > Oh, Jeremy, you were going so well on the bug, but now you've activated my > trap card (since you love the memes :) ) > > It's been repeatedly documented every time a CA tries to make this > argument. > > Would you suggest we remove that from the BRs? I'm wholly supportive of > this, since it's known I was not a fan of adding it to the BRs for > precisely this sort of creative interpretation. I believe you're now the > ... fourth... CA that's tried to skate on this? > > Multiple root programs have clarified: The existence of a pre-certificate > is seen as a binding committment, for purposes of policy, by that CA, that > it will or has issued an equivalent certificate. > > Is there a requirement that a CA return a valid OCSP response for a > pre-cert if they have not yet issued the equivalent certificate? > > Is there a requirement that a CA return a valid OCSP response for a serial > number that has never been assigned? I know of several OCSP responders > that return a HTTP error in this case. > > Thanks, > Peter > _______________________________________________ > 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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
