Correct. That's what I intended to convey with the last sentence: 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. >
Do you have any suggestions for how I can improve/clarify? On Wed, Sep 11, 2019 at 6:19 PM Jeremy Rowley <jeremy.row...@digicert.com> wrote: > 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
