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
