Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SC31 - Browser Alignment #195

Merged
merged 30 commits into from Jul 17, 2020

Conversation

sleevi
Copy link
Contributor

@sleevi sleevi commented Jun 16, 2020

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.

sleevi and others added 24 commits Jun 16, 2020
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.
Microsoft Policy requires that OCSP MUST be supported. This removes
the exception for stapling.
Both Microsoft and Mozilla forbid the use of DSA.

Mozilla forbids the use of NIST P-521 and requires that the
hash algorithm for ECC keys matches in output length as the
key size (e.g. P-256 = ecdsa-with-sha256).
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 7.1.4.1 to better express the rules in RFC 5280, Section 4.1.2.4 and 4.1.2.6.

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)
Update the audit criteria to align with the current versions used by
WebTrust.
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 <ryan.sleevi@gmail.com>
Add in the fingerprint formatting requirements from the CCADB policy at https://www.ccadb.org/policy at Mozilla's request
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.
This was a wording mangling from how "technically constrained sub-CAs" are defined versus how the Mozilla policy defined things. This aligns with the Mozilla policy, and, presumably, the Microsoft policy.
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.
As these may require a ceremony to produce new CRLs, particularly
for intermediate certificates, the effective date for the BRs is
set as 2020-09-30. Root Programs MAY impose earlier effective dates,
at their discretion.
Certificate Policies may require establishing a new issuing
intermediate, if the CA assigned a policy OID to the intermediate
and did not include one or more CA/Browser Forum OIDs. Because this
may require a ceremony, the effective date is 2020-09-30.
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.
While it affects how subjectAltNames/Generalnames are handled, it doesn't change the comparison algorithm for DNs.
Historically, Section 7.1.2.2 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.
sleevi added 2 commits Jun 17, 2020
The effective date for EV was accidentally left off. This avoids a repeat of Ballot 193 / Ballot 197.
sleevi added 2 commits Jun 22, 2020
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.
@sleevi sleevi changed the base branch from master to Ballot-SC30-and-31 Jul 17, 2020
@sleevi sleevi merged commit 1e0f766 into cabforum:Ballot-SC30-and-31 Jul 17, 2020
1 check was pending
@sleevi sleevi deleted the 2019-10-Browser_Alignment branch Jul 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants