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

[Rob Stradling]

On 23/10/2019 15:20, Ryan Sleevi wrote:
> On Wed, Oct 23, 2019 at 8:40 AM Rob Stradling <rob at sectigo.com 
> <mailto:rob at sectigo.com>> wrote:
> 
>     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).
> 
> 
> That was intentional, to address the concerns raised by Bruce; that is, 
> this was to avoid introducing a normative requirement that CAs MUST 
> provide such information for Precertificates, and allow that to be 
> addressed via policy, as Wayne originally proposed, while we look to 
> separately discuss and ballot a more systemic fix that might require 
> more discussion.
> 
> That is, I was trying to get the "quick fix" now so we could bash out 
> the "best fix" separately.

OK.  Understood.

>     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.
> 
> 
> This is a great catch!
> 
> ISTM that the simple addition of:
> 
> "The CA MAY provide definitive status information for "reserved" 
> certificate serial numbers, as if there was a corresponding Certificate 
> that matches the Precertificate [RFC6962]."
> 
> Might address the concern of "can they", and then separately a question 
> of must they is addressed via the policy, while the BRs look for a more 
> systemic fix for the intersection of Ballot 134.
> 
> WDYT?

Works for me.

This simple addition addresses the "can they" without treading into 
"must they" territory; and I agree that "must they" can (and should) be 
addressed by root store policies.
(I've taken a similar "can they" approach for 6962-bis: 
https://github.com/google/certificate-transparency-rfcs/commit/e7ee518cbe5a7dcbfa3486be5e4fa3de91646937)

"as if there was a corresponding Certificate that matches the 
Precertificate" clever avoids both (i) having to update 7.1.2.5 and (ii) 
having to extend OCSP to support things that aren't certificates!

> I put that as a PR at 
> https://github.com/sleevi/cabforum-docs/compare/2019-10-OCSP...2019-10-OCSP-MAY-fix?quick_pull=1 to 
> make the proposed language clearer, while you can see the overall set of 
> changes at 
> https://github.com/sleevi/cabforum-docs/compare/master...2019-10-OCSP-MAY-fix

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited