On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > 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.

Why does a CA need to sign something to allocate a serial? Could you expand
a bit more on that?

> 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”.

I'm not sure I follow why that seems to be?
dev-security-policy mailing list

Reply via email to