SCXX - Certificate Profiles #373

CBonnell · 2022-07-13T18:57:49Z

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.

AIA allows multiple methods, and multiple instances of each method. However, client implementations use the ordering to indicate priority, as per RFC 5280, so clarify the requirements for multiple AccessDescriptions with the same accessMethod.

Rather than make basicConstraints MUST, make it a MAY, to allow omission (plus v3) or presence (but empty) to indicate that it is not a CA certificate.

As captured on https://archive.cabforum.org/pipermail/validation/2021-July/001675.html provide better guidance for the encoding of cRLDistributionPoints and the permitted protocols.

Non-TLS CAs MUST NOT include id-kp-OCSPSigning, since this would potentially make them OCSP signers for the issuing CA. Similarly, with respect to non-TLS CAs, it's fine (and useful!) to use other EKUs, so this is a MAY (or possibly SHOULD), not a SHOULD NOT.

A Precertificate Signing CA, ontologically, a type of Technically Constrained Non-TLS Sub-CA, by virtue of the Extended Key Usage. To avoid ambiguity, this introduces a profile specific for Precert Signing CAs that make it clear that the Precert Signing EKU MUST be the only EKU present, to avoid a situation similar to that seen with OCSP responders. RFC 6962 is somewhat fast and loose with respect to whether or not "CA:true" is required in the profile for these, but in practice, implementations of logs, and existing CAs, do expect CA:true. Although not meant to be a normative change from the existing practices and consequences of existing requirements, it does make explicit that such CAs MUST only sign Precertificates; although this is less critical given the EKU constraint (to being a singular EKU), it represents a defense in depth approach consistent with existing practice.

As pointed out by DigiCert, postal code represents a greater enclosing area than the street address, and thus hierarchically should appear first.

They were accidentally a MUST, when they should have been a MAY. Bad copy/paste.

Move the effective date to 6 months from now; will likely continue to move as we finalize things, but offers a placeholder to handling effective dates.

As pointed out by Corey, an id-pkix-ocsp-nocheck should be expected to disable all revocation checking (not just recursive OCSP revocation checking), so it makes sense to MUST NOT the cRLDP for the OCSP Responder, since we MUST nocheck.

This introduces the notion of Precertificates and Precertificate Signing CAs as part of the Profiles, and captures the existing requirements from RFC 6962. It defines a Precertificate as based on a transformation of an existing Certificate conforming to one of the profiles, as opposed to attempting to define variants for every version or how to construct a Precertificate for a given profile. This attempts to similarly capture that, for purposes of compliance, a Precertificate is treated as if there is an equivalent Certificate, by reflecting that Precertificates need to match a Certificate based on the transformations defined, and that the Certificates need to match the profiles defined.

This attempts to clarify when/how backdating is allowed, particularly since it may affect path building. It gives a generous period for CA backdating when the distinguishedName remains the same, but may be imperfect if the keys are changing.

This adopts the language from 7.1.2.4 to the various extensibility points, by trying to explicitly clarify as appropriate as to what is permitted.

While RFC 2119 establishes that these two phrases are semantically equivalent, it's been suggested that this may resolve some anxiety around misinterpretations of SHOULD NOT as SHALL NOT, particularly by auditors. By changing this to NOT RECOMMENDED, the same guidance is preserved, but it hopefully makes it more palatable to CAs. See https://github.com/sleevi/cabforum-docs/pull/36/files#r856429830 for related discussion.

This restructures the naming rules to try to clarify: - That technically constrained non-TLS sub-CAs are in-scope, but the certificates they issue are not - That the rules about byte-for-byte apply for all certificates in scope - That the requirements for the ordering and sequencing of names is a forward-dated requirement. Although it can be argued that some of these are existing requirements, avoid any messiness by structuring it holistically. - Adds a note to 7.1.4 to call out that 7.1.2.2.1 provides an exception - State the exception in 7.1.2.2.1 both normatively and informatively, to try and avoid misinterpretation. This was based on Corey's feedback in https://github.com/sleevi/cabforum-docs/pull/36/files#r689880007

This removes the (buggy) description of DNS SRV and leaves it overall as a SHOULD NOT and in scope of the (existing) 7.1.4.2 requirements. It also fixes up a typo (extension OID -> type-id)

Originally it was part of the common fields, when there were multiple variations of non-TLS CAs. However, as there is only a single reference to this section, fold it in to the non-TLS profile. This hopefully makes it clearer about the EKU requirements for non-TLS CAs (being what defines something as non-TLS), and reduces some confusion around non-TLS and TLS common sections.

The existing language was buggy, in that a link target was updated, but not the section heading. However, it was further buggy due to the interactions between Affiliated and Non-Affiliated CAs. This overhauls it in line with the November and F2F discussions; unlike many of the other extensions in this section (which are dictated by RFC 5280 as being mandatory for certain situations), certificatePolicies is not, so this is demoted to a MAY. However, the language from RFC 5280 does set out some guidance - such as not recommending that a policyQualifier be present - and so that requirement is preserved, under the argument that a non-TLS CA should still align with RFC 5280 if issued under a BR CA. This does *remove* an existing BR requirement, namely those inherited from Section 7.1.6.3, but since that seemed to align with the intent of the SCWG, this should be a positive change.

