Profiles WIP

[sleevi]

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.

[dzacharo]

Currently there are no fields that explicitly specify that more instances are allowed. I think we should consider allowing multiple instances for:

• organizationalUnitName (although the goal is to ultimately deprecate)
• givenName (Subscribers with multiple given names that possibly exceed the 16 characters limit)
• surname (Subscribers with multiple surnames that possibly exceed the 40 characters limit).

It's also possible that streetAddress is also used with multiple instances but that remains to be confirmed.

[dzacharo]

If there are no upper-bound restrictions for givenName, surname, it should be fine to have only one instance allowed.

[sleevi]

I definitely disagree with the premise of multiple OUs :) streetAddress is one that was discussed with Tim a little, but I'm not sold, for the same reason we should be looking at OU deprecation.

I'll crunch CT data to see if/how many CAs used multiple instances of different fields.

[CBonnell]

https://censys.io/certificates?q=%28parsed.subject_dn.raw%3A+%2F.%2Astreet%5C%3D.%2B%2C+street%5C%3D.%2B%2F%29+AND+tags.raw%3A+%22trusted%22&

[sleevi]

@CBonnell The issue with that Censys query is that trust bits have been borked for a hot minute, and don't consider both distrusts and new trusts. crt.sh is a quite a bit more accurate here :)

[CBonnell]

GRID certificates include multiple DC attributes, so that use case would be impacted by this requirement.

[sleevi]

@CBonnell Do you have instances of publicly trusted GRID certificates?

[CBonnell]

https://search.censys.io/certificates?q=%28parsed.subject.domain_component%3A+%2A+and+parsed.extensions.extended_key_usage.server_auth%3A+true%29+AND+tags.raw%3A+%22trusted%22&

Only a few CAs issue them, but it is a use case that would be affected.

[sleevi]

Thanks for that. I seem to recall a CA incident around this, but would need to dig in; I believe at one point this was explicitly called out as prohibited, but perhaps something got lost in a refactor. It also seems questionable under some of the BR blanket prohibitions re: domains in subject names (and misleading information).

Still, phasing from multiple to singular could be done with a phase-in to avoid any issue and provide clarity for these other fields, separate from any possible incident-related revocation for these GRID certs

[dlgroep]

We only recently became aware of this discussion, so our apologies for possible chiming in later than usual. The Grid community is not directly represented in these discussions, usually relying on our partners in the Forum (over time we work and have worked with many, such as DigiCert and Sectigo, earlier also with GlobalSign and the former Comodo), so the “GRID” may appear remote and distant. I will try to close that gap a bit, since what is “GRID” here, is in fact a shorthand for the global research and education authentication community that uses PKIX for web-based research infrastructures. This includes e.g. CERN’s Large Hadron Collider, many US and European supercomputing centres, life science and health research, astronomy, &c - and their globally distributed web (storage) services accessed both via browsers as well as via automated transfer services. In addition, next to its server PKI deployment that is relevant here it includes a global end-user client PKI than allows researchers to authenticate.

Over almost two decades, the research and education collaborations, such as TERENA (now GEANT) for all European research and education networks, and InCommon in the US, have worked with their partners here to create a secure and tightly controlled ecosystem providing name uniqueness, adherence to standards (and providing some security and authentication innovations thereof along the way). We, as the global non-profit research community, are very supportive of a secure and trusted ecosystem for WebPKI, also by ensuring that browser-based access and service-agents can work together to secure the ecosystem in a comprehensive way.

The use of domainComponents in the subjectName is a core elements since it provides uniqueness of subject naming through (verified domain name owner-authorized) namespace slicing. This allows the browser users to validate the server, but at the same time is used e.g. for service-agent based authentication. Since these will by necessity use the very same end-points, it is important that the server certificates used have both WebPKI browser trust for human users as well as the uniqueness properties necessary for agent-based access.

The specific global uniqueness of the subject DN and having these certificates trusted for WebPKI is critical for securing connection to services that are access by both browsers as well as automated agents. Such as storage services: end-users can retrieves files via their browser, but automated large-scale research transfer services connect to the endpoints to do data placement (e.g. for CERN’s worldwide Large Hadron Collider Computing Grid) and must authenticate the endpoints based on their certificate subject name. To identify the endpoints, unique naming is necessary, which is what – for TCS and InCommon - the subject DN domainComponents supplies.

But, by design and semantics, domainComponent should appear multiple times. RFC 2247 is quite clear: “The value of this attribute is a string holding one component of a domain name.” So, given that a domain name usually consists of multiple components, also domainComponent should have multiple occurrences. With the domain name system being hierarchical, the ASN.1 thus has to be a sequence (of sets of unitary length) of this attribute.

The inclusion of domainComponent, in the way that it is worded today, was definitely not accidental or a refactoring anomaly. Our community worked together with several members, specifically DigiCert and Comodo (around ~2011), to align the BR text with these joint WebPKI security requirements. And ensure that domainComponent, and its standardized semantics, were included consistently in BR. The result was reconfirmed in Ballot 102 (https://cabforum.org/2013/05/31/ballot-102-br-9-2-3-domaincomponent/).

We therefore hereby reconfirm the existing current and continuing case for domainComponent, in line with the purpose as included in BR and in Ballot 102.

The use of domainComponents, as may be observed from Censys, identifies the long-term domain name from, and authorized explicitly by, the domain name owner, e.g. the Trans-European Research and Education Networking Association TERENA – terena.org, now GEANT; or the InCommon federation – incommon.org, providing certificates for the US research and education community (even if our issuing partners change). Intentionally, for security reasons certificate validity periods have always been rather short (the community had settled on max 400 days since its conception in 2001), but the subject names themselves are much longer lived: many of the research use cases is easily 30+ years. DomainComponents are the most appropriate attribute to carry the uniqueness information.

We note by the way that the rendering by Censys.io is not what is actually in the certificate subject names, since there is a bug in Censys that duplicates the sequence of domainComponents in the string rendering. It is in fact of course “[…non-DC-attributes…], dc=tcs, dc=terena, dc=org” (in RFC2253 ordering). Crt.sh shows it correctly (e.g. https://crt.sh/?id=5460913588).

Unique certificate subject naming, when used in combination with relying-party defined namespace constraints, also permits mutual authentication between endpoints. Admittedly, this is beyond the browser use case today, but the concept provides some supplementary protections by moving the source of authority for NameConstraints to the relying party, as discussed in GFD-I.189 (https://www.ogf.org/documents/GFD.189.pdf). Even in browsing scenarios this adds some security (admittedly only slightly) for text-browser-based access by end-users to the web services, since there global name uniqueness can be verified in appropriate clients.

Without the availability of (RFC standards-compliant) domainComponents, subject distinguished names will no longer be distinguishable …

[dzacharo]

Should this table contain a column for explicitly allowing multiple instances of the same attribute?

[sleevi]

So, I had the draft language until folks could discuss further which and whether we allow multiple instances. You'll recall I raised it two calls ago, but there was no discussion on the list about that. I still think the right answer is no multiple instances, but I held off adding the column until we decided one way or the other (for the interim).

[dzacharo]

I believe your answer in #36 (comment) clears the givenName, surname need for multiple instances :)

With the OU deprecation planned ahead, multiple OU fields would only be used until full deprecation.

[dougbeattie]

An explicit requirement to say serverAuth is required is new and I totally understand the discussions that if you want client auth only you should/must not use the webPKI for that. Given this might be perceived as a change and impact some customers, should we assign a specific effective date for this (and other changes) so we can ballot the profiles work and make the spec immediately effective, but have specific dates for the items that need them?

[sleevi]

Could you describe a little more what you believe would be impacted? Perhaps an example crt.sh link?

I don't think your proposed fix is correct: a certificate with id-kp-clientAuth only is not one that should be issued for server auth, and the transition is only going to muddy those waters. I'm open to explicitly having a certificate profile for this, but I think it'd be useful if you could provide an example cert or certs to understand what this looks like today.

[sleevi]

Just following up on this @dougbeattie - You seemed OK on our most recent call, but did want to touch base to make sure before closing this out as resolved.

[chrisbn]

The first Certificate Policies entry for non-affiliated CAs (7.1.2.10.4) says "MUST NOT" where this is "SHOULD NOT". Is there a reason for the difference? If the intention is to not include a policyQualifier for reserved policy identifiers, should this also be a "MUST NOT"?

[sleevi]

Thanks for flagging!

Under the existing BRs, the language in 7.1.2.2 states:

The following fields MAY be present if the Subordinate CA is not an Affiliate of the
entity that controls the Root CA

The key being "is not an Affiliate of the entity that controls the Root CA"

Logically, if we read this as written, then it means that if the Subordinate CA is an Affiliate, then those fields MUST NOT be present, because they are only permitted under certain situations.

So the intent here was to transcribe the existing requirement.

[sleevi]

@chrisbn Did this answer address your concern?

[sleevi]

@chrisbn I reworked this some in 197f096 and I'm wondering if this fully addresses your concern?

Namely, this ends up allowing cPSuri everywhere for the time being, following the last validation call.

[wthayer]

@sleevi for a cross-cert not operated by the signing TSP, shouldn't the CPSuri point to the subordinate operator's policies? Also, there's a typo on line 2740 (extra "an")

[sleevi]

@wthayer Thanks for the typo flag.

This is actually a transcription of our current policies (7.1.2.2 (a) for Subordinate CAs)

HTTP URL for the Root CA’s Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the CA.

I agree, it's not exactly intuitive. RFC 5280, 4.2.1.4 states:

   In an end entity certificate, these policy information terms indicate
   the policy under which the certificate has been issued and the
   purposes for which the certificate may be used.  In a CA certificate,
   these policy information terms limit the set of policies for
   certification paths that include this certificate.

Ignoring any policyQualifiers for a second, just for the policy identifier, it's clear that it's a restriction on the subordinate CA set by the issuer, in that it limits the 'set of policies for certification paths'.

That said, in practice, I suspect the vast majority of CAs have arguably misissued (per the BRs) the intermediates, by reading the clause as "HTTP URL for (the Root CA's CP, CPS, RPA) or (other pointer to online policy information provided by the CA)", rather than as "HTTP URL for the Root CA's (CP, CPS, RPA, or other pointer to online policy information)", and placed the subordinate CA's CPS URI in the certificate.

RFC 5280 does read somewhat against this practice, but it also fairly "YOLOs", when 4.2.1.4 states:

   The CPS Pointer qualifier contains a pointer to a Certification
   Practice Statement (CPS) published by the CA.  The pointer is in the
   form of a URI.  Processing requirements for this qualifier are a
   local matter.  No action is mandated by this specification regardless
   of the criticality value asserted for the extension.

"by the CA" seems to be "by this issuer" here, although it's also somewhat unsurprisingly targeted towards end-entity uses, rather than CAs.

[sleevi]

@wthayer Should we take this one to the list? I think this is probably an example of widespread misinterpretation (and thus, potentially, misissuance), but which we benefit from clarity on.

[wthayer]

@sleevi I now agree that the new language isn't a requirement change, so we may want to decouple this from the profiles ballot. Having said that, I agree that it's worth discussing. I'll bring it up on the next Validation call if you don't beat me to it.

[sleevi]

Sounds good.

I think this one could go either way, as hopefully I captured above, and so making this flexible in the profiles ballot is also a viable path (e.g. loosening the present requirement, until we figure out what it should be).

[sleevi]

I did some further (light) checking on this, it looks like DigiCert and Sectigo have been setting it correctly. The only one I found that looked misissued was the (now-expired) Let's Encrypt certificate from IdenTrust, as it had LE's CPS, rather than IdenTrust's.

So it may not be a widespread misinterpretation, but I also agree the current rules may not be great. This change does fix one area of weirdness though, with is if you have:

Root CA (Org 1) -> Cross-Sign CA (Org 2) -> Intermediate (Org 2), then under the existing BRs, "Intermediate" can contain a cPSUri (because it's not an affiliate of the root), but it needs to be Root CA's. The new language here would limit Intermediate (because it's the same as the Issuing CA), while if Intermediate was operated by Org 3, then it could contain Org 2's CPS, rather than Org 1.

It's good you flagged this, because this is a slight change, although it doesn't seem that it's being depended upon. I'll make sure to document as such.

[CBonnell]

Resuming the discussion here since #39 has been closed...

Can you explain a bit more how you believe this is an existing BR requirement? I don't see any obligation in the BRs to validate Domain Names that are not contained in the SAN/CN according to 3.2.2.4.

[sleevi]

@CBonnell

From 7.1.2.4

CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in Section 3.2.2.4 or Section 3.2.2.5.

From 3.2.2.4

Note: FQDNs may be listed in Subscriber Certificates using dNSNames in the subjectAltName extension or in Subordinate CA Certificates via dNSNames in permittedSubtrees within the Name Constraints extension.

From 9.6.1:

implemented a procedure for verifying that the Applicant either had the right to use, or had control of, the Domain Name(s) and IP address(es) listed in the Certificate’s subject field and subjectAltName extension (or, only in the case of Domain Names, was delegated such right or control by someone who had such right to use or control);

[CBonnell]

Isn't the note in 3.2.2.4 clarifying that validation is only required for the SAN dNSNames or permittedSubtrees field of the NC extension? I don't believe it's prohibiting the inclusion of values that conform to Domain Name syntax in other fields. If it did, the current language would prohibit the inclusion of Domain Names in CN.

More fundamentally, any prohibition on Domain Names or IP Addresses from appearing in Subject attributes would have the logical conclusion that any OV/EV Subscriber Certificate today with a countryName value of "US" is mis-issued unless the Applicant asserted control of the entire ".us" TLD. I don't believe that's the state of the WebPKI today, so the current ballot language is more restrictive than the current requirements.

[sleevi]

Isn't the note in 3.2.2.4 clarifying that validation is only required for the SAN dNSNames or permittedSubtrees field of the NC extension?

I've always read it as an upper-bound, not a minimum.

If it did, the current language would prohibit the inclusion of Domain Names in CN.

Well, we already limit things, by requiring the CN contain the SAN, right?

I think we're in agreement that the language, as written, is internally inconsistent. However, I'm not sure how you can hold the current position, since it seems to require ignoring the clear language of 7.1.2.4 and 9.6.1. I wasn't sure: Were you trying to point out the inconsistency (which is trying to be addressed), or were you trying to argue that the overall interpretation holds consistent with the requirements?

I don't believe that's the state of the WebPKI today, so the current ballot language is more restrictive than the current requirements.

"More restrictive" is an interesting choice, because it seems the comparison is between "Don't do it" and "validate the authorization if you do it" (unless you ignore 7.1.2.4/9.6.1). That is, it's only more restrictive if we believe that CAs are presently validating that C=US means the subject is entitled to issue for all of the .us TLD, and that this would forbid it.

But I think that gets to your above point, that you haven't seen the requirements of 7.1.2.4/9.6.1 as "validate every domain name in a(ny) Subject Field", but rather "validate any domain names in (these) Subject fields". That's not what we have presently written, though, but perhaps you can help me understand how you reach that conclusion?

For example, digging in the older BRs, such as when the CA/B Forum allowed domainComponent, which it did until Ballot 148 in Version 1.2.5 (redline)

Of course, even if you look back that far, the language was unambiguous:

CAs SHALL NOT include a Domain Name in a Subject attribute except as specified in Sections 9.2.1
and 9.2.2(a) below

The refactor to the BRs (in v.1.3.0) changed that language to the present form (referencing 3.2.2.4 / 3.2.2.5), but you can see from the discussion, the intent was to preserve the existing requirements.

[CBonnell]

But I think that gets to your above point, that you haven't seen the requirements of 7.1.2.4/9.6.1 as "validate every domain name in a(ny) Subject Field", but rather "validate any domain names in (these) Subject fields". That's not what we have presently written, though, but perhaps you can help me understand how you reach that conclusion?

Although it sounds like you don't agree, I believe the Note in 3.2.2.4 makes it clear that validation is only required for values contained in the SAN/NC. The language in 7.1.2.4 and 9.6.1 references 3.2.2.4, so, while not entirely clear, the BRs are not stating there is an obligation to validate other Subject attribute values per 3.2.2.4/5, only those that contain values echoed in the SAN/NC. Otherwise, as I pointed out previously, if the current requirements are to be read that every Subject attribute value that contains a Domain Name or IP Address must be validated by 3.2.2.4/3.2.2.5, then virtually every OV/EV certificate issued today is mis-issued due to the lack of validation of the countryName value as a Domain Name (or other attributes, for that matter). I imagine the vast majority BR readers would find this to be a quite surprising interpretation.

In drafting the ballot language, I think it would be useful to first have a goal in mind. If I understand the concern correctly, we want to ensure that CN values undergo 3.2.2.4/3.2.2.5 validation, as the CN-ID may be used for hostname identification. I am unaware of any standard that defines other attributes as suitable for hostname identification. In other words, if a client implementation is extracting the hostname from the organizationName attribute, then that implementation is flawed. Therefore, I'm not seeing a reason to mandate 3.2.2.4/3.2.2.5 for any attribute besides CN. Can you clarify what your goal is here?

[BenWilson-Mozilla]

Personally (i.e. input is needed from others), I think that BOTH organization vetting through government business registries AND 3.2.2.4 validation would be the way to go for organization names that are also domain names before they are allowed in other subject attribute fields. I don't see a need for anyone to put IP addresses in other applicant-controlled fields, so that should just be forbidden.

[sleevi]

OK, this is super helpful, thanks @clintwilson and @BenWilson-Mozilla !

I agree, it’s definitely something worth further discussion during the review. And @CBonnell has rightfully pointed out areas the current language is overbroad, so we can definitely work to address those.

@CBonnell I’ll try to make an update to the language here to clarify, based on the excellent points you’ve raised, and we’ll continue to discuss. But I think the above shows a bit of directional alignment to the goal, and how we fix the existing (but buggy/overly restrictive, as you point out) language.

[sleevi]

@CBonnell

This turned out to be rather devilish, so thanks again for raising this. In looking through UTS#46 and related, it understandably is complex to validate this in a reliable, automated fashion (the best kind of validation).

The options here are either taking an overly broad/restrictive approach, which shunts every 'maybe' into a DV case, which I think is fine in theory, but still somewhat tricky to define as such, or attempt to come up with a nuanced approach that still lets "obvious" badness through. For example, the Numbers Period ( https://unicode-table.com/en/blocks/enclosed-alphanumerics/ - U+2488 - U+249B ) that decompose into fullstops, which are not valid IDNA, but which could still be visually confusable (U+2491 0 . 0 . 1) becomes "10.0.0.1"

I'm still needing to do CT examinations for this data to understand the implications for existing certs, but the current thinking for "potential domain name or IP address" language is

• Two or more sequences of two or more characters separated by FULL STOP (U+002E), FULLWIDTH FULL STOP (U+FF03), IDEOGRAPHIC FULL STOP (U+3002), HALFWIDTH IDEOGRAPHIC FULL STOP (U+FF61)
  • Note: This ends up not being able to prevent the "Numbers Period" character ranges because of their decomposition, unless they're mapped per IDNA
  • Note: This also ends up including/catching "spol. s r.o" (Slovakia), since whitespace is a character (invalid in IDNA, but you don't know until you've processed the string)
  • Note: This ends up (incorrectly) allowing domainComponent decomposition, which you highlighted in Profiles WIP #36 (comment)
• Any sequence of characters that may be successfully parsed according to the textual representation of an IPv6 address, per RFC 4291, Section 2.2
• Four sequences of digits separated by FULL STOP (U+002E), FULLWIDTH FULL STOP (U+FF03), IDEOGRAPHIC FULL STOP (U+3002), HALFWIDTH IDEOGRAPHIC FULL STOP (U+FF61)

Alternatively, if we accept that (malicious) confusables are possible, for as long as "attacker controlled" strings are present in the Subject (e.g. before any explicit MUST NOT of any other value), then an alternative is just to repurpose the language from Ballot SC48v2, focusing on just the ASCII minimal encodings, and saying no instances (outside of organizationName, per above)

What are your thoughts, while I dig into this?

[CBonnell]

A few thoughts:

• I like the proposal for IPv4 and IPv6 addresses; it addresses the concern with decimal or hex-encoded IP addresses that I raised earlier.

• My understanding was that the requirement to vet per 3.2.2.4 is applicable solely to attribute values that match Domain Name syntax in its entirety, not necessarily contains/substring match. If the latter, then the logic becomes much more difficult. If the requirement is for substring matches to be vetted, then O values such as "O=Foo Enterprises, Co.Ltd" or "O=United PKI Workers Credit Union of St.Louis" need "Co.Ltd" and "St.Louis" to be vetted, respectively.

• Performing NFKC normalization on the attribute value string should catch the "Numbers Period" case you outlined above.

• An additional complication is that some user agents will display the A-label representation of the peer hostname in the address bar if certain checks (confusables, presence of multiple scripts, etc.) fail. Since the organizationName value is a not a IDNA-aware domain name slot, it will likely not undergo the same UI treatment as the address bar. So even if we write specific rules surrounding non-ASCII characters in the organizationName, UI display will likely not be consistent across browsers. In other words, restrictions on the allowed set of values encoded in certificates is an incomplete mitigation given that there is no standard for the display of certificate contents in user agents.

I realize the above points aren't a comprehensive treatment of the issue, but I wanted to share them to keep the discussion going.

[sleevi]

My understanding was that the requirement to vet per 3.2.2.4 is applicable solely to attribute values that match Domain Name syntax in its entirety,

No, we discussed on our call yesterday why that's not the case. An O field of "Authorized representative of Example.com, LLC" has the same problem.

then O values such as "O=Foo Enterprises, Co.Ltd" or "O=United PKI Workers Credit Union of St.Louis" need "Co.Ltd" and "St.Louis" to be vetted, respectively.

Yes, it does mean that, by default, the CA would need to block such fields. They can then decide whether to issue a DV certificate (avoiding the issue), or escalating for review to determine if the provisions under (old BRs 7.1.4.2.2(b) / this PR the table), for example, if "Co.Ltd" could be transformed to "Co. Ltd" or "St.Louis" becomes "St. Louis"

This is what makes it a compromise proposal: It avoids the current approach of outright blocking.

Performing NFKC normalization on the attribute value string should catch the "Numbers Period" case you outlined above.

Just making sure I parse this suggestion: Is it that the encoded fields contain the normalized form? Or that the CA needs to normalize, then process, while encoding the un-normalized values? I used "numbers period" as an example, but I think really it's a question of what extent U-Labels are or can be protected against, since plenty of other confusables exist in this problem space. I think that's where we're in agreement?

It doesn't sound like your reply has identified any breaking issues with the proposed approach, other than yes, there are trade-offs, but hopefully in a way that are readily implementable and potentially unambiguous?

It sounds like next steps are for more concrete language to be added, to make sure any other tradeoffs are identified.

[chrisbn]

How would fields need to be handled that are not in the current list? E.g. subject:businessCategory or subject:jurisdictionLocalityName from EVG? I'm also interested to know if there's a source for this requirement, or what's the driver for the ordering?

[sleevi]

You mean, where would these be sorted?

These are requirements derived from the semantics of RFC 5280 and X.509. A DN is hierarchical in semantic naming, and an RDN with multiple elements is saying that these names are semantically equivalent hierarchically.

For the name forms listed, they are not semantically equivalent (e.g. a countryName is not the same hierarchy as a localityName / interchangeable with), and there is a semantic hierarchy.

These are already existing logical requirements, just being made explicit.

[chrisbn]

Yes, I wonder about the order of fields not in this list.

I understand the hierarchy to order logic, but is the order defined in Section 7.1.4.2 based on an existing specification, or how did we come to this ordering?

[sleevi]

It is based on the definitions within X.509 and X.520, given these fields are generally geographical in nature.

That said, there’s definitely flexibility here to get us closer to consistency among CAs, which is a key point of profiling, so if there are changes and concerns, it’s totally appropriate to highlight.

Prior relevant art includes RFC 2377, RFC 1218, and RFC 1255