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
