SC31 - Browser Alignment

[sleevi]

Introduction

As a regular part of Root Program maintenance, and reflecting the independent nature of each Root Programs' needs and requirements, Root Programs have introduced a number of requirements above and beyond those captured in the Baseline Requirements. For Root Programs, this approach results in a lack of certainty, as the requirements are not independently audited and assessed, unless otherwise provided for. For CAs, this introduces confusion when applying to have the same CA certificate trusted by multiple Root Programs, as the effective requirements that the CA and certificates need to comply with are the union of the most-restrictive policies.

The following ballot attempts to resolve this uncertainty for Root Programs, and ambiguity for CAs, by incorporating Root Program-specific requirements that are either effective or will, in the future, be effective.

Effective dates

Compliance	Section(s)	Summary Description
On Adoption	All	Except as specified, all requirements are existing requirements of one or more Root Programs and the effective date specific to that Root Program is in the past. As such, these requirements take immediate effect
On Adoption	BRs 7.1.2.3	Subscriber Certificates MUST NOT contain the id-kp-anyExtendedKeyUsage value in the extendedKeyUsage extension
2020-08-01T00:00:00Z	BRs 8.6	Audit Reports for Audit Periods on or after this date MUST comply with the Audit Report requirements
2020-09-01T00:00:00Z	BRs 6.3.2, EVGs 9.4, EVGs Appendix F	Certificates MUST NOT be valid for more than 398 days, and SHOULD NOT be valid for more than 397 days
2020-09-30T00:00:00Z	BRs 4.9.10	OCSP responses MUST NOT have validity intervals less than the minimum or greater than the maximum and must be refreshed in a timely manner
2020-09-30T00:00:00Z	BRs 7.1.4.1	Subject and Issuer Name encoding for all certificates in the certification path of new Certificates MUST be byte-for-byte identical
2020-09-30T00:00:00Z	BRs 7.1.6.4	A CA/Browser Forum Reserved Policy OID MUST be present in Subscriber Certificates
2020-09-30T00:00:00Z	BRs 7.2.2, 7.3, 7.3.2	OCSP and CRL responses MUST include a reason code for Subordinate CA Certificates

Summary of Changes

Audit Reporting

Multiple Root Programs have placed specific requirements on the format and contents of audits. Many common requirements are expressed as part of the CCADB Policy, with additional requirements expressed by Mozilla and Microsoft regarding the disclosure of in-scope CAs and the format of the reports themselves.

• Specific formatting requirements for SHA-256 Fingerprints
• Significant expansion of the required information (see Section 8.6)
• An authoritative English version of the audit MUST be available
• The audit report MUST be delivered within 3 months (from a SHOULD), and any delays MUST be accompanied with an explanatory letter from the auditor (from a MAY)
• The audit report MUST be available as a text-searchable PDF.
• The associated audit criteria versions are updated to their newer versions. The versions are newer, but not necessarily the newest, to reflect audits that may still be provided after the effective date for the previous year's period.
• ETSI audits MUST reference that they considered the CA/Browser Forum criteria.

These requirements are for all new audits that are for the period on-or-after 2020-08-01. Audits that have already begun, or which will begin during the IP review period of this ballot, SHOULD comply, while Audits afterwards MUST comply.

OCSP

The Microsoft Root Program expresses a more tightly defined certificate profile for OCSP, and also places requirements on CRLs for intermediates. These requirements include:

• OCSP MUST be supported for end-entity/Subscriber certificates with no exceptions. Previously, an exception was given to contractually-defined OCSP stapling, allowing the responder URL to be omitted from the certificate. (Section 7.1.2.3 (c))
• OCSP for intermediate certificates is now a MAY level requirement, where previously it was a MUST. As CRLs are already a MUST level requirement, this aligns with Microsoft's "either/or" approach, and with Apple/Mozilla/Google's preference for CRLs for intermediate certs. Overall, AIA is still a SHOULD, because the Issuing CA's certificate is still a SHOULD. (Section 7.1.2.2 (c))
• The validity interval for an OCSP response (thisUpdate to nextUpdate) is more explicitly defined. (Section 4.9.10)
• CAs MUST provide fresh OCSP responses, and in some cases, sooner than the four days required under the current BRs. For certificates with a validity interval less than sixteen hours, it must be at 1/2 the validity interval (e.g. 8 hours or less). For certificates with a validity interval greater than sixteen hours, it must be the earlier of 4 days or 8 hours before the expiration of the current response. Previously, if the validity interval was 96 hours (4 days) or less, no such requirement existed. (Section 4.9.10)
• OCSP responses for intermediate CAs, if provided, MUST contain a revocationReason (Section 7.3)
• OCSP responses MUST NOT contain a reasonCode singleExtension. Any reason, if present, should be stated in the revocationReason (Section 7.3.2)

