Sorry for being unclear. If the IETF goes the direction of "pre-certificates are not certificates", then we find ourselves in a world where the RFCs say that they should not get OCSP services, but Mozilla policy (and potentially the BRs) says that they should.
I think that's fine as Mozilla and/or the CABF can and should override RFCs when it makes sense to do so, but I think it would also be helpful in the long term to fix the discrepancy, especially as CT is likely to be used in more certificate ecosystems in the future. Note that this doesn't mean that CT-bis has to state that pre-certificates are certificates, but it (or something later, or another draft ...) should at mention that OCSP responses for pre-certificates are allowed. -Tim > -----Original Message----- > From: Rob Stradling <r...@sectigo.com> > Sent: Monday, September 16, 2019 5:28 AM > To: Tim Hollebeek <tim.holleb...@digicert.com> > Cc: Jeremy Rowley <jeremy.row...@digicert.com>; Alex Cohn > <a...@alexcohn.com>; mozilla-dev-security-pol...@lists.mozilla.org; Wayne > Thayer <wtha...@mozilla.com> > Subject: Re: DigiCert OCSP services returns 1 byte > > On 13/09/2019 19:24, Tim Hollebeek wrote: > > Yes, but I think this clarifies things in the wrong direction. > > Hi Tim. I'm not clear what you mean. > > I was talking specifically and only about what IETF could/should do regarding > this matter. Which part did you disagree with, and why? > > > -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. > > -- > 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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
