Thanks everyone for your feedback! I'm sensing that the proposed language is generally helpful. I've made two updates:
* Accepted Jeremy's proposed language for the examples in the last paragraph. * attempted to address Tim Shirley's point that a precertificate is not literally "proof" that a certificate exists by changing that sentence to "Otherwise, Mozilla infers from the existence of a precertificate that a corresponding certificate has been issued, even when we have no evidence of the certificate." The new statement of "required practice" reads: 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. Otherwise, Mozilla infers from the existence of a > Precertificate that a corresponding certificate has been issued, even when > we have no evidence of the certificate. > > This means, for example, that (i) a CA must provide OCSP services and > responses in accordance with Mozilla policy for all Precertificates as if > the corresponding certificate exists, and (ii) a CA must be able to revoke > a Precertificate if revocation of the certificate is required under Mozilla > policy and the corresponding certificate doesn’t actually exist and > therefore cannot be revoked. > I will again welcome everyone's constructive feedback on this proposal, and when there are no further comments I'll add this to our wiki. - Wayne On Fri, Sep 13, 2019 at 11:24 AM Tim Hollebeek <tim.holleb...@digicert.com> wrote: > Yes, but I think this clarifies things in the wrong direction. > > -Tim > > > -----Original Message----- > > From: Rob Stradling <r...@sectigo.com> > > Sent: Friday, September 13, 2019 4:22 AM > > To: Tim Hollebeek <tim.holleb...@digicert.com>; Jeremy Rowley > > <jeremy.row...@digicert.com>; Alex Cohn <a...@alexcohn.com> > > Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer > > <wtha...@mozilla.com> > > Subject: Re: DigiCert OCSP services returns 1 byte > > > > On 12/09/2019 20:48, Tim Hollebeek via dev-security-policy wrote: > > > So, this is something that would be helpfully clarified via either an > > > IETF draft, > > > > There's already a 6962-bis draft [1] in IESG Last Call, which (when we > finally > > complete it!) will obsolete RFC6962. 6962-bis redefines precertificates > so that > > they're not actually X.509 certificates. > > Therefore, I don't think a "clarify RFC6962" draft is necessary. > > > > Thinking aloud... > > Does anything need to be clarified in 6962-bis though? > > A (non-X.509) 6962-bis precertificate contains the serial number that > will > > appear in the certificate (if or when that certificate is issued), > > so: Should the CA be forbidden, permitted or required to operate > revocation > > services for that serial number once the 6962-bis precertificate has been > > produced but before the certificate has been issued? (And is this a > technical > > matter for 6962-bis to address, or a policy matter that's out of scope > for the > > 6962-bis document?) > > > > > > [1] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ > > > > > or clarifications in the BRs. There are various things in the OCSP > RFCs and > > even the BRs that can be read as precluding good OCSP responses for pre- > > certificates, although the situation is unclear since the relevant > sections are > > blissfully ignorant of CT, and the correct behavior here was > unfortunately left > > out of RFC 6962, which should have clarified this. > > > > > > Happy to help draft something. There are some interesting complexities > > once you dig deeper. > > > > > > -Tim > > > > > >> -----Original Message----- > > >> From: dev-security-policy > > >> <dev-security-policy-boun...@lists.mozilla.org> On Behalf Of Jeremy > > >> Rowley via dev-security-policy > > >> Sent: Thursday, September 12, 2019 1:46 PM > > >> To: Alex Cohn <a...@alexcohn.com> > > >> Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer > > >> <wtha...@mozilla.com> > > >> Subject: RE: DigiCert OCSP services returns 1 byte > > >> > > >> The language says you have to provide the response for the cert as if > > >> it exists, but the reality is that sending a response for the precert > > >> is the same as calculating the result for the certificate as if it > > >> exists and sending that. They are the same thing because the precert > > >> is treated the same as the final cert if the final cert doesn’t exist. > > >> > > >> I believe the intent is that a CT-naïve OCSP checker would work > > >> normally when presented with a precert or a certificate. Afterall, a > > >> precert is really just a certificate with a special extension. > > >> > > >> From: Alex Cohn <a...@alexcohn.com> > > >> Sent: Thursday, September 12, 2019 9:25 AM > > >> To: Jeremy Rowley <jeremy.row...@digicert.com> > > >> Cc: Wayne Thayer <wtha...@mozilla.com>; mozilla-dev-security- > > >> pol...@lists.mozilla.org > > >> Subject: Re: DigiCert OCSP services returns 1 byte > > >> > > >> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via > > >> dev-security-policy > > >> <dev-security-policy@lists.mozilla.org<mailto:dev-security- > > >> pol...@lists.mozilla.org>> wrote: > > >> This means, for example, that (i) a CA must provide OCSP services and > > >> responses in accordance with the Mozilla policy for all > > >> pre-certificates as if corresponding certificate exists and (ii) a CA > > >> must be able to revoke a pre- certificate if revocation of the > > >> certificate is required under the Mozilla policy and the > > >> corresponding certificate doesn't actually exist and therefore cannot > be > > revoked. > > >> > > >> Should a CA using a precertificate signing certificate be required to > > >> provide OCSP services for their precertificates? Or is it on the > > >> relying party to calculate the proper OCSP request for the final > > >> certificate and send that instead? In other words, should we expect a > > >> CT-naïve OCSP checker to work normally when presented, e.g., with > > https://crt.sh/?id=1868433277? > > >> > > >> Alex > > >> _______________________________________________ > > >> 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 > > > > -- > > Rob Stradling > > Senior Research & Development Scientist > > Email: r...@sectigo.com > > Bradford, UK > > Office: +441274024707 > > Sectigo Limited > > > > This message and any files associated with it may contain legally > privileged, > > confidential, or proprietary information. If you are not the intended > recipient, > > you are not permitted to use, copy, or forward it, in whole or in part > without > > the express consent of the sender. Please notify the sender by reply > email, > > disregard the foregoing messages, and delete it immediately. > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
