Yes, but I think this clarifies things in the wrong direction. -Tim
> -----Original Message----- > From: Rob Stradling <[email protected]> > Sent: Friday, September 13, 2019 4:22 AM > To: Tim Hollebeek <[email protected]>; Jeremy Rowley > <[email protected]>; Alex Cohn <[email protected]> > Cc: [email protected]; Wayne Thayer > <[email protected]> > 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 > >> <[email protected]> On Behalf Of Jeremy > >> Rowley via dev-security-policy > >> Sent: Thursday, September 12, 2019 1:46 PM > >> To: Alex Cohn <[email protected]> > >> Cc: [email protected]; Wayne Thayer > >> <[email protected]> > >> 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 <[email protected]> > >> Sent: Thursday, September 12, 2019 9:25 AM > >> To: Jeremy Rowley <[email protected]> > >> Cc: Wayne Thayer <[email protected]>; mozilla-dev-security- > >> [email protected] > >> Subject: Re: DigiCert OCSP services returns 1 byte > >> > >> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via > >> dev-security-policy > >> <[email protected]<mailto:dev-security- > >> [email protected]>> 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 > >> [email protected] > >> https://lists.mozilla.org/listinfo/dev-security-policy > >> > >> _______________________________________________ > >> dev-security-policy mailing list > >> [email protected] > >> https://lists.mozilla.org/listinfo/dev-security-policy > > -- > Rob Stradling > Senior Research & Development Scientist > Email: [email protected] > 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
