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

[Mike Reilly (GRC)]

DigiCert folks (ballot endorses), in the conversation between Ryan and Dimitris yesterday (mail below) Ryan leaves it with “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.”  In that thread Jeremy’s proposed language is referenced (https://cabforum.org/pipermail/servercert-wg/2019-October/001289.html<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fpipermail%2Fservercert-wg%2F2019-October%2F001289.html&data=02%7C01%7CMike.reilly%40microsoft.com%7C977649ee430642278ed508d758b34b52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075399399848324&sdata=z3%2FLfj3vLHoHYkC2a5EtfZbbdJAWblwklhXtE2nLJpk%3D&reserved=0>).  In there is the proposal to:

“Add to the defined terms:
Precertificate has the meaning defined in RFC 6962.
Precertificate Signing Certificate has the meaning defined in RFC 6962.”

Reading RFC 6962 I don’t see a clear definition of a precertificate but section 3.1 (Log Entries) states “Alternatively, (root as well as intermediate) certificate authorities “MAY” (my caps) submit a certificate to logs prior to issuance.  To do so, the CA submits a Precertificate that the log can use to create an entry that will be valid against the issued certificate.”  That sounds like there is no requirement to log precertificates.

I’m still hung up on why a precert is treated as a cert in this ballot.  Is this primarily because Mozilla policy interprets the BRs to mean that all certificates are presumed to exist based on the presence of a precert, even if the certificate does not actually exist?  It seems the problem is with the Mozilla policy rather than with the BRs unless I’m missing something.  In simple terms is the purpose of this ballot to get the BRs to state that CAs must add precerts to CT logs?  I can’t say I agree with that direction.

The discussion and purpose of the ballot overall is still not clear to me and based on the amount of discussion on it so far I don’t think it’s clear to most other folks as well.

Thanks, Mike

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Thursday, October 24, 2019 11:51 AM
To: Dimitris Zacharopoulos (HARICA) via Servercert-wg <servercert-wg at cabforum.org>
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcabforum.org%2Fpipermail%2Fservercert-wg%2F2019-October%2F001289.html&data=02%7C01%7CMike.reilly%40microsoft.com%7C977649ee430642278ed508d758b34b52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075399399848324&sdata=z3%2FLfj3vLHoHYkC2a5EtfZbbdJAWblwklhXtE2nLJpk%3D&reserved=0>

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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...sleevi%3A2019-10-OCSP&data=02%7C01%7CMike.reilly%40microsoft.com%7C977649ee430642278ed508d758b34b52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075399399848324&sdata=micFONy8aD6G%2BnrVg%2BjPaxhU1dTc7xqpIZjaaNaJHAw%3D&reserved=0> , 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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcabforum%2Fdocuments%2Fcompare%2Fmaster...sleevi%3A2019-10-OCSP&data=02%7C01%7CMike.reilly%40microsoft.com%7C977649ee430642278ed508d758b34b52%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637075399399848324&sdata=micFONy8aD6G%2BnrVg%2BjPaxhU1dTc7xqpIZjaaNaJHAw%3D&reserved=0>, 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/20191025/43592879/attachment-0001.html>