SCXX - Certificate Profiles

[CBonnell]

NOTE: For previous discussion on this draft, see: sleevi#36

Comparison of Changes to v1.8.1

Definitions

• "Cross Certificate" now becomes "Cross-Certified Subordinate CA Certificate", to clarify that it unambiguously is treated as a subordinate CA certificate. This change is reflected primarily in the profiles.

• "Technically Constrained Subordinate CA Certificate" is changed to make it explicit that it's only a TCSC if it meets one of the defined profiles.

Cleanups

• 3.2.2.5 is tweaked to remove the language about where a validated iPAddress can appear, as that's now reflected in the profiles themselves.

• 4.2.2's remarks about Internal Server Names is updated to refer to 3.2.2.4/3.2.2.5, rather than the subjectAltName requirements, as the subjectAltName was refactored.

Root CA Certificates (7.1.2.1)

The scope of what classifies for this section is addressed in Section 1.6.1 of the BRs.

• version: RFC 5280, Section 4.1.2.1 states "When extensions are used, as expected in this profile, version MUST be 3 (value is 2)". Extensions are always used.

• serialNumber: RFC 5280, Section 4.1.2.2 states "the serial number MUST be a positive integer". Further, it notes that zero is not positive, as "Note: non-conforming CAs may issue certificates with serial numbers that are negative or zero." Section 7.1 of the BRs requires that at least 64 bits of output from a CSPRNG.

• signature: Unchanged. This continues to be addressed by BRs 7.1.3.2

• issuer: Unchanged. This was previously within BRs 7.1.4.1

• validity: This is a new requirement. The validity intervals were chosen based on the Microsoft Root Program requirements, A.3.

• subject: BRs 7.1.4.3 already required countryName, organizationName, and commonName, and set forth rules for validating. All other fields were to be required to be validated as set forth in the CA's CP/CPS. This profile extends guidance for the semantics of stateOrProvinceName, localityName, postalCode, and streetAddress, in line with the BRs existing gudance for Subscriber Certificates (7.1.4.2.2). Although these are left as MAY in v1, the intent is to move them to NOT RECOMMENDED/MUST NOT in v2 (for new certificates).

• issuerUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• subjectUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• signatureAlgorithm: RFC 5280, Section 4.1.2.2 states "This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate"

Extensions

• authorityKeyIdentifier:

  • keyIdentifier: RFC 5280, 4.2.1.1 states "The keyIdentifier field of the authorityKeyIdentifier extension MUST be included in all certificates generated by conforming CAs to facilitate certification path construction. There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted." Although this MAY indicates it is optional for root certificates (with good reason), this profile continues to RECOMMEND that it be included, as this helps assist applications such as Microsoft Windows (among several), which can prioritize matches between the subjectKeyIdentifier and authorityKeyIdentifier over matches like subject and issuer name. In the absence of an authorityKeyIdentifier on the root, a cross-signed certificate may receive higher preference than the self-signed root, resulting in longer chains and more expensive path processing.
  • authorityCertIssuer: This is a new requirement. This is partially derived from Mozilla Root Store Policy, which restricts the inclusion. However, it is also explicitly restricted for efficiency: the authorityCertIssuer / authorityCertSerialNumber method of authorityKeyIdentifiers is less efficient to transmit and process. This is not broadly supported in Web PKI implementations, nor necessary for Web PKI.
  • authorityCertSerialNumber: This is a new requirement. This is partially derived from Mozilla Root Store Policy, which restricts the inclusion. However, it is also explicitly restricted for efficiency: the authorityCertIssuer / authorityCertSerialNumber method of authorityKeyIdentifiers is less efficient to transmit and process. This is not broadly supported in Web PKI implementations, nor necessary for Web PKI.
  • Note: The prohibitions on authorityCertIssuer and authorityCertSerialNumber align with BRs 7.1.2.2 (h), for subordinate CAs.

• basicConstraints: RFC 5280, Section 4.2.1.9 and BRs 7.1.2.1 (a)

• keyUsage: BRs 7.1.2.1 (b) already explicitly require usages be asserted. A new requirement/clarification makes it clear that other usages MUST NOT be asserted. This is derived from the fact that CA private keys must not be used except as specified.

• subjectKeyIdentifier: RFC 5280, Section 4.2.1.2 states "... this extension MUST appear in all conforming CA certificates ...", and sets forth expected semantics. A new requirement is introduced, in line with the remarks with respect to authorityKeyIdentifier, that the SKI needs to be unique for each unique public key. Multiple certificates for the same public key can share the same SKI, but different public keys should not.

• extKeyUsage: BRs 7.1.2.1 (d)

• certificatePolicies: BRs 7.1.2.1 (c). When present, this aligns with subordinate CAs, previously expressed in BRs 7.1.2.2 (a)

• Signed Certificate Timestamp List: This clarifies that, when present, the extension contents MUST conform with RFC 6962's requirements. This is derived from 7.1.2.4.

Cross-Certified Subordinate CA (7.1.2.2)

This is meant to capture any time a certificate is issued with the same name and key of an existing certificate.

The first time a name and key are used, the CA uses one of 7.1.2.3, 7.1.2.4, 7.1.2.5, or 7.1.2.6. However, if that name or key are reused, then the profile of 7.1.2.2 applies.

This means, for example, if a CA is performing a CA key signing ceremony under one of 7.1.2.3 - 7.1.2.6, and a mistake is made and detected (e.g. post-issuance linting), before performing the ceremony again, the CA MUST confirm that the requirements of 7.1.2.2 are met OR they must use a new name and key. This is explicitly intentional, to reduce the risk of "buggy" certificates using the same name and key as "good" certificates, and to ensure that ceremonies are carefully reviewed. Changing the name OR the key is sufficient to allow both ceremonies to be performed under 7.1.2.3 - 7.1.2.6, although in general, changing the key will be best, due to the interplay with subjectKeyIdentifier.

• version: RFC 5280, Section 4.1.2.1 states "When extensions are used, as expected in this profile, version MUST be 3 (value is 2)". Extensions are always used.

• serialNumber: RFC 5280, Section 4.1.2.2 states "the serial number MUST be a positive integer". Further, it notes that zero is not positive, as "Note: non-conforming CAs may issue certificates with serial numbers that are negative or zero." Section 7.1 of the BRs requires that at least 64 bits of output from a CSPRNG.

• signature: Unchanged. This continues to be addressed by BRs 7.1.3.2

• issuer: Unchanged. This was previously within BRs 7.1.4.1

• validity: This is a new requirement. The notBefore date is allowed to be any date in the range of [earliest in-scope doppelganger CA's notBefore, signing time], to allow existing certificates (with a notBefore earlier than the current time) to continue to work with the new Cross-Certified Subordinate CA, and to assist in path building for applications that prioritize paths based on the notBefore date. The notAfter date does not have an upper-bound defined, as applications may also prioritize paths based on notBefore being earlier, or later, than other doppelganger CAs.

• subject:

  • BRs 7.1.4.3 already required countryName, organizationName, and commonName, and set forth rules for validating. All other fields were to be required to be validated as set forth in the CA's CP/CPS. This profile extends guidance for the semantics of stateOrProvinceName, localityName, postalCode, and streetAddress, in line with the BRs existing gudance for Subscriber Certificates (7.1.4.2.2). Although these are left as MAY in v1, the intent is to move them to NOT RECOMMENDED/MUST NOT in v2 (for new certificates).
  • BRs 7.1.4.1 already requires subject/issuer pairs be byte-for-byte identical. This clarifies that the identical-ness requirement supersedes any requirement on naming forms for subordinate CAs, but only for Cross-Certified Subordinate CAs, and only if the name being certified was compliant with the version of the BRs in force. For example, this allows CAs to cross-certify a CA that does not comply with the (new) rules on CAs' streetAddress or localityName, provided that it complied with the rules at the time of issuance, such as the old rules of just requiring it be documented in the CA's CP/CPS.

• issuerUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• subjectUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• signatureAlgorithm: RFC 5280, Section 4.1.2.2 states "This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate"

Extensions

• authorityKeyIdentifier: BRs 7.1.2.2 (h)

• basicConstraints: RFC 5280, Section 4.2.1.9 and BRs 7.1.2.2 (d)

• certificatePolicies: This is a mix of clarifications and new requirements.

  • BRs 7.1.6.3 is structured to describe different requirements for when a CA is affiliated and when a CA is not affiliated. In both cases, an exhaustive list of accepted practices is listed, such that anything not on that list is not permitted.
  • RFC 5280, 4.2.1.4 states "When a CA does not wish to limit the set of policies for certification paths that include this certificate, it MAY assert the special policy anyPolicy, with a value of { 2 5 29 32 0 }." BRs 7.1.6.3 one allowance for anyPolicy states "MAY contain the anyPolicy identifier (2.5.29.32.0) in place of an explicit policy identifier." Both individually and together, these mean that anyPolicy is mutually exclusive with any other policies.
  • RFC 5280, 4.2.1.4 states "To promote interoperability, this profile RECOMMENDS that policy information terms consist of only an OID." This is why policyQualifiers is NOT RECOMMENDED for non-Affiliated CAs.
  • BRs 7.1.2.2 (a) only permits the policyQualifier of cPSUri when the CA is not an Affiliate of the Issuing CA. This is why policyQualifiers is MUST NOT for Affiliated-CAs.
  • For CA Certificates, a new requirement that the Reserved Certificate Policy Identifier be the first policy identifier present. Although this is not required by RFC 5280, multiple applications have implemented logic that extracts the first matching/known policy identifier from a certificate, when computing special policies (e.g. EV treatment). Ensuring the Reserved Policy Identifier is first reduces the risk of improper classification of a certificate. As this only applies to new CA Certificates going forward, it's phased in with immediate effect.

• crlDistributionPoints: This is a new requirement.

  • BRs 7.1.2.2 (b) requires that the extension "MUST contain the HTTP URL of the CA’s CRL service." This remains unchanged.
  • Some questions were raised about whether this means that other URLs, such as LDAP, can be included. Further, the order of the crlDistributionPoints has an impact on client processing, as they reflect a priority order to be tried during path validation. The new requirement makes it clear that the HTTP URL MUST be the first URL, and that ONLY HTTP URLs are permitted. This allows a CA to provide a secondary URL for failover, although both URLs are still subject to the BRs requirements on availability, so this is not generally desirable.
  • There are two ways to express "multiple distribution points" for CRLs: Either as two separate DistributionPoints, each with one URL in the fullName, or as a single DistributionPoint with multiple fullNames. Given that differences in DistributionPoint are meant to reflect different scopes, this encourages the latter approach, of multiple fullNames, which mostly aligns with existing practice. This does not yet forbid multiple DistributionPoints, but that is planned for a follow-up ballot.
  • This change does make it clear that CAs MUST NOT split CRLs by reasons or attempt to use delegated CRL signing certificates (cRLIssuer), as neither are well-supported in existing clients and introduce significant complexity. CAs are still permitted to split CRLs by distributionPoint URL (aka "sharding"), provided they ensure that the issuingDistributionPoint extension in the CRL is critical, as required by RFC 5280, 5.2.5 for such scenarios.

• keyUsage: BRs 7.1.2.1 (b) already explicitly require usages be asserted. A new requirement/clarification makes it clear that other usages MUST NOT be asserted. This is derived from the fact that CA private keys must not be used except as specified.

• subjectKeyIdentifier: RFC 5280, Section 4.2.1.2 states "... this extension MUST appear in all conforming CA certificates ..."

• extKeyUsage: This is a new requirement.

  • BRs 7.1.2.2 (g) contains several requirements in the first paragraph and which have resulted in some ambiguity. This attempts to clarify existing requirements, but may be perceived as a new requirement. Specifically, the only potential change is that EKU MUST only contain key usage purposes for which the Issuing CA has verified that the Subordinate CA is authorized to issue for. The following language exists in the BRs as "This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert", but some CAs have read that as only applying when cross-certifying Root Certificates, rather than applying to all Cross Certificates.
  • The additional language regarding validing each key purpose is derived from BRs 7.1.2.4, and is not intended to be a change.
  • RFC 5280, 4.2.1.12, allows for explicit key usages (such as id-kp-serverAuth) to be combined with anyExtendedKeyUsage. This profile restricts it, such that if anyExtendedKeyUsage is present, explicit key usages MUST NOT be present. The purpose of this restriction is to avoid ambiguity when it comes to restricted vs unrestricted CAs, since client applications do not generally enforce the restrictive model mentioned in RFC 5280 as a possibility.

• authorityInformationAccess: This is a new requirement.

  • BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP responder.
  • Some questions were raised about whether this means other URLs, other schemes, or multiple URLs can be included. Similar to crlDistributionPoints, the ordering of URLs implies processing semantics on clients, and only particular URL schemes are supported. Namely, if one of the two supported access methods are present (CA issuer or OCSP), then the only URLs present MUST be HTTP URLs, and MUST be listed in order of priority.
  • This prohibits the use of other access methods, as they are not used in the Web PKI.

• nameConstraints:

  • BRs 7.1.5 currently expresses rules for nameConstraints, but some concern was raised whether or not those rules only apply in the context of Technically Constrained Sub-CAs, or if those rules also extended to certificates that were capable of TLS issuance, but which didn't meet the Technically Constrained definition. BRs 7.1.2.4 sets rules in general for extensions, which would apply here, and 3.2.2.4 / 3.2.2.5 further expressed rules around the field. This restructures the definition to make it unambiguous that any nameConstraint extension needs to, minimally, match these requirements.
  • (New) rules for rfc822Name are introduced. This is to account for the fact that a Technically Constrained Non-TLS Sub-CA is still within scope of the BRs, if it is issued by an in-scope Issuing CA. In order for that non-TLS Sub-CA to also be seen as technically constrained for its purpose (e.g. technically constrained for email), it's necessary to be explicit that rfc822Name is permitted. The existing rules from 7.1.2.4 would apply to any rfc822Name constraint, and this attempts to derive the functional requirements for this field, also in line with the existing requirements of 3.2.2.4 / 3.2.2.5. Although not intended to be seen as a "new" requirement, as these are reflected through the combination of existing requirements and clauses, it may be seen as such.
  • The rules with respect to otherName and other name forms are derived from BRs 7.1.2.4. Making these MUST NOT was deferred to v2.

• Signed Certificate Timestamp List: This clarifies that, when present, the extension contents MUST conform with RFC 6962's requirements. This is derived from 7.1.2.4.

Technically Constrained Non-TLS Subordinate CA (7.1.2.3)

This is a new profile meant to capture a "not used for TLS" intermediate. When issued from a TLS-capable CA (e.g. one with no EKU restrictions), the issuance is still subject to the BRs, but any operation - such as private key protection, auditing, logging, issuance beneath - are seen as out of scope. The purpose of this profile is to ensure that such issuance aligns with RFC 5280 and the BRs, such that it can be seen as reduced risk.

Note, however, that it relies on using EKU to exclude from scope. Not all applications support this logic or behaviour, and so root programs MAY still set further requirements, including the use of audits. It MAY be that this form of issuance is prohibited in the future from BR-compliant CAs.

• version: RFC 5280, Section 4.1.2.1 states "When extensions are used, as expected in this profile, version MUST be 3 (value is 2)". Extensions are always used.

• serialNumber: RFC 5280, Section 4.1.2.2 states "the serial number MUST be a positive integer". Further, it notes that zero is not positive, as "Note: non-conforming CAs may issue certificates with serial numbers that are negative or zero." Section 7.1 of the BRs requires that at least 64 bits of output from a CSPRNG.

• signature: Unchanged. This continues to be addressed by BRs 7.1.3.2

• issuer: Unchanged. This was previously within BRs 7.1.4.1

• validity: This is a new requirement. The notBefore is permitted to be backdated up to 1 day. The notAfter must be equal to or later than the time of signing, and thus prohibits signing expired CAs.

• subject: BRs 7.1.4.3 already required countryName, organizationName, and commonName, and set forth rules for validating. All other fields were to be required to be validated as set forth in the CA's CP/CPS. This profile extends guidance for the semantics of stateOrProvinceName, localityName, postalCode, and streetAddress, in line with the BRs existing gudance for Subscriber Certificates (7.1.4.2.2). Although these are left as MAY in v1, the intent is to move them to NOT RECOMMENDED/MUST NOT in v2 (for new certificates).

• issuerUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• subjectUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• signatureAlgorithm: RFC 5280, Section 4.1.2.2 states "This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate"

Extensions

• authorityKeyIdentifier: BRs 7.1.2.2 (h)

• basicConstraints: RFC 5280, Section 4.2.1.9 and BRs 7.1.2.2 (d)

• certificatePolicies: This attempts to clarify the existing 7.1.6.3 as it applies to non-TLS CAs

  • BUG/TODO: anyPolicy policyQualifier wierdness for affiliated CA
  • BUG/TODO: Explicitly prohibit Reserved Policy Identifiers from the non-TLS CA

• crlDistributionPoints: This is a new requirement.

  • Note: These requirements apply to obtaining the CRLs for the Technically Constrained Non-TLS Subordinate CA. These requirements do not apply to certificates (or CRLs) issued by this Subordinate CA.
  • BRs 7.1.2.2 (b) requires that the extension "MUST contain the HTTP URL of the CA’s CRL service." This remains unchanged.
  • Some questions were raised about whether this means that other URLs, such as LDAP, can be included. Further, the order of the crlDistributionPoints has an impact on client processing, as they reflect a priority order to be tried during path validation. The new requirement makes it clear that the HTTP URL MUST be the first URL, and that ONLY HTTP URLs are permitted. This allows a CA to provide a secondary URL for failover, although both URLs are still subject to the BRs requirements on availability, so this is not generally desirable.
  • There are two ways to express "multiple distribution points" for CRLs: Either as two separate DistributionPoints, each with one URL in the fullName, or as a single DistributionPoint with multiple fullNames. Given that differences in DistributionPoint are meant to reflect different scopes, this encourages the latter approach, of multiple fullNames, which mostly aligns with existing practice. This does not yet forbid multiple DistributionPoints, but that is planned for a follow-up ballot.
  • This change does make it clear that CAs MUST NOT split CRLs by reasons or attempt to use delegated CRL signing certificates (cRLIssuer), as neither are well-supported in existing clients and introduce significant complexity. CAs are still permitted to split CRLs by distributionPoint URL (aka "sharding"), provided they ensure that the issuingDistributionPoint extension in the CRL is critical, as required by RFC 5280, 5.2.5 for such scenarios.

• keyUsage: BRs 7.1.2.1 (b) already explicitly require usages be asserted. A new requirement/clarification makes it clear that other usages MUST NOT be asserted. This is derived from the fact that CA private keys must not be used except as specified.

• subjectKeyIdentifier: RFC 5280, Section 4.2.1.2 states "... this extension MUST appear in all conforming CA certificates ..."

• extKeyUsage: This clarifies existing requirements.

  • BRs 7.1.2.2 (g) already contains rules for non-TLS subordinate CAs, such as prohibiting id-kp-serverAuth and recommending against multiple key purposes.
  • The additional language regarding validing each key purpose is derived from BRs 7.1.2.4, and is not intended to be a change.

• authorityInformationAccess: This is a new requirement.

  • BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP responder.
  • Some questions were raised about whether this means other URLs, other schemes, or multiple URLs can be included. Similar to crlDistributionPoints, the ordering of URLs implies processing semantics on clients, and only particular URL schemes are supported. Namely, if one of the two supported access methods are present (CA issuer or OCSP), then the only URLs present MUST be HTTP URLs, and MUST be listed in order of priority.
  • This prohibits the use of other access methods, as they are not used in the Web PKI.

• nameConstraints:

  • BRs 7.1.5 currently expresses rules for nameConstraints, but some concern was raised whether or not those rules only apply in the context of Technically Constrained Sub-CAs, or if those rules also extended to certificates that were capable of TLS issuance, but which didn't meet the Technically Constrained definition. BRs 7.1.2.4 sets rules in general for extensions, which would apply here, and 3.2.2.4 / 3.2.2.5 further expressed rules around the field. This restructures the definition to make it unambiguous that any nameConstraint extension needs to, minimally, match these requirements.
  • (New) rules for rfc822Name are introduced. This is to account for the fact that a Technically Constrained Non-TLS Sub-CA is still within scope of the BRs, if it is issued by an in-scope Issuing CA. In order for that non-TLS Sub-CA to also be seen as technically constrained for its purpose (e.g. technically constrained for email), it's necessary to be explicit that rfc822Name is permitted. The existing rules from 7.1.2.4 would apply to any rfc822Name constraint, and this attempts to derive the functional requirements for this field, also in line with the existing requirements of 3.2.2.4 / 3.2.2.5. Although not intended to be seen as a "new" requirement, as these are reflected through the combination of existing requirements and clauses, it may be seen as such.
  • The rules with respect to otherName and other name forms are derived from BRs 7.1.2.4. Making these MUST NOT was deferred to v2.

• Signed Certificate Timestamp List: This clarifies that, when present, the extension contents MUST conform with RFC 6962's requirements. This is derived from 7.1.2.4.

Technically Constrained Precertificate Signing CA (7.1.2.4)

This attempts to clarify the role of Precertificate Signing CAs in the BRs. Under RFC 6962, a Precertificate Signing CA's EKU extension only needs to contain the Precertificate Signing Certificate EKU, and CT Logs are supposed to ignore any EKU chaining restrictions when validating precertificates from this CA. In this scenario, the BRs 7.1.5 rules for Name Constraints would suggest that such a CA is Technically Constrained.

BUG/TODO: Fix this

Technically Constrained TLS Subordinate CA (7.1.2.5)

This profile is otherwise identical to the general Subordinate TLS CA Profiles, with the exception of nameConstraints being required.

• version: RFC 5280, Section 4.1.2.1 states "When extensions are used, as expected in this profile, version MUST be 3 (value is 2)". Extensions are always used.

• serialNumber: RFC 5280, Section 4.1.2.2 states "the serial number MUST be a positive integer". Further, it notes that zero is not positive, as "Note: non-conforming CAs may issue certificates with serial numbers that are negative or zero." Section 7.1 of the BRs requires that at least 64 bits of output from a CSPRNG.

• signature: Unchanged. This continues to be addressed by BRs 7.1.3.2

• issuer: Unchanged. This was previously within BRs 7.1.4.1

• validity: This is a new requirement. The notBefore is permitted to be backdated up to 1 day. The notAfter must be equal to or later than the time of signing, and thus prohibits signing expired CAs.

• subject: BRs 7.1.4.3 already required countryName, organizationName, and commonName, and set forth rules for validating. All other fields were to be required to be validated as set forth in the CA's CP/CPS. This profile extends guidance for the semantics of stateOrProvinceName, localityName, postalCode, and streetAddress, in line with the BRs existing gudance for Subscriber Certificates (7.1.4.2.2). Although these are left as MAY in v1, the intent is to move them to NOT RECOMMENDED/MUST NOT in v2 (for new certificates).

• issuerUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• subjectUniqueID: RFC 5280, Section 4.1.2.8, states "CAs conforming to this profile MUST NOT generate certificates with unique identifiers"

• signatureAlgorithm: RFC 5280, Section 4.1.2.2 states "This field MUST contain the same algorithm identifier as the signature field in the sequence tbsCertificate"

Extensions

• authorityKeyIdentifier: BRs 7.1.2.2 (h)

• basicConstraints: RFC 5280, Section 4.2.1.9 and BRs 7.1.2.2 (d)

• certificatePolicies: This is a mix of clarifications and new requirements.

  • BRs 7.1.6.3 is structured to describe different requirements for when a CA is affiliated and when a CA is not affiliated. In both cases, an exhaustive list of accepted practices is listed, such that anything not on that list is not permitted.
  • RFC 5280, 4.2.1.4 states "When a CA does not wish to limit the set of policies for certification paths that include this certificate, it MAY assert the special policy anyPolicy, with a value of { 2 5 29 32 0 }." BRs 7.1.6.3 one allowance for anyPolicy states "MAY contain the anyPolicy identifier (2.5.29.32.0) in place of an explicit policy identifier." Both individually and together, these mean that anyPolicy is mutually exclusive with any other policies.
  • RFC 5280, 4.2.1.4 states "To promote interoperability, this profile RECOMMENDS that policy information terms consist of only an OID." This is why policyQualifiers is NOT RECOMMENDED for non-Affiliated CAs.
  • BRs 7.1.2.2 (a) only permits the policyQualifier of cPSUri when the CA is not an Affiliate of the Issuing CA. This is why policyQualifiers is MUST NOT for Affiliated-CAs.
  • For CA Certificates, a new requirement that the Reserved Certificate Policy Identifier be the first policy identifier present. Although this is not required by RFC 5280, multiple applications have implemented logic that extracts the first matching/known policy identifier from a certificate, when computing special policies (e.g. EV treatment). Ensuring the Reserved Policy Identifier is first reduces the risk of improper classification of a certificate. As this only applies to new CA Certificates going forward, it's phased in with immediate effect.

• crlDistributionPoints: This is a new requirement.

  • Note: These requirements apply to obtaining the CRLs for the Technically Constrained Non-TLS Subordinate CA. These requirements do not apply to certificates (or CRLs) issued by this Subordinate CA.
  • BRs 7.1.2.2 (b) requires that the extension "MUST contain the HTTP URL of the CA’s CRL service." This remains unchanged.
  • Some questions were raised about whether this means that other URLs, such as LDAP, can be included. Further, the order of the crlDistributionPoints has an impact on client processing, as they reflect a priority order to be tried during path validation. The new requirement makes it clear that the HTTP URL MUST be the first URL, and that ONLY HTTP URLs are permitted. This allows a CA to provide a secondary URL for failover, although both URLs are still subject to the BRs requirements on availability, so this is not generally desirable.
  • There are two ways to express "multiple distribution points" for CRLs: Either as two separate DistributionPoints, each with one URL in the fullName, or as a single DistributionPoint with multiple fullNames. Given that differences in DistributionPoint are meant to reflect different scopes, this encourages the latter approach, of multiple fullNames, which mostly aligns with existing practice. This does not yet forbid multiple DistributionPoints, but that is planned for a follow-up ballot.
  • This change does make it clear that CAs MUST NOT split CRLs by reasons or attempt to use delegated CRL signing certificates (cRLIssuer), as neither are well-supported in existing clients and introduce significant complexity. CAs are still permitted to split CRLs by distributionPoint URL (aka "sharding"), provided they ensure that the issuingDistributionPoint extension in the CRL is critical, as required by RFC 5280, 5.2.5 for such scenarios.

• keyUsage: BRs 7.1.2.1 (b) already explicitly require usages be asserted. A new requirement/clarification makes it clear that other usages MUST NOT be asserted. This is derived from the fact that CA private keys must not be used except as specified.

• subjectKeyIdentifier: RFC 5280, Section 4.2.1.2 states "... this extension MUST appear in all conforming CA certificates ..."

• extKeyUsage: This attempts to clarify existing requirements.

  • BRs 7.1.2.2 (g) requires that for TLS CAs, only id-kp-serverAuth and (as a MAY) id-kp-clientAuth are permitted.
  • The Precertificate Signing Certificate key purpose is explicitly forbidden. Under 7.1.2.2 (g), this is a SHOULD NOT, but the prohibition is derived from BRs 7.1.2.4, as a subordinate CA containing this EKU is being authorized to issue Precertificates for the Issuing CA

• authorityInformationAccess: This is a new requirement.

  • BRs 7.1.2.2 (c) notes that it SHOULD contain the HTTP URL of the Issuing CA's certificate and MAY contain the HTTP URL of the Issuing CA's OCSP responder.
  • Some questions were raised about whether this means other URLs, other schemes, or multiple URLs can be included. Similar to crlDistributionPoints, the ordering of URLs implies processing semantics on clients, and only particular URL schemes are supported. Namely, if one of the two supported access methods are present (CA issuer or OCSP), then the only URLs present MUST be HTTP URLs, and MUST be listed in order of priority.
  • This prohibits the use of other access methods, as they are not used in the Web PKI.

• nameConstraints:

  • BRs 7.1.5 contain the existing rules with respect to dNSName, iPAddress, and DirectoryName
  • TODO/BUG: (New) rules for rfc822Name are introduced.
  • The rules with respect to otherName and other name forms are derived from BRs 7.1.2.4. Making these MUST NOT was deferred to v2.

• Signed Certificate Timestamp List: This clarifies that, when present, the extension contents MUST conform with RFC 6962's requirements. This is derived from 7.1.2.4.

[chrisbn]

Can I ask what's the origin of the relative order requirement?

[chrisbn]

The table for EV Subject DN fields is below the general table. Does that mean the order of the fields is after the other fields, or is the order only applicable to the first table?

[wthayer]

Should this table of contents include sections 7.1.2.10 and 7.1.2.11?