Yes, but I think this clarifies things in the wrong direction.

-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.

Attachment: 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

Reply via email to