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

Tue Oct 29 09:06:44 MST 2019

Thanks for the clarification.

Bruce.

From: Wayne Thayer <wthayer at mozilla.com>
Sent: Tuesday, October 29, 2019 12:01 PM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [EXTERNAL][Servercert-wg] Ballot SC23 v3: Precertificates

It sounds like you are asking for an effective date for a "MAY" requirement, and I'm arguing that effective dates are only relevant for "SHALL" or "MUST" requirements.

Here's how I described the need for a future effective date with the original ballot language:

I think the concern here is that some CAs have interpreted the current section 7.1.2.5 as placing no OCSP requirements on precertificates (because they are not within the scope of the BRs because they are not certificates). With the new language, this argument becomes mirky (because we remove the statement that precertificates are not certificates). Hence the assertion that this ballot does place new requirements on CAs and thus should include a reasonable effective date.

So the need for an effective date was driven by the change to BR 7.1.2.5 in the original ballot. That section is not changed in v3 of the ballot.

I agree that CAs will need time to make the change, but since the language is "...MAY provide definitive responses about "reserved" certificate serial numbers..." there is no requirement for them to do so by the effective date of the ballot, or ever (at least as far as the BRs are concerned).

On Tue, Oct 29, 2019 at 8:37 AM Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>> wrote:
Your ballot introduces a problem that “BR section 4.9.10 combined with BR section 7.1.2.5 prevents a CA from responding “good” for a precertificate.” I assumed that the ballot was to fix this issue.

This statement, although it is a MAY statement, appears to be a change to address your stated problem, “The OCSP responder MAY provide definitive responses about "reserved" certificate serial numbers, as if there was a corresponding Certificate that matches the Precertificate [RFC6962].”

The action for the CAs, which have your stated problem, would be to provide OCSP responses for reserved certificate serial numbers. This action may take time.

Please clarify if I am not understanding the new approach.

Thanks, Bruce.

From: Wayne Thayer <wthayer at mozilla.com<mailto:wthayer at mozilla.com>>
Sent: Tuesday, October 29, 2019 11:15 AM
To: Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Subject: Re: [EXTERNAL][Servercert-wg] Ballot SC23 v3: Precertificates

Hi Bruce,

On Tue, Oct 29, 2019 at 8:10 AM Bruce Morton <Bruce.Morton at entrustdatacard.com<mailto:Bruce.Morton at entrustdatacard.com>> wrote:
Hi Wayne,

Do you still intend to propose an effective date of 1 March 2020?

Given the new approach to solving the problem, can you explain why a phase-in period is needed? I'm thinking that this version doesn't place any new requirements on CAs.

Thanks, Bruce.

From: Servercert-wg <servercert-wg-bounces at cabforum.org<mailto:servercert-wg-bounces at cabforum.org>> On Behalf Of Wayne Thayer via Servercert-wg
Sent: Monday, October 28, 2019 11:45 PM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>>
Subject: [EXTERNAL][Servercert-wg] Ballot SC23 v3: Precertificates

WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.
________________________________
Here is v3 of the Precertificates ballot, based on Ryan Sleevi's proposal. This email resets the discussion period as defined below.
==========================

Ballot SC23 v3: Precertificates

Purpose of Ballot:

This ballot intends to clarify requirements placed on Precertificates in BR section 4.9.10.

During a lengthy discussion on the mozilla.dev.security.policy forum [1], it was discovered that BR section 4.9.10 combined with BR section 7.1.2.5 prevents a CA from responding “good” for a precertificate. This is a problem because there is no guarantee that a certificate corresponding to a Precertificate has not been issued, resulting in root store policies such as [2] that require CAs to treat the existence of a Precertificate as a presumption that a corresponding certificate has been issued and thus that a valid OCSP response is required.

This ballot intends to resolve the problem by clarifying in the BRs that a CA may provide revocation information for the serial number contained in a Precertificate.

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/LC_y8yPDI9Q/NbOmVB77AQAJ

[2] https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates

The following motion has been proposed by Wayne Thayer of Mozilla and endorsed by Jeremy Rowley of DigiCert and Rob Stradling of Sectigo.

-- MOTION BEGINS --

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.6.6, or based on Version 1.6.6 as modified by ballot SC24:

ADD a reference to section 1.6.3 of the Baseline Requirements as defined in the following redline:

https://github.com/cabforum/documents/compare/master@%7B10-23-19%7D...sleevi:2019-10-OCSP

REPLACE section 4.9.10 of the Baseline Requirements in its entirety as defined in the following redline:

https://github.com/cabforum/documents/compare/master@%7B10-23-19%7D...sleevi:2019-10-OCSP

-- MOTION ENDS --

This ballot proposes a Final Maintenance Guideline.

The procedure for approval of this ballot is as follows:

Discussion (7+ days)

Start Time: 3-October 2019 18:00 UTC

End Time: No earlier than 05-November 2019 04:00 UTC

Vote for approval (7 days)

Start Time: TBD

End Time: TBD
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191029/de35c6ff/attachment-0001.html>