This makes the requirement for the Reserved Policy Identifier to be the first policyIdentifier optional, while explaining with a note the basis for that logic. To avoid confusion, it makes it clear that only one instance of a Reserved Policy Identifier may be present (e.g. can't be simultaneously OV and EV)

This incorporates Corey's sleevi@04c55a4

The approach to SKI uniqueness was flagged as ambigous, and two options were presented: - Option 1, mandate the SKI generation algorithm - Option 2, clarify that it's only unique "for the CA" Option 2 still has security risks with respect to denial of service, but CAs were unsure about when Option 1 would b eimplementable (e.g. if mandating SHA-2, CA software that uses SHA-1 would need to be updated). For now, this goes with Option 2, although a mandatory algorithm would resolve the issues wholesale. This is adapted from Corey Bonnell's sleevi@41cb306

This adopts a 48 hour window, as proposed in sleevi@816ad7a

This moves the metadata prohibition and domain name prohibition from applying to all certificates to only applying to Subscriber certificates (and in particular, to IV/OV/EV). This also corrects the organizationalUnit name to reflect SC47v2.

This only affects the certificatePolicies for OCSP Responders and the naming rules (for all certificates), but shifts to a harmonized date.

Changing dataEncipherment for RSA and KeyAgreement for ECC to not recommended.

* Add single all-encompassing effective date * Integrate discussion from 2022-08-25 VSC call Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com>

Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com>

* Update to allow multiple instances of subject attributes To allow for multiple instances of the domainContact attributes until we can address at an upcoming ballot. * Specific exceptions for attributes with multiple instances Allow multiple instances of the same attribute for `streetAddress` and `domainComponent`. For the latter, language from [ballot 102](https://cabforum.org/2013/05/31/ballot-102-br-9-2-3-domaincomponent/) was used. * Correct IV streetAddress multiple instances For consistency allow multiple instances for the `streetAddress` attribute in IV Certificates. * Update docs/BR.md Improved language for the domainComponent Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com>

Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com>

* Clarify that OUs are not allowed for CA Certificates described in section 7.1.2.3 per conversation in https://lists.cabforum.org/pipermail/validation/2022-October/001812.html. Added an effective date of 2022-12-12 which can be updated as needed. * Fix typo with quotes * Update based on F2F 57 - Removal of OU validation rules prior to 2022-12-12 because it includes non-TLS Issuing CAs - Clarification that the "MUST NOT" for OUs after 2022-12-12 also applies to Root CA Certificates and TLS Subordinate CA Certificates * fix effective date * Fix references and adding the two types of TLS CAs * Improve language around OUs in CA Certificates Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Capitalize "CA certificates" for consistency * Fix typo Fix typo based on #398 (comment) Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com>

* Add order and encoding requirement for DC attribute * Remove overly specific Cross-cert requirement; fix serialNumber encoding * Clarify NC exclusion * Remove "Domain Name or IP Address" validation requirement for now Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com>

chrisbn · 2022-11-24T13:41:00Z

docs/BR.md

-   __Optional__ if the `subject:organizationName`, `subject:givenName` field, or `subject:surname` fields are present.  
-   __Prohibited__ if the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are absent.  
-   __Contents:__ If present, the `subject:postalCode` field MUST contain the Subject's zip or postal information as verified under [Section 3.2.2.1](#3221-identity).
+CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL encode those attributes in the relative order as they appear in the table and follow the specified encoding requirements for the attribute.


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

chrisbn · 2022-11-24T14:15:12Z

docs/BR.md


-By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate's issuance date, all of the Subject Information was accurate.
+Table: Encoding Requirements for Selected Attributes


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?

* Update README (#294) Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Adjust the workflow file to build the actions (#296) This addresses a few requests that recently came up from the certificate profiles work: - Remove the explicit retention period (of 21 days) to allow the GitHub default of 90 days. - Change the generated ZIP file from being "BR.md-hash" to being "BR-hash". - Allow manually invoking the workflow (via workflow_dispatch), in the event folks want to re-run for a particular branch (e.g. profiles) - Attempt to resolve the "non-deterministic redline" noted by Jos. When a given commit is on cabforum/servercert, it may be both a commit (to a branch) and part of a pull request (to main). We want the pull request redline to be against main, while the commit redline to be against the previous commit. Because both jobs run, and both upload the same file name, this results in a non-deterministic clobbering, where the commit-redline may clobber the pr-redline. This changes the generated zip file to be "file-hash-event_type", so that it will generate redlines for both PRs and commits and attach both. * SC47 Sunset subject:organizationalUnitName (#282) (#290) * SC47 Sunset subject:organizationalUnitName (#282) * Deprecation of subject:organizationalUnitName * Update language to avoid confusion on the effective date This version updates SC47 to state "issued on or after September 1, 2022" and makes the EV Guidelines reference the BRs as suggested by Ryan Sleevi from Google. Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC47 datefix (#298) * Update dates table * Update EVG.md Add SC47 reference to relevant dates table * Fixup section number in prior commit Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> * SC48 - Domain Name and IP Address Encoding (#285) (#302) * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC50 - Remove the requirements of 4.1.1 (#328) * SC50 - Remove the requirements of 4.1.1 (#323) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](Kozea/CairoSVG@1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Remove 4.1.1; persist compromised keys in 6.1.1.3 Remove section 4.1.1 from the BRs Explicitly require persistent access to compromised keys * Rebase based on upstream/main * Move System requirement to 6.1.1.3 * Add 4.1.1 as blank * Remove capitalization from 6.1.1.3 where terms are not defined * Re-add 'No stipulation.' to 4.1.1 * Remove change to 6.1.1.3 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update version and date table Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC53: Sunset SHA-1 for OCSP signing (#330) (#338) * Sunset SHA-1 for OCSP signing (#330) * Sunset SHA-1 OCSP signing * Clarify necessity of both items * Standardize date format, fix year in effective date table Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version, table, and date Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Bump actions/checkout from 2 to 3 (#342) Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v2...v3) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Ballot SC51: Reduce and Clarify Log and Records Archival Retention Requirements (#347) * Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements (#336) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](Kozea/CairoSVG@1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Restructure parts of 5.4.x and 5.5.x * Use 'events' consistently in 5.4.1 * Forgot to remove "revocation" as condition for start of retention period of Subscriber Certificates. * Introduce possessive in 5.4.1 and 5.5.1 to better deliniate responsiblities of CAs using DTPs * Remove WIP title; * re-order list in 5.5.2; add 'or' clause to validation documentation archival list entry. * Incorporate feedback from Aaron and Dimitris in Servercert-wg Discussion Period Based on the feedback from Aaron here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003115.html) and here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003125.html), update 5.5.1 and 5.5.2. Based on the feedback from Dimitris here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003110.html), update 5.4.3 and 5.5.2. * Update link formatting in 5.4.1 The "Section" links throughout include the word "Section" in the link, except for in 5.4.1; this fixes that inconsistency. Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC54: Onion Cleanup (#369) * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to #191 (comment), effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to #191 (comment), effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Integrate SC-48 CN requirements Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com>

* Update README (#294) Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Adjust the workflow file to build the actions (#296) This addresses a few requests that recently came up from the certificate profiles work: - Remove the explicit retention period (of 21 days) to allow the GitHub default of 90 days. - Change the generated ZIP file from being "BR.md-hash" to being "BR-hash". - Allow manually invoking the workflow (via workflow_dispatch), in the event folks want to re-run for a particular branch (e.g. profiles) - Attempt to resolve the "non-deterministic redline" noted by Jos. When a given commit is on cabforum/servercert, it may be both a commit (to a branch) and part of a pull request (to main). We want the pull request redline to be against main, while the commit redline to be against the previous commit. Because both jobs run, and both upload the same file name, this results in a non-deterministic clobbering, where the commit-redline may clobber the pr-redline. This changes the generated zip file to be "file-hash-event_type", so that it will generate redlines for both PRs and commits and attach both. * SC47 Sunset subject:organizationalUnitName (#282) (#290) * SC47 Sunset subject:organizationalUnitName (#282) * Deprecation of subject:organizationalUnitName * Update language to avoid confusion on the effective date This version updates SC47 to state "issued on or after September 1, 2022" and makes the EV Guidelines reference the BRs as suggested by Ryan Sleevi from Google. Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC47 datefix (#298) * Update dates table * Update EVG.md Add SC47 reference to relevant dates table * Fixup section number in prior commit Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> * SC48 - Domain Name and IP Address Encoding (#285) (#302) * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC50 - Remove the requirements of 4.1.1 (#328) * SC50 - Remove the requirements of 4.1.1 (#323) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](Kozea/CairoSVG@1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Remove 4.1.1; persist compromised keys in 6.1.1.3 Remove section 4.1.1 from the BRs Explicitly require persistent access to compromised keys * Rebase based on upstream/main * Move System requirement to 6.1.1.3 * Add 4.1.1 as blank * Remove capitalization from 6.1.1.3 where terms are not defined * Re-add 'No stipulation.' to 4.1.1 * Remove change to 6.1.1.3 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update version and date table Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC53: Sunset SHA-1 for OCSP signing (#330) (#338) * Sunset SHA-1 for OCSP signing (#330) * Sunset SHA-1 OCSP signing * Clarify necessity of both items * Standardize date format, fix year in effective date table Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version, table, and date Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Bump actions/checkout from 2 to 3 (#342) Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](actions/checkout@v2...v3) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Ballot SC51: Reduce and Clarify Log and Records Archival Retention Requirements (#347) * Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements (#336) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](Kozea/CairoSVG@1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Restructure parts of 5.4.x and 5.5.x * Use 'events' consistently in 5.4.1 * Forgot to remove "revocation" as condition for start of retention period of Subscriber Certificates. * Introduce possessive in 5.4.1 and 5.5.1 to better deliniate responsiblities of CAs using DTPs * Remove WIP title; * re-order list in 5.5.2; add 'or' clause to validation documentation archival list entry. * Incorporate feedback from Aaron and Dimitris in Servercert-wg Discussion Period Based on the feedback from Aaron here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003115.html) and here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003125.html), update 5.5.1 and 5.5.2. Based on the feedback from Dimitris here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003110.html), update 5.4.3 and 5.5.2. * Update link formatting in 5.4.1 The "Section" links throughout include the word "Section" in the link, except for in 5.4.1; this fixes that inconsistency. Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC54: Onion Cleanup (#369) * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to #191 (comment), effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to #191 (comment), effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC-56: 2022 Cleanup (#401) * SC-56: 2022 Cleanup (#385) Ballot has passed; moving to SC56 branch for IPR * #340 * #339 * #333 * #318 * #315 * #312 * #309 * #275 * #344 * #345 * #378 * #380 * #287 * #300 * #259 * #284 * #277 * #311 * #310 * Remove historical effective dates * #196 * #251 * #212 * #386 * Grammatical improvement suggested by Wendy Brown * Remove text for retired methods * Switch to new tables tooling * Fix broken section references * Bump upload-artifact version * Linkify US denied persons/entities list URLs Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update effective dates and tables Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-58: Require distributionPoint in sharded CRLs (#396) (#403) * SC-58: Require distributionPoint in sharded CRLs (#396) * SC-XX: Require distributionPoint in sharded CRLs The language in RFC 5280 regarding the interaction between the distributionPoint field of the Issuing Distribution Point CRL extension and the existence of sharded CRLs has led to significant debate on interpretation, and appears to contradict X.509. To protect against replacement attacks, make it explicitly clear that the Issuing Distribution Point extension and distributionPoint field are required for sharded or partitioned CRLs. * Remind readers that the IDP must be critical * Change effective date to Jan 15 * Change effective date in Section 1.2 table, too * Update BR.md Co-authored-by: Aaron Gable <aaron@letsencrypt.org> Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Aaron Gable <aaron@letsencrypt.org>

wthayer · 2023-01-14T00:11:53Z

docs/BR.md

+  * [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile)
+  * [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile)
+  * [Section 7.1.2.9 - Precertificate Profile](#7129-precertificate-profile)
+


Should this table of contents include sections 7.1.2.10 and 7.1.2.11?

* Update BR.md * Update BR.md

* Add policyQualifiers Note Added explanation of rationale for NOT RECOMMENDED to section 7.1.2.10.5 * Update docs/BR.md Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com>

* Use unicode figure space for table indentation * Use unicode superscript for exponentiation * Fix surname_givenname footnote link * Use approx instead of e.g. for approximate years * Include profile name in subsection titles * Reduce table duplication in 7.1.2.2.3 * Explain criticality of Subscriber SAN in-line * Unify language in 7.1.2.7.12 * Unify language around NULL extension values * Simplify CRL Distribution Point tables * Cross-Certification establishes trust between any two CAs * Fix AuthorityInfoAccessSyntax name * More flexible Certificate Policy OID definitions * Close two precertificates with same serial loophole * fix basicConstraints empty value Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Fix upper bound for organizational-unit-name [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#:~:text=ub%2Dorganizational%2Dunit%2Dname%20INTEGER%20%3A%3A%3D%2064) defines 64 characters as the upper bound for ub-organizational-unit-name. * Fix typo: "committment" --> "commitment" (#2) * Clarify Cross-Certificate EKU Requirements (#3) --------- Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Ryan Dickson <ryan.dickson@gmail.com>

* Update BR.md * Update BR.md * Update BR.md * Update BR.md * Update BR.md

* Profiles WIP * Clarify AIA based on 2021-06-12 call AIA allows multiple methods, and multiple instances of each method. However, client implementations use the ordering to indicate priority, as per RFC 5280, so clarify the requirements for multiple AccessDescriptions with the same accessMethod. * Address basicConstraints for OCSP Responder feedback Rather than make basicConstraints MUST, make it a MAY, to allow omission (plus v3) or presence (but empty) to indicate that it is not a CA certificate. * Address cRLDistributionPoints As captured on https://archive.cabforum.org/pipermail/validation/2021-July/001675.html provide better guidance for the encoding of cRLDistributionPoints and the permitted protocols. * Fix broken link and better clarify WIP sections * Clarify OCSP and other EKUs Non-TLS CAs MUST NOT include id-kp-OCSPSigning, since this would potentially make them OCSP signers for the issuing CA. Similarly, with respect to non-TLS CAs, it's fine (and useful!) to use other EKUs, so this is a MAY (or possibly SHOULD), not a SHOULD NOT. * Remove stale FIXME regarding serial numbers * Introduce Precertificate Signing CA Profile A Precertificate Signing CA, ontologically, a type of Technically Constrained Non-TLS Sub-CA, by virtue of the Extended Key Usage. To avoid ambiguity, this introduces a profile specific for Precert Signing CAs that make it clear that the Precert Signing EKU MUST be the only EKU present, to avoid a situation similar to that seen with OCSP responders. RFC 6962 is somewhat fast and loose with respect to whether or not "CA:true" is required in the profile for these, but in practice, implementations of logs, and existing CAs, do expect CA:true. Although not meant to be a normative change from the existing practices and consequences of existing requirements, it does make explicit that such CAs MUST only sign Precertificates; although this is less critical given the EKU constraint (to being a singular EKU), it represents a defense in depth approach consistent with existing practice. * Align postalCode/streetAddress hierarchy As pointed out by DigiCert, postal code represents a greater enclosing area than the street address, and thus hierarchically should appear first. * Fix nameConstraints for TLS subCAs They were accidentally a MUST, when they should have been a MAY. Bad copy/paste. * Bump OCSP placeholder dates for cert policies Move the effective date to 6 months from now; will likely continue to move as we finalize things, but offers a placeholder to handling effective dates. * Make cRLDP MUST NOT for OCSP Responders As pointed out by Corey, an id-pkix-ocsp-nocheck should be expected to disable all revocation checking (not just recursive OCSP revocation checking), so it makes sense to MUST NOT the cRLDP for the OCSP Responder, since we MUST nocheck. * Fix typo -> MMAY to MAY * Precertificates and Precertificate Signing CAs This introduces the notion of Precertificates and Precertificate Signing CAs as part of the Profiles, and captures the existing requirements from RFC 6962. It defines a Precertificate as based on a transformation of an existing Certificate conforming to one of the profiles, as opposed to attempting to define variants for every version or how to construct a Precertificate for a given profile. This attempts to similarly capture that, for purposes of compliance, a Precertificate is treated as if there is an equivalent Certificate, by reflecting that Precertificates need to match a Certificate based on the transformations defined, and that the Certificates need to match the profiles defined. * Address validity periods This attempts to clarify when/how backdating is allowed, particularly since it may affect path building. It gives a generous period for CA backdating when the distinguishedName remains the same, but may be imperfect if the keys are changing. * Address the "any other value" situations with 7.1.2.4 language This adopts the language from 7.1.2.4 to the various extensibility points, by trying to explicitly clarify as appropriate as to what is permitted. * Fix the certificatePolicies mismatched highlighted by Corey * Formatting and plurality fixup * Change SHOULD NOT to NOT RECOMMENDED While RFC 2119 establishes that these two phrases are semantically equivalent, it's been suggested that this may resolve some anxiety around misinterpretations of SHOULD NOT as SHALL NOT, particularly by auditors. By changing this to NOT RECOMMENDED, the same guidance is preserved, but it hopefully makes it more palatable to CAs. See https://github.com/sleevi/cabforum-docs/pull/36/files#r856429830 for related discussion. * Clarify subject name rules & add effective date This restructures the naming rules to try to clarify: - That technically constrained non-TLS sub-CAs are in-scope, but the certificates they issue are not - That the rules about byte-for-byte apply for all certificates in scope - That the requirements for the ordering and sequencing of names is a forward-dated requirement. Although it can be argued that some of these are existing requirements, avoid any messiness by structuring it holistically. - Adds a note to 7.1.4 to call out that 7.1.2.2.1 provides an exception - State the exception in 7.1.2.2.1 both normatively and informatively, to try and avoid misinterpretation. This was based on Corey's feedback in https://github.com/sleevi/cabforum-docs/pull/36/files#r689880007 * Remove dnsSRV and cleanup otherName handling This removes the (buggy) description of DNS SRV and leaves it overall as a SHOULD NOT and in scope of the (existing) 7.1.4.2 requirements. It also fixes up a typo (extension OID -> type-id) * Formatting fix * Move the Non-TLS EKU requirement into the Non-TLS profile Originally it was part of the common fields, when there were multiple variations of non-TLS CAs. However, as there is only a single reference to this section, fold it in to the non-TLS profile. This hopefully makes it clearer about the EKU requirements for non-TLS CAs (being what defines something as non-TLS), and reduces some confusion around non-TLS and TLS common sections. * Redo Certificate Policies for Non-TLS CAs The existing language was buggy, in that a link target was updated, but not the section heading. However, it was further buggy due to the interactions between Affiliated and Non-Affiliated CAs. This overhauls it in line with the November and F2F discussions; unlike many of the other extensions in this section (which are dictated by RFC 5280 as being mandatory for certain situations), certificatePolicies is not, so this is demoted to a MAY. However, the language from RFC 5280 does set out some guidance - such as not recommending that a policyQualifier be present - and so that requirement is preserved, under the argument that a non-TLS CA should still align with RFC 5280 if issued under a BR CA. This does *remove* an existing BR requirement, namely those inherited from Section 7.1.6.3, but since that seemed to align with the intent of the SCWG, this should be a positive change. * Make PolicyIdentifier ordering optional This makes the requirement for the Reserved Policy Identifier to be the first policyIdentifier optional, while explaining with a note the basis for that logic. To avoid confusion, it makes it clear that only one instance of a Reserved Policy Identifier may be present (e.g. can't be simultaneously OV and EV) * Indicate a max for serial numbers This incorporates Corey's https://github.com/sleevi/cabforum-docs/pull/39/commits/04c55a4cdf2f6ea068bd1f743a83b60def34dcae * Try to address the SKI uniqueness The approach to SKI uniqueness was flagged as ambigous, and two options were presented: - Option 1, mandate the SKI generation algorithm - Option 2, clarify that it's only unique "for the CA" Option 2 still has security risks with respect to denial of service, but CAs were unsure about when Option 1 would b eimplementable (e.g. if mandating SHA-2, CA software that uses SHA-1 would need to be updated). For now, this goes with Option 2, although a mandatory algorithm would resolve the issues wholesale. This is adapted from Corey Bonnell's https://github.com/sleevi/cabforum-docs/pull/39/commits/41cb3063b41af69615bba5410279396994d2ebc0 * Allow backdating up to 48 hours This adopts a 48 hour window, as proposed in https://github.com/sleevi/cabforum-docs/pull/39/commits/816ad7aa79cbfc1315561590d89ed7a9fd076b97 * Naming Cleanup This moves the metadata prohibition and domain name prohibition from applying to all certificates to only applying to Subscriber certificates (and in particular, to IV/OV/EV). This also corrects the organizationalUnit name to reflect SC47v2. * Harmonize effective dates to 2022-11-01 This only affects the certificatePolicies for OCSP Responders and the naming rules (for all certificates), but shifts to a harmonized date. * Formatting & Section Heading fixes This fixes a few unnumbered sections (around validity periods) and adjusts the formatting for several tables to better accomodate the text. * OrganizationalUnitName fixups Fixup the OU field * Remove stale TODO/TBDs * Fix a bug in non-TLS technically constrained CAs For non-TLS CAs, don't allow them to assert the BR's CP OIDs, as the certificates will not be BR compliant. * CT Cleanups In order for the precertificate signing CA to be considered technically constrained, restrict its EKU to only permitting it to issue precertificates. Additionally, add a cross-reference and tweak a MAY to a may, as the paragraph that follows the MAY contains the actual normative requirement, and this is just an informative explainer. * Remove rfc822Name from TLS technically constrained CAs rfc822Name is allowed, and described, in 7.1.2.10.9, as its a translation of the requirements of 3.2.2.4/3.2.2.5/7.1.2.4 of the existing BRs, and there are some CA profiles that allow non-TLS EKUs to be present (for ex, cross-certification). For technically constrained TLS sub-CAs, it was originally present because of Mozilla Root Store Policy, Section 1.1, which requires out-of-scope CAs to constrain on that name type. However, since a TCSC TLS CA MUST NOT include EKUs other than serverAuth & clientAuth, it was seen as unnecessary to even allow rfc822Name. * Clarify Precert language This clarifies the language around precerts by: * harmonizing on 'corresponding Certificate' instead of 'equivalent Certificate' * changing 'byte-for-byte equivalent' to 'byte-for-byte identical' to avoid any ambiguity * Rewording the AKI section when using a Precert Signing CA, to avoid stating the same requirement several ways that might be read as giving conflicting or different guidance, and RECOMMENDING/SHOULD harmonizing on the AKI containing the Precert Signing CA's SKI, as the Log is expected to transform and substitute (and all observed logs appear to do so). * Redo Certificate Policies This reworks the presentation and format of the certificatePolicies extensions, better aligning to the BRs, and hopefully providing sufficient clarity: Relaxations: - Reserved Policy OID is * no longer* required to be first, but is RECOMMENDED (SHOULD). - The separation of "Affiliated" and "Unaffiliated" for certificate policies is removed. This was introduced for Cross-Certified Sub-CAs, but resulted in some ambiguity about what happens when a Technically Constrained (non-TLS or nameConstraints) Sub-CA is operated by a non-Affiliated entity. The requirements around Affiliation are now folded into a common section, rather than being two sections. - Although not permitted by the current BRs, the cPSuri is now explicitly allowed for all certificate policies (_including_ for anyPolicy). - anyPolicy is now explicitly permitted (but NOT RECOMMENDED) for OCSP Responders - Reserved CABF OIDs are now explicitly permitted (but NOT RECOMMENDED) for OCSP Responders. Clarifications: - A note is added to the OCSP Responder section explaining that because CPs limit the validity and purposes of a certificate, it becomes possible to create an "invalid" responder that clients will reject (and thus also reject responses), and that this is part of the reason for forbidding. - For TLS certificates, the requirements for CPs for sub-CAs versus leaf certificates had a slightly different wording: whether a given CP needed to be documented by the CA (e.g. could be any policy, including a reserved CP or anyPolicy) or needed to be _defined_ and documented by the CA (i.e. must be from the CA's own OID arc). This harmonizes the language for TLS ("defined by"), while still leaving a fairly large carveout for non-TLS ("documented"). * Changes to Key Usage values for Subscriber Certificates (#376) Changing dataEncipherment for RSA and KeyAgreement for ECC to not recommended. * Definitions Update - Pending Prohibition (#388) * Add single all-encompassing effective date (#381) * Add single all-encompassing effective date * Integrate discussion from 2022-08-25 VSC call Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Add specification for EV attributes (#391) Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update to allow multiple instances of subject attributes (#392) * Update to allow multiple instances of subject attributes To allow for multiple instances of the domainContact attributes until we can address at an upcoming ballot. * Specific exceptions for attributes with multiple instances Allow multiple instances of the same attribute for `streetAddress` and `domainComponent`. For the latter, language from [ballot 102](https://cabforum.org/2013/05/31/ballot-102-br-9-2-3-domaincomponent/) was used. * Correct IV streetAddress multiple instances For consistency allow multiple instances for the `streetAddress` attribute in IV Certificates. * Update docs/BR.md Improved language for the domainComponent Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Add order and encoding requirement for DC attribute (#395) Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Clarify OUs in CA Certificates (#398) * Clarify that OUs are not allowed for CA Certificates described in section 7.1.2.3 per conversation in https://lists.cabforum.org/pipermail/validation/2022-October/001812.html. Added an effective date of 2022-12-12 which can be updated as needed. * Fix typo with quotes * Update based on F2F 57 - Removal of OU validation rules prior to 2022-12-12 because it includes non-TLS Issuing CAs - Clarification that the "MUST NOT" for OUs after 2022-12-12 also applies to Root CA Certificates and TLS Subordinate CA Certificates * fix effective date * Fix references and adding the two types of TLS CAs * Improve language around OUs in CA Certificates Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Capitalize "CA certificates" for consistency * Fix typo Fix typo based on https://github.com/cabforum/servercert/pull/398#discussion_r1013037979 Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Minor fixes and cleanups (#399) * Add order and encoding requirement for DC attribute * Remove overly specific Cross-cert requirement; fix serialNumber encoding * Clarify NC exclusion * Remove "Domain Name or IP Address" validation requirement for now Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Integrate newer ballots (#406) * Update README (#294) Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Adjust the workflow file to build the actions (#296) This addresses a few requests that recently came up from the certificate profiles work: - Remove the explicit retention period (of 21 days) to allow the GitHub default of 90 days. - Change the generated ZIP file from being "BR.md-hash" to being "BR-hash". - Allow manually invoking the workflow (via workflow_dispatch), in the event folks want to re-run for a particular branch (e.g. profiles) - Attempt to resolve the "non-deterministic redline" noted by Jos. When a given commit is on cabforum/servercert, it may be both a commit (to a branch) and part of a pull request (to main). We want the pull request redline to be against main, while the commit redline to be against the previous commit. Because both jobs run, and both upload the same file name, this results in a non-deterministic clobbering, where the commit-redline may clobber the pr-redline. This changes the generated zip file to be "file-hash-event_type", so that it will generate redlines for both PRs and commits and attach both. * SC47 Sunset subject:organizationalUnitName (#282) (#290) * SC47 Sunset subject:organizationalUnitName (#282) * Deprecation of subject:organizationalUnitName * Update language to avoid confusion on the effective date This version updates SC47 to state "issued on or after September 1, 2022" and makes the EV Guidelines reference the BRs as suggested by Ryan Sleevi from Google. Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC47 datefix (#298) * Update dates table * Update EVG.md Add SC47 reference to relevant dates table * Fixup section number in prior commit Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> * SC48 - Domain Name and IP Address Encoding (#285) (#302) * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC50 - Remove the requirements of 4.1.1 (#328) * SC50 - Remove the requirements of 4.1.1 (#323) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Remove 4.1.1; persist compromised keys in 6.1.1.3 Remove section 4.1.1 from the BRs Explicitly require persistent access to compromised keys * Rebase based on upstream/main * Move System requirement to 6.1.1.3 * Add 4.1.1 as blank * Remove capitalization from 6.1.1.3 where terms are not defined * Re-add 'No stipulation.' to 4.1.1 * Remove change to 6.1.1.3 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update version and date table Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC53: Sunset SHA-1 for OCSP signing (#330) (#338) * Sunset SHA-1 for OCSP signing (#330) * Sunset SHA-1 OCSP signing * Clarify necessity of both items * Standardize date format, fix year in effective date table Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version, table, and date Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Bump actions/checkout from 2 to 3 (#342) Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v2...v3) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Ballot SC51: Reduce and Clarify Log and Records Archival Retention Requirements (#347) * Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements (#336) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Restructure parts of 5.4.x and 5.5.x * Use 'events' consistently in 5.4.1 * Forgot to remove "revocation" as condition for start of retention period of Subscriber Certificates. * Introduce possessive in 5.4.1 and 5.5.1 to better deliniate responsiblities of CAs using DTPs * Remove WIP title; * re-order list in 5.5.2; add 'or' clause to validation documentation archival list entry. * Incorporate feedback from Aaron and Dimitris in Servercert-wg Discussion Period Based on the feedback from Aaron here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003115.html) and here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003125.html), update 5.5.1 and 5.5.2. Based on the feedback from Dimitris here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003110.html), update 5.4.3 and 5.5.2. * Update link formatting in 5.4.1 The "Section" links throughout include the word "Section" in the link, except for in 5.4.1; this fixes that inconsistency. Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC54: Onion Cleanup (#369) * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Integrate SC-48 CN requirements Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> * Integrate SC-56 and SC-58 (#409) * Update README (#294) Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Adjust the workflow file to build the actions (#296) This addresses a few requests that recently came up from the certificate profiles work: - Remove the explicit retention period (of 21 days) to allow the GitHub default of 90 days. - Change the generated ZIP file from being "BR.md-hash" to being "BR-hash". - Allow manually invoking the workflow (via workflow_dispatch), in the event folks want to re-run for a particular branch (e.g. profiles) - Attempt to resolve the "non-deterministic redline" noted by Jos. When a given commit is on cabforum/servercert, it may be both a commit (to a branch) and part of a pull request (to main). We want the pull request redline to be against main, while the commit redline to be against the previous commit. Because both jobs run, and both upload the same file name, this results in a non-deterministic clobbering, where the commit-redline may clobber the pr-redline. This changes the generated zip file to be "file-hash-event_type", so that it will generate redlines for both PRs and commits and attach both. * SC47 Sunset subject:organizationalUnitName (#282) (#290) * SC47 Sunset subject:organizationalUnitName (#282) * Deprecation of subject:organizationalUnitName * Update language to avoid confusion on the effective date This version updates SC47 to state "issued on or after September 1, 2022" and makes the EV Guidelines reference the BRs as suggested by Ryan Sleevi from Google. Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC47 datefix (#298) * Update dates table * Update EVG.md Add SC47 reference to relevant dates table * Fixup section number in prior commit Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> * SC48 - Domain Name and IP Address Encoding (#285) (#302) * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * SC48 - Domain Name and IP Address Encoding (#285) * First pass * Add more RFC references, some wordsmithing * Another few fixes * Switch to use "LDH Labels" * Propose concrete effective date * Clarification about root zone trailing dot * Replace "label" with "Domain Label" throughout (#1) Replace "label" with "Domain Label" and "domain name" with "Domain Name" throughout Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos <castillar@melete.org> * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC50 - Remove the requirements of 4.1.1 (#328) * SC50 - Remove the requirements of 4.1.1 (#323) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Remove 4.1.1; persist compromised keys in 6.1.1.3 Remove section 4.1.1 from the BRs Explicitly require persistent access to compromised keys * Rebase based on upstream/main * Move System requirement to 6.1.1.3 * Add 4.1.1 as blank * Remove capitalization from 6.1.1.3 where terms are not defined * Re-add 'No stipulation.' to 4.1.1 * Remove change to 6.1.1.3 Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update version and date table Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC53: Sunset SHA-1 for OCSP signing (#330) (#338) * Sunset SHA-1 for OCSP signing (#330) * Sunset SHA-1 OCSP signing * Clarify necessity of both items * Standardize date format, fix year in effective date table Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version, table, and date Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Bump actions/checkout from 2 to 3 (#342) Bumps [actions/checkout](https://github.com/actions/checkout) from 2 to 3. - [Release notes](https://github.com/actions/checkout/releases) - [Changelog](https://github.com/actions/checkout/blob/main/CHANGELOG.md) - [Commits](https://github.com/actions/checkout/compare/v2...v3) --- updated-dependencies: - dependency-name: actions/checkout dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> * Ballot SC51: Reduce and Clarify Log and Records Archival Retention Requirements (#347) * Ballot SC51: Reduce and Clarify Audit Log and Records Archival Retention Requirements (#336) * Bump cairosvg from 1.0.20 to 2.5.1 Bumps [cairosvg](https://github.com/Kozea/CairoSVG) from 1.0.20 to 2.5.1. - [Release notes](https://github.com/Kozea/CairoSVG/releases) - [Changelog](https://github.com/Kozea/CairoSVG/blob/master/NEWS.rst) - [Commits](https://github.com/Kozea/CairoSVG/compare/1.0.20...2.5.1) Signed-off-by: dependabot[bot] <support@github.com> * Bump kramdown from 2.3.0 to 2.3.1 Bumps [kramdown](https://github.com/gettalong/kramdown) from 2.3.0 to 2.3.1. - [Release notes](https://github.com/gettalong/kramdown/releases) - [Changelog](https://github.com/gettalong/kramdown/blob/master/doc/news.page) - [Commits](https://github.com/gettalong/kramdown/commits) Signed-off-by: dependabot[bot] <support@github.com> * Restructure parts of 5.4.x and 5.5.x * Use 'events' consistently in 5.4.1 * Forgot to remove "revocation" as condition for start of retention period of Subscriber Certificates. * Introduce possessive in 5.4.1 and 5.5.1 to better deliniate responsiblities of CAs using DTPs * Remove WIP title; * re-order list in 5.5.2; add 'or' clause to validation documentation archival list entry. * Incorporate feedback from Aaron and Dimitris in Servercert-wg Discussion Period Based on the feedback from Aaron here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003115.html) and here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003125.html), update 5.5.1 and 5.5.2. Based on the feedback from Dimitris here (https://lists.cabforum.org/pipermail/servercert-wg/2022-January/003110.html), update 5.4.3 and 5.5.2. * Update link formatting in 5.4.1 The "Section" links throughout include the word "Section" in the link, except for in 5.4.1; this fixes that inconsistency. Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * Ballot SC54: Onion Cleanup (#369) * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-54: Onion cleanup (#348) # Voting Results The voting on ballot SC54 has completed, and the ballot has passed. Voting Results Certificate Issuers votes total, with no abstentions: 18 Yes votes: Amazon, Buypass, DigiCert, eMudhra, Entrust, GDCA, GlobalSign, GoDaddy, HARICA, Izenpe, JPRS, NAVER, OISTE, Sectigo, SwissSign, TrustCor, SecureTrust, Visa 0 No Votes 0 Abstentions Certificate Consumers 6 votes total, with no abstentions: 6 Yes votes: 360, Apple, Cisco, Google, Microsoft, Mozilla 0 No votes 0 Abstentions Bylaw Requirements 1. Bylaw 2.3(f) requires: · A "yes" vote by two-thirds of Certificate Issuer votes and by 50%-plus-one of Certificate Consumer votes. Votes to abstain are not counted for this purpose. This requirement was MET for Certificate Issuers and MET for Certificate Consumers. · At least one Certificate Issuer and one Certificate Consumer Member must vote in favor of a ballot for the ballot to be adopted. This requirement was MET. 2. Bylaw 2.3(g) requires that a ballot result only be considered valid when “more than half of the number of currently active Members has participated”. Votes to abstain are counted in determining quorum. Half of the currently active members at the start of voting was 14, so the quorum was 15 for this ballot. This requirement was MET. This ballot now enters the IP Rights Review Period to permit members to review the ballot for relevant IP rights issues. —— # Commit History * Addresses #270 allowing method 3.2.2.4.20 for `.onion` domains. * Addresses #242 creating an exception for `.onion` domains, using existing language from the opening section of 3.2.2.4. * Addresses #241 removing the currently deprecated Domain validation method 3.2.2.4.6. * Addresses #240. Things are signed using private, not public keys. * Addresses #190, #191. According to https://github.com/cabforum/servercert/issues/191#issuecomment-827810409, effectively 2021-10-15 is when v2 stops working everywhere. We could proceed without an effective date, remove most of Appendix F in the EV Guidelines and point to Appendix B of the Baseline Requirements directly. No strong feelings either way. * This is a mitigation against a malicious CA but the Applicant ultimately creates the Nonce. We agreed with Corey and Wayne to propose the removal of the requirement for the CA to *confirm* entropy. * Update language to deprecate legacy Appendix F validation method with "immediate" effect, after the ballot clears IPR (30 days after voting). * remove double space * Remove EVG Appendix F, introduce Onion Domain Name term * A few more minor tweaks * Fix numbering * Update for easier read. * Revert "Update for easier read." This reverts commit 1bac785b2fd6a3fe0957434f9d13b13a47d4d19b. Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Jos Purvis <jopurvis@cisco.com> * SC-56: 2022 Cleanup (#401) * SC-56: 2022 Cleanup (#385) Ballot has passed; moving to SC56 branch for IPR * #340 * #339 * #333 * #318 * #315 * #312 * #309 * #275 * #344 * #345 * #378 * #380 * #287 * #300 * #259 * #284 * #277 * #311 * #310 * Remove historical effective dates * #196 * #251 * #212 * #386 * Grammatical improvement suggested by Wendy Brown * Remove text for retired methods * Switch to new tables tooling * Fix broken section references * Bump upload-artifact version * Linkify US denied persons/entities list URLs Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * Update effective dates and tables Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> * SC-58: Require distributionPoint in sharded CRLs (#396) (#403) * SC-58: Require distributionPoint in sharded CRLs (#396) * SC-XX: Require distributionPoint in sharded CRLs The language in RFC 5280 regarding the interaction between the distributionPoint field of the Issuing Distribution Point CRL extension and the existence of sharded CRLs has led to significant debate on interpretation, and appears to contradict X.509. To protect against replacement attacks, make it explicitly clear that the Issuing Distribution Point extension and distributionPoint field are required for sharded or partitioned CRLs. * Remind readers that the IDP must be critical * Change effective date to Jan 15 * Change effective date in Section 1.2 table, too * Update BR.md Co-authored-by: Aaron Gable <aaron@letsencrypt.org> Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Aaron Gable <aaron@letsencrypt.org> * This PR fixes issues in section 7.1.2.7.3 and 7.1.2.7.4. (#416) * Profiles extended effective date (#413) * Update BR.md * Update BR.md * Add policyQualifiers Note (#412) * Add policyQualifiers Note Added explanation of rationale for NOT RECOMMENDED to section 7.1.2.10.5 * Update docs/BR.md Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * SC-062 Profiles: Address various editorial and content nits (#418) * Use unicode figure space for table indentation * Use unicode superscript for exponentiation * Fix surname_givenname footnote link * Use approx instead of e.g. for approximate years * Include profile name in subsection titles * Reduce table duplication in 7.1.2.2.3 * Explain criticality of Subscriber SAN in-line * Unify language in 7.1.2.7.12 * Unify language around NULL extension values * Simplify CRL Distribution Point tables * Cross-Certification establishes trust between any two CAs * Fix AuthorityInfoAccessSyntax name * More flexible Certificate Policy OID definitions * Close two precertificates with same serial loophole * fix basicConstraints empty value Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> * Fix upper bound for organizational-unit-name [RFC 5280](https://www.rfc-editor.org/rfc/rfc5280#:~:text=ub%2Dorganizational%2Dunit%2Dname%20INTEGER%20%3A%3A%3D%2064) defines 64 characters as the upper bound for ub-organizational-unit-name. * Fix typo: "committment" --> "commitment" (#2) * Clarify Cross-Certificate EKU Requirements (#3) --------- Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Ryan Dickson <ryan.dickson@gmail.com> * Fix broken links (#427) * Update BR.md * Update BR.md * Update BR.md * Update BR.md * Update BR.md * Update BR.md (#429) --------- Co-authored-by: Ryan Sleevi <rsleevi@chromium.org> Co-authored-by: AnetaWojtczak <104534364+AnetaWojtczak@users.noreply.github.com> Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com> Co-authored-by: Dimitris Zacharopoulos <dzacharo@users.noreply.github.com> Co-authored-by: Jos <castillar@melete.org> Co-authored-by: Jos Purvis <jopurvis@cisco.com> Co-authored-by: Ryan Sleevi <sleevi@google.com> Co-authored-by: Paul van Brouwershaven <vanbroup@users.noreply.github.com> Co-authored-by: Ryan Sleevi <ryan.sleevi@gmail.com> Co-authored-by: Wayne Thayer <wthayer@gmail.com> Co-authored-by: Clint Wilson <clint@wilsonovi.com> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson <clintw@apple.com> Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Aaron Gable <aaron@letsencrypt.org> Co-authored-by: Ryan Dickson <ryan.dickson@gmail.com>

sleevi added 30 commits July 13, 2022 14:38

Profiles WIP

4b56725

Clarify AIA based on 2021-06-12 call

03a388e

AIA allows multiple methods, and multiple instances of each method. However, client implementations use the ordering to indicate priority, as per RFC 5280, so clarify the requirements for multiple AccessDescriptions with the same accessMethod.

Address basicConstraints for OCSP Responder feedback

f7e22bb

Rather than make basicConstraints MUST, make it a MAY, to allow omission (plus v3) or presence (but empty) to indicate that it is not a CA certificate.

Address cRLDistributionPoints

f22537f

As captured on https://archive.cabforum.org/pipermail/validation/2021-July/001675.html provide better guidance for the encoding of cRLDistributionPoints and the permitted protocols.

Fix broken link and better clarify WIP sections

1d5ee9c

Remove stale FIXME regarding serial numbers

25fd686

Align postalCode/streetAddress hierarchy

51811aa

As pointed out by DigiCert, postal code represents a greater enclosing area than the street address, and thus hierarchically should appear first.

Fix nameConstraints for TLS subCAs

b7a269b

They were accidentally a MUST, when they should have been a MAY. Bad copy/paste.

Bump OCSP placeholder dates for cert policies

a85067a

Move the effective date to 6 months from now; will likely continue to move as we finalize things, but offers a placeholder to handling effective dates.

Make cRLDP MUST NOT for OCSP Responders

941af64

As pointed out by Corey, an id-pkix-ocsp-nocheck should be expected to disable all revocation checking (not just recursive OCSP revocation checking), so it makes sense to MUST NOT the cRLDP for the OCSP Responder, since we MUST nocheck.

Fix typo -> MMAY to MAY

e62f560

Address validity periods

cb28681

This attempts to clarify when/how backdating is allowed, particularly since it may affect path building. It gives a generous period for CA backdating when the distinguishedName remains the same, but may be imperfect if the keys are changing.

Address the "any other value" situations with 7.1.2.4 language

57552a7

This adopts the language from 7.1.2.4 to the various extensibility points, by trying to explicitly clarify as appropriate as to what is permitted.

Fix the certificatePolicies mismatched highlighted by Corey

a2af324

Formatting and plurality fixup

ad4f121

Remove dnsSRV and cleanup otherName handling

cb1eff3

This removes the (buggy) description of DNS SRV and leaves it overall as a SHOULD NOT and in scope of the (existing) 7.1.4.2 requirements. It also fixes up a typo (extension OID -> type-id)

Formatting fix

e8eb511

Indicate a max for serial numbers

ed5f01c

This incorporates Corey's sleevi@04c55a4

Allow backdating up to 48 hours

04cadf2

This adopts a 48 hour window, as proposed in sleevi@816ad7a

Naming Cleanup

099122b

This moves the metadata prohibition and domain name prohibition from applying to all certificates to only applying to Subscriber certificates (and in particular, to IV/OV/EV). This also corrects the organizationalUnit name to reflect SC47v2.

Harmonize effective dates to 2022-11-01

ab5fedc

This only affects the certificatePolicies for OCSP Responders and the naming rules (for all certificates), but shifts to a harmonized date.

AnetaWojtczak and others added 3 commits August 16, 2022 16:44

Changes to Key Usage values for Subscriber Certificates (#376)

e7b2fbf

Changing dataEncipherment for RSA and KeyAgreement for ECC to not recommended.

Definitions Update - Pending Prohibition (#388)

15711d8

Add single all-encompassing effective date (#381)

18a98c3

* Add single all-encompassing effective date * Integrate discussion from 2022-08-25 VSC call Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com>

dzacharo force-pushed the profiles branch from 53914ea to 18a98c3 Compare September 22, 2022 09:11

CBonnell and others added 5 commits October 5, 2022 16:01

Add specification for EV attributes (#391)

8999394

Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com>

Add order and encoding requirement for DC attribute (#395)

948dda6

Co-authored-by: Corey Bonnell <corey.bonnell@digicert.com>

chrisbn reviewed Nov 24, 2022

View reviewed changes

sammmm0119 approved these changes Jan 5, 2023

View reviewed changes

wthayer reviewed Jan 14, 2023

View reviewed changes

AnetaWojtczak and others added 3 commits January 26, 2023 13:55

This PR fixes issues in section 7.1.2.7.3 and 7.1.2.7.4. (#416)

e366471

Profiles extended effective date (#413)

4be388a

* Update BR.md * Update BR.md

Add policyQualifiers Note (#412)

0689ba5

* Add policyQualifiers Note Added explanation of rationale for NOT RECOMMENDED to section 7.1.2.10.5 * Update docs/BR.md Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com> Co-authored-by: Corey Bonnell <corey.j.bonnell@outlook.com>

ryancdickson mentioned this pull request Feb 2, 2023

Improve CRL profile specificity in Section 7.2 #419

Closed

ryancdickson mentioned this pull request Feb 14, 2023

SC-062 Profiles: Address various editorial and content nits #418

Merged

aarongable and others added 2 commits February 17, 2023 12:20

Merge branch 'main' into profiles

edf6a1c

barrini approved these changes Mar 22, 2023

View reviewed changes

ryancdickson and others added 3 commits March 30, 2023 11:16

Fix broken links (#427)

83711e9

* Update BR.md * Update BR.md * Update BR.md * Update BR.md * Update BR.md

Update BR.md (#429)

92abb91

Merge branch 'main' into profiles

ec4f074

barrini approved these changes Apr 24, 2023

View reviewed changes

barrini merged commit a0360b6 into main Apr 24, 2023
6 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

SCXX - Certificate Profiles #373

SCXX - Certificate Profiles #373

CBonnell commented Jul 13, 2022

chrisbn Nov 24, 2022

chrisbn Nov 24, 2022

wthayer Jan 14, 2023 •

edited


		By issuing a Subordinate CA Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy and/or Certification Practice Statement to verify that, as of the Certificate's issuance date, all of the Subject Information was accurate.
		Table: Encoding Requirements for Selected Attributes

SCXX - Certificate Profiles #373

SCXX - Certificate Profiles #373

Conversation

CBonnell commented Jul 13, 2022

Comparison of Changes to v1.8.1

Definitions

Cleanups

Root CA Certificates (7.1.2.1)

Extensions

Cross-Certified Subordinate CA (7.1.2.2)

Extensions

Technically Constrained Non-TLS Subordinate CA (7.1.2.3)

Extensions

Technically Constrained Precertificate Signing CA (7.1.2.4)

Technically Constrained TLS Subordinate CA (7.1.2.5)

Extensions

chrisbn Nov 24, 2022

Choose a reason for hiding this comment

chrisbn Nov 24, 2022

Choose a reason for hiding this comment

wthayer Jan 14, 2023 • edited

Choose a reason for hiding this comment

wthayer Jan 14, 2023 •

edited