Tim Shirley did a good job of pointing it out. The relevant OCSP RFCs talk about issued certificates, which pre-certificates aren’t. This isn’t a policy matter, it’s a matter of a plain reading of the relevant RFCs, and trying to align that with what people want them to say as opposed to what they actually say.
Whatever the policy is, and I’m actually supportive of Wayne’s policy goals, the CT and OCSP RFCs actually have requirements that potentially contradict those goals, especially under some interpretations. I’d like to fix the relevant requirements to allow to the policy that there seems to be a growing consensus for. -Tim From: Ryan Sleevi <[email protected]> Sent: Thursday, September 12, 2019 6:44 PM To: Tim Hollebeek <[email protected]> Cc: Jeremy Rowley <[email protected]>; Alex Cohn <[email protected]>; [email protected]; Wayne Thayer <[email protected]> Subject: Re: DigiCert OCSP services returns 1 byte Without wanting to be antagonistic, I've come to learn I can count on you to suggest that X deserves clarification because it's ambiguous, but I've also learned I have trouble learning where the ambiguity exists or why. Recall that part of this confusion, regrettably, came from an earnest attempt to try and helpfully clarify the BRs with respect to precertificates, so I've come to view clarifications as just as much, if not more, risky than the original language. The question about whether and how a pre-certificate is viewed is definitely a matter for policy, and so I'm definitely opposed to attempting to address it in IETF drafts, and somewhat opposed to clarifying it in the BRs, since really, it's a matter of policy. Could you perhaps highlight which "various things in the OCSP RFCs" that might be read to conflict or preclude a good response? I think that's probably the best way to figure out what, where, is to understand how the interpretation came to be. It could be simply that the interpretation overlooked other sections, as we've seen in the past (e.g. with IP addresses in dNSName or with underscores), and so that seems like the best starting point. On Thu, Sep 12, 2019 at 3:49 PM Tim Hollebeek via dev-security-policy <[email protected] <mailto:[email protected]> > wrote: So, this is something that would be helpfully clarified via either an IETF draft, 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] > <mailto:[email protected]> > On > Behalf Of Jeremy Rowley via dev-security-policy > Sent: Thursday, September 12, 2019 1:46 PM > To: Alex Cohn <[email protected] <mailto:[email protected]> > > Cc: [email protected] > <mailto:[email protected]> ; Wayne Thayer > <[email protected] <mailto:[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] <mailto:[email protected]> > > Sent: Thursday, September 12, 2019 9:25 AM > To: Jeremy Rowley <[email protected] > <mailto:[email protected]> > > Cc: Wayne Thayer <[email protected] <mailto:[email protected]> >; > mozilla-dev-security- > [email protected] <mailto:[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:[email protected]> <mailto:dev-security- > <mailto:dev-security-> > [email protected] <mailto:[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] > <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
