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

Tue Oct 8 14:40:51 MST 2019

Hi Ryan,

Entrust Datacard supports the intent of the ballot; however, we are asking that the ballot provide a reasonable time to implement.

I don’t think that the IP review period should be considered working time. My thinking is that the IP review period is to help organizations protect their IP. I don’t think the CAB Forum should count on the CAs to develop changes during a period where the ballot may be revoked. It has been suggested that ballots should include a period to allow the CAs to implement changes, both technical and procedural, and also allow effective testing as required. I do not think that 30 days as a default would be sufficient. We should also consider that BR changes may impact all CA members and non-members such as third party subCAs, so the effectivity period should consider communication time. Finally, the effectivity period should consider the blackout period which occurs towards the end of the year.

I don’t think that 6 months should not be considered a long time. The effectivity period should allow CAs to address this type of change as a non-emergency issue. The period should allow proper design implementation and testing. The period should allow most CAs to be complete in a comfortable period before the deadline. In essence all CAs may not need 6 months, but I see no reason for CAs to implement in a blackout period or suffer the risk of being non-compliant for this type of issue.

Regarding the security of users, I think that the CAs have addressed this issue with CT logging. Although the BRs do not require CT, the CAs support CT. Although the BRs do not require precertificates, most CAs issue precertificates. Unfortunately, the BRs state that a precertificate “shall not be considered to be a “certificate” subject to the requirements of RFC 5280.” My assumption is that this statement may just be a symptom of the problem that there has been misinterpretation as to how to provide the status of a precertificate. I assume this problem dates back to when we deployed CT at the start of 2015. However, since a precertificate has a poison extension, the risks to users of not knowing its status appears to be extremely limited.

I would request that the ballot proposer and endorsers consider allowing for a future effectivity date, which will provide sufficient time for CAs to be compliant and avoid the blackout period starting towards the end of 2019.

Thanks, Bruce.

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Monday, October 7, 2019 5:34 PM
To: Bruce Morton via Servercert-wg <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] [EXTERNAL] Ballot SC23: Precertificates

Bruce,

That sounds like a really long time. Could you share data about the presumed impact?

In the past, it was suggested that 30 days (in addition to the 30 days provided by the IP review period) is sufficient for changes.

If the argument is that it requires significant effort, I think any data that can be used to establish this would be useful. There's plenty of data available that disputes the challenge or complexity here. For example, we've already seen Commercial Off the Shelf Software and Open Source software able to comply with this within hours, using existing tools and capabilities.

In short: I think any CA asking for a delay has a duty of care to share why they believe a delay is in the community interest, especially when the failure to comply calls into question the security for users.

On Mon, Oct 7, 2019 at 5:24 PM Bruce Morton via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
Hi Wayne,

This ballot may impact how CAs are providing OCSP responses precertificates; however, there is no future effectivity date provided. To allow the CAs to be compliant, I would request that we have a effectivity date which is 6 months after the IPR review period is completed.

Thanks, Bruce.

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

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.
________________________________

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
_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org<mailto:Servercert-wg at cabforum.org>
http://cabforum.org/mailman/listinfo/servercert-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191008/d438920b/attachment-0001.html>