On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy < [email protected]> wrote:
> > > > On 17 Sep 2019, at 14:34, Rob Stradling via dev-security-policy < > [email protected]> 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 [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
