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

[Tim Hollebeek]

DigiCert’s position is my position, which as we discussed on Thursday’s validation call is close to or possibly identical to your position.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, October 24, 2019 2:51 PM
To: Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org>
Cc: Tim Hollebeek <tim.hollebeek at digicert.com>; Wayne Thayer <wthayer at mozilla.com>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

 

 

 

On Thu, Oct 24, 2019 at 2:21 PM Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org <mailto: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/20191028/e729fa00/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191028/e729fa00/attachment-0001.p7s>