[Servercert-wg] Draft Ballot: Precertificates and OCSP

[Wayne Thayer]

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/35cf0ccb/attachment.html>