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

[Ryan Sleevi]

On Wed, Oct 23, 2019 at 8:40 AM Rob Stradling <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.


> 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? 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191023/232706fa/attachment.html>