Certainly we (as a CA who uses such precertificate-signing CAs) never interpreted RFC 6962 or the other requirements as mandating or even suggesting that, for either of the possible interpretations of Alex's question. As soon as you hit the precertificate-signing CA in the validation path you've encountered a signed entity that is unusable in the public PKI, as it fails validation on a couple of fronts: it has the critical poison extension in the EKU and it has Basic Constraints set and yet was issued from a CA with path-length 0. If we did need to provide OCSP responses for that hierarchy, that would mean generating and distributing twice as many OCSP responses, so if that became a requirement that would likely cause us to reconsider this implementation approach.
More generally speaking to the entirety of this thread though I'm wondering a couple of things: 1) Is there an actual goal or problem we're trying to solve by having a rule at all on whether an OCSP responder should respond UNKNOWN or GOOD on a precertificate where there is no certificate? I understand the rationale for requiring that a CA be able to revoke a precertificate, since there's no way for a CA to prove that a corresponding certificate doesn't exist. So if you can satisfy any of the criteria for which the BRs require revocation of a certificate today, an OCSP response of REVOKED on that serial number gives assurance that if any corresponding certificate DOES exist, it's now revoked. But what is the practical difference between an OCSP responder returning GOOD and it returning UNKNOWN unless a corresponding certificate exists? 2) How does the statement from RFC 6962 lead to the conclusion that a precertificate is "proof that a corresponding certificate has been issued". Of course for a certain period of time (typically very short) that statement can't possibly be true because you need to create a precertificate before you can request SCTs and you need SCTs to create the certificate. But ignoring that technicality, I read "This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate)" as saying essentially "you'll be found guilty in a court of law if you commit a crime in your precertificate, whether or not you go through with it in a real certificate. You signaled your intent, and we'll find you guilty based on that intent, if your intent was unlawful." I could see where it might be ambiguous without the i.e. parenthetical between that interpretation and the interpretation that "binding intent" means a promise to issue a corresponding certificate. But the i.e. parenthetical seems to have been added specifically to clear up that potential ambiguity. Regards, Tim -----Original Message----- From: dev-security-policy <[email protected]> On Behalf Of Neil Dunbar via dev-security-policy Sent: Thursday, September 12, 2019 1:58 PM To: [email protected] Subject: Re: DigiCert OCSP services returns 1 byte > On 12 Sep 2019, at 18:46, Jeremy Rowley via dev-security-policy > <[email protected]> wrote: > > The language says you have to provide the response for the cert as if it > exists, but the reality is that sending a response for the precert is the > same as calculating the result for the certificate as if it exists and > sending that. They are the same thing because the precert is treated the same > as the final cert if the final cert doesn't exist. I could be horribly mistaken, but I think Alex was asking is: in the event that precertificates are not signed by the issuing CA's private key, but rather by a separate signing key/certificate dedicated to that purpose (per RFC 6962, Section 3.1) - is there then an obligation to provide OCSP services for that, given that the (name-hash, key-hash) on the OCSP request would not be the same as that which would normally obtain for the final certificate, which is signed directly by the issuing CA key? It would _seem_ right that it should, since a pre-certificate could reasonably be revoked prior to issuing the final certificate, for several reasons. Yet it's a reasonable follow-up question: would CAs who have such dedicated certificates make them available such that RPs could construct those OCSP requests? > I believe the intent is that a CT-naïve OCSP checker would work normally when > presented with a precert or a certificate. Afterall, a precert is really just > a certificate with a special extension. Would an OCSP server even be able to tell the difference? After all, it simply gets presented with a CA identifier (name-hash, key-hash) and a serial number. If it knows about that combination, it provides a response, but it's got no way of knowing, absent extra information in its database whether the request pertains to a pre-cert or cert - in general. But see above for the case of dedicated precertificate signing certificates. Regards, Neil _______________________________________________ dev-security-policy mailing list [email protected] https://scanmail.trustwave.com/?c=4062&d=vYf63SFHw3OMTLs5z_XBTWHEejkpuh1h5FY8k9MvsA&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
