[Servercert-wg] Draft Ballot: Precertificates and OCSP

[Wayne Thayer]

Forgot to add the link to the redline:

[1]
https://github.com/wthayer/documents/commit/f0b7c0a27fe51e73d5ed5d8d453024c51713ed70

On Thu, Oct 3, 2019 at 10:06 AM Wayne Thayer <wthayer at mozilla.com> wrote:

> Thanks Jeremy and Rob. I've created a redline [1] that includes a few
> tweaks to the language in section 7.1.2.5 to better align with the existing
> version (adding in descriptive names for RFCs that are referenced, and
> adding "...under these Baseline Requirements." to the last sentence). I'll
> begin the discussion period now.
>
> - Wayne
>
> On Tue, Oct 1, 2019 at 1:37 AM Rob Stradling <rob at sectigo.com> wrote:
>
>> I'll endorse for Sectigo.
>>
>> On 01/10/2019 02:16, Jeremy Rowley via Servercert-wg wrote:
>> > DigiCert will endorse.
>> >
>> > *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
>> Of
>> > *Wayne Thayer via Servercert-wg
>> > *Sent:* Monday, September 30, 2019 5:12 PM
>> > *To:* CA/B Forum Server Certificate WG Public Discussion List
>> > <servercert-wg at cabforum.org>
>> > *Subject:* Re: [Servercert-wg] Draft Ballot: Precertificates and OCSP
>> >
>> > Thanks Jacob, Rob, and Ryan for the outstanding feedback. Below is a
>> > draft incorporating your changes, except for Jacob's proposed
>> > clarification (I see the point, but I don't think it's really any
>> clearer).
>> >
>> > Could I ask for two endorsers for this ballot?
>> >
>> > - Wayne
>> >
>> > ========================
>> >
>> > Purpose of Ballot:
>> >
>> > This ballot intends to clarify requirements placed on precertificates
>> in
>> > BR section 7.1.2.5.
>> >
>> > 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 reducing the scope of
>> > section 7.1.2.5. This section was originally [3] intended only to
>> > address duplicate serial numbers that would violate RFC 5280 section
>> > 4.1.2.2. In addition, this ballot removes legacy effective dates from
>> BR
>> > section 4.9.10.
>> >
>> > [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
>> >
>> > [3] https://cabforum.org/pipermail/public/2014-January/002694.html
>> >
>> > The following motion has been proposed by Wayne Thayer of Mozilla and
>> > endorsed by XXX of YYY and XXX of YYY.
>> >
>> > -- 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:
>> >
>> > *REPLACE section 7.1.2.5 of the Baseline Requirements in its entirety
>> with:*
>> >
>> > 7.1.2.5 Application of RFC 5280
>> >
>> > For purposes of clarification, any Precertificate MAY have the same
>> > serial number as exactly one certificate that is not a Precertificate,
>> > provided that the two are related as described in RFC 6962. This is a
>> > modification of the uniqueness requirements of RFC 5280 section 4.1.2.2.
>> >
>> > *REPLACE section 4.9.10 of the Baseline Requirements as follows:*
>> >
>> > The CA SHALL support an OCSP capability using the GET method for
>> > Certificates issued in accordance with these Requirements.
>> >
>> > For the status of Subscriber Certificates:
>> >
>> > The CA SHALL update information provided via an Online Certificate
>> > Status Protocol at least every four days. OCSP responses from this
>> > service MUST have a maximum expiration time of ten days.
>> >
>> > For the status of Subordinate CA Certificates:
>> >
>> > The CA SHALL update information provided via an Online Certificate
>> > Status Protocol at least (i) every twelve months and (ii) within 24
>> > hours after revoking a Subordinate CA Certificate.
>> >
>> > 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.
>> >
>> > -- MOTION ENDS --
>> >
>> > *** WARNING ***: USE AT YOUR OWN RISK.  THE REDLINE BELOW IS NOT THE
>> > OFFICIAL VERSION OF THE CHANGES (CABF Bylaws, Section 2.4(a)):
>> >
>> > A comparison of the changes can be found at:<TBD>
>> > <
>> https://github.com/wthayer/documents/compare/master...wthayer:EV-Subject-Information
>> >
>> >
>> > The procedure for approval of this ballot is as follows:
>> >
>> > Discussion (7+ days)
>> >
>> > Start Time: TBD UTC
>> >
>> > End Time: TBD UTC
>> >
>> > Vote for approval (7 days)
>> >
>> > Start Time: TBD
>> >
>> > End Time: TBD
>> >
>> >
>> > _______________________________________________
>> > Servercert-wg mailing list
>> > Servercert-wg at cabforum.org
>> > http://cabforum.org/mailman/listinfo/servercert-wg
>> >
>>
>> --
>> Rob Stradling
>> Senior Research & Development Scientist
>> Email: rob at sectigo.com
>> Bradford, UK
>> Office: +441274024707
>> Sectigo Limited
>>
>> This message and any files associated with it may contain legally
>> privileged, confidential, or proprietary information. If you are not the
>> intended recipient, you are not permitted to use, copy, or forward it,
>> in whole or in part without the express consent of the sender. Please
>> notify the sender by reply email, disregard the foregoing messages, and
>> delete it immediately.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191003/b1ea179a/attachment-0001.html>