[Servercert-wg] Draft Ballot: Precertificates and OCSP

Rob Stradling rob at sectigo.com
Mon Sep 23 03:10:59 MST 2019


Hi Wayne.  I raised the following point during the m.d.s.p discussion, 
but this draft ballot does not yet address it.

This sentence is problematic:

'If the OCSP responder receives a request for status of a certificate 
that has not been issued, then the responder {SHOULD or MUST} NOT 
respond with a "good" status.'

The scenario that this draft ballot seeks to address is where a 
precertificate `P` has been issued, but the corresponding certificate 
`C` (that will contain embedded SCTs) has not (yet) been issued.
`C` is clearly 'a certificate that has not been issued', and so (per the 
problematic sentence) the CA {SHOULD or MUST} *NOT* 'respond with a 
"good" status'.
It makes no difference whether you regard `P` to be a certificate or 
not-a-certificate.  `C` may be due to be issued, but until it has 
actually been issued, `C` is by definition 'a certificate that has not 
been issued'.

So, unless this ballot also changes the wording of this problematic 
sentence, ISTM that CAs will be in the unfortunate position of having to 
choose between...
1. Complying with Mozilla policy, which looks set to override this 
problematic sentence (meaning that CAs are REQUIRED to provide OCSP 
status in this scenario)
or
2. Complying with other browser policies, which incorporate the BRs and 
which, crucially, *don't* override this problematic sentence (meaning 
that CAs are FORBIDDEN from providing OCSP status in this scenario).

I propose rewording the problematic sentence along these lines...

'If the OCSP responder receives a request for status of a serial number 
that does not yet belong to an issued Certificate or Precertificate, 
then the responder {SHOULD or MUST} NOT respond with a "good" status.'

On 20/09/2019 23:40, Jacob Hoffman-Andrews via Servercert-wg wrote:
> Thanks for drafting this!
> 
> On Fri, Sep 20, 2019 at 2:05 PM Wayne Thayer via Servercert-wg 
> <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org>> wrote:
> 
>     For purposes of clarification, a Precertificate, as described in RFC
>     6962 – Certificate Transparency, shall not be considered to be a
>     “certificate” subject to the serial number uniqueness requirements
>     of section 4.1.2.2 of RFC 5280 - Internet X.509 Public Key
>     Infrastructure Certificate and Certificate Revocation List (CRL)
>     Profile under these Baseline Requirements.
> 
> 
> There's a hole in this where you could issue hundreds of precertificates 
> all with the same serial number. Arguably that hole exists in the 
> current BRs as well. How about:
> 
> For purposes of clarification, any Precertificate MAY have the same 
> serial number as exactly one certificate that is not a Precertificate, 
> provided that the two are related as described in RFC 6962. This is a 
> modification of the uniqueness requirements of RFC 5280 section 4.1.2.2.
> 
>     If the OCSP responder receives a request for status of a certificate
>     that has not been issued, then the responder SHOULD NOT respond with
>     a "good" status. OCSP responders for CAs which are not Technically
>     Constrained in line with Section 7.1.5 MUST NOT respond with a
>     "good" status for such certificates. The CA SHOULD monitor the
>     responder for such requests as part of its security response procedures.
> 
> 
> If we're aiming to clarify this language we should switch it around so 
> the most salient part is first:
> 
> If the OCSP responder receives a request for status of a certificate 
> that has not been issued, then the responder MUST NOT respond with a 
> "good" status. As an exception, CAs which are Technically constrained in 
> line with Section 7.1.5  MAY, respond with a "good" status to such 
> requests, but this is NOT RECOMMENDED. All CAs SHOULD monitor the 
> responder for such requests as part of its security response procedures.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited



More information about the Servercert-wg mailing list