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

[Mike Reilly (GRC)]

Hi all.  I think we should be looking more at what Jeremy stated earlier in this thread:   "To be honest, I’d rather just correct the mistake the CAB Forum made and clarify that a pre-cert is really just a cert and should be treated just like a cert minus the duplicate serial number. That’s a much simpler fix."  It sounds like we need to clarify what a precert is and whether it's in scope or not under the BRs as a cert.  7.1.2.5 clearly states a precert is not a cert.  Seems that is what we should be discussing in as simple terms as possible.

Given we have CAs from across the globe, many of which use English as a second language and probably don't regularly read the large amount of mail traffic on this forum, the simpler the better.  As a native English speaker I'm still not completely following this discussion and the nuances of the language proposed in this ballot.  It's still not clear how we are defining a precert and if it's even in scope for the BRs.

Is the goal that we treat precerts as certificates and we have OCSP services prepared upon the creation and posting of the precert to CT logs?

Thanks, Mike

-----Original Message-----
From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Rob Stradling via Servercert-wg
Sent: Wednesday, October 23, 2019 5:40 AM
To: Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

On 23/10/2019 03:28, Ryan Sleevi via Servercert-wg wrote:
<snip>
>     Rob, Jeremy: Could you check if
>     https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fpipermail%2Fservercert-wg%2F2019-October%2F001244.html&data=02%7C01%7CMike.reilly%40microsoft.com%7C9bff4aaa18f7463e48e708d757b62841%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074312180934241&sdata=eDVBTH1ab4qeNDkS6dEh02qD8wNcdjc3BKsVjwMJejI%3D&reserved=0 addresses
>     the immediate concerns raised?
> 
> 
> More concretely: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...sleevi%3A2019-10-OC
> SP&data=02%7C01%7CMike.reilly%40microsoft.com%7C9bff4aaa18f7463e48
> e708d757b62841%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6370743121
> 80944193&sdata=65hR4siIGvEIMT2XQShV%2BROyAy2SCskMkaK%2BKeX5Vq8%3D&
> amp;reserved=0
> 
> 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

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=02%7C01%7CMike.reilly%40microsoft.com%7C9bff4aaa18f7463e48e708d757b62841%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637074312180944193&sdata=GnMbgem0yDHr1wVoKaXkzJrpu%2FsQovc7zJdQ5TRKH7s%3D&reserved=0