May 2020 CA Communication

 

Dear Certification Authority,

This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program.

To respond to this survey, login to the Common CA Database (CCADB), click on the 'CA Communications (Page)' tab, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020.

A compiled list of CA responses to the survey will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Kathleen Wilson
Mozilla CA Program Manager

ITEM 1: Impact of COVID-19 Restrictions

Mandated restrictions due to COVID-19 may result in CAs being unable to physically access private key material or get auditors onsite to perform audits of CA facilities. Mozilla has provided guidance about what a CA should do if they realize that their audits will be delayed, including filing a Bugzilla Bug with Whiteboard = [ca-compliance][audit-delay][covid-19]. Similarly, CA Compliance problems that are due to mandated restrictions regarding COVID-19, such as delayed revocations, should also be indicated in a Bugzilla Bug by appending the [covid-19] Whiteboard tag. Please monitor the mozilla.dev.security.policy forum for updates.

As a reminder, Mozilla can add certificates to OneCRL even if the CA is unable to revoke the certificates themselves. You may request this by sending email to certificates@mozilla.org. If such action is needed for a security vulnerability then also send the email to security@mozilla.org as described in Mozilla’s process for security-related problems. While adding certificates to OneCRL enables quicker propagation of revocation information, it is only relevant to Mozilla's Root Store, and CAs will still need to file a delayed-revocation Incident Report via Bugzilla whenever they are unable to meet the revocation requirements as specified in the CA/Browser Forum Baseline Requirements (BRs). (Required)

ITEM 1 COMMENTS

ITEM 2: Mozilla Root Store Policy version 2.7 Requirements and Deadlines

Version 2.7 of Mozilla’s Root Store Policy was published in December, and a January 2020 CA Communication and survey was sent. We would like to remind you about the following 4 items.
1) Beginning on 1-July, 2020, end-entity certificates MUST include an Extended Key Usage (EKU) extension containing KeyPurposeId(s) describing the intended usage(s) of the certificate, and the EKU extension MUST NOT contain the KeyPurposeId anyExtendedKeyUsage. (last paragraph in Section 5.2)
2) Certificate Policy and Certificate Practice Statement (CP/CPS) versions dated after March 2020 cannot contain blank sections and must – in accordance with RFC 3647 – only use “No Stipulation” to mean that no requirements are imposed. (item 5 in Section 3.3)
3) Ensure that all new audit reports are properly formatted and contain the required information, especially in regards to the SHA-256 Fingerprint of each audited root and intermediate certificate that was in scope of the audit being listed with no colons, no spaces, and no linefeeds.
4) Resolve entries in the “Intermediate Certs with Failed ALV Results” task list item on your CCADB home page, by following the published instructions. (Required)

ITEM 2 COMMENTS

ITEM 3: Reducing Maximum Validity Period for TLS Certificates

Mozilla plans to discuss and release an update to the Root Store Policy soon, and will appreciate your input when we discuss the potential changes in the mozilla.dev.security.policy forum. There are two potential changes that we are seeking your input on before we start the discussion. Please reply to the Sub Items below if your CA has root certificates that are enabled with the Websites trust bit.

ITEM 3 COMMENTS

SUB ITEM 3.1: Limit TLS Certificates to 398-day validity

Last year there was a CA/Browser Forum ballot to set a 398-day maximum validity for TLS certificates. Mozilla voted in favor, but the ballot failed due to a lack of support from CAs. Since then, Apple announced they plan to require that TLS certificates issued on or after September 1, 2020 must not have a validity period greater than 398 days, treating certificates longer than that as a Root Policy violation as well as technically enforcing that they are not accepted. We would like to take your CA’s current situation into account regarding the earliest date when your CA will be able to implement changes to limit new TLS certificates to a maximum 398-day validity period.

SUB ITEM 3.1 DATE

SUB ITEM 3.1 COMMENTS

SUB ITEM 3.2: Limit re-use of domain name and IP address verification to 398 days

Mozilla would like to have the domain name or IP address re-verified each time a TLS certificate is issued. However, as a first step, given that a TLS certificate will be valid for a maximum of 398 days we would like to see the domain name or IP address verification also only valid for 398 days or less. We realize that this change has an impact on CA processes and documentation, so we would like your input as to the date by which you believe your CA can make this change.

SUB ITEM 3.2 DATE

SUB ITEM 3.2 COMMENTS

ITEM 4: CA/Browser Forum Ballot for Browser Alignment

A ballot called Browser Alignment is being drafted for the CA/Browser Forum with the goal of resolving ambiguity for CAs by incorporating current root-program-specific requirements directly into the Baseline Requirements (BRs). Mozilla would like to see such a ballot succeed, so we are looking for CA input on the effective dates for the root-program-specific requirements that are not currently part of Mozilla’s Root Store Policy, and thus may be new requirements or requirements of other Root Programs that you may not have been aware of. Please reply to the Sub Items below if your CA has root certificates that are enabled with the Websites trust bit.

ITEM 4 COMMENTS

SUB ITEM 4.1: CA/Browser Forum defined-policy OID in Subscriber Cert certificatePolicies

The proposal is to add the following text to section 7.1.6.4 of the BRs:
“A Certificate issued to a Subscriber MUST contain, within the Certificate's certificatePolicies extension, one or more policy identifier(s) that are specified beneath the CA/Browser Forum's reserved policy OID arc of {joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1).”

Note: This item is also being tracked in regards to directly updating Mozilla's Root Store Policy via https://github.com/mozilla/pkipolicy/issues/212.

SUB ITEM 4.1 DATE

SUB ITEM 4.1 COMMENTS

SUB ITEM 4.2: Byte-for-byte Identical Issuer and Subject Distinguished Names

The proposal is to add the following text to section 7.1.4.1 of the BRs:
“The encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate.”
And
“The encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Name can be compared as equal according to RFC 5280, Section 7.1.”

Note: This item is also being tracked in regards to directly updating Mozilla's Root Store Policy via https://github.com/mozilla/pkipolicy/issues/213.

SUB ITEM 4.2 DATE

SUB ITEM 4.2 COMMENTS

SUB ITEM 4.3: Text-searchable PDF Audit Statements

The proposal is to add the following text to section 8.6 of the BRs:
“The Audit Report MUST be available as a PDF, and SHALL be text searchable for all information required. Each SHA-256 fingerprint within the Audit Report MUST be uppercase letters and MUST NOT contain colons, spaces, or line feeds.”

Note: This item is also being tracked in regards to directly updating the CCADB Policy via https://github.com/mozilla/pkipolicy/issues/210.

SUB ITEM 4.3 DATE

SUB ITEM 4.3 COMMENTS

SUB ITEM 4.4 OCSP Requirements

The proposal is to add the following text to section 4.9.10 of the BRs:
“The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.
For the status of Subscriber Certificates:
1. OCSP responses MUST have a validity interval greater than or equal to eight hours;
2. OCSP responses MUST have a validity interval less than or equal to ten days;
3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.
4. For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate."

And add the following text to section 7.1.2.3(c, authorityInformationAccess) of the BRs:
“This extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA's OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CA's certificate (accessMethod = 1.3.6.1.5.5.7.48.2).”

Note: This item is also being tracked in regards to directly updating Mozilla's Root Store Policy via https://github.com/mozilla/pkipolicy/issues/211.

SUB ITEM 4.4 DATE

SUB ITEM 4.4 COMMENTS