[Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

[Rob Stradling]

On 23/10/2019 03:28, Ryan Sleevi via Servercert-wg wrote:
<snip>
>     Rob, Jeremy: Could you check if
>     https://cabforum.org/pipermail/servercert-wg/2019-October/001244.html addresses
>     the immediate concerns raised?
> 
> 
> More concretely: 
> https://github.com/cabforum/documents/compare/master...sleevi:2019-10-OCSP
> 
> This isn't identical to what Dimitris proposed, to try to close the gaps 
> identified. It tries to use terms that are unused by RFC 5019/6960 - 
> such as "unused" - to avoid confusion with "unknown".
> 
> It's not perfect, but I'm curious if that gets closer to a minimal and 
> clear change.

Hi Ryan.  (tl;dr Thanks for this alternative proposal; I think it could 
be made to work).

OCSP operates on "certificates (cf. RFC5280, Section 3.3)" (see RFC6960 
section 2).

Your alternative proposal retains the
   'For the status of Subscriber Certificates...The CA SHALL update
    information provided via...OCSP'
language in section 4.9.10, but a Precertificate cannot be a Subscriber 
Certificate because you also retain the
   '...a Precertificate...shall not be considered to be a "certificate"
    subject to the requirements of RFC 5280'
language in section 7.1.2.5.

I don't see any requirement in (the current wording of) your alternative 
proposal, stated either directly or indirectly, that has the meaning 
"CAs MUST operate OCSP services for serial numbers that have been 
included in Precertificates".  (The '"SHOULD NOT / MUST NOT respond with 
a "good" status' requirements don't imply a "MUST operate OCSP services" 
requirement).

Therefore, if we're expected to read the BRs with a "Default Deny" 
mindset, ISTM that (the current wording of) your alternative proposal 
effectively requires that CAs *MUST NOT* operate OCSP services for (to 
use your term) "reserved" serial numbers.

ISTM that this problem/loophole can only be addressed by either:
(1) Scrapping the 7.1.2.5 language, so that Precertificates are 
considered to be certificates (as per Wayne's draft ballot).
or
(2) Somehow extending OCSP to also be usable for "reserved" serial 
numbers, and requiring CAs to provide OCSP status for "reserved" serial 
numbers.

I think drafting an RFC6960-bis to achieve (2) would be a non-starter, 
because I expect the IETF community would (quite rightly IMHO) take the 
view that RFC6962 Precertificates are in fact certificates!  So...

Maybe 7.1.2.5 could be updated to say that Precertificates aren't 
considered "certificates" per RFC5280 but *are* considered 
"certificates" per RFC6960?  Seems a bit messy, but I don't know how 
else to achieve (2).

Also, might I suggest that (in 4.9.10)
   'For the status of Subscriber Certificates:'
be changed to
   'For the status of Subscriber Certificates and Precertificates:'
?

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited