On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy <
> dev-security-policy@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?

I think this may be the wrong framing. The issue is not about ensuring "a
CT-naïve OCSP checker" can get responses for pre-certs. It's about ensuring
that, from the point of view of a user agent that views a pre-certificate
as evidence that an equivalent certificate exists, even if it's not known
(or even if it was not actually issued), can they verify that OCSP services
exist and are configured for that equivalent certificate?

In this scenario, because RFC 6962 establishes that, even when using a
Precertificate Signing Certificate, it will have been directly issued by
the CA Certificate that will ultimately issue the "final" certificate (...
or would be treated as if it had), then we have the (name-hash, key-hash)
that Neil was referring to, and we can easily verify using that, for the
serial number indicated in the pre-certificate, that the OCSP response can
be verified using the issuer of the Precertificate Signing Certificate.

Have I overlooked some ambiguity?
dev-security-policy mailing list

Reply via email to