Hey Wayne - I take it that this "Mozilla recognizes a precertificate as proof that a corresponding certificate has been issued" means a CA issuing a precert without the final cert must respond "good" unless the pre-cert is revoked? Responding unknown means the CA wouldn't know that they issued the cert, which means they disagree with the proof that a corresponding cert has been issued.
Jeremy -----Original Message----- From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Wayne Thayer via dev-security-policy Sent: Wednesday, September 11, 2019 7:08 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: DigiCert OCSP services returns 1 byte 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
