> 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 

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.


dev-security-policy mailing list

Reply via email to