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

Fri Oct 25 13:43:15 MST 2019

On Fri, Oct 25, 2019 at 1:19 PM Mike Reilly (GRC) via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> 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 original ballot doesn't state that "a precertificate is a certificate".
It references the original ballot from 2014 in limiting the scope of the
exception in BR 7.1.2.5 to only the RFC 5280 requirement that certificates
not have duplicate serial numbers. The intent is to allow CAs to comply
with BR 4.9.10 when issuing OCSP responses for precertificates when no
corresponding certificate exists. This is not something that Mozilla policy
can fix (or I would do that).

My sense is that there is general agreement that the solution proposed by
Dimitris and improved by Ryan is better. I'm fine with that, but (to Ryan's
point in asking DigiCert for input), since Jeremy is an endorser, I'd like
to hear from him before changing the ballot to the new solution.

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> 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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191025/eed991a3/attachment.html>