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

[Ryan Sleevi]

On Thu, Oct 24, 2019 at 2:21 PM Dimitris Zacharopoulos (HARICA) via
Servercert-wg <servercert-wg at cabforum.org> wrote:

> Jeremy's proposal was in the right direction adding these terms to the
> definitions section (1.6.1).
>
> https://cabforum.org/pipermail/servercert-wg/2019-October/001289.html
>

I'm hoping DigiCert folks can talk amongst themselves here; Tim's
suggestions in the cleanup thread really run counter to Jeremy's
suggestions here, and it's useful if maybe they could talk amongst
themselves and figure out where they stand, since it seems they're the ones
with strongest opinions here.

What I think is relevant here is
1) This is a "temporary" fix
2) This is consistent with the existing language in Ballot 134 and the
existing BRs.

I appreciate the concern being raised here, but it's entirely inconsistent
with the concerns raised to date, from what CAs have expressed. I am
totally on board with making things better, but I don't think there's a
clear articulation as to the why, and it certainly is fairly inconsistent
with existing practice. So I'm hoping someone can clearly articulate why
they believe it should be in definitions, not simply that they do believe
it should be in definitions.

In the draft,
https://github.com/cabforum/documents/compare/master...sleevi:2019-10-OCSP ,
you'll see I followed our existing pattern, used extensively throughout the
BRs in discussion of extensions (e.g. Section 7.1.2.2). What we've seen,
rather consistently, is when stuff is added to Definitions, this causes CAs
more confusion than it solves. Concretely, the discussion about Cross
Certificates is a recent example. I'm hoping we can, in the spirit of "Keep
it Simple", focus on the minimal and useful change, and clearly articulate
the issues with the language proposed.


> I am still having hard time reading and understanding:
>
> "If the OCSP responder receives an OCSP request but has no record of ever
> having issued any certificate with the certificate serial number in that
> request, using any current or previous issuing key for the CA subject, then
> the responder SHOULD NOT respond with a "good" status. OCSP responders for
> CAs that 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."
>

This is why I carefully worded it, in
https://github.com/cabforum/documents/compare/master...sleevi:2019-10-OCSP,
to avoid this confusion. My proposal does not have that language, in order
to address the concerns you raised.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191024/a733fd89/attachment.html>