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 <tshir...@securetrust.com> wrote: > 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 <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@lists.mozilla.org > > https://scanmail.trustwave.com/?c=4062&d=ysn63WDApoyhRKbM1KwsYGvdnm11YYNCq7_hMxDGZg&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
