[Servercert-wg] Draft Ballot: Precertificates and OCSP

[Wayne Thayer]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190930/36000f14/attachment-0001.html>