SC31 - Browser Alignment #195
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
The requirements on Audit Report content are updated to align with the requirements placed by Mozilla. The requirements on Audit Report delivery are updated to align with the requirements placed by Microsoft. The requirements on OCSP responses are updated to align with the requirements placed by Microsoft. The requirements on certificatePolicies for Subscriber Certificates are updated to align with the requirements placed by Microsoft.
RFC 5280 requires that authorityKeyIdentifier MUST be present and MUST contain a keyIdentifier field for all certificates except self-signed certificates intended as trust anchors. Mozilla further requires that authorityKeyIdentifiers not simultaneously include the key ID and the issuer's name and serial number.
Clarify Section 18.104.22.168 to better express the rules in RFC 5280, Section 22.214.171.124 and 126.96.36.199. In general, RFC 5280 requires that new certificates MUST use the UTF8String or PrintableString encodings within DirectoryString subject names. There are exceptions given, for backwards compatibility, where the CA MAY use the pre-existing encoding. This aligns the MAY in RFC 5280 with the MUST in the implementations of Mozilla, Apple, and Google. The existing text tried to capture this MUST, but in a way that was ambiguous. Some CAs interpreted the language as reiterating the MAY, rather than expressing the MUST. The objective is to ensure that the entire contents of the Subject field SHOULD be memcmp()-able with the entire contents of the Issuer field. RFC 2459 defined a subset of the algorithm from X.500, only requiring case folding and whitespace normalization for PrintableString, which RFC 3280 continued. While RFC 5280 expanded this (including the StringPrep profile), implementations have not adopted this. However, the situations (in RFC 5280-and-predecessors) where these apply do not apply in the context of the Baseline Requirements; for example, there is no need for interoperability with LDAP identities in TLS server certificates. A CA can easily comply with this by ensuring 1) They don't issue new certificates for existing Subjects, generally. When they do (e.g. for cross-signing), ensure it's byte-for-byte identical 2) For new certificates - Issuing CAs, Root CAs, or Subscriber - they ensure they always use UTF8String or PrintableString (recommended: UTF8String only)
This updates the requirement on the CP/CPS to make an explicit annual versioning scheme required, as required by Mozilla. Related, this updates the Audit Report requirements to align with the current Microsoft and CCADB requirements, by removing the requirement for CAs to document explicitly which CAs are out of scope. It also aligns the language for "publicly accessible" by unhyphenating it, as well as adding Microsoft's requirement that the Audit Report be provided as a text-searchable PDF, in line with other industry's requirements on electronic document submission.
This incorporates the changes from the Mozilla Root Store Policy 2.7, which explicitly enumerates the permitted encodings for algorithms. Major changes to the BRs: - Explicitly enumerates permitted RSA key algorithms - Forbids the use of P-521 - Explicitly requires the signature+hash algorithm choice is appropriate for the key size - Explicitly enumerates the permitted cases for the use of SHA-1, such as only permitting its use with RSA. Major differences from Mozilla requirements: - The main difference is in the set of exceptions permitted for the issuance of SHA-1 Certificates (which presently precludes Certificates). Mozilla only permits the serial number changing if the new serial number is the same length as the old serial number. The BRs require that serial numbers are unique (RFC 5280), as well as requires that serial numbers contain at least 64-bits of entropy. Regardless of whether the Mozilla policy is interpreted as relaxing these requirements of the BRs, this change restructures the exception from how Mozilla worded it, to try and make it clearer that SHA-1 issuance does not supercede other requirements, including that the 'new' certificate must fully conform to the BRs.
Align with Microsoft's latest root program policy, which requires the CA indicate the reason for revocation if the revoked certificate is an intermediate certificate. To avoid terminology confusion, this makes the requirement apply for Root CA and Subordinate CA Certificates alike. This incorporates RFC 5280's SHOULD NOT for unspecified (0) as a MUST NOT. It also incorporates the prohibition on certificateHold, by way of Section 4.9.13. This clarifies for OCSP responses that the reason MUST be indicated via the RevokedInfo. RFC 6960 permits any CRL entry extension to also appear as an extension in the singleResponses field (see RFC 6960, Section 4.4.5), thus it's possible to omit from the RevokedInfo and instead stash as an extension
Highlighted in #10 (comment) , but more specifically, the Microsoft requirement states (emphasis added) Issuing CA certificates that chain to a participating Root CA must be constrained to **a single EKU** (e.g., separate Server Authentication, S/MIME, Code Signing, and Time Stamping uses.
Align the BRs with Apple requirements (https://support.apple.com/en-us/HT211025) This aligns the normative language in 6.3.2 to a clearer form (opting for "MUST NOT ... greater than" instead of "MUST ... no greater than") and the formatting of 'validity period' to the defined term "Validity Period" Co-authored-by: sleevi <email@example.com>
As requested by Clint Wilson at Apple, avoid ambiguity in relevant dates by clarifying that the effective datetime is the 00:00:00 on the effective date in UTC. An alternative approach would have been to use ISO 8601-1 timestamps, but that was seen as too repetitive and may cause CAs to overlook the actual date.
Merge in feedback from Microsoft based on their Root Program and upcoming changes to their Root Program Policy * The OCSP changes are partially reverted * Kept: A minimum validity period (eight hours) * Removed: The maximum validity of seven days is now restored to the existing 10 days * Changed: For validity periods < 16 hours, refresh must be 1/2 the interval. For validity > 16 hours, refresh must be the earlier of 4 days (existing BRs) or 8 hours before expiration (new) * P-521 restrictions (from the Mozilla Root Program) are removed * Microsoft would like to keep P-521 for the time being. It is still prohibited by Mozilla * Explicitly clarify that id-kp-clientAuth is allowed to be included in TLS server certificates and in TLS subordinate CAs. * Existing language meant it was "SHOULD NOT"; new language is that it MAY. * Clarify the Audit Period language by using the defined term * Clarify that ETSI audits MUST make reference to the applicable CA/Browser Forum documents
This updates to Mozilla policy, based on the mailing list discussion, to incorporate Section 5.2 of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#52-forbidden-and-required-practices to explicitly forbid Subscriber Key Generation for TLS server certificates. It also updates the Subscriber EKU to reflect that beyond requiring id-kp-serverAuth/id-kp-clientAuth, the value anyExtendedKeyUsage is explicitly prohibited.
Clarify that the new requirements for Audit Reports are triggered based on what dates were under audit. This allows audits that have started before the ballot's Effective Date to continue to adhere to the existing rules, while ensuring that new audits (effectively, audits started after the effective date) follow the new requirements. Rather than create a self-referential date, which then would need to be updated in a subsequent ballot, simply use August 1 as a stand-in for the effective date.
Address the comments from SecureTrust by making it clearer that the requirements apply to both IDNA2003 and/or IDNA2008, by incorporating RFC 8399. Address the comments from Mozilla by clarifying that as far as the Baseline Requirements go, this is not intended to require revocation of existing, non-TLS-capable CAs, but is intended to ensure that all newly issued certificates comply with this requirement. Any CA which has a non-compliant configuration may need to transition to a new issuing intermediate, and thus an effective date of 2020-09-30 is provided to allow for key ceremonies to be performed.
Historically, Section 188.8.131.52 required CAs MUST support both CRLs and OCSP for Subordinate CA certificates (that is, the Sub-CA certificates themselves). An exception was given for stapling, but that exception largely did not make sense, because support for OCSP Multi-Staple is rare, although TLS 1.3 made that easier. Existing Root Programs prefer CRLs (Mozilla, Apple, Google) for Sub-CAs, and either make no statement about OCSP, or make it optional so that a CA only needs to support one of either OCSP or CRLs (Microsoft). As requiring OCSP for a Sub-CA effectively necessitates OCSP delegated signing, due to wanting to avoid having to periodically access root key material, and since OCSP delegated signing is not necessarily desirable, this makes OCSP support a MAY level for Sub-CAs, relying on the existing MUST level provision for CRLs.
The "anyExtendedKeyUsage" restriction for Subscriber certificates would effectively happen before the IP review period had concluded. Rather than have it retroactive, make it "effective immediately" Also, address some wording suggestions from @dzacharo to be clearer about the prohibition on Subscriber Key Generation.
This attempts to clarify that the revocationReason MAY be omitted for Subscriber certificates, but MUST NOT be omitted for CA certificates. It also attempts to clarify that if an Issuing CA was issuing multiple types of certificates, they MAY continue to use certificateHold for those certificates. However, as the restriction on EKUs comes into effect 2020-09-30, they MUST transition to separate intermediates for any new certificates, not subject to the BRs, that they may wish to suspend in the future. Existing certificates, not subject to the BRs, MAY be suspended.
In the process of incorporating Microsoft's requirements on EKUs, the requirement was worded in a way that clarified the existing RFC 6960 requirements (and those of Section 4.9.9 of the BRs). This caused confusion for some, thinking it was a new requirement being introduced as part of a browser alignment, but it's actually an existing requirement that goes back to v1 of the BRs. To resolve this confusion, move this requirement to the "Cleanups and Clarifications" ballot, to make sure that it is more prominent for CAs.
Add this suggestion to a batch that can be applied as a single commit. This suggestion is invalid because no changes were made to the code. Suggestions cannot be applied while the pull request is closed. Suggestions cannot be applied while viewing a subset of changes. Only one suggestion per line can be applied in a batch. Add this suggestion to a batch that can be applied as a single commit. Applying suggestions on deleted lines is not supported. You must change the existing code in this line in order to create a valid suggestion. Outdated suggestions cannot be applied. This suggestion has been applied or marked resolved. Suggestions cannot be applied from pending reviews. Suggestions cannot be applied on multi-line comments. Suggestions cannot be applied while the pull request is queued to merge.