There's a problem with this framing, and this was the earlier reference to
Jeremy about Yu-gi-oh!

From that earlier response:
> Multiple root programs have clarified: The existence of a pre-certificate
is seen as a binding committment, for purposes of policy, by that CA, that
it will or has issued an equivalent certificate.

Or, to quote from RFC 6962:
>  The signature on the TBSCertificate indicates the
>   certificate authority's intent to issue a certificate.  This intent
>   is considered binding (i.e., misissuance of the Precertificate is
>   considered equal to misissuance of the final certificate).

I suspect part of the issue is the incorrect view of seeing "misissuance"
as "Issuing a certificate that does not comply with the profile", where
we've seen (most obvious through the many CA incident reports), that
"misissuance" is "Issuing a certificate that does not comply with the
policy" - that is, including services like AIA, OCSP, and, well, all the
many validation requirements.

From the point of view of browser policy, a pre-certificate is absolutely
evidence that an equivalent certificate exists. Anything less than that,
and a CA would (and CAs have) tried to argue that it's not really
misissuance, as long as they didn't actually issue the equivalent
certificate. The very point of pre-certificates is to indicate a binding
commitment, with cryptographic evidence, that they cannot dispute an
equivalent certificate "could" exist.

On Thu, Sep 12, 2019 at 8:21 PM Tim Shirley <>

> 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 so.
> Regards,
> Tim
> -----Original Message-----
> From: dev-security-policy <>
> On Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Thursday, September 12, 2019 6:40 PM
> To: Alex Cohn <>
> Cc:; Wayne Thayer <
>>; Jeremy Rowley <>
> Subject: Re: DigiCert OCSP services returns 1 byte
> On Thu, Sep 12, 2019 at 11:25 AM Alex Cohn via dev-security-policy <
>> wrote:
> > On Wed, Sep 11, 2019 at 10:09 PM Jeremy Rowley via dev-security-policy
> > <> 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
> >
> > 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