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

Thu Oct 10 17:01:22 MST 2019

Wayne, a simple question – I see that Ballot SC23 has RFC 6962 overriding RFC 5280 – so 5280 will *still* prohibit two “certificates” from having the same serial number (such as a certificate and potentially a pre-certificate), but 6962 will separately say “ignore that part of 5280”.  We though 5280 was so important before that we passed Ballot 134 to say a pre-certificate was *not* a certificate under 5280, but your ballot removes that statement.

Is this normal?  Does IETF allow that, or should we instead seek to amend RFC 5280 to clarify that a certificate and per-certificate are allowed to have the same serial number?  (I know on other issues in the past we have been told that we *can’t* proceed unless we go back to IETF and amend some RFC that prohibits or regulates some action – if it’s as easy as drafting another RFC that says “you can ignore Section X of this prior RFC” then wouldn’t that create confusion?

Anyone looking at RFC 5280 might not know of RFC 6962’s amending language, and so still believe two certificates are not allowed to have the same serial number.  Shouldn’t we focus on changing 5280?  Should we ask IETF officials for their opinion?

Kirk

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Wayne Thayer via Servercert-wg
Sent: Thursday, October 3, 2019 10:30 AM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: [EXTERNAL][Servercert-wg] Ballot SC23: Precertificates

Ballot SC23: Precertificates

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 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:

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 - Certificate Transparency. This is a modification of the uniqueness requirements of RFC 5280  - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile section 4.1.2.2 under these Baseline Requirements.

REPLACE section 4.9.10 of the Baseline Requirements in its entirety with:

4.9.10 On-line Revocation Checking Requirements

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(1)):

A comparison of the changes can be found at: https://github.com/wthayer/documents/commit/f0b7c0a27fe51e73d5ed5d8d453024c51713ed70

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 10-October 2019 18: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/20191011/c3caef9f/attachment-0001.html>