Why would a user agent view a pre-certificate as "evidence that an equivalent 
certificate exists"?  It's evidence that it might exist..  That the CA had the 
intent to make it exist at the time they signed the precertificate..  But I 
can't find anything in RFC 6962 that suggests to me that if the CA doesn't 
follow through on that intent that their systems are required to behave as if 
it does exist.

And of course Mozilla could add a policy to require exactly that, as the 
proposed addition does.  But I'm struggling to see the practical value in doing 


-----Original Message-----
From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> On 
Behalf Of Ryan Sleevi via dev-security-policy
Sent: Thursday, September 12, 2019 6:40 PM
To: Alex Cohn <a...@alexcohn.com>
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 
<wtha...@mozilla.com>; Jeremy Rowley <jeremy.row...@digicert.com>
Subject: Re: DigiCert OCSP services returns 1 byte

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://scanmail.trustwave.com/?c=4062&d=ysn63WDApoyhRKbM1KwsYGvdnm11Y
> YNCq-2zZRHKOQ&s=5&u=https%3a%2f%2fcrt%2esh%2f%3fid%3d1868433277%3f

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
dev-security-policy mailing list

Reply via email to