[Servercert-wg] [EXTERNAL] Draft Ballot: Precertificates and OCSP

Bruce Morton Bruce.Morton at entrustdatacard.com
Fri Sep 20 14:18:15 MST 2019


Hi Wayne,

In summary, does this mean that a precertificate is a certificate per RFC 5280 with the exception of RFC 5280 section 4.1.2.2, and as such, OCSP should respond to the status of a precertificate as if a certificate has been issued?

Thanks, Bruce.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Wayne Thayer via Servercert-wg
Sent: Friday, September 20, 2019 5:06 PM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [EXTERNAL][Servercert-wg] Draft Ballot: Precertificates and OCSP

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.
________________________________
In a discussion on the mozilla.dev.security.policy list [1], it was pointed out that the BR requirements related to precertificates conflict with the expectations of some browsers for valid OCSP responses to be supplied in response to a request for a serial number in a precertificate. This ballot is a minimal attempt to resolve the issue.

It also attempts to remove the 2013 effective dates from BR section 4.9.10. I've restructured the language in the last two paragraphs of that section without intending to change the meaning, but the current language is a bit confusing.

I'll appreciate everyone's feedback on this draft ballot. I'm also looking for two endorsers.

Thanks,

Wayne
========================

Ballot SCXX: Precertificates and OCSP


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, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the serial number uniqueness requirements of section 4.1.2.2 of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements.


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 a request for status of a certificate that has not been issued, then the responder SHOULD NOT respond with a "good" status. OCSP responders for CAs which 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(1)):


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/20190920/f2bb54e6/attachment-0001.html>


More information about the Servercert-wg mailing list