> On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy 
> <dev-security-policy@lists.mozilla.org> wrote:
> Hi Kurt.  I agree, hence why I proposed:
>   "- I would also like to see BR 4.9.10 revised to say something roughly
> along these lines:
>    'If the OCSP responder receives a status request for a serial number
>     that has not been allocated by the CA, then the responder SHOULD NOT
>     respond with a "good" status.’"

I suppose one issue there is for CAs which allocate the serial number very 
early on in the issuance workflow - signing a dummy certificate with an 
untrusted key, for instance, but not committing the CA to actually producing 
either a pre-certificate or certificate (e.g, because the applicant has 
insufficient funds to complete the process). It would not seem correct to start 
answering (affirmatively) OCSP requests where no artefact has been signed by a 
trusted key.

It seems to me that the trigger point to start answering OCSP requests for a 
(Issuer, Serial Number) request would be when the serial number has been 
allocated AND an artefact has been signed by an issuer private key.

In other words, a CA might well allocate a serial number, which, if all goes 
well, will find its way into a certificate; but until a publicly trusted 
signature has been made on a TBSCertificate containing that serial number, an 
OCSP responder is behaving properly were it to answer “Never heard of that 
serial number for that Issuer”.


dev-security-policy mailing list

Reply via email to