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

[Wayne Thayer]

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> 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>
> *Sent:* Tuesday, October 29, 2019 11:15 AM
> *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
>
>
>
> Hi Bruce,
>
>
>
> On Tue, Oct 29, 2019 at 8:10 AM Bruce Morton <
> 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> *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>
> *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/561c5db8/attachment.html>