These requirements largely come into effect 2020-09-30, particularly as they may require new ceremonies for subordinate CA certificates, with the exception of the stapling exception sunset.

CRLs

The Microsoft Root Program places specific requirements on CRLs, particularly those for Subordinate CAs (including Cross-Certificates). This requires that the CA explicitly enumerate the reason for the revocation.

• CRLs for Subordinate CAs MUST include a reasonCode entry extension indicating the reason for revocation. (Section 7.2.2 (a)).
• The reasonCode extension MUST NOT be present for unspecified revocations. RFC 5280 places this as a SHOULD, due to requiring an additional 12 bytes to encode the extension that is semantically equivalent to omitting it. The combination of requiring meaningful revocation reasons and wanting to ensure reasonably-sized CRLs means this value MUST NOT be present. (Section 7.2.2 (a))

These requirements come into effect 2020-09-30, as issuing new CRLs requires a new ceremony.

Certificate Policies

The Microsoft Root Program places requirements on the contents of Certificate Policies, in order to ensure consistent distinguishing of certificates that comply with the Baseline Requirements and EV Guidelines.

• The certificatePolicies extension for Subscriber Certificates MUST contain at least one CA/Browser Forum defined-policy OID. (Section 7.1.6.4)

These requirements come into effect 2020-09-30, as it may require the creation of new Subordinate CA Certificates if the existing issuing CA certificates are not permitted to issue for these policies.

Authority Key ID

RFC 5280 requires that the authorityKeyIdentifier MUST be present and MUST contain a keyIdentifier field for all certificates other than self-signed certificates intended as Root Certificates. ITU-T's X.509 permits both key ID and issuer name to be present within an authorityKeyIdentifier, while RFC 5280 discourages this with prose, and Mozilla's Root Program explicitly forbids this.

• The authorityKeyIdentifier field MUST be present, MUST contain a keyIdentifier, and MUST NOT contain authorityCertIssuer or authorityCertSerialNumber field. (Section 71.2.2(h), Section 7.1.2.3(g))

This requirement is effective immediately.

Extended Key Usage

The Microsoft Root Program places a number of requirements on the use of the Extended Key Usage extension, particularly for Subordinate CA certificates, which includes both Technically-Constrained Sub CAs and Cross Certificates. The requirement is that a single subordinate CA MUST NOT contain EKUs that indicate multiple different usages (e.g. e-mail and TLS).

• For Subordinate CA Certificates that are Cross-Certificates, EKU MAY be present. (See 7.1.2.2 (g))
• For all other cases, the id-kp-serverAuth EKU MUST be present for TLS-issuing sub-CAs and MUST NOT be present with certain other identified usages. (See 7.1.2.2 (g))
• id-kp-clientAuth MAY be present for TLS-issuing sub-CAs (e.g. for server-to-server authentication that uses both id-kp-clientAuth and id-kp-serverAuth). It MAY also be present for non-TLS-issuing sub-CAs (e.g. for client certificates)

These requirements are effective immediately.

• For TLS Subscriber Certificates, the value id-kp-anyExtendedKeyUsage MUST NOT be present.

This requirement is effective immediately, as this ballot effective date will be after the Mozilla effective date of 2020-07-01.

Name Encoding Rules

Section 7.1.4.1 of the existing Baseline Requirements place requirements on the encoding of Subject and Issuer Names, constraining the profile in RFC 5280 by making a SHOULD into a MUST. However, some CAs have interpreted the requirement differently, causing incompatibilities with Apple and Google software. In order to try and clarify the existing requirement, Section 7.1.4.1 is restated to ensure byte-for-byte equality.

• The Issuer field within a certificate (including Subscriber, Sub-CA, and Root CA) MUST be byte-for-byte identical with the Subject field of the issuing certificate. (Section 7.1.4.1)
• The Subject field of a CA Certificate MUST be byte-for-byte identical among all certificates for that Subject. (Section 7.1.4.1)

These requirements come into effect 2020-09-30. As these requirements affect certification path building and discovery, they apply to the certification path(s) of all certificates issued after the effective date. This allows CAs that have issued non-compliant CAs, including for non-TLS use cases, do not have to revoke such certificates; however, such non-compliant certificates MUST NOT be used to issue any certificates.

Note: Because this affects certification path building, which happens before certificate validity or revocation checks, the CA MUST ensure that their Subject names are unique across all CA certificates, including those that have been revoked or expired. CAs MUST transition to new issuing CA certificates if there are non-compliant certificates in the path.

CP/CPS

The Baseline Requirements, Section 2.3, already requires annual update of their CP/CPS to ensure conformance to the latest version of the Baseline Requirements. The Mozilla Root Program places specific requirements as to how the CA demonstrates compliance with this requirement, by requiring that the CP/CPS be explicitly versioned and incremented upon the completion of the review, even if no other changes are necessary.

• Require that the CP/CPS have its version incremented annually, at minimum, to indicate compliance with the Baseline Requirements (Section 2.3)

This requirement is effective immediately.

Key Algorithms and Sizes

The Apple, Microsoft, Mozilla, and Google Root Programs all effectively prohibit DSA, and so it is removed.

• DSA support is removed (Section 6.1.5)
• RSA modulus size MUST be divisible by 8 (Section 6.1.5)
• RSA modulus size, when encoded, must be at least 2048 bits. This resolves ambiguities with leading zeroes. (Section 6.1.5)

This requirement is effective immediately.

Signature Algorithms

The Mozilla Root Program provides explicit normative guidance on the encoding of signatureAlgorithm and subjectPublicKeyAlgorithm fields. This language either resolves ambiguities from the relevant RFCs, or addresses SHOULDs that permit multiple non-standard encodings or variables by making them MUSTs. Similarly, it requires that the hash algorithm for an ECDSA signing key MUST be appropriately sized, where previously it was a SHOULD.

The Mozilla Root Program places significantly greater restrictions on when a SHA-1 signature can be created, including for Cross-Certificates or infrastructure CA certificates such as OCSP Responders.

• The required encodings for Algorithm fields are explicitly specified, including clarifying the use of NULL within optional fields (Section 7.1.3)
• The use of the SHA-1 hash algorithm with an RSA key pair is significantly restricted (Section 7.1.3.2.1)
• CAs MUST NOT use the SHA-1 hash algorithm with an ECDSA key pair. (Section 7.1.3.2.2)

This requirement is effective immediately.

Certificate Lifetimes

The Apple Root Program requires that, effective 2020-09-01T00:00:00Z, certificates MUST NOT have a validity period greater than 398 days and SHOULD NOT have a validity period greater than 397 days.

• On 2020-09-01T00:00:00Z, define the Validity Period as being measured by the notBefore/notAfter, aligning with RFC 5280, rather than the date of issuance, which may be different than the notBefore. (Section 1.6.1)
• On 2020-09-01T00:00:00Z, the validity period for Subscriber certificates MUST be less than or equal to 398 days, and SHOULD be less than or equal to 397 days. (BRs Section 6.3.2, EVGs Section 9.4, EVGs Appendix F)

Clarify Effective Dates

The Apple, Mozilla, and Google Root Programs treat effective dates as on that day, 00:00:00 UTC. Some CAs have interpreted these dates as relative to their local timezone, and find that their certificates are not compliant with and treated as misissued by these Root Programs.

• Clarify that the effective time for requirements is on the effective date, at 00:00:00 UTC (BRs Section 1.6.4, EVGs Section 6)

This clarification is effective immediately.

Prohibit Subscriber Key Generation

the Mozilla Root Program prohibits CAs from generating Key Pairs for Subscriber Certificates if they are capable of being used for TLS.

• Clarify Section 6.1.1.3 / Section 6.1.2 that the CA MUST NOT use a Key Pair that the CA generated (either during this request or a previous request) within a TLS Certificate for a Subscriber

This requirement is effective immediately.