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 < dev-security-policy@lists.mozilla.org> 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 <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 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
