> On 17 Sep 2019, at 16:14, Ryan Sleevi via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > On Tue, Sep 17, 2019 at 10:00 AM Neil Dunbar via dev-security-policy < > dev-security-policy@lists.mozilla.org > <mailto: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? >
Yes - on further consideration, I could have been a lot clearer. I didn’t mean that a CA _has_ to sign something to allocate a serial in some internal database; merely that the allocation of a serial number, in itself, isn’t the trigger (in my opinion, of course) for any OCSP server to start responding to the (Issuer, Serial Number) request with successful response codes. What I meant was that some workflows allocate a serial number, sign a dummy certificate containing that serial number (with an untrusted key), which then flows through with linting checks, and so on. But the decision to sign the said certificate with a trusted key has not yet been made (officially). But when any object (precertificate, certificate) containing that allocated serial number gets signed with a trusted key, it is a reasonable expectation for relying parties to be able to query OCSP services and not get a “Never heard of it” answer (whether that’s a RFC 6960 4.4.8 response, or an “unauthorized”, or whatever). In other words, Rob’s original language which refers purely to the (CA-internal) allocation of the serial number as the triggering event seems not to cover all relevant cases. Not that I’ve been able to come up with any better language, I should add. Regards, Neil _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
