From 4b56725eae9fdf10689a4c2336d008a4919abf6c Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Wed, 10 Feb 2021 19:56:06 -0500 Subject: [PATCH 01/54] Profiles WIP --- .github/workflows/build-draft-docs.yml | 2 +- docs/BR.md | 1223 ++++++++++++++++++------ 2 files changed, 931 insertions(+), 294 deletions(-) diff --git a/.github/workflows/build-draft-docs.yml b/.github/workflows/build-draft-docs.yml index adac8c13..1be3e0fd 100644 --- a/.github/workflows/build-draft-docs.yml +++ b/.github/workflows/build-draft-docs.yml @@ -18,7 +18,7 @@ jobs: with: ref: ${{ github.event.pull_request.base.sha || github.event.push.before }} path: old/ - - uses: docker://ghcr.io/cabforum/build-guidelines-action:2.0.2 + - uses: docker://ghcr.io/sleevi/build-guidelines-action:tables id: build_doc with: markdown_file: docs/${{ matrix.document }} diff --git a/docs/BR.md b/docs/BR.md index 58239958..9ea1cb2f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -293,7 +293,7 @@ No stipulation. **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations. -**Cross Certificate**: A certificate that is used to establish a trust relationship between two Root CAs. +**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two Root CAs. **CSPRNG**: A random number generator intended for use in cryptographic system. @@ -884,8 +884,6 @@ Completed validations of Applicant authority may be valid for the issuance of mu After July 31, 2019, CAs SHALL maintain a record of which IP validation method, including the relevant BR version number, was used to validate every IP Address. -**Note**: IP Addresses verified in accordance with this [Section 3.2.2.5](#3225-authentication-for-an-ip-address) may be listed in Subscriber Certificates as defined in [Section 7.1.4.2](#7142-subject-information---subscriber-certificates) or in Subordinate CA Certificates via iPAddress in permittedSubtrees within the Name Constraints extension. CAs are not required to verify IP Addresses listed in Subordinate CA Certificates via iPAddress in excludedSubtrees in the Name Constraints extension prior to inclusion in the Subordinate CA Certificate. - ##### 3.2.2.5.1 Agreed-Upon Change to Website Confirming the Applicant's control over the requested IP Address by confirming the presence of a Request Token or Random Value contained in the content of a file or webpage in the form of a meta tag under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of validating control of IP Addresses, on the IP Address that is accessible by the CA via HTTP/HTTPS over an Authorized Port. The Request Token or Random Value MUST NOT appear in the request. @@ -970,7 +968,7 @@ When processing CAA records, CAs MUST process the issue, issuewild, and iodef pr RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following: * CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. -* CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.5](#715-name-constraints), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. +* CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. * For certificates issued prior to July 1, 2021, CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS. CAs are permitted to treat a record lookup failure as permission to issue if: @@ -1003,7 +1001,7 @@ In addition, the CA SHALL establish a process that allows an Applicant to specif ### 3.2.6 Criteria for Interoperation or Certification -The CA SHALL disclose all Cross Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross Certificate at issue). +The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that identify the CA as the Subject, provided that the CA arranged for or accepted the establishment of the trust relationship (i.e. the Cross-Certified Subordinate CA Certificate at issue). ## 3.3 Identification and authentication for re-key requests @@ -1054,7 +1052,7 @@ If a Delegated Third Party fulfills any of the CA's obligations under this secti ### 4.2.2 Approval or rejection of certificate applications -CAs SHALL NOT issue certificates containing Internal Names (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)). +CAs SHALL NOT issue certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address). ### 4.2.3 Time to process certificate applications @@ -1312,7 +1310,7 @@ For the status of Subordinate CA Certificates: i. at least every twelve months; and ii. within 24 hours after revoking a Subordinate CA Certificate. -If the OCSP responder receives a request for the status of a certificate serial number that is "unused", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.5](#715-name-constraints), the responder MUST NOT respond with a "good" status for such requests. +If the OCSP responder receives a request for the status of a certificate serial number that is "unused", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests. The CA SHOULD monitor the OCSP responder for requests for "unused" serial numbers as part of its security response procedures. @@ -1672,7 +1670,7 @@ ECDSA: The CA SHOULD confirm the validity of all keys using either the ECC Full Private Keys corresponding to Root Certificates MUST NOT be used to sign Certificates except in the following cases: 1. Self-signed Certificates to represent the Root CA itself; -2. Certificates for Subordinate CAs and Cross Certificates; +2. Certificates for Subordinate CAs and Cross-Certified Subordinate CA Certificates; 3. Certificates for infrastructure purposes (administrative role certificates, internal CA operational device certificates); and 4. Certificates for OCSP Response verification. @@ -1756,142 +1754,907 @@ The CA SHALL enforce multi-factor authentication for all accounts capable of dir The CA SHALL meet the technical requirements set forth in [Section 2.2 - Publication of Information](#22-publication-of-information), [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking). +TODO(sleevi): FIXME + CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG. ### 7.1.1 Version number(s) Certificates MUST be of type X.509 v3. -### 7.1.2 Certificate Content and Extensions; Application of RFC 5280 - -This section specifies the additional requirements for Certificate content and extensions for Certificates. - -#### 7.1.2.1 Root CA Certificate - -a. `basicConstraints` - - This extension MUST appear as a critical extension. The `cA` field MUST be set true. The `pathLenConstraint` field SHOULD NOT be present. - -b. `keyUsage` - - This extension MUST be present and MUST be marked critical. Bit positions for `keyCertSign` and `cRLSign` MUST be set. If the Root CA Private Key is used for signing OCSP responses, then the `digitalSignature` bit MUST be set. - -c. `certificatePolicies` - - This extension SHOULD NOT be present. - -d. `extKeyUsage` - - This extension MUST NOT be present. - -#### 7.1.2.2 Subordinate CA Certificate - -a. `certificatePolicies` - - This extension MUST be present and SHOULD NOT be marked critical. - - `certificatePolicies:policyIdentifier` (Required) - - The following fields MAY be present if the Subordinate CA is not an Affiliate of the entity that controls the Root CA. - - * `certificatePolicies:policyQualifiers:policyQualifierId` (Optional) - - `id-qt 1` [RFC5280]. - - * `certificatePolicies:policyQualifiers:qualifier:cPSuri` (Optional) - - HTTP URL for the Root CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the CA. - -b. `cRLDistributionPoints` - - This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA's CRL service. - -c. `authorityInformationAccess` - - This extension SHOULD be present. It MUST NOT be marked critical. - - It SHOULD contain the HTTP URL of the Issuing CA's certificate (`accessMethod` = 1.3.6.1.5.5.7.48.2). - It MAY contain the HTTP URL of the Issuing CA's OCSP responder (`accessMethod` = 1.3.6.1.5.5.7.48.1). - -d. `basicConstraints` +### 7.1.2 Certificate Content and Extensions + +If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles: + + * CA Certificates + * [Section 7.1.2.1.- Root CA Certificate Profile](#7121-root-ca-certificate-profile) + * Subordinate CA Certificates + * Cross Certificates + * [Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile) + * Technically Constrained CA Certificates + * [Section 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) + * [Section 7.1.2.4 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7124-technically-constrained-tls-subordinate-ca-certificate-profile) + * [Section 7.1.2.5 - TLS Subordinate CA Certificate Profile](#7125-tls-subordinate-ca-certificate-profile) + * [Section 7.1.2.6 - Subscriber (End-Entity) Certificate Profile](#7126-subscriber-server-certificate-profile) + * Domain Validated + * Individual Validated + * Organization Validated + * Extended Validation + * __**TBD: Infrastructure Certificates**__ + * [Section 7.1.2.7 - OCSP Responder Certificate Profile](#7127-ocsp-responder-certificate-profile) + * __**TBD: Infrastructure Cert**__ + * __**TBD: Precert Signing CA**__ + * __**TBD: Interoperability Testing Certs (valid/revoked/expired)?**__ + +#### 7.1.2.1 Root CA Certificate Profile + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | +| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.1.1](#71211-root-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.1.1 Root CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | SHOULD | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.3](#71213-basic-constraints) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `extKeyUsage` | MUST NOT | N | - | +| `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.8 4](#71284-certificate-policies---affiliated-ca) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +##### 7.1.2.1.2 Authority Key Identifier + +| __Field__ | __Description__ | +| --- | ------- | +| `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field. | +| `authorityCertIssuer` | MUST NOT be present | +| `authorityCertSerialNumber` | MUST NOT be present | + +##### 7.1.2.1.3 Basic Constraints + +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be set TRUE | +| `pathLenConstraint` | SHOULD NOT be present | + +#### 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile + +This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as an existing CA Certificate, whether a Root CA Certificate or Subordinate CA Certificate. + +Before issuing a CA Certificate using this Profile, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance. + +__**TBD: Remarks about audits**__ + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `subject` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.2.1 Cross-Certified Subordinate CA Naming + +Provided that the Issuing CA has confirmed that the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the Issuing CA MAY deviate from the requirements in [Section 7.1.4](#714-name-forms) as follows: + +The encoded `subject` name shall be byte-for-byte identical to the encoded `subject` name of the existing CA Certificate. + +##### 7.1.2.2.2 Cross-Certified Subordinate CA Extensions + +The acceptable extensions and the requirements for those extensions in a Cross-Certified Subordinate CA vary based on whether or not the Subordinate CA is issued to and operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. + +Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Affiliate of the Issuing CA. + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.3](#71223-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +Table: Extensions when the Subordinate CA is operated by an entity that is not the Issuing CA or an Affiliate of the Issuing CA. + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.5](#71285-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---restricted-cross-certified-ca) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +[^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. + +[^name_constraints]: See [Section 7.1.2.8.9](#71289-name-constraints) for further requirements, including regarding criticality of this extension. + +##### 7.1.2.2.3 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA + +When the Cross-Certified Subordinate CA is issued to and operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA, the Extended Key Usage extension MAY be encoded as follows: + +Table: Unrestricted Extended Key Usage (Affiliated Cross-Certified CA) + +| __Key Purpose__ | __Description__ | +| --- | ------- | +| `anyExtendedKeyUsage` | The special extended key usage to indicate there are no restrictions applied. If present, this MUST be the only key usage present. | +| Any other value | CAs MUST NOT include any other key usage with the `anyExtendedKeyUsage` key usage present. | + +Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension MUST be encoded as specified in [Section 7.1.2.2.4, Extended Key Usage - Restricted Cross-Certified CA](#71224-extended-key-usage---restricted-cross-certified-ca). + +##### 7.1.2.2.4 Extended Key Usage - Restricted Cross-Certified CA + +If present, the Extended Key Usage extension MUST only contain key usage purposes for which the Issuing CA has verified the Cross-Certified Subordinate CA is authorized to assert. + +#### 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile + +This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively. If the CA Certificate does not conform to this profile, or the profile specified in [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), then it is not Technically Constrained. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.3.1](#71231-technically-constrained-non-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.8.5](#71286-extended-key-usage---non-tls-ca) (Non-TLS CA) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +#### 7.1.2.4 Technically Constrained TLS Subordinate CA Certificate Profile + +This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively. If the CA Certificate does not conform to this profile, or the profile specified in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), then it is not Technically Constrained. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.4.1 Technically Constrained TLS Subordinate CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.8.7](#71287-extended-key-usage---tls-ca) (TLS CA) | +| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.4.2](#71242-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +##### 7.1.2.4.2 Name Constraints + +For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. + +Table: `nameConstraints` requirements + +| __Field__ | __Description__ | +| -- | ------- | +| `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. | +| \ \ \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +| \ \ \ \ \ \ \ \ `base` | See following table. | +| \ \ \ \ \ \ \ \ `minimum` | MUST NOT be present. | +| \ \ \ \ \ \ \ \ `maximum` | MUST NOT be present. | +| `excludedSubtrees` | The `excludedSubtrees` MUST contain at least one `GeneralSubtree` for each of the `dNSName` and `iPAddress` `GeneralName` name types, unless there is an instance present of that name type in the `permittedSubtrees`. The `directoryName` name type SHOULD NOT be present. | +| \ \ \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +| \ \ \ \ \ \ \ \ `base` | See following table. | +| \ \ \ \ \ \ \ \ `minimum` | MUST NOT be present. | +| \ \ \ \ \ \ \ \ `maximum` | MUST NOT be present. | + +The following table contains the requirements for the `GeneralName` that appears within the `base` of a `GeneralSubtree` in either the `permittedSubtrees` or `excludedSubtrees`. + +Table: `GeneralName` requirements for the `base` field + +| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | +| --- | - | ---- | ---- | ---- | +| `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | +| `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | +| `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | +| `rfc822Name` | SHOULD NOT | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | +| `otherName` | SHOULD NOT | See following table. | See following table. | See following table. | +| Any other value | SHOULD NOT | - | - | - | + +When an `otherName` is present within a `GeneralName` present in the `base` of a `nameConstraints` `permittedSubtrees` or `excludedSubtrees`, it MUST meet the following requirements: + +Table: `otherName` requirements within a `GeneralName` + +| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | +| --- | - | ---- | ---- | ---- | +| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | SHOULD NOT | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | +| Any other value | SHOULD NOT | - | - | - | + +#### 7.1.2.5 TLS Subordinate CA Certificate Profile + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.5.1](#71251-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.5.1 TLS Subordinate CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.8.7](#71287-extended-key-usage---tls-ca) (TLS CA) | +| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +#### 7.1.2.6 Subscriber (Server) Certificate Profile + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +| \ \ \ \ `validity` | | +| \ \ \ \ \ \ \ \ `notBefore` | __**TBD**__ | +| \ \ \ \ \ \ \ \ `notAfter` | See [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | +| \ \ \ \ `subject` | See [Section 7.1.2.6.1](#71261-subscriber-certificate-types) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.6.1](#71261-subscriber-certificate-types) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.6.1 Subscriber Certificate Types + +There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the `subject` name fields that may occur, how those fields are validated, and the contents of the `certificatePolicies` extension. + +| __Type__ | __Description__ | +| --- | ------- | +| Domain Validated (DV) | See [Section 7.1.2.6.2](#71262-domain-validated) | +| Individual Validated (IV) | See [Section 7.1.2.6.3](#71263-individual-validated) | +| Organization Validated (OV) | See [Section 7.1.2.6.4](#71264-organization-validated) | +| Extended Validation (EV) | See [Section 7.1.2.6.5](#71265-extended-validation) | + +**Note**: Although each Subscriber Certificate type varies in Subject Information, all Certificates provide the same level of assurance of the device identity (domain name and/or IP address). + +##### 7.1.2.6.2 Domain Validated + +For a Subscriber Certificate to be Domain Validated, it MUST meet the following profile: + +| __Field__ | __Requirements__ | +| -- | ------- | +| `subject` | See following table. | +| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. | +| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) | + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. + +Table: Domain Validated `subject` Attributes + +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MAY | The two-letter ISO 3166-1 country code for the country associated with the Subject. | [Section 3.2.2.3](#3223-verification-of-country) | +| `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | MUST NOT | __**TBD**__ | | + +##### 7.1.2.6.3 Individual Validated + +For a Subscriber Certificate to be Individual Validated, it MUST meet the following profile: + +| __Field__ | __Requirements__ | +| -- | ------- | +| `subject` | See following table. | +| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. | +| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) | + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. + +Table: Individual Validated `subject` Attributes + +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `postalCode` | SHOULD NOT | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationName` | SHOULD NOT | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationalUnitName` | SHOULD NOT | __**TBD**__ | __**TBD**__ | +| `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | SHOULD NOT | __**TBD**__ | __**TBD**__ | + +##### 7.1.2.6.4 Organization Validated + +For a Subscriber Certificate to be Organization Validated, it MUST meet the following profile: + +| __Field__ | __Requirements__ | +| -- | ------- | +| `subject` | See following table. | +| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. | +| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) | + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. + +Table: Individual Validated `subject` Attributes + +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | +| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | +| `postalCode` | SHOULD NOT | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | +| `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `surname` | MUST NOT | | | +| `givenName` | MUST NOT | | | +| `organizationalUnitName` | SHOULD NOT | __**TBD**__ | __**TBD**__ | +| `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | SHOULD NOT | __**TBD**__ | __**TBD**__ | + +##### 7.1.2.6.5 Extended Validation + +For a Subscriber Certificate to be Extended Validation, it MUST comply with the Certificate Profile specified in the then-current version of the Guidelines for the Issuance and Management of Extended Validation Certificates. + In addition, it MUST meet the following profile: + +| __Field__ | __Requirements__ | +| -- | ------- | +| `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 9.2. | +| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. | +| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | + +##### 7.1.2.6.6 Subscriber Certificate Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.6.7](#71267-authority-information-access) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.6.9](#71269-certificate-policies) | +| `extKeyUsage` | MUST | N | See [Section 7.1.2.6.10](#712610-extended-key-usage) | +| `subjectAltName` | MUST | - | See [Section 7.1.2.6.12](#712612-subject-alternative-name) | +| `nameConstraints` | MUST NOT | - | - | +| `keyUsage` | SHOULD | Y | See [Section 7.1.2.6.11](#712611-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.6.8](#71268-basic-constraints) | +| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| CA/Browser Forum Onion Extension | MAY | N | __**TODO**__ | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +##### 7.1.2.6.7 Authority Information Access + +The `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. + +| __Access Method__ | __OID__ | __Presence__ | __Access Location__ | __Description__ | +| -- | -- | - | ---- | --- | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | MUST | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's OCSP responder. | +| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | SHOULD | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's certificate. | +| Any other value | - | MUST NOT | - | - | + +##### 7.1.2.6.8 Basic Constraints + +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be FALSE | +| `pathLenConstraint` | MUST NOT be present | + +##### 7.1.2.6.9 Certificate Policies + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | +| \ \ \ \ `policyIdentifier` | | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.6.1](#71261-subscriber-certificate-types). | +| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | +| \ \ **2+** | MAY | The Issuing CA MAY include additional `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the Issuing CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | +| \ \ **3** | MUST NOT | The Issuing CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | + +If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: + +| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| --- | - | - | ----- | +| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | +| Any other qualifier | MUST NOT | - | - | + +##### 7.1.2.6.10 Extended Key Usage + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Any other value | - | SHOULD NOT | + +##### 7.1.2.6.11 Key Usage + +The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key. + +Table: Key Usage for RSA Public Keys + +| __Key Usage__ | __Permitted__ | __Required__ | +| ---- | - | - | +| `digitalSignature` | Y | SHOULD | +| `nonRepudiation` | N | -- | +| `keyEncipherment` | Y | MAY | +| `dataEncipherment` | N | -- | +| `keyAgreement` | N | -- | +| `keyCertSign` | N | -- | +| `cRLSign` | N | -- | +| `encipherOnly` | N | -- | +| `decipherOnly` | N | -- | + +**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm MAY choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this SHOULD NOT be done by default. + +Table: Key Usage for ECC Public Keys + +| __Key Usage__ | __Permitted__ | __Required__ | +| ---- | - | - | +| `digitalSignature` | Y | MUST | +| `nonRepudiation` | N | -- | +| `keyEncipherment` | N | -- | +| `dataEncipherment` | N | -- | +| `keyAgreement` | N | -- | +| `keyCertSign` | N | -- | +| `cRLSign` | N | -- | +| `encipherOnly` | N | -- | +| `decipherOnly` | N | -- | + +##### 7.1.2.6.12 Subject Alternative Name + +For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements. + +If the `subject` field of the certificate is an empty SEQUENCE, this extension MUST be marked critical, as specified in [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6). Otherwise, this extension MUST NOT be marked critical. + +Table: `GeneralName` within a `subjectAltName` extension + +| __Name Type__ | __Permitted__ | __Validation__ | +| --- | - | ------ | +| `otherName` | N | - | +| `rfc822Name` | N | - | +| `dNSName` | Y | MUST contain the Fully-Qualified Domain Name. The Issuing CA MUST confirm that the Applicant controls or has been granted the right to use the Domain Name through a method specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). As an exception to the requirement of RFC 5280 requirements, Wildcard FQDNs are permitted. All other domain labels MUST be in the "preferred name syntax" and thus MUST NOT contain underscore characters ("\_"). MUST NOT contain an Internal Name. | +| `x400Address` | N | - | +| `directoryName` | N | - | +| `ediPartyName` | N | - | +| `uniformResourceIdentifier` | N | - | +| `iPAddress` | Y | MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in [Section 3.2.2.5](#3225-authentication-for-an-ip-address). MUST NOT contain a Reserved IP Address. | +| `registeredID` | N | - | + +#### 7.1.2.7 OCSP Responder Certificate Profile + +If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as definied by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.5.1](#71251-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.7.1 OCSP Responder Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.7.3](#71273-basic-constraints) | +| `extKeyUsage` | MUST | - | See [Section 7.1.2.7.4](#71274-extended-key-usage) | +| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.7.5](#71275-id-pkix-ocsp-nocheck) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.7.6](#71276-key-usage) | +| `nameConstraints` | MUST NOT | - | - | +| `subjectAltName` | MUST NOT | - | - | +| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `authorityInformationAccess` | SHOULD NOT | N | See [Section 7.1.2.7.2](#71272-authority-information-access) | +| `certificatePolicies` | - | - | - | +| \ \ \ \ _Prior to 2021-10-01_ | SHOULD NOT | N | See [Section 7.1.2.7.7](#71277-certificate-policies) | +| \ \ \ \ _Effective 2021-10-01_ | MUST NOT | - | - | +| `crlDistributionPoints` | SHOULD NOT | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +##### 7.1.2.7.2 Authority Information Access + +For OCSP Responder certificates, this extension SHOULD NOT be present, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties. + +If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. + +| __Access Method__ | __OID__ | __Presence__ | __Access Location__ | __Description__ | +| -- | -- | - | ---- | --- | +| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | SHOULD NOT | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's certificate. | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | MUST NOT | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's OCSP responder. | +| Any other value | - | MUST NOT | - | - | + +##### 7.1.2.7.3 Basic Constraints + +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be FALSE | +| `pathLenConstraint` | MUST NOT be present | + +**Note**: CAs MUST observe DER encoding rules, such as not explicitly encoding DEFAULT values within OPTIONAL fields. + +##### 7.1.2.7.4 Extended Key Usage + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MUST NOT | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Any other value | - | MUST NOT | + +##### 7.1.2.7.5 id-pkix-ocsp-nocheck + +The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5). + +This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1). + +##### 7.1.2.7.6 Key Usage + +| __Key Usage__ | __Permitted__ | __Required__ | +| ---- | - | - | +| `digitalSignature` | Y | Y | +| `nonRepudiation` | N | -- | +| `keyEncipherment` | N | -- | +| `dataEncipherment` | N | -- | +| `keyAgreement` | N | -- | +| `keyCertSign` | N | -- | +| `cRLSign` | N | -- | +| `encipherOnly` | N | -- | +| `decipherOnly` | N | -- | + +##### 7.1.2.7.7 Certificate Policies + +**Note**: See [Section 7.1.2.7.1](#71271-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. + +If present, the Certificate Policies extension MUST be formatted as follows: + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | MAY | The CA MAY include one or more `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | +| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | + +If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: + +| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| --- | - | - | ----- | +| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | +| Any other qualifier | MUST NOT | - | - | + +#### 7.1.2.8 Common CA Fields + +This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). + +##### 7.1.2.8.1 CA Certificate Naming + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. + +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) | +| `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) | +| `localityName` | MAY | If present, the CA's locality. | [Section 3.2.2.1](#3221-identity) | +| `streetAddress` | MAY | If present, the CA's street address. Multiple instances MAY be present. | [Section 3.2.2.1](#3221-identity) | +| `postalCode` | MAY | If present, the CA's zip or postal information. | [Section 3.2.2.1](#3221-identity) | +| `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `organizationalUnitName` | SHOULD NOT | __**TBD**__ | | +| `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | +| Any other attribute | SHOULD NOT | __**TBD**__ | | + +##### 7.1.2.8.2 Authority Information Access + +If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. + +| __Access Method__ | __OID__ | __Presence__ | __Access Location__ | __Description__ | +| -- | -- | - | ---- | --- | +| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | SHOULD | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's certificate. | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | MAY | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's OCSP responder. | +| Any other value | - | MUST NOT | - | - | + +##### 7.1.2.8.3 Basic Constraints + +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be set TRUE | +| `pathLenConstraint` | MAY be present | + +##### 7.1.2.8.4 Certificate Policies - Affiliated CA + +The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by an organization that is the same as the organization operating the Issuing CA or that is an Affiliate of the organization operating the Issuing CA. + +If present, the Certificate Policies extension MUST be one of the following two formats: + +Table: No Policy Restrictions + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | | The first `PolicyInformation` present in the `certificatePolicies`. | +| \ \ \ \ `policyIdentifier` | MUST | The `anyPolicy` (OID: 2.5.29.32.0) identifier. | +| \ \ \ \ `policyQualifiers` | MUST NOT | | +| \ \ **2** | MUST NOT | When the `anyPolicy` policy is present, the CA MUST NOT include any further `PolicyInformation` values. | + +Table: Policy Restricted + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | +| \ \ \ \ `policyIdentifier` | | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | +| \ \ \ \ `policyQualifiers` | MUST NOT | | +| \ \ **2+** | SHOULD | The CA SHOULD include additional Reserved Certificate Policy Identifiers for each type of Subscriber certificate that may be issued beneath it. | +| \ \ \ \ `policyIdentifier` | MUST | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | +| \ \ \ \ `policyQualifiers` | MUST NOT | | +| \ \ **3+** | MAY | The CA MAY include additional `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | MUST NOT | | +| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | + +##### 7.1.2.8.5 Certificate Policies - Non-Affiliated CA + +The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by a CA that is an not an Affiliate of the Issuing CA. + +If present, the Certificate Policies extension MUST be formatted as follows: + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | +| \ \ \ \ `policyIdentifier` | | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | +| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | +| \ \ **2+** | SHOULD | The CA SHOULD include additional Reserved Certificate Policy Identifiers for each type of Subscriber certificate that may be issued beneath it. | +| \ \ \ \ `policyIdentifier` | MUST | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | +| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | +| \ \ **3+** | MAY | The CA MAY include additional `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | +| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | - This extension MUST be present and MUST be marked critical. The `cA` field MUST be set true. The `pathLenConstraint` field MAY be present. +If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: -e. `keyUsage` +| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| --- | - | - | ----- | +| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | +| Any other qualifier | MUST NOT | - | - | + +##### 7.1.2.8.6 Extended Key Usage - Non-TLS CA + +The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) SHOULD NOT be present. + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MAY | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MAY | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MAY | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MAY | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Any other value | - | SHOULD NOT | + +##### 7.1.2.8.7 Extended Key Usage - TLS CA + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Any other value | - | SHOULD NOT | + +##### 7.1.2.8.8 Key Usage + +| __Key Usage__ | __Permitted__ | __Required__ | +| ---- | - | - | +| `digitalSignature` | Y | N[^ocsp_signing] | +| `nonRepudiation` | N | -- | +| `keyEncipherment` | N | -- | +| `dataEncipherment` | N | -- | +| `keyAgreement` | N | -- | +| `keyCertSign` | Y | Y | +| `cRLSign` | Y | Y | +| `encipherOnly` | N | -- | +| `decipherOnly` | N | -- | + +[^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information. + +##### 7.1.2.8.9 Name Constraints + +If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. + + +Table: `nameConstraints` requirements + +| __Field__ | __Description__ | +| -- | -------- | +| `permittedSubtrees` | | +| \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +| \ \ \ \ `base` | See following table. | +| \ \ \ \ `minimum` | MUST NOT be present. | +| \ \ \ \ `maximum` | MUST NOT be present. | +| `excludedSubtrees` | | +| \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +| \ \ \ \ `base` | See following table. | +| \ \ \ \ `minimum` | MUST NOT be present. | +| \ \ \ \ `maximum` | MUST NOT be present. | + +The following table contains the requirements for the `GeneralName` that appears within the `base` of a `GeneralSubtree` in either the `permittedSubtrees` or `excludedSubtrees`. + +Table: `GeneralName` requirements for the `base` field + +| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | +| -- | - | ---- | ---- | +| `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | +| `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | +| `directoryName` | MMAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | +| Any other value | SHOULD NOT | - | - | - This extension MUST be present and MUST be marked critical. Bit positions for `keyCertSign` and `cRLSign` MUST be set. If the Subordinate CA Private Key is used for signing OCSP responses, then the `digitalSignature` bit MUST be set. +#### 7.1.2.9 Common Certificate Fields + +This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). + +##### 7.1.2.9.1 Authority Key Identifier + +| __Field__ | __Description__ | +| --- | ------- | +| `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the Issuing CA. | +| `authorityCertIssuer` | MUST NOT be present | +| `authorityCertSerialNumber` | MUST NOT be present | -f. `nameConstraints` (optional) +##### 7.1.2.9.2 CRL Distribution Points - If present, this extension SHOULD be marked critical[^*]. +If present, the CRL Distribution Points extension MUST be formatted as follows: -[^*]: Non-critical Name Constraints are an exception to RFC 5280 (4.2.1.10), however, they MAY be used until the Name Constraints extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide. +Table: `CRLDistributionPoints` profile -g. `extKeyUsage` (optional/required) +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `CRLDistributionPoints` | | | +| \ \ **1** | MUST | The first `DistributionPoint` present in the `CRLDistributionPoints` | +| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | +| \ \ \ \ `reasons` | MUST NOT | | +| \ \ \ \ `cRLIssuer` | MUST NOT | | +| \ \ **2+** | MAY | Additional `DistributionPoint`s that meet the following profile MAY be present. | +| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | +| \ \ \ \ `reasons` | MUST NOT | | +| \ \ \ \ `cRLIssuer` | MUST NOT | | +| \ \ **3** | MUST NOT | `DistributionPoints` that to not conform to the above requirements MUST NOT be present. | + +Table: `fullName` profile - For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension MUST only contain usages for which the issuing CA has verified the Cross Certificate is authorized to assert. This extension MAY contain the `anyExtendedKeyUsage` [RFC5280] usage, if the Root Certificate(s) associated with this Cross Certificate are operated by the same organization as the issuing Root Certificate. +| __Field__ | __Presence__ | __Description__ | +| ---- | - | ----- | +| `fullName` | | | +| \ \ **1** | MUST | The first `GeneralName` present in `fullName` MUST be of type `unformResourceIdentifier` | +| \ \ \ \ `uniformResourceIdentifier` | MUST | The HTTP URL of the Issuing CA's CRL service for this certificate. | +| \ \ **2** | SHOULD NOT | Additional `GeneralName`s SHOULD NOT be present. __**TBD: MUST NOT**__ | - For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates: +##### 7.1.2.9.3 Signed Certificate Timestamp List - This extension MUST be present and SHOULD NOT be marked critical[^**]. +If present, the Signed Certificate Timestamp List extension contents MUST be an `OCTET STRING` containing the encoded `SignedCertificateTimestampList`, as specified in [RFC 6962, Section 3.3](https://tools.ietf.org/html/rfc6962#section-3.3). - For Subordinate CA Certificates that will be used to issue TLS certificates, the value `id-kp-serverAuth` [RFC5280] MUST be present. The value `id-kp-clientAuth` [RFC5280] MAY be present. The values `id-kp-emailProtection` [RFC5280], `id-kp-codeSigning` [RFC5280], `id-kp-timeStamping` [RFC5280], and `anyExtendedKeyUsage` [RFC5280] MUST NOT be present. Other values SHOULD NOT be present. +Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestampList` MUST be for a `PreCert` `LogEntryType` that corresponds to the current certificate. - For Subordinate CA Certificates that are not used to issue TLS certificates, then the value `id-kp-serverAuth` [RFC5280] MUST NOT be present. Other values MAY be present, but SHOULD NOT combine multiple independent key purposes (e.g. including `id-kp-timeStamping` [RFC5280] with `id-kp-codeSigning` [RFC5280]). +##### 7.1.2.9.4 Subject Key Identifier -[^**]: While RFC 5280, Section 4.2.1.12, notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of subordinate certificates, as implemented by a number of Application Software Suppliers. - -h. `authorityKeyIdentifier` (required) - - This extension MUST be present and MUST NOT be marked critical. It MUST contain a `keyIdentifier` field and it MUST NOT contain a `authorityCertIssuer` or `authorityCertSerialNumber` field. - -#### 7.1.2.3 Subscriber Certificate - -a. `certificatePolicies` - - This extension MUST be present and SHOULD NOT be marked critical. - - * `certificatePolicies:policyIdentifier` (Required) - - A Policy Identifier, defined by the issuing CA, that indicates a Certificate Policy asserting the issuing CA's adherence to and compliance with these Requirements. - - The following extensions MAY be present: - - * `certificatePolicies:policyQualifiers:policyQualifierId` (Recommended) - - `id-qt 1` [RFC 5280]. - - * `certificatePolicies:policyQualifiers:qualifier:cPSuri` (Optional) - - HTTP URL for the Subordinate CA's Certification Practice Statement, Relying Party Agreement or other pointer to online information provided by the CA. - -b. `cRLDistributionPoints` - - This extension MAY be present. If present, it MUST NOT be marked critical, and it MUST contain the HTTP URL of the CA's CRL service. - -c. `authorityInformationAccess` - - This extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the Issuing CA's OCSP responder (`accessMethod` = 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing CA's certificate (`accessMethod` = 1.3.6.1.5.5.7.48.2). - -d. `basicConstraints` (optional) - - The `cA` field MUST NOT be true. - -e. `keyUsage` (optional) - - If present, bit positions for `keyCertSign` and `cRLSign` MUST NOT be set. - -f. `extKeyUsage` (required) - - Either the value `id-kp-serverAuth` [RFC5280] or `id-kp-clientAuth` [RFC5280] or both values MUST be present. `id-kp-emailProtection` [RFC5280] MAY be present. Other values SHOULD NOT be present. The value `anyExtendedKeyUsage` MUST NOT be present. - -g. `authorityKeyIdentifier` (required) - - This extension MUST be present and MUST NOT be marked critical. It MUST contain a `keyIdentifier` field and it MUST NOT contain a `authorityCertIssuer` or `authorityCertSerialNumber` field. +If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). CAs MUST generate a unique `subjectKeyIdentifier` for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs MAY generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. #### 7.1.2.4 All Certificates -All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a `keyUsage` flag, `extKeyUsage` value, Certificate extension, or other data not specified in [Section 7.1.2.1](#7121-root-ca-certificate), [Section 7.1.2.2](#7122-subordinate-ca-certificate), or [Section 7.1.2.3](#7123-subscriber-certificate) unless the CA is aware of a reason for including the data in the Certificate. +All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a `keyUsage` flag, `extKeyUsage` value, Certificate extension, or other data not specified in [Section 7.1.2](#712-certificate-content-and-extensions) unless the CA is aware of a reason for including the data in the Certificate. CAs SHALL NOT issue a Certificate with: @@ -1902,7 +2665,9 @@ b. semantics that, if included, will mislead a Relying Party about the certifica #### 7.1.2.5 Application of RFC 5280 -For purposes of clarification, a Precertificate, as described in RFC 6962 - Certificate Transparency, shall not be considered to be a "certificate" subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements. +Except where explicitly noted, all certificates MUST conform to the certificate profile of RFC 5280. The following requirements are noted in addition to any normative requirements placed within RFC 5280. In particular, CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further discussion of normative requirements imposed by RFC 5280 and its normative dependencies. + +For purposes of clarification, a Precertificate, as described in [RFC 6962 - Certificate Transparency](https://tools.ietf.org/html/rfc6962), shall not be considered to be a "certificate" subject to the requirements of [RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile](https://tools.ietf.org/html/rfc5280) under these Baseline Requirements. ### 7.1.3 Algorithm object identifiers @@ -2030,136 +2795,62 @@ If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When enc ### 7.1.4 Name Forms -#### 7.1.4.1 Name Encoding - -Prior to 2020-09-30, the content of the Certificate Issuer Distinguished Name field MUST match the Subject DN of the Issuing CA to support Name chaining as specified in RFC 5280, Section 4.1.2.4. - -Effective 2020-09-30, the following requirements SHOULD be met by all newly-issued Subordinate CA Certificates that are not used to issue TLS certificates, as defined in [Section 7.1.2.2](#7122-subordinate-ca-certificate), and MUST be met for all other Certificates, regardless of whether the Certificate is a CA Certificate or a Subscriber Certificate. - -For every valid Certification Path (as defined by RFC 5280, Section 6): - -* For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. -* For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to RFC 5280, Section 7.1, and including expired and revoked Certificates. - -#### 7.1.4.2 Subject Information - Subscriber Certificates - -By issuing the 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. CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute except as specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address). - -Subject attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. - -##### 7.1.4.2.1 Subject Alternative Name Extension - -__Certificate Field:__ `extensions:subjectAltName` -__Required/Optional:__ Required -__Contents:__ This extension MUST contain at least one entry. Each entry MUST be either a `dNSName` containing the Fully-Qualified Domain Name or an `iPAddress` containing the IP address of a server. The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name or IP address or has been granted the right to use it by the Domain Name Registrant or IP address assignee, as appropriate. - -Wildcard FQDNs are permitted. - -CAs SHALL NOT issue certificates with a `subjectAltName` extension or `subject:commonName` field containing a Reserved IP Address or Internal Name. - -Entries in the `dNSName` MUST be in the "preferred name syntax", as specified in RFC 5280, and thus MUST NOT contain underscore characters ("_"). +This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within [Section 7.1.2](#712-certificate-content-and-extensions), but these restrictions do not supersede these requirements. -##### 7.1.4.2.2 Subject Distinguished Name Fields +In addition, the following requirements apply to all Subject Attributes (i.e. those attributes within the `subject` field of a `tbsCertificate`): + * Subject Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. + * Subject Attributes MUST NOT include a Domain Name or IP Address, except as specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address) -a. __Certificate Field:__ `subject:commonName` (OID 2.5.4.3) - __Required/Optional:__ __Deprecated__ (Discouraged, but not prohibited) - __Contents:__ If present, this field MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)). - -b. __Certificate Field:__ `subject:organizationName` (OID 2.5.4.10) - __Required/Optional:__ __Optional__. - __Contents:__ If present, the `subject:organizationName` field MUST contain either the Subject's name or DBA as verified under [Section 3.2.2.2](#3222-dbatradename). The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". Because Subject name attributes for individuals (e.g. givenName (2.5.4.42) and surname (2.5.4.4)) are not broadly supported by application software, the CA MAY use the `subject:organizationName` field to convey a natural person Subject's name or DBA. - -c. __Certificate Field:__ `subject:givenName` (2.5.4.42) and `subject:surname` (2.5.4.4) - __Required/Optional:__ __Optional__. - __Contents:__ If present, the `subject:givenName` field and `subject:surname` field MUST contain a natural person Subject’s name as verified under [Section 3.2.3](#323-authentication-of-individual-identity). A Certificate containing a `subject:givenName` field or `subject:surname` field MUST contain the (2.23.140.1.2.3) Certificate Policy OID. - -d. __Certificate Field:__ Number and street: `subject:streetAddress` (OID: 2.5.4.9) - __Required/Optional:__ - __Optional__ if the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are present. - __Prohibited__ if the `subject:organizationName` field, `subject:givenName`, and `subject:surname` field are absent. - __Contents:__ If present, the `subject:streetAddress` field MUST contain the Subject's street address information as verified under [Section 3.2.2.1](#3221-identity). - -e. __Certificate Field:__ `subject:localityName` (OID: 2.5.4.7) - __Required/Optional:__ - __Required__ if the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are present and the `subject:stateOrProvinceName` field is absent. - __Optional__ if the `subject:stateOrProvinceName` field and the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are present. - __Prohibited__ if the `subject:organizationName` field, `subject:givenName`, and `subject:surname` field are absent. - __Contents:__ If present, the `subject:localityName` field MUST contain the Subject's locality information as verified under [Section 3.2.2.1](#3221-identity). If the `subject:countryName` field specifies the ISO 3166-1 user-assigned code of XX in accordance with [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields) (g), the `localityName` field MAY contain the Subject's locality and/or state or province information as verified under [Section 3.2.2.1](#3221-identity). - -f. __Certificate Field:__ `subject:stateOrProvinceName` (OID: 2.5.4.8) - __Required/Optional:__ - __Required__ if the `subject:organizationName` field, `subject:givenName` field, or `subject:surname` field are present and `subject:localityName` field is absent. - __Optional__ if the `subject:localityName` field and the `subject:organizationName` field, the `subject:givenName` field, or the `subject:surname` field are present. - __Prohibited__ if the `subject:organizationName` field, the `subject:givenName` field, or `subject:surname` field are absent. - __Contents:__ If present, the `subject:stateOrProvinceName` field MUST contain the Subject's state or province information as verified under [Section 3.2.2.1](#3221-identity). If the `subject:countryName` field specifies the ISO 3166-1 user-assigned code of XX in accordance with [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields) (g), the `subject:stateOrProvinceName` field MAY contain the full name of the Subject's country information as verified under [Section 3.2.2.1](#3221-identity). - -g. __Certificate Field:__ `subject:postalCode` (OID: 2.5.4.17) - __Required/Optional:__ - __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). - -h. __Certificate Field:__ `subject:countryName` (OID: 2.5.4.6) - __Required/Optional:__ - __Required__ if the `subject:organizationName` field, `subject:givenName`, or `subject:surname` field are present. - __Optional__ if the `subject:organizationName` field, `subject:givenName` field, and `subject:surname` field are absent. - __Contents:__ If the `subject:organizationName` field is present, the `subject:countryName` MUST contain the two-letter ISO 3166-1 country code associated with the location of the Subject verified under [Section 3.2.2.1](#3221-identity). If the `subject:organizationName` field is absent, the `subject:countryName` field MAY contain the two-letter ISO 3166-1 country code associated with the Subject as verified in accordance with [Section 3.2.2.3](#3223-verification-of-country). If a Country is not represented by an official ISO 3166-1 country code, the CA MAY specify the ISO 3166-1 user-assigned code of XX indicating that an official ISO 3166-1 alpha-2 code has not been assigned. - -i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11) - __Required/Optional:__ __Optional__. - __Contents__: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 3.2](#32-initial-identity-validation) and the Certificate also contains `subject:organizationName`, `subject:givenName`, `subject:surname`, `subject:localityName`, and `subject:countryName` attributes, also verified in accordance with [Section 3.2.2.1](#3221-identity). - -j. Other Subject Attributes - Other attributes MAY be present within the subject field. If present, other attributes MUST contain information that has been verified by the CA. +#### 7.1.4.1 Name Encoding -#### 7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates +When encoding a `Name`, the CA SHALL ensure that: -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. + * Each `Name` MUST contain an `RDNSequence`. + * Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`. + * Each `RelativeDistinguishedName`, if present, is encoded within the `RDNSequence` in the order that it appears in [Section 7.1.4.2](#7142-subject-attribute-encoding). + * For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`. + * Except where explicitly specified, each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s. -##### 7.1.4.3.1 Subject Distinguished Name Fields +In addition to the above, the following requirements SHOULD be met by all newly-issued Technically Constrained Non-TLS Subordinate CA Certificates, as defined in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), and MUST be met for all other Certificates, regardless of whether the Certificate is a CA Certificate or a Subscriber Certificate. -a. __Certificate Field:__ `subject:commonName` (OID 2.5.4.3) - __Required/Optional:__ Required - __Contents:__ This field MUST be present and the contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. +For every valid Certification Path (as defined by [RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6)): -b. __Certificate Field:__ `subject:organizationName` (OID 2.5.4.10) - __Required/Optional:__ Required - __Contents:__ This field MUST be present and the contents MUST contain either the Subject CA's name or DBA as verified under [Section 3.2.2.2](#3222-dbatradename). The CA may include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g., if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". +* For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. +* For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to RFC 5280, Section 7.1, and including expired and revoked Certificates. -c. __Certificate Field:__ `subject:countryName` (OID: 2.5.4.6) - __Required/Optional:__ Required - __Contents:__ This field MUST contain the two‐letter ISO 3166‐1 country code for the country in which the CA's place of business is located. +#### 7.1.4.2 Subject Attribute Encoding -### 7.1.5 Name constraints +This document defines requirements for the content and validation of a number of attributes that may appear within the `subject` field of a `tbsCertificate`. CAs SHALL NOT include these attributes unless their content has been validated as specified by, and only if permitted by, the relevant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions). -For a Subordinate CA Certificate to be considered Technically Constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the Subordinate CA Certificate is authorized to issue certificates for. The `anyExtendedKeyUsage` KeyPurposeId MUST NOT appear within this extension. +Table: Attribute Encoding and Order Requirements -If the Subordinate CA Certificate includes the id-kp-serverAuth extended key usage, then the Subordinate CA Certificate MUST include the Name Constraints X.509v3 extension with constraints on `dNSName`, `iPAddress` and `DirectoryName` as follows: +| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | +| ---- | -- | --- | ---- | - | +| `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | | 2 | +| `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `streetAddress` | `2.5.4.9` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | +| `postalCode` | `2.5.4.17` | X.520 | MUST use `UTF8String` or `PrintableString` | 40 | +| `organizationName` | `2.5.4.10` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `surname` | `2.5.4.4` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | +| `givenName` | `2.5.4.42` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | +| `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 32 | +| `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -a. For each `dNSName` in `permittedSubtrees`, the CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). -b. For each `iPAddress` range in `permittedSubtrees`, the CA MUST confirm that the Applicant has been assigned the IP Address range or has been authorized by the assigner to act on the assignee's behalf. -c. For each `DirectoryName` in `permittedSubtrees`, the CA MUST confirm the Applicant's and/or Subsidiary's Organizational name and location such that end entity certificates issued from the subordinate CA Certificate will be in compliance with [Section 7.1.2.4](#7124-all-certificates) and [Section 7.1.2.5](#7125-application-of-rfc-5280). +[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. -If the Subordinate CA Certificate is not allowed to issue certificates with an IP Address, then the Subordinate CA Certificate MUST specify the entire IPv4 and IPv6 address ranges in `excludedSubtrees`. The Subordinate CA Certificate MUST include within `excludedSubtrees` an `iPAddress` `GeneralName` of 8 zero octets (covering the IPv4 address range of 0.0.0.0/0). The Subordinate CA Certificate MUST also include within `excludedSubtrees` an `iPAddress` `GeneralName` of 32 zero octets (covering the IPv6 address range of ::0/0). Otherwise, the Subordinate CA Certificate MUST include at least one `iPAddress` in `permittedSubtrees`. +[^surname_givenname] **Note**: Although RFC 5280 specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. -A decoded example for issuance to the domain and sub domains of `example.com` by organization `Example LLC, Boston, Massachusetts, US` would be: +#### 7.1.4.3 Other Subject Attributes -```text -X509v3 Name Constraints: - Permitted: - DNS:example.com - DirName: C=US, ST=MA, L=Boston, O=Example LLC - Excluded: - IP:0.0.0.0/0.0.0.0 - IP:0:0:0:0:0:0:0:0/0:0:0:0:0:0:0:0 -``` +When explicitly stated as permitted by the relavant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). -If the Subordinate CA is not allowed to issue certificates with `dNSName`s, then the Subordinate CA Certificate MUST include a zero-length `dNSName` in `excludedSubtrees`. Otherwise, the Subordinate CA Certificate MUST include at least one `dNSName` in `permittedSubtrees`. +Before including such an attribute, the CA SHALL: + * Document the attributes within Section 7.1.4 of their CP/CPS, along with the applicable validation practices. + * Ensure that the contents contain information that has been verified by the CA, independent of the Applicant. ### 7.1.6 Certificate policy object identifier -This section describes the content requirements for the Root CA, Subordinate CA, and Subscriber Certificates, as they relate to the identification of Certificate Policy. - #### 7.1.6.1 Reserved Certificate Policy Identifiers The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting that a Certificate complies with these Requirements. @@ -2172,60 +2863,6 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o `{joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) certificate‐policies(1) ev-guidelines(1)} (2.23.140.1.1)` -#### 7.1.6.2 Root CA Certificates - -A Root CA Certificate SHOULD NOT contain the `certificatePolicies` extension. If present, the extension MUST conform to the requirements set forth for Certificates issued to Subordinate CAs in [Section 7.1.6.3](#7163-subordinate-ca-certificates). - -#### 7.1.6.3 Subordinate CA Certificates - -A Certificate issued to a Subordinate CA that is not an Affiliate of the Issuing CA: - -1. MUST include one or more explicit policy identifiers that indicate the Subordinate CA's adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum Reserved Certificate Policy Identifiers or identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement) and -2. MAY contain one or more identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement and -3. MUST NOT contain the `anyPolicy` identifier (2.5.29.32.0). - -A Certificate issued to a Subordinate CA that is an affiliate of the Issuing CA: - -1. MAY include one or more explicit policy identifiers that indicate the Subordinate CA's adherence to and compliance with these Requirements (i.e. either the CA/Browser Forum Reserved Certificate Policy Identifiers or identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement) and -2. MAY contain one or more identifiers documented by the Subordinate CA in its Certificate Policy and/or Certification Practice Statement and -3. MAY contain the `anyPolicy` identifier (2.5.29.32.0) in place of an explicit policy identifier. - -The Subordinate CA and the Issuing CA SHALL represent, in their Certificate Policy and/or Certification Practice Statement, that all Certificates containing a policy identifier indicating compliance with these Requirements are issued and managed in accordance with these Requirements. - -#### 7.1.6.4 Subscriber Certificates - -Effective 2020-09-30, a Certificate issued to a Subscriber MUST contain, within the Certificate's `certificatePolicies` extension, one or more policy identifier(s) that are specified beneath the CA/Browser Forum's reserved policy OID arc of `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1)} (2.23.140.1)`. - -The certificate MAY also contain additional policy identifier(s) defined by the Issuing CA. The issuing CA SHALL document in its Certificate Policy or Certification Practice Statement that the Certificates it issues containing the specified policy identifier(s) are managed in accordance with these requirements. - -For certificates issued prior to 2020-09-30, a Certificate issued to a Subscriber MUST contain a `certificatePolicies` extension. The extension MUST contain one or more policy identifiers that indicate adherence to and compliance with these Requirements. CAs MUST either use a CA/Browser Forum identifier reserved for this purpose or MUST use a policy identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement to indicate the Certificate's compliance with these Requirements. - -Prior to including a Reserved Certificate Policy Identifier, the CA MUST ensure the following requirements are met: - -* __Certificate Policy Identifier:__ `2.23.140.1.2.1` - - If the Certificate complies with these requirements and lacks Subject identity information that has been verified in accordance with [Section 3.2.2.1](#3221-identity) or [Section 3.2.3](#323-authentication-of-individual-identity). - - Such Certificates MUST NOT include `organizationName`, `givenName`, `surname`, `streetAddress`, `localityName`, `stateOrProvinceName`, or `postalCode` in the Subject field. - -* __Certificate Policy Identifier:__ `2.23.140.1.2.2` - - If the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with [Section 3.2.2.1](#3221-identity). - - Such Certificates MUST also include `organizationName`, `localityName` (to the extent such field is required under [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields)), `stateOrProvinceName` (to the extent such field is required under [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields)), and `countryName` in the Subject field. - -* __Certificate Policy Identifier:__ `2.23.140.1.2.3` - - If the Certificate complies with these Requirements and includes Subject Identity Information that is verified in accordance with [Section 3.2.3](#323-authentication-of-individual-identity). - - Such Certificates MUST also include either `organizationName` or both `givenName` and `surname`, `localityName` (to the extent such field is required under [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields)), `stateOrProvinceName` (to the extent required under [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields)), and `countryName` in the Subject field. - -* __Certificate Policy Identifier:__ `2.23.140.1.1` - - If the Certificate complies with these Requirements and has been issued and operated in accordance with the CA/Browser Forum Guidelines for the Issuance and Management of Extended Validation Certificates ("EV Guidelines"). - - Such Certificates MUST also include Subject Identity Information as required and verified according to the EV Guidelines. - ### 7.1.7 Usage of Policy Constraints extension ### 7.1.8 Policy qualifiers syntax and semantics @@ -2244,7 +2881,7 @@ Prior to including a Reserved Certificate Policy Identifier, the CA MUST ensure If present, this extension MUST NOT be marked critical. - If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross Certificates, this CRL entry extension MUST be present. + If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, this CRL entry extension MUST be present. If a CRL entry is for a Certificate not technically capable of causing issuance, this CRL entry extension SHOULD be present, but MAY be omitted, subject to the following requirements. The `CRLReason` indicated MUST NOT be unspecified (0). If the reason for revocation is unspecified, CAs MUST omit `reasonCode` entry extension, if allowed by the previous requirements. @@ -2255,7 +2892,7 @@ Prior to including a Reserved Certificate Policy Identifier, the CA MUST ensure ## 7.3 OCSP profile -Effective 2020-09-30, if an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present. +Effective 2020-09-30, if an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present. Effective 2020-09-30, the `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions). @@ -2278,7 +2915,7 @@ The CA SHALL at all times: ## 8.1 Frequency or circumstances of assessment -Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with [Section 7.1.5](#715-name-constraints) and audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. +Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with either [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), as well as audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration. @@ -2332,7 +2969,7 @@ The Audit Report MUST contain at least the following clearly-labelled informatio 1. name of the organization being audited; 2. name and address of the organization performing the audit; -3. the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross Certificates, that were in-scope of the audit; +3. the SHA-256 fingerprint of all Roots and Subordinate CA Certificates, including Cross-Certified Subordinate CA Certificates, that were in-scope of the audit; 4. audit criteria, with version number(s), that were used to audit each of the certificates (and associated keys); 5. a list of the CA policy documents, with version numbers, referenced during the audit; 6. whether the audit assessed a period of time or a point in time; @@ -2432,7 +3069,7 @@ The Certificate Warranties specifically include, but are not limited to, the fol ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; 5. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA - i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.4.2.2](#71422-subject-distinguished-name-fields); + i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.2](#712-certificate-content-and-extensions); ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; 6. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use; From 03a388e0be76032c0ec896aee00431a182acd8e3 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 26 Jul 2021 13:04:25 -0400 Subject: [PATCH 02/54] 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. --- docs/BR.md | 37 ++++++++++++++++++++----------------- 1 file changed, 20 insertions(+), 17 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 9ea1cb2f..9e1a3ab4 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2212,13 +2212,15 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the ##### 7.1.2.6.7 Authority Information Access -The `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. +The `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. -| __Access Method__ | __OID__ | __Presence__ | __Access Location__ | __Description__ | -| -- | -- | - | ---- | --- | -| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | MUST | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's OCSP responder. | -| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | SHOULD | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's certificate. | -| Any other value | - | MUST NOT | - | - | +The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. + +| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| -- | -- | ---- | - | - | --- | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MUST | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | +| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.6.8 Basic Constraints @@ -2360,11 +2362,10 @@ For OCSP Responder certificates, this extension SHOULD NOT be present, as the Re If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. -| __Access Method__ | __OID__ | __Presence__ | __Access Location__ | __Description__ | -| -- | -- | - | ---- | --- | -| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | SHOULD NOT | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's certificate. | -| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | MUST NOT | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's OCSP responder. | -| Any other value | - | MUST NOT | - | - | +| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| -- | -- | ---- | - | - | --- | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | SHOULD NOT | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.7.3 Basic Constraints @@ -2453,13 +2454,15 @@ The following table details the acceptable `AttributeType`s that may appear with ##### 7.1.2.8.2 Authority Information Access -If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. +If present, the `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. + +The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. -| __Access Method__ | __OID__ | __Presence__ | __Access Location__ | __Description__ | -| -- | -- | - | ---- | --- | -| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | SHOULD | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's certificate. | -| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | MAY | `uniformResourceIdentifier` | A HTTP URL of the Issuing CA's OCSP responder. | -| Any other value | - | MUST NOT | - | - | +| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| -- | -- | ---- | - | - | --- | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | +| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.8.3 Basic Constraints From f7e22bb1ca0ad9ed2a4020911d33192edc9236f2 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 26 Jul 2021 13:12:05 -0400 Subject: [PATCH 03/54] 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. --- docs/BR.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 9e1a3ab4..281c3412 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2341,10 +2341,10 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.7.3](#71273-basic-constraints) | | `extKeyUsage` | MUST | - | See [Section 7.1.2.7.4](#71274-extended-key-usage) | | `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.7.5](#71275-id-pkix-ocsp-nocheck) | | `keyUsage` | MUST | Y | See [Section 7.1.2.7.6](#71276-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.3](#71273-basic-constraints) | | `nameConstraints` | MUST NOT | - | - | | `subjectAltName` | MUST NOT | - | - | | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | @@ -2369,6 +2369,8 @@ If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `Ac ##### 7.1.2.7.3 Basic Constraints +OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. When using DER encoding, the encoded value of a `BasicConstraints` sequence is an empty SEQUENCE, as DEFAULT values are not encoded. + | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be FALSE | From f22537f4131312a5f4e57df70fa12befde8e8da5 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 29 Jul 2021 18:06:23 -0400 Subject: [PATCH 04/54] 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. --- docs/BR.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 281c3412..c069f9b1 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2332,7 +2332,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.5.1](#71251-tls-subordinate-ca-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.7.5.1](#71251-ocsp-responder-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | @@ -2632,20 +2632,22 @@ Table: `CRLDistributionPoints` profile | \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | | \ \ \ \ `reasons` | MUST NOT | | | \ \ \ \ `cRLIssuer` | MUST NOT | | -| \ \ **2+** | MAY | Additional `DistributionPoint`s that meet the following profile MAY be present. | +| \ \ **2+** | SHOULD NOT | Additional `DistributionPoint`s SHOULD NOT be present. | | \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | | \ \ \ \ `reasons` | MUST NOT | | | \ \ \ \ `cRLIssuer` | MUST NOT | | -| \ \ **3** | MUST NOT | `DistributionPoints` that to not conform to the above requirements MUST NOT be present. | +| \ \ **3** | MUST NOT | `DistributionPoints` that do not conform to the above requirements MUST NOT be present. | Table: `fullName` profile | __Field__ | __Presence__ | __Description__ | | ---- | - | ----- | | `fullName` | | | -| \ \ **1** | MUST | The first `GeneralName` present in `fullName` MUST be of type `unformResourceIdentifier` | +| \ \ **1** | MUST | The first `GeneralName` present in `fullName` MUST be of type `uniformResourceIdentifier` | | \ \ \ \ `uniformResourceIdentifier` | MUST | The HTTP URL of the Issuing CA's CRL service for this certificate. | -| \ \ **2** | SHOULD NOT | Additional `GeneralName`s SHOULD NOT be present. __**TBD: MUST NOT**__ | +| \ \ **2+** | MAY | Additional `GeneralName`s MAY be present. If present, they MUST be of type `uniformResourceIdentifier`. | +| \ \ \ \ `uniformResourceIdentifier` | MUST | If present, the scheme of the `uniformResourceIdentifier` MUST be "http". | +| \ \ **3** | MUST NOT | `GeneralName`s that do not conform to the above requirements MUST NOT be present. | ##### 7.1.2.9.3 Signed Certificate Timestamp List From 1d5ee9cf97c0fce57a174ccc64a6e881fbe6b87d Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 Aug 2021 13:52:27 -0400 Subject: [PATCH 05/54] Fix broken link and better clarify WIP sections --- docs/BR.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index c069f9b1..ab47817f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2332,7 +2332,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.7.5.1](#71251-ocsp-responder-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.2.7.1](#71271-ocsp-responder-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | @@ -2659,7 +2659,9 @@ Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestam If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). CAs MUST generate a unique `subjectKeyIdentifier` for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs MAY generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. -#### 7.1.2.4 All Certificates +#### 7.1.2.4 TO DELETE All Certificates + +**TODO: Integrate into 7.1.2.9 as the catch-all for all certificates (currently listed TBD)** All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a `keyUsage` flag, `extKeyUsage` value, Certificate extension, or other data not specified in [Section 7.1.2](#712-certificate-content-and-extensions) unless the CA is aware of a reason for including the data in the Certificate. @@ -2670,7 +2672,9 @@ a. Extensions that do not apply in the context of the public Internet (such as a ii. the Applicant can otherwise demonstrate the right to assert the data in a public context; or b. semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA (such as including an `extKeyUsage` value for a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance). -#### 7.1.2.5 Application of RFC 5280 +#### 7.1.2.5 TO DELETE Application of RFC 5280 + +**TODO: Move this text into 7.1.2 requirements** Except where explicitly noted, all certificates MUST conform to the certificate profile of RFC 5280. The following requirements are noted in addition to any normative requirements placed within RFC 5280. In particular, CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further discussion of normative requirements imposed by RFC 5280 and its normative dependencies. From 1fd2d677193841f3bf177f9104482f0629854aaa Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Wed, 4 Aug 2021 14:20:51 -0400 Subject: [PATCH 06/54] 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. --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ab47817f..0870840e 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2543,9 +2543,9 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to | `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MAY | | `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MAY | | `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MAY | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MAY | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | | `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Any other value | - | SHOULD NOT | +| Any other value | - | MAY | ##### 7.1.2.8.7 Extended Key Usage - TLS CA From 25fd686036fb002d069106547782a036f6f97cf4 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 19 Aug 2021 15:43:25 -0400 Subject: [PATCH 07/54] Remove stale FIXME regarding serial numbers --- docs/BR.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 0870840e..c423260c 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1754,10 +1754,6 @@ The CA SHALL enforce multi-factor authentication for all accounts capable of dir The CA SHALL meet the technical requirements set forth in [Section 2.2 - Publication of Information](#22-publication-of-information), [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking). -TODO(sleevi): FIXME - -CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG. - ### 7.1.1 Version number(s) Certificates MUST be of type X.509 v3. From a2a7f75746a754165a9d883cd17a5e5dc4f7cc4b Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:40:47 -0400 Subject: [PATCH 08/54] 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. --- docs/BR.md | 442 +++++++++++++++++++++++++++++------------------------ 1 file changed, 245 insertions(+), 197 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index c423260c..b9206bf2 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -440,7 +440,7 @@ The script outputs: **Subsidiary Company**: A company that is controlled by a Parent Company. -**Technically Constrained Subordinate CA Certificate**: A Subordinate CA certificate which uses a combination of Extended Key Usage settings and Name Constraint settings to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates. +**Technically Constrained Subordinate CA Certificate**: A Subordinate CA certificate which uses a combination of Extended Key Usage and/or Name Constraint extensions, as defined within the relevant Certificate Profiles of this document, to limit the scope within which the Subordinate CA Certificate may issue Subscriber or additional Subordinate CA Certificates. **Terms of Use**: Provisions regarding the safekeeping and acceptable uses of a Certificate issued in accordance with these Requirements when the Applicant/Subscriber is an Affiliate of the CA or is the CA. @@ -968,7 +968,7 @@ When processing CAA records, CAs MUST process the issue, issuewild, and iodef pr RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following: * CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. -* CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. +* CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. * For certificates issued prior to July 1, 2021, CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS. CAs are permitted to treat a record lookup failure as permission to issue if: @@ -1310,7 +1310,7 @@ For the status of Subordinate CA Certificates: i. at least every twelve months; and ii. within 24 hours after revoking a Subordinate CA Certificate. -If the OCSP responder receives a request for the status of a certificate serial number that is "unused", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests. +If the OCSP responder receives a request for the status of a certificate serial number that is "unused", then the responder SHOULD NOT respond with a "good" status. If the OCSP responder is for a CA that is not Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), the responder MUST NOT respond with a "good" status for such requests. The CA SHOULD monitor the OCSP responder for requests for "unused" serial numbers as part of its security response procedures. @@ -1321,7 +1321,7 @@ A certificate serial number within an OCSP request is one of the following three 1. "assigned" if a Certificate with that serial number has been issued by the Issuing CA, using any current or previous key associated with that CA subject; or 2. "reserved" if a Precertificate [RFC6962] with that serial number has been issued by a. the Issuing CA; or - b. a Precertificate Signing Certificate [RFC6962] associated with the Issuing CA; or + b. a Precertificate Signing Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), associated with the Issuing CA; or 3. "unused" if neither of the previous conditions are met. ### 4.9.11 Other forms of revocation advertisements available @@ -1769,18 +1769,17 @@ If the CA asserts compliance with these Baseline Requirements, all certificates * [Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile) * Technically Constrained CA Certificates * [Section 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) - * [Section 7.1.2.4 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7124-technically-constrained-tls-subordinate-ca-certificate-profile) - * [Section 7.1.2.5 - TLS Subordinate CA Certificate Profile](#7125-tls-subordinate-ca-certificate-profile) - * [Section 7.1.2.6 - Subscriber (End-Entity) Certificate Profile](#7126-subscriber-server-certificate-profile) + * [Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile](7124-technically-constrained-precertificate-signing-ca-certificate-profile) + * [Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) + * [Section 7.1.2.6 - TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile) + * [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile) * Domain Validated * Individual Validated * Organization Validated * Extended Validation - * __**TBD: Infrastructure Certificates**__ - * [Section 7.1.2.7 - OCSP Responder Certificate Profile](#7127-ocsp-responder-certificate-profile) - * __**TBD: Infrastructure Cert**__ - * __**TBD: Precert Signing CA**__ - * __**TBD: Interoperability Testing Certs (valid/revoked/expired)?**__ + * [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile) + * __**TBD: Infrastructure Cert**__ + * __**TBD: Interoperability Testing Certs (valid/revoked/expired)?**__ #### 7.1.2.1 Root CA Certificate Profile @@ -1792,7 +1791,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -1806,11 +1805,11 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | ---- | - | - | ----- | | `authorityKeyIdentifier` | SHOULD | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.1.3](#71213-basic-constraints) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | `extKeyUsage` | MUST NOT | N | - | -| `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.8 4](#71284-certificate-policies---affiliated-ca) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.9 4](#71294-certificate-policies---affiliated-ca) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | ##### 7.1.2.1.2 Authority Key Identifier @@ -1866,37 +1865,37 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.3](#71223-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | Table: Extensions when the Subordinate CA is operated by an entity that is not the Issuing CA or an Affiliate of the Issuing CA. | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.5](#71285-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.5](#71295-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---restricted-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. -[^name_constraints]: See [Section 7.1.2.8.9](#71289-name-constraints) for further requirements, including regarding criticality of this extension. +[^name_constraints]: See [Section 7.1.2.9.9](#71299-name-constraints) for further requirements, including regarding criticality of this extension. ##### 7.1.2.2.3 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA @@ -1917,7 +1916,7 @@ If present, the Extended Key Usage extension MUST only contain key usage purpose #### 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile -This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively. If the CA Certificate does not conform to this profile, or the profile specified in [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), then it is not Technically Constrained. +This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively. | __Field__ | __Description__ | | --- | ------ | @@ -1927,7 +1926,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -1939,21 +1938,23 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.8.5](#71286-extended-key-usage---non-tls-ca) (Non-TLS CA) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.9.5](#71296-extended-key-usage---non-tls-ca) (Non-TLS CA) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | -#### 7.1.2.4 Technically Constrained TLS Subordinate CA Certificate Profile +#### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile -This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively. If the CA Certificate does not conform to this profile, or the profile specified in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), then it is not Technically Constrained. +This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in [RFC 6962, Section 3.1](https://tools.ietf.org/html/rfc6962#section-3.1). If a CA Certificate conforms to this profile, it is considered Technically Constrained. + +A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in [RFC6962]. When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching `tbsCertificate` of the Precertificate, after applying the modifications specified in [RFC 6962, Section 3.2](https://tools.ietf.org/html/rfc6962#section-3.2). | __Field__ | __Description__ | | --- | ------ | @@ -1963,31 +1964,81 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-tls-subordinate-ca-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-precertificate-signing-ca-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -##### 7.1.2.4.1 Technically Constrained TLS Subordinate CA Extensions +##### 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.8.7](#71287-extended-key-usage---tls-ca) (TLS CA) | -| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.4.2](#71242-name-constraints) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | -##### 7.1.2.4.2 Name Constraints +##### 7.1.2.4.2 Extended Key Usage + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MUST NOT | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Any other value | - | SHOULD NOT | + +#### 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile + +This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | MUST be v3(2) | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `issuerUniqueID` | MUST NOT be present | +| \ \ \ \ `subjectUniqueID` | MUST NOT be present | +| \ \ \ \ `extensions` | See [Section 7.1.2.5.1](#71251-technically-constrained-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.9.7](#71297-extended-key-usage---tls-ca) (TLS CA) | +| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| Any other extension | SHOULD NOT | - | __**TBD**__ | + +##### 7.1.2.5.2 Name Constraints For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. @@ -2028,7 +2079,7 @@ Table: `otherName` requirements within a `GeneralName` | `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | SHOULD NOT | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | | Any other value | SHOULD NOT | - | - | - | -#### 7.1.2.5 TLS Subordinate CA Certificate Profile +#### 7.1.2.6 TLS Subordinate CA Certificate Profile | __Field__ | __Description__ | | --- | ------ | @@ -2038,31 +2089,31 @@ Table: `otherName` requirements within a `GeneralName` | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.5.1](#71251-tls-subordinate-ca-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.2.6.1](#71261-tls-subordinate-ca-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -##### 7.1.2.5.1 TLS Subordinate CA Extensions +##### 7.1.2.6.1 TLS Subordinate CA Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.8.4](#71284-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.8](#71288-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.8.7](#71287-extended-key-usage---tls-ca) (TLS CA) | -| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.8.9](#71289-name-constraints) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.9.7](#71297-extended-key-usage---tls-ca) (TLS CA) | +| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | -#### 7.1.2.6 Subscriber (Server) Certificate Profile +#### 7.1.2.7 Subscriber (Server) Certificate Profile | __Field__ | __Description__ | | --- | ------ | @@ -2074,28 +2125,28 @@ Table: `otherName` requirements within a `GeneralName` | \ \ \ \ `validity` | | | \ \ \ \ \ \ \ \ `notBefore` | __**TBD**__ | | \ \ \ \ \ \ \ \ `notAfter` | See [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | -| \ \ \ \ `subject` | See [Section 7.1.2.6.1](#71261-subscriber-certificate-types) | +| \ \ \ \ `subject` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.6.1](#71261-subscriber-certificate-types) | +| \ \ \ \ `extensions` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -##### 7.1.2.6.1 Subscriber Certificate Types +##### 7.1.2.7.1 Subscriber Certificate Types There are four types of Subscriber Certificates that may be issued, which vary based on the amount of Subject Information that is included. Each of these certificate types shares a common profile, with three exceptions: the `subject` name fields that may occur, how those fields are validated, and the contents of the `certificatePolicies` extension. | __Type__ | __Description__ | | --- | ------- | -| Domain Validated (DV) | See [Section 7.1.2.6.2](#71262-domain-validated) | -| Individual Validated (IV) | See [Section 7.1.2.6.3](#71263-individual-validated) | -| Organization Validated (OV) | See [Section 7.1.2.6.4](#71264-organization-validated) | -| Extended Validation (EV) | See [Section 7.1.2.6.5](#71265-extended-validation) | +| Domain Validated (DV) | See [Section 7.1.2.7.2](#71272-domain-validated) | +| Individual Validated (IV) | See [Section 7.1.2.7.3](#71273-individual-validated) | +| Organization Validated (OV) | See [Section 7.1.2.7.4](#71274-organization-validated) | +| Extended Validation (EV) | See [Section 7.1.2.7.5](#71275-extended-validation) | **Note**: Although each Subscriber Certificate type varies in Subject Information, all Certificates provide the same level of assurance of the device identity (domain name and/or IP address). -##### 7.1.2.6.2 Domain Validated +##### 7.1.2.7.2 Domain Validated For a Subscriber Certificate to be Domain Validated, it MUST meet the following profile: @@ -2103,7 +2154,7 @@ For a Subscriber Certificate to be Domain Validated, it MUST meet the following | -- | ------- | | `subject` | See following table. | | `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. | -| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2117,7 +2168,7 @@ Table: Domain Validated `subject` Attributes | `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | MUST NOT | __**TBD**__ | | -##### 7.1.2.6.3 Individual Validated +##### 7.1.2.7.3 Individual Validated For a Subscriber Certificate to be Individual Validated, it MUST meet the following profile: @@ -2125,7 +2176,7 @@ For a Subscriber Certificate to be Individual Validated, it MUST meet the follow | -- | ------- | | `subject` | See following table. | | `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. | -| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2147,7 +2198,7 @@ Table: Individual Validated `subject` Attributes | `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | SHOULD NOT | __**TBD**__ | __**TBD**__ | -##### 7.1.2.6.4 Organization Validated +##### 7.1.2.7.4 Organization Validated For a Subscriber Certificate to be Organization Validated, it MUST meet the following profile: @@ -2155,7 +2206,7 @@ For a Subscriber Certificate to be Organization Validated, it MUST meet the foll | -- | ------- | | `subject` | See following table. | | `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. | -| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2177,7 +2228,7 @@ Table: Individual Validated `subject` Attributes | `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | SHOULD NOT | __**TBD**__ | __**TBD**__ | -##### 7.1.2.6.5 Extended Validation +##### 7.1.2.7.5 Extended Validation For a Subscriber Certificate to be Extended Validation, it MUST comply with the Certificate Profile specified in the then-current version of the Guidelines for the Issuance and Management of Extended Validation Certificates. In addition, it MUST meet the following profile: @@ -2186,27 +2237,27 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | -- | ------- | | `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 9.2. | | `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. | -| All other extensions | See [Section 7.1.2.6.6](#71266-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | -##### 7.1.2.6.6 Subscriber Certificate Extensions +##### 7.1.2.7.6 Subscriber Certificate Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.6.7](#71267-authority-information-access) | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.6.9](#71269-certificate-policies) | -| `extKeyUsage` | MUST | N | See [Section 7.1.2.6.10](#712610-extended-key-usage) | -| `subjectAltName` | MUST | - | See [Section 7.1.2.6.12](#712612-subject-alternative-name) | +| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-authority-information-access) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-certificate-policies) | +| `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-extended-key-usage) | +| `subjectAltName` | MUST | - | See [Section 7.1.2.7.12](#712712-subject-alternative-name) | | `nameConstraints` | MUST NOT | - | - | -| `keyUsage` | SHOULD | Y | See [Section 7.1.2.6.11](#712611-key-usage) | -| `basicConstraints` | MAY | Y | See [Section 7.1.2.6.8](#71268-basic-constraints) | -| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | +| `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-basic-constraints) | +| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | | CA/Browser Forum Onion Extension | MAY | N | __**TODO**__ | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | -| `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | Any other extension | SHOULD NOT | - | __**TBD**__ | -##### 7.1.2.6.7 Authority Information Access +##### 7.1.2.7.7 Authority Information Access The `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. @@ -2218,20 +2269,20 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.6.8 Basic Constraints +##### 7.1.2.7.8 Basic Constraints | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be FALSE | | `pathLenConstraint` | MUST NOT be present | -##### 7.1.2.6.9 Certificate Policies +##### 7.1.2.7.9 Certificate Policies | __Field__ | __Presence__ | __Description__ | | --- | - | ------ | | `certificatePolicies` | | | | \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.6.1](#71261-subscriber-certificate-types). | +| \ \ \ \ `policyIdentifier` | | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types). | | \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | | \ \ **2+** | MAY | The Issuing CA MAY include additional `PolicyInformation` values that meet the following profile: | | \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the Issuing CA in its Certificate Policy and/or Certification Practice Statement. | @@ -2245,20 +2296,21 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.6.10 Extended Key Usage +##### 7.1.2.7.10 Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Any other value | - | SHOULD NOT | +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | +| Any other value | - | SHOULD NOT | -##### 7.1.2.6.11 Key Usage +##### 7.1.2.7.11 Key Usage The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key. @@ -2268,9 +2320,9 @@ Table: Key Usage for RSA Public Keys | ---- | - | - | | `digitalSignature` | Y | SHOULD | | `nonRepudiation` | N | -- | -| `keyEncipherment` | Y | MAY | +| `keyEncipherment` | Y | MAY | | `dataEncipherment` | N | -- | -| `keyAgreement` | N | -- | +| `keyAgreement` | N | -- | | `keyCertSign` | N | -- | | `cRLSign` | N | -- | | `encipherOnly` | N | -- | @@ -2292,7 +2344,7 @@ Table: Key Usage for ECC Public Keys | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -##### 7.1.2.6.12 Subject Alternative Name +##### 7.1.2.7.12 Subject Alternative Name For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements. @@ -2312,7 +2364,7 @@ Table: `GeneralName` within a `subjectAltName` extension | `iPAddress` | Y | MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in [Section 3.2.2.5](#3225-authentication-for-an-ip-address). MUST NOT contain a Reserved IP Address. | | `registeredID` | N | - | -#### 7.1.2.7 OCSP Responder Certificate Profile +#### 7.1.2.8 OCSP Responder Certificate Profile If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as definied by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. @@ -2324,35 +2376,35 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.8.1](#71281-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.7.1](#71271-ocsp-responder-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.2.8.1](#71281-ocsp-responder-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -##### 7.1.2.7.1 OCSP Responder Extensions +##### 7.1.2.8.1 OCSP Responder Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.9.1](#71291-authority-key-identifier) | -| `extKeyUsage` | MUST | - | See [Section 7.1.2.7.4](#71274-extended-key-usage) | -| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.7.5](#71275-id-pkix-ocsp-nocheck) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.7.6](#71276-key-usage) | -| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.3](#71273-basic-constraints) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.4](#71284-extended-key-usage) | +| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.5](#71285-id-pkix-ocsp-nocheck) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.6](#71286-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | | `nameConstraints` | MUST NOT | - | - | | `subjectAltName` | MUST NOT | - | - | -| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.9.4](#71294-subject-key-identifier) | -| `authorityInformationAccess` | SHOULD NOT | N | See [Section 7.1.2.7.2](#71272-authority-information-access) | +| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `authorityInformationAccess` | SHOULD NOT | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | | `certificatePolicies` | - | - | - | -| \ \ \ \ _Prior to 2021-10-01_ | SHOULD NOT | N | See [Section 7.1.2.7.7](#71277-certificate-policies) | +| \ \ \ \ _Prior to 2021-10-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | | \ \ \ \ _Effective 2021-10-01_ | MUST NOT | - | - | -| `crlDistributionPoints` | SHOULD NOT | N | See [Section 7.1.2.9.2](#71292-crl-distribution-points) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.9.3](#71293-signed-certificate-timestamp-list) | +| `crlDistributionPoints` | SHOULD NOT | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | -##### 7.1.2.7.2 Authority Information Access +##### 7.1.2.8.2 Authority Information Access For OCSP Responder certificates, this extension SHOULD NOT be present, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties. @@ -2363,7 +2415,7 @@ If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `Ac | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | SHOULD NOT | \* | A HTTP URL of the Issuing CA's OCSP responder. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.7.3 Basic Constraints +##### 7.1.2.8.3 Basic Constraints OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. When using DER encoding, the encoded value of a `BasicConstraints` sequence is an empty SEQUENCE, as DEFAULT values are not encoded. @@ -2374,26 +2426,20 @@ OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indi **Note**: CAs MUST observe DER encoding rules, such as not explicitly encoding DEFAULT values within OPTIONAL fields. -##### 7.1.2.7.4 Extended Key Usage +##### 7.1.2.8.4 Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MUST NOT | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Any other value | - | MUST NOT | +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | +| Any other value | - | MUST NOT | -##### 7.1.2.7.5 id-pkix-ocsp-nocheck +##### 7.1.2.8.5 id-pkix-ocsp-nocheck The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5). This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1). -##### 7.1.2.7.6 Key Usage +##### 7.1.2.8.6 Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2407,9 +2453,9 @@ This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960 | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -##### 7.1.2.7.7 Certificate Policies +##### 7.1.2.8.7 Certificate Policies -**Note**: See [Section 7.1.2.7.1](#71271-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. +**Note**: See [Section 7.1.2.8.1](#71281-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. If present, the Certificate Policies extension MUST be formatted as follows: @@ -2428,11 +2474,11 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -#### 7.1.2.8 Common CA Fields +#### 7.1.2.9 Common CA Fields This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). -##### 7.1.2.8.1 CA Certificate Naming +##### 7.1.2.9.1 CA Certificate Naming All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2450,7 +2496,7 @@ The following table details the acceptable `AttributeType`s that may appear with | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | | Any other attribute | SHOULD NOT | __**TBD**__ | | -##### 7.1.2.8.2 Authority Information Access +##### 7.1.2.9.2 Authority Information Access If present, the `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. @@ -2462,14 +2508,14 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.8.3 Basic Constraints +##### 7.1.2.9.3 Basic Constraints | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be set TRUE | | `pathLenConstraint` | MAY be present | -##### 7.1.2.8.4 Certificate Policies - Affiliated CA +##### 7.1.2.9.4 Certificate Policies - Affiliated CA The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by an organization that is the same as the organization operating the Issuing CA or that is an Affiliate of the organization operating the Issuing CA. @@ -2501,7 +2547,7 @@ Table: Policy Restricted | \ \ \ \ `policyQualifiers` | MUST NOT | | | \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | -##### 7.1.2.8.5 Certificate Policies - Non-Affiliated CA +##### 7.1.2.9.5 Certificate Policies - Non-Affiliated CA The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by a CA that is an not an Affiliate of the Issuing CA. @@ -2528,35 +2574,37 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.8.6 Extended Key Usage - Non-TLS CA +##### 7.1.2.9.6 Extended Key Usage - Non-TLS CA The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) SHOULD NOT be present. -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MAY | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MAY | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MAY | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Any other value | - | MAY | - -##### 7.1.2.8.7 Extended Key Usage - TLS CA - -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Any other value | - | SHOULD NOT | - -##### 7.1.2.8.8 Key Usage +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MAY | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MAY | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MAY | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | +| Any other value | - | MAY | + +##### 7.1.2.9.7 Extended Key Usage - TLS CA + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | +| Any other value | - | SHOULD NOT | + +##### 7.1.2.9.8 Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2572,7 +2620,7 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to [^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information. -##### 7.1.2.8.9 Name Constraints +##### 7.1.2.9.9 Name Constraints If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. @@ -2603,11 +2651,11 @@ Table: `GeneralName` requirements for the `base` field | `directoryName` | MMAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | | Any other value | SHOULD NOT | - | - | -#### 7.1.2.9 Common Certificate Fields +#### 7.1.2.10 Common Certificate Fields This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). -##### 7.1.2.9.1 Authority Key Identifier +##### 7.1.2.10.1 Authority Key Identifier | __Field__ | __Description__ | | --- | ------- | @@ -2615,7 +2663,7 @@ This section contains several fields that are common among multiple certificate | `authorityCertIssuer` | MUST NOT be present | | `authorityCertSerialNumber` | MUST NOT be present | -##### 7.1.2.9.2 CRL Distribution Points +##### 7.1.2.10.2 CRL Distribution Points If present, the CRL Distribution Points extension MUST be formatted as follows: @@ -2645,19 +2693,19 @@ Table: `fullName` profile | \ \ \ \ `uniformResourceIdentifier` | MUST | If present, the scheme of the `uniformResourceIdentifier` MUST be "http". | | \ \ **3** | MUST NOT | `GeneralName`s that do not conform to the above requirements MUST NOT be present. | -##### 7.1.2.9.3 Signed Certificate Timestamp List +##### 7.1.2.10.3 Signed Certificate Timestamp List If present, the Signed Certificate Timestamp List extension contents MUST be an `OCTET STRING` containing the encoded `SignedCertificateTimestampList`, as specified in [RFC 6962, Section 3.3](https://tools.ietf.org/html/rfc6962#section-3.3). Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestampList` MUST be for a `PreCert` `LogEntryType` that corresponds to the current certificate. -##### 7.1.2.9.4 Subject Key Identifier +##### 7.1.2.10.4 Subject Key Identifier If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). CAs MUST generate a unique `subjectKeyIdentifier` for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs MAY generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. -#### 7.1.2.4 TO DELETE All Certificates +#### 7.1.2.5 TO DELETE All Certificates -**TODO: Integrate into 7.1.2.9 as the catch-all for all certificates (currently listed TBD)** +**TODO: Integrate into 7.1.2.10 as the catch-all for all certificates (currently listed TBD)** All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a `keyUsage` flag, `extKeyUsage` value, Certificate extension, or other data not specified in [Section 7.1.2](#712-certificate-content-and-extensions) unless the CA is aware of a reason for including the data in the Certificate. @@ -2668,7 +2716,7 @@ a. Extensions that do not apply in the context of the public Internet (such as a ii. the Applicant can otherwise demonstrate the right to assert the data in a public context; or b. semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA (such as including an `extKeyUsage` value for a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance). -#### 7.1.2.5 TO DELETE Application of RFC 5280 +#### 7.1.2.6 TO DELETE Application of RFC 5280 **TODO: Move this text into 7.1.2 requirements** @@ -2922,7 +2970,7 @@ The CA SHALL at all times: ## 8.1 Frequency or circumstances of assessment -Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with either [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.4](#7124-technically-constrained-tls-subordinate-ca-certificate-profile), as well as audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. +Certificates that are capable of being used to issue new certificates MUST either be Technically Constrained in line with [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile), or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), as well as audited in line with [Section 8.7](#87-self-audits) only, or Unconstrained and fully audited in line with all remaining requirements from this section. A Certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 `basicConstraints` extension, with the `cA` boolean set to true and is therefore by definition a Root CA Certificate or a Subordinate CA Certificate. The period during which the CA issues Certificates SHALL be divided into an unbroken sequence of audit periods. An audit period MUST NOT exceed one year in duration. From 51811aa0955008bc18499e7a9cf2a908d751f6ef Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:45:45 -0400 Subject: [PATCH 09/54] 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. --- docs/BR.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index b9206bf2..499ed6bd 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2189,8 +2189,8 @@ Table: Individual Validated `subject` Attributes | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `postalCode` | SHOULD NOT | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `organizationName` | SHOULD NOT | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | @@ -2219,8 +2219,8 @@ Table: Individual Validated `subject` Attributes | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | -| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | | `postalCode` | SHOULD NOT | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | +| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | | `surname` | MUST NOT | | | | `givenName` | MUST NOT | | | @@ -2489,8 +2489,8 @@ The following table details the acceptable `AttributeType`s that may appear with | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) | | `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MAY | If present, the CA's locality. | [Section 3.2.2.1](#3221-identity) | -| `streetAddress` | MAY | If present, the CA's street address. Multiple instances MAY be present. | [Section 3.2.2.1](#3221-identity) | | `postalCode` | MAY | If present, the CA's zip or postal information. | [Section 3.2.2.1](#3221-identity) | +| `streetAddress` | MAY | If present, the CA's street address. Multiple instances MAY be present. | [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | | `organizationalUnitName` | SHOULD NOT | __**TBD**__ | | | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | @@ -2884,8 +2884,8 @@ Table: Attribute Encoding and Order Requirements | `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | | 2 | | `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | | `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | -| `streetAddress` | `2.5.4.9` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | | `postalCode` | `2.5.4.17` | X.520 | MUST use `UTF8String` or `PrintableString` | 40 | +| `streetAddress` | `2.5.4.9` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | | `organizationName` | `2.5.4.10` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | | `surname` | `2.5.4.4` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | | `givenName` | `2.5.4.42` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | From b7a269bec6cd09208662cf20b110190d955f664d Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:54:54 -0400 Subject: [PATCH 10/54] Fix nameConstraints for TLS subCAs They were accidentally a MUST, when they should have been a MAY. Bad copy/paste. --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 499ed6bd..d4d91159 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2108,8 +2108,8 @@ Table: `otherName` requirements within a `GeneralName` | `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.9.7](#71297-extended-key-usage---tls-ca) (TLS CA) | -| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | From a85067ad6b16fcedb3ef6581ef73ebab09e4df89 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:55:33 -0400 Subject: [PATCH 11/54] 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. --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d4d91159..d11e519b 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2398,8 +2398,8 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | | `authorityInformationAccess` | SHOULD NOT | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | | `certificatePolicies` | - | - | - | -| \ \ \ \ _Prior to 2021-10-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | -| \ \ \ \ _Effective 2021-10-01_ | MUST NOT | - | - | +| \ \ \ \ _Prior to 2022-02-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | +| \ \ \ \ _Effective 2022-02-01_ | MUST NOT | - | - | | `crlDistributionPoints` | SHOULD NOT | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | From 941af64acb0c1c0068a3fc0038946599aa5665ae Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:57:47 -0400 Subject: [PATCH 12/54] 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. --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index d11e519b..4b77b17f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2400,7 +2400,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | `certificatePolicies` | - | - | - | | \ \ \ \ _Prior to 2022-02-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | | \ \ \ \ _Effective 2022-02-01_ | MUST NOT | - | - | -| `crlDistributionPoints` | SHOULD NOT | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | From e62f560c03add7ae4157b2814f16b3f6ad07edbb Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 14:00:07 -0400 Subject: [PATCH 13/54] Fix typo -> MMAY to MAY --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 4b77b17f..105ac1b7 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2648,7 +2648,7 @@ Table: `GeneralName` requirements for the `base` field | -- | - | ---- | ---- | | `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | | `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | -| `directoryName` | MMAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | +| `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | | Any other value | SHOULD NOT | - | - | #### 7.1.2.10 Common Certificate Fields From fd362d723eef1effc888d6be4f7cc555cf8df6bf Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 21 Oct 2021 19:02:15 -0400 Subject: [PATCH 14/54] 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. --- docs/BR.md | 283 +++++++++++++++++++++++++++++++++++------------------ 1 file changed, 188 insertions(+), 95 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 105ac1b7..bda8c321 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1778,7 +1778,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates * Organization Validated * Extended Validation * [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile) - * __**TBD: Infrastructure Cert**__ + * [Section 7.1.2.9 - Precertificate Profile](#7129-precertificate-profile) * __**TBD: Interoperability Testing Certs (valid/revoked/expired)?**__ #### 7.1.2.1 Root CA Certificate Profile @@ -1791,7 +1791,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -1805,11 +1805,11 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | ---- | - | - | ----- | | `authorityKeyIdentifier` | SHOULD | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.1.3](#71213-basic-constraints) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST NOT | N | - | -| `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.9 4](#71294-certificate-policies---affiliated-ca) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.10 4](#712104-certificate-policies---affiliated-ca) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | ##### 7.1.2.1.2 Authority Key Identifier @@ -1865,37 +1865,37 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.3](#71223-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | Table: Extensions when the Subordinate CA is operated by an entity that is not the Issuing CA or an Affiliate of the Issuing CA. | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.5](#71295-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---restricted-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. -[^name_constraints]: See [Section 7.1.2.9.9](#71299-name-constraints) for further requirements, including regarding criticality of this extension. +[^name_constraints]: See [Section 7.1.2.10.9](#712109-name-constraints) for further requirements, including regarding criticality of this extension. ##### 7.1.2.2.3 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA @@ -1926,7 +1926,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -1938,23 +1938,25 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.9.5](#71296-extended-key-usage---non-tls-ca) (Non-TLS CA) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.5](#712106-extended-key-usage---non-tls-ca) (Non-TLS CA) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | #### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in [RFC 6962, Section 3.1](https://tools.ietf.org/html/rfc6962#section-3.1). If a CA Certificate conforms to this profile, it is considered Technically Constrained. -A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in [RFC6962]. When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching `tbsCertificate` of the Precertificate, after applying the modifications specified in [RFC 6962, Section 3.2](https://tools.ietf.org/html/rfc6962#section-3.2). +A Precertificate Signing CA MUST only be used to sign Precertificates, as defined in [Section 7.1.2.9](#7129-precertificate-profile). When a Precertificate Signing CA issues a Precertificate, it shall be interpreted as if the Issuing CA of the Precertificate Signing CA has issued a Certificate with a matching `tbsCertificate` of the Precertificate, after applying the modifications specified in [RFC 6962, Section 3.2](https://tools.ietf.org/html/rfc6962#section-3.2). + +As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair. | __Field__ | __Description__ | | --- | ------ | @@ -1964,8 +1966,8 @@ A Precertificate Signing CA MUST only be used to sign Precertificates, as define | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | +| \ \ \ \ `subjectPublicKeyInfo` | The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the `subjectPublicKeyInfo` field of the Issuing CA. See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | | \ \ \ \ `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-precertificate-signing-ca-extensions) | @@ -1976,16 +1978,16 @@ A Precertificate Signing CA MUST only be used to sign Precertificates, as define | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | ##### 7.1.2.4.2 Extended Key Usage @@ -2014,7 +2016,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -2026,16 +2028,16 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.9.7](#71297-extended-key-usage---tls-ca) (TLS CA) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | | `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | ##### 7.1.2.5.2 Name Constraints @@ -2089,7 +2091,7 @@ Table: `otherName` requirements within a `GeneralName` | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -2101,16 +2103,16 @@ Table: `otherName` requirements within a `GeneralName` | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.9.3](#71293-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.9.4](#71294-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.9.8](#71298-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.9.7](#71297-extended-key-usage---tls-ca) (TLS CA) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.9.2](#71292-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.9.9](#71299-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | #### 7.1.2.7 Subscriber (Server) Certificate Profile @@ -2244,17 +2246,17 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-authority-information-access) | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-certificate-policies) | | `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-extended-key-usage) | | `subjectAltName` | MUST | - | See [Section 7.1.2.7.12](#712712-subject-alternative-name) | | `nameConstraints` | MUST NOT | - | - | | `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-key-usage) | | `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-basic-constraints) | -| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | +| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | CA/Browser Forum Onion Extension | MAY | N | __**TODO**__ | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | -| `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | Any other extension | SHOULD NOT | - | __**TBD**__ | ##### 7.1.2.7.7 Authority Information Access @@ -2366,7 +2368,7 @@ Table: `GeneralName` within a `subjectAltName` extension #### 7.1.2.8 OCSP Responder Certificate Profile -If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as definied by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. +If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. | __Field__ | __Description__ | | --- | ------ | @@ -2376,7 +2378,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | __**TBD**__ | -| \ \ \ \ `subject` | See [Section 7.1.2.9.1](#71291-ca-certificate-naming) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -2388,20 +2390,20 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.10.1](#712101-authority-key-identifier) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `extKeyUsage` | MUST | - | See [Section 7.1.2.8.4](#71284-extended-key-usage) | | `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.5](#71285-id-pkix-ocsp-nocheck) | | `keyUsage` | MUST | Y | See [Section 7.1.2.8.6](#71286-key-usage) | | `basicConstraints` | MAY | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | | `nameConstraints` | MUST NOT | - | - | | `subjectAltName` | MUST NOT | - | - | -| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.10.4](#712104-subject-key-identifier) | +| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `authorityInformationAccess` | SHOULD NOT | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | | `certificatePolicies` | - | - | - | | \ \ \ \ _Prior to 2022-02-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | | \ \ \ \ _Effective 2022-02-01_ | MUST NOT | - | - | -| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.10.2](#712102-crl-distribution-points) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.10.3](#712103-signed-certificate-timestamp-list) | +| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | __**TBD**__ | ##### 7.1.2.8.2 Authority Information Access @@ -2474,11 +2476,102 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -#### 7.1.2.9 Common CA Fields +#### 7.1.2.9 Precertificate Profile + +A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of an equivalent Certificate also existing, as the signature represents a binding committment by the CA that it may issue such a Certificate. + +A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate to be equivalent to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate's `extensions` field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate. + +Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue an equivalent Certificate, or more commonly, that an equivalent Certificate exists. A Certificate is said to be equivalent to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). + +This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue an equivalent Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the equivalent Certificate conforms to these Baseline Requirements, regardless of whether they sign the equivalent Certificate. + +A Precertificate may be issued either directly by the Issuing CA or by a Technically Constrained Precertificate Signing CA, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). If issued by a Precertificate Signing CA, then in addition to the precertificate poison and signed certificate timestamp list extensions, the Precertificate `issuer` field and, if present, `authorityKeyIdentifier` extension, may differ from the Certificate, as described below. + + +Table: When the Precertificate is issued directly by the Issuing CA + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | +| \ \ \ \ `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | +| \ \ \ \ `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | +| \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the `issuer` field of the Certificate | +| \ \ \ \ `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | +| \ \ \ \ `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | +| \ \ \ \ `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | +| \ \ \ \ `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +| \ \ \ \ `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +| \ \ \ \ `extensions` | See [Section 7.1.2.9.1](#71291-directly-issued-precertificate-profile-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + + +Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +| \ \ \ \ `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | +| \ \ \ \ `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | +| \ \ \ \ `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | +| \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the `subject` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) | +| \ \ \ \ `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | +| \ \ \ \ `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | +| \ \ \ \ `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | +| \ \ \ \ `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +| \ \ \ \ `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +| \ \ \ \ `extensions` | See [Section 7.1.2.9.2](#71292-precertificate-ca-issued-precertificate-profile-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +**Note:** This profile requires that the `serialNumber` field of the Precertificate be identical to that of the equivalent Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the equivalent Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they are byte-for-byte equivalent, as this would otherwise indicate there are equivalent Certificates that share the same `serialNumber`. + +##### 7.1.2.9.1 Directly Issued Precertificate Profile Extensions + +These extensions apply in the context of a Precertificate directly issued from a CA, and not from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) | +| Signed Certificate Timestamp List | MUST NOT | \* | | +| Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate | + +**Note:** This requirement is expressing that if the Precertificate Poison extension is removed from the Precertificate, and the Signed Certificate Timestamp List is removed from the certificate, the contents of the `extensions` field MUST be byte-for-byte identical to the Certificate. + +##### 7.1.2.9.2 Precertificate CA Issued Precertificate Profile Extensions + +These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). For such Precertificates, the `authorityKeyIdentifier`, if present in the Certificate, is modified in the Precertificate, as described in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) | +| `authorityKeyIdentifier` | \* | \* | See [Section 7.1.2.9.4](#71294-authority-key-identifier) | +| Signed Certificate Timestamp List | MUST NOT | \* | | +| Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate | + +##### 7.1.2.9.3 Precertificate Poison + +The Precertificate Poison extension is identified by the OID 1.3.6.1.4.1.11129.2.4.3. The contents of the extension's `extnValue` `OCTET STRING` MUST be byte-for-byte identical with the following hex-encoded bytes, `0500`, representing the encoded representation of a zero-length ASN.1 `NULL` value, as specified in [RFC 6962, Section 3.1](https://tools.ietf.org/doc/html/rfc6962#section-3.1). + +##### 7.1.2.9.4 Authority Key Identifier + +For Precertificates issued by a Precertificate Signing CA, the `authorityKeyIdentifier`, if present in the equivalent Certificate, MAY be modified to reflect the values of the Technically Constrained Precertificate Signing CA Certificate; for example, if the Precertificate Signing CA uses a different Key Pair than the Issuing CA it is acting on behalf of. + +If the `authorityKeyIdentifier` extension is present in the Certificate, then the Precertificate MUST contain an `authorityKeyIdentifier` in the same order within the extension sequence as the Certificate, ignoring the [Precertificate Poison](#71293-precertificate-poison) extension. It MUST be byte-for-byte identical in value to the `authorityKeyIdentifier` extension of the Certificate, or MAY be modified as defined below: + +| __Field__ | __Description__ | +| --- | ------- | +| `keyIdentifier` | MUST be present. MUST be identical to the `subjectKeyIdentifier` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) | +| `authorityCertIssuer` | MUST NOT be present | +| `authorityCertSerialNumber` | MUST NOT be present | + +#### 7.1.2.10 Common CA Fields This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). -##### 7.1.2.9.1 CA Certificate Naming +##### 7.1.2.10.1 CA Certificate Naming All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2496,7 +2589,7 @@ The following table details the acceptable `AttributeType`s that may appear with | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | | Any other attribute | SHOULD NOT | __**TBD**__ | | -##### 7.1.2.9.2 Authority Information Access +##### 7.1.2.10.2 Authority Information Access If present, the `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. @@ -2508,14 +2601,14 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.9.3 Basic Constraints +##### 7.1.2.10.3 Basic Constraints | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be set TRUE | | `pathLenConstraint` | MAY be present | -##### 7.1.2.9.4 Certificate Policies - Affiliated CA +##### 7.1.2.10.4 Certificate Policies - Affiliated CA The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by an organization that is the same as the organization operating the Issuing CA or that is an Affiliate of the organization operating the Issuing CA. @@ -2547,7 +2640,7 @@ Table: Policy Restricted | \ \ \ \ `policyQualifiers` | MUST NOT | | | \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | -##### 7.1.2.9.5 Certificate Policies - Non-Affiliated CA +##### 7.1.2.10.5 Certificate Policies - Non-Affiliated CA The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by a CA that is an not an Affiliate of the Issuing CA. @@ -2574,7 +2667,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.9.6 Extended Key Usage - Non-TLS CA +##### 7.1.2.10.6 Extended Key Usage - Non-TLS CA The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) SHOULD NOT be present. @@ -2590,7 +2683,7 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | Any other value | - | MAY | -##### 7.1.2.9.7 Extended Key Usage - TLS CA +##### 7.1.2.10.7 Extended Key Usage - TLS CA | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2604,7 +2697,7 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | Any other value | - | SHOULD NOT | -##### 7.1.2.9.8 Key Usage +##### 7.1.2.10.8 Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2620,7 +2713,7 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to [^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information. -##### 7.1.2.9.9 Name Constraints +##### 7.1.2.10.9 Name Constraints If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. @@ -2651,11 +2744,11 @@ Table: `GeneralName` requirements for the `base` field | `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | | Any other value | SHOULD NOT | - | - | -#### 7.1.2.10 Common Certificate Fields +#### 7.1.2.11 Common Certificate Fields This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). -##### 7.1.2.10.1 Authority Key Identifier +##### 7.1.2.11.1 Authority Key Identifier | __Field__ | __Description__ | | --- | ------- | @@ -2663,7 +2756,7 @@ This section contains several fields that are common among multiple certificate | `authorityCertIssuer` | MUST NOT be present | | `authorityCertSerialNumber` | MUST NOT be present | -##### 7.1.2.10.2 CRL Distribution Points +##### 7.1.2.11.2 CRL Distribution Points If present, the CRL Distribution Points extension MUST be formatted as follows: @@ -2693,19 +2786,19 @@ Table: `fullName` profile | \ \ \ \ `uniformResourceIdentifier` | MUST | If present, the scheme of the `uniformResourceIdentifier` MUST be "http". | | \ \ **3** | MUST NOT | `GeneralName`s that do not conform to the above requirements MUST NOT be present. | -##### 7.1.2.10.3 Signed Certificate Timestamp List +##### 7.1.2.11.3 Signed Certificate Timestamp List If present, the Signed Certificate Timestamp List extension contents MUST be an `OCTET STRING` containing the encoded `SignedCertificateTimestampList`, as specified in [RFC 6962, Section 3.3](https://tools.ietf.org/html/rfc6962#section-3.3). Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestampList` MUST be for a `PreCert` `LogEntryType` that corresponds to the current certificate. -##### 7.1.2.10.4 Subject Key Identifier +##### 7.1.2.11.4 Subject Key Identifier If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). CAs MUST generate a unique `subjectKeyIdentifier` for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs MAY generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. #### 7.1.2.5 TO DELETE All Certificates -**TODO: Integrate into 7.1.2.10 as the catch-all for all certificates (currently listed TBD)** +**TODO: Integrate into 7.1.2.11 as the catch-all for all certificates (currently listed TBD)** All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a `keyUsage` flag, `extKeyUsage` value, Certificate extension, or other data not specified in [Section 7.1.2](#712-certificate-content-and-extensions) unless the CA is aware of a reason for including the data in the Certificate. From cb286812bb09ea662e7fc38a206439e56fa8de69 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 10:58:05 -0500 Subject: [PATCH 15/54] 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. --- docs/BR.md | 44 +++++++++++++++++++++++++++++++++++++------- 1 file changed, 37 insertions(+), 7 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index bda8c321..1a4d32c7 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1790,7 +1790,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | -| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `validity` | See [Section 7.1.2.1.x](#7121x-root-ca-validity) | | \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | @@ -1799,6 +1799,15 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | +##### 7.1.2.1.x Root CA Validity + +| __Field__ | __Minimum__ | __Maximum__ | +| - | ---- | ---- | +| `notBefore` | One day prior to the time of signing | The time of signing | +| `notAfter` | 2922 days (e.g. 8 years) | 9132 days (e.g. 25 years) | + +**Note**: This restriction applies even in the event of generating a new Root CA Certificate for an existing `subject` and `subjectPublicKeyInfo` (e.g. reissuance). The new CA Certificate MUST conform to these rules. + ##### 7.1.2.1.1 Root CA Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | @@ -1842,7 +1851,7 @@ __**TBD: Remarks about audits**__ | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `validity` | See [Section 7.1.2.2.x](#7122x-cross-certified-subordinate-ca-validity) | | \ \ \ \ `subject` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | @@ -1851,6 +1860,13 @@ __**TBD: Remarks about audits**__ | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | +##### 7.1.2.2.x Cross-Certified Subordinate CA Validity + +| __Field__ | __Minimum__ | __Maximum__ | +| -- | ---- | ---- | +| `notBefore` | The earlier of one day prior to the time of signing or the earliest `notBefore` date of the existing CA Certificate(s) | The time of signing | +| `notAfter` | The time of signing | Unspecified | + ##### 7.1.2.2.1 Cross-Certified Subordinate CA Naming Provided that the Issuing CA has confirmed that the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the Issuing CA MAY deviate from the requirements in [Section 7.1.4](#714-name-forms) as follows: @@ -1925,7 +1941,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | | \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | @@ -1965,7 +1981,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | | \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the `subjectPublicKeyInfo` field of the Issuing CA. See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | @@ -2015,7 +2031,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | | \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | @@ -2090,7 +2106,7 @@ Table: `otherName` requirements within a `GeneralName` | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | | \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | @@ -2377,7 +2393,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | __**TBD**__ | +| \ \ \ \ `validity` | See [Section 7.1.2.8.x](#7128x-ocsp-responder-validity) | | \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | @@ -2386,6 +2402,13 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | +##### 7.1.2.8.x OCSP Responder Validity + +| __Field__ | __Minimum__ | __Maximum__ | +| -- | ---- | ---- | +| `notBefore` | One day prior to the time of signing | The time of signing | +| `notAfter` | The time of signing | Unspecified | + ##### 7.1.2.8.1 OCSP Responder Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | @@ -2571,6 +2594,13 @@ If the `authorityKeyIdentifier` extension is present in the Certificate, then th This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). +##### 7.1.2.10.x CA Certificate Validity + +| __Field__ | __Minimum__ | __Maximum__ | +| -- | ---- | ---- | +| `notBefore` | One day prior to the time of signing | The time of signing | +| `notAfter` | The time of signing | Unspecified | + ##### 7.1.2.10.1 CA Certificate Naming All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). From 57552a75d754ad643dacdddcfe58f5401b4e7e57 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 11:03:26 -0500 Subject: [PATCH 16/54] 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. --- docs/BR.md | 115 +++++++++++++++++++++++++++++++++-------------------- 1 file changed, 72 insertions(+), 43 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 1a4d32c7..0d311209 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1760,7 +1760,7 @@ Certificates MUST be of type X.509 v3. ### 7.1.2 Certificate Content and Extensions -If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles: +If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280](https://tools.ietf.org/doc/html/rfc5280#appendix-B) for further issues to be aware of. * CA Certificates * [Section 7.1.2.1.- Root CA Certificate Profile](#7121-root-ca-certificate-profile) @@ -1819,7 +1819,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | `extKeyUsage` | MUST NOT | N | - | | `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.10 4](#712104-certificate-policies---affiliated-ca) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.1.2 Authority Key Identifier @@ -1891,7 +1891,7 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | Table: Extensions when the Subordinate CA is operated by an entity that is not the Issuing CA or an Affiliate of the Issuing CA. @@ -1907,7 +1907,7 @@ Table: Extensions when the Subordinate CA is operated by an entity that is not t | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. @@ -1930,6 +1930,16 @@ Alternatively, if the Issuing CA does not use this form, then the Extended Key U If present, the Extended Key Usage extension MUST only contain key usage purposes for which the Issuing CA has verified the Cross-Certified Subordinate CA is authorized to assert. +Each included Extended Key Usage key usage purpose: + + 1. MUST apply in the context of the public Internet (e.g. MUST NOT be for a service that is only valid in a privately managed network), unless: + a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or, + b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context. + 2. MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance. + 3. MUST NOT be included unless the Certificate conforms to the relevant specification defining the key usage purpose. + +CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate. + #### 7.1.2.3 Technically Constrained Non-TLS Subordinate CA Certificate Profile This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively. @@ -1964,7 +1974,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | #### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile @@ -2004,22 +2014,19 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.4.2 Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MUST NOT | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | | Any other value | - | SHOULD NOT | +CAs SHOULD NOT include additional key usage purposes beyond those specified in the table above. If present, they SHOULD be equal to, or a subset of, the key usage purposes for the Issuing CA Certificate. + +Any additional key usage purposes MUST conform to the requirements and restrictions specified in [Section 7.1.2.2.4, Extended Key Usage - Restricted Cross-Certified CA](#71224-extended-key-usage---restricted-cross-certified-ca). + #### 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively. @@ -2054,7 +2061,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.5.2 Name Constraints @@ -2086,7 +2093,7 @@ Table: `GeneralName` requirements for the `base` field | `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | | `rfc822Name` | SHOULD NOT | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | | `otherName` | SHOULD NOT | See following table. | See following table. | See following table. | -| Any other value | SHOULD NOT | - | - | - | +| Any other value | MUST NOT | - | - | - | When an `otherName` is present within a `GeneralName` present in the `base` of a `nameConstraints` `permittedSubtrees` or `excludedSubtrees`, it MUST meet the following requirements: @@ -2097,6 +2104,15 @@ Table: `otherName` requirements within a `GeneralName` | `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | SHOULD NOT | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | | Any other value | SHOULD NOT | - | - | - | +All other `otherName` `type-id`s other than those listed above: + 1. MUST apply in the context of the public Internet, unless: + a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, + b. the Applicant can otherwise demonstrate the right to assert the data in a public context. + 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. + 3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. + +CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate. + #### 7.1.2.6 TLS Subordinate CA Certificate Profile | __Field__ | __Description__ | @@ -2129,7 +2145,7 @@ Table: `otherName` requirements within a `GeneralName` | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | #### 7.1.2.7 Subscriber (Server) Certificate Profile @@ -2184,7 +2200,7 @@ Table: Domain Validated `subject` Attributes | --- | - | ------ | -- | | `countryName` | MAY | The two-letter ISO 3166-1 country code for the country associated with the Subject. | [Section 3.2.2.3](#3223-verification-of-country) | | `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | MUST NOT | __**TBD**__ | | +| Any other attribute | MUST NOT | - | - | ##### 7.1.2.7.3 Individual Validated @@ -2214,7 +2230,7 @@ Table: Individual Validated `subject` Attributes | `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `organizationalUnitName` | SHOULD NOT | __**TBD**__ | __**TBD**__ | | `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | SHOULD NOT | __**TBD**__ | __**TBD**__ | +| Any other attribute | SHOULD NOT | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | ##### 7.1.2.7.4 Organization Validated @@ -2240,11 +2256,11 @@ Table: Individual Validated `subject` Attributes | `postalCode` | SHOULD NOT | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | | `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | -| `surname` | MUST NOT | | | -| `givenName` | MUST NOT | | | +| `surname` | MUST NOT | - | - | +| `givenName` | MUST NOT | - | - | | `organizationalUnitName` | SHOULD NOT | __**TBD**__ | __**TBD**__ | | `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | SHOULD NOT | __**TBD**__ | __**TBD**__ | +| Any other attribute | SHOULD NOT | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | ##### 7.1.2.7.5 Extended Validation @@ -2273,7 +2289,7 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | CA/Browser Forum Onion Extension | MAY | N | __**TODO**__ | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.7.7 Authority Information Access @@ -2427,7 +2443,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | \ \ \ \ _Effective 2022-02-01_ | MUST NOT | - | - | | `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | __**TBD**__ | +| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.8.2 Authority Information Access @@ -2442,7 +2458,7 @@ If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `Ac ##### 7.1.2.8.3 Basic Constraints -OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. When using DER encoding, the encoded value of a `BasicConstraints` sequence is an empty SEQUENCE, as DEFAULT values are not encoded. +OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. | __Field__ | __Description__ | | --- | ------- | @@ -2549,7 +2565,7 @@ Table: When the Precertificate is issued by a Precertificate Signing CA on behal | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -**Note:** This profile requires that the `serialNumber` field of the Precertificate be identical to that of the equivalent Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the equivalent Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they are byte-for-byte equivalent, as this would otherwise indicate there are equivalent Certificates that share the same `serialNumber`. +**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the equivalent Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the equivalent Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they are byte-for-byte equivalent, as this would otherwise indicate there are equivalent Certificates that share the same `serialNumber`. ##### 7.1.2.9.1 Directly Issued Precertificate Profile Extensions @@ -2617,7 +2633,7 @@ The following table details the acceptable `AttributeType`s that may appear with | `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | | `organizationalUnitName` | SHOULD NOT | __**TBD**__ | | | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | -| Any other attribute | SHOULD NOT | __**TBD**__ | | +| Any other attribute | SHOULD NOT | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | ##### 7.1.2.10.2 Authority Information Access @@ -2772,8 +2788,30 @@ Table: `GeneralName` requirements for the `base` field | `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | | `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | | `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | +| `rfc822Name` | SHOULD NOT | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | +| `otherName` | SHOULD NOT | See following table. | See following table. | See following table. | | Any other value | SHOULD NOT | - | - | +When an `otherName` is present within a `GeneralName` present in the `base` of a `nameConstraints` `permittedSubtrees` or `excludedSubtrees`, it MUST meet the following requirements: + +Table: `otherName` requirements within a `GeneralName` + +| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | +| --- | - | ---- | ---- | ---- | +| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | SHOULD NOT | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | +| Any other value | SHOULD NOT | - | - | - | + +All other `otherName` `type-id`s other than those listed above: + 1. MUST apply in the context of the public Internet, unless: + a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, + b. the Applicant can otherwise demonstrate the right to assert the data in a public context. + 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. + 3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. + +CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate. + + + #### 7.1.2.11 Common Certificate Fields This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). @@ -2826,26 +2864,17 @@ Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestam If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). CAs MUST generate a unique `subjectKeyIdentifier` for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs MAY generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. -#### 7.1.2.5 TO DELETE All Certificates - -**TODO: Integrate into 7.1.2.11 as the catch-all for all certificates (currently listed TBD)** - -All other fields and extensions MUST be set in accordance with RFC 5280. The CA SHALL NOT issue a Certificate that contains a `keyUsage` flag, `extKeyUsage` value, Certificate extension, or other data not specified in [Section 7.1.2](#712-certificate-content-and-extensions) unless the CA is aware of a reason for including the data in the Certificate. - -CAs SHALL NOT issue a Certificate with: - -a. Extensions that do not apply in the context of the public Internet (such as an extKeyUsage value for a service that is only valid in the context of a privately managed network), unless: - i. such value falls within an OID arc for which the Applicant demonstrates ownership, or - ii. the Applicant can otherwise demonstrate the right to assert the data in a public context; or -b. semantics that, if included, will mislead a Relying Party about the certificate information verified by the CA (such as including an `extKeyUsage` value for a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance). - -#### 7.1.2.6 TO DELETE Application of RFC 5280 +##### 7.1.2.11.5 Other Extensions -**TODO: Move this text into 7.1.2 requirements** +All extensions and extension values not directly addressed by the applicable certificate profile: -Except where explicitly noted, all certificates MUST conform to the certificate profile of RFC 5280. The following requirements are noted in addition to any normative requirements placed within RFC 5280. In particular, CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further discussion of normative requirements imposed by RFC 5280 and its normative dependencies. + 1. MUST apply in the context of the public Internet, unless: + a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, + b. the Applicant can otherwise demonstrate the right to assert the data in a public context. + 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA (such as including an extension that indicates a Private Key is stored on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance). + 3. MUST be DER encoded according to the relevant ASN.1 module defining the extension and extension values. -For purposes of clarification, a Precertificate, as described in [RFC 6962 - Certificate Transparency](https://tools.ietf.org/html/rfc6962), shall not be considered to be a "certificate" subject to the requirements of [RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile](https://tools.ietf.org/html/rfc5280) under these Baseline Requirements. +CAs SHALL NOT include additional extensions or values unless the CA is aware of a reason for including the data in the Certificate. ### 7.1.3 Algorithm object identifiers From a2af324463c8dab02a2b15426c03b45276b8b5ef Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 11:04:39 -0500 Subject: [PATCH 17/54] Fix the certificatePolicies mismatched highlighted by Corey --- docs/BR.md | 31 ++++++++++++++++++++++++++++--- 1 file changed, 28 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 0d311209..91591c4d 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1966,7 +1966,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#71232-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | @@ -1976,6 +1976,31 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +##### 7.1.2.3.2 Certificate Policies + +If present, the Certificate Policies extension MUST be one of the following two formats: + +Table: No Policy Restrictions + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | | The first `PolicyInformation` present in the `certificatePolicies`. | +| \ \ \ \ `policyIdentifier` | MUST | The `anyPolicy` (OID: 2.5.29.32.0) identifier. | +| \ \ \ \ `policyQualifiers` | MUST NOT | | +| \ \ **2** | MUST NOT | When the `anyPolicy` policy is present, the CA MUST NOT include any further `PolicyInformation` values. | + + +Table: Policy Restricted + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1+** | MAY | The CA MAY include one or more `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | MUST NOT | | +| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | + #### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in [RFC 6962, Section 3.1](https://tools.ietf.org/html/rfc6962#section-3.1). If a CA Certificate conforms to this profile, it is considered Technically Constrained. @@ -2439,8 +2464,8 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `authorityInformationAccess` | SHOULD NOT | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | | `certificatePolicies` | - | - | - | -| \ \ \ \ _Prior to 2022-02-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | -| \ \ \ \ _Effective 2022-02-01_ | MUST NOT | - | - | +| \ \ \ \ _Prior to 2022-04-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | +| \ \ \ \ _Effective 2022-04-01_ | MUST NOT | - | - | | `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | From ad4f121f5e6742ee67794bf0423c8f0245dc2ae0 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 11:06:59 -0500 Subject: [PATCH 18/54] Formatting and plurality fixup --- docs/BR.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 91591c4d..c69ffa0f 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1838,9 +1838,9 @@ If the CA asserts compliance with these Baseline Requirements, all certificates #### 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile -This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as an existing CA Certificate, whether a Root CA Certificate or Subordinate CA Certificate. +This Certificate Profile MAY be used when issuing a CA Certificate using the same Subject Name and Subject Public Key Information as one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate. -Before issuing a CA Certificate using this Profile, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance. +Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance. __**TBD: Remarks about audits**__ @@ -2599,10 +2599,10 @@ These extensions apply in the context of a Precertificate directly issued from a | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) | -| Signed Certificate Timestamp List | MUST NOT | \* | | +| Signed Certificate Timestamp List | MUST NOT | - | | | Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate | -**Note:** This requirement is expressing that if the Precertificate Poison extension is removed from the Precertificate, and the Signed Certificate Timestamp List is removed from the certificate, the contents of the `extensions` field MUST be byte-for-byte identical to the Certificate. +**Note**: This requirement is expressing that if the Precertificate Poison extension is removed from the Precertificate, and the Signed Certificate Timestamp List is removed from the certificate, the contents of the `extensions` field MUST be byte-for-byte identical to the Certificate. ##### 7.1.2.9.2 Precertificate CA Issued Precertificate Profile Extensions @@ -2612,7 +2612,7 @@ These extensions apply in the context of a Precertificate from a Precertificate | ---- | - | - | ----- | | Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) | | `authorityKeyIdentifier` | \* | \* | See [Section 7.1.2.9.4](#71294-authority-key-identifier) | -| Signed Certificate Timestamp List | MUST NOT | \* | | +| Signed Certificate Timestamp List | MUST NOT | - | | | Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate | ##### 7.1.2.9.3 Precertificate Poison From 24b3d5d51e7be30bec3f1aafbd4f8381fc6ac430 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:25 -0400 Subject: [PATCH 19/54] 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. --- docs/BR.md | 494 ++++++++++++++++++++++++++--------------------------- 1 file changed, 247 insertions(+), 247 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index c69ffa0f..7c0b82ec 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1810,16 +1810,16 @@ If the CA asserts compliance with these Baseline Requirements, all certificates ##### 7.1.2.1.1 Root CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityKeyIdentifier` | SHOULD | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.3](#71213-basic-constraints) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST NOT | N | - | -| `certificatePolicies` | SHOULD NOT | N | See [Section 7.1.2.10 4](#712104-certificate-policies---affiliated-ca) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.3](#71213-basic-constraints) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST NOT | N | - | +| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10 4](#712104-certificate-policies---affiliated-ca) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.1.2 Authority Key Identifier @@ -1834,7 +1834,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be set TRUE | -| `pathLenConstraint` | SHOULD NOT be present | +| `pathLenConstraint` | NOT RECOMMENDED | #### 7.1.2.2 Cross-Certified Subordinate CA Certificate Profile @@ -1891,23 +1891,23 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | Table: Extensions when the Subordinate CA is operated by an entity that is not the Issuing CA or an Affiliate of the Issuing CA. -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---restricted-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---restricted-cross-certified-ca) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. @@ -1962,19 +1962,19 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be ##### 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#71232-certificate-policies) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.5](#712106-extended-key-usage---non-tls-ca) (Non-TLS CA) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#71232-certificate-policies) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.5](#712106-extended-key-usage---non-tls-ca) (Non-TLS CA) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.3.2 Certificate Policies @@ -2027,28 +2027,28 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is ##### 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.4.2 Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST | -| Any other value | - | SHOULD NOT | +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST | +| Any other value | - | NOT RECOMMENDED | -CAs SHOULD NOT include additional key usage purposes beyond those specified in the table above. If present, they SHOULD be equal to, or a subset of, the key usage purposes for the Issuing CA Certificate. +CAs are NOT RECOMMENDED to include additional key usage purposes beyond those specified in the table above. If present, they SHOULD be equal to, or a subset of, the key usage purposes for the Issuing CA Certificate. Any additional key usage purposes MUST conform to the requirements and restrictions specified in [Section 7.1.2.2.4, Extended Key Usage - Restricted Cross-Certified CA](#71224-extended-key-usage---restricted-cross-certified-ca). @@ -2074,19 +2074,19 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be ##### 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | -| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | +| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.5.2 Name Constraints @@ -2101,7 +2101,7 @@ Table: `nameConstraints` requirements | \ \ \ \ \ \ \ \ `base` | See following table. | | \ \ \ \ \ \ \ \ `minimum` | MUST NOT be present. | | \ \ \ \ \ \ \ \ `maximum` | MUST NOT be present. | -| `excludedSubtrees` | The `excludedSubtrees` MUST contain at least one `GeneralSubtree` for each of the `dNSName` and `iPAddress` `GeneralName` name types, unless there is an instance present of that name type in the `permittedSubtrees`. The `directoryName` name type SHOULD NOT be present. | +| `excludedSubtrees` | The `excludedSubtrees` MUST contain at least one `GeneralSubtree` for each of the `dNSName` and `iPAddress` `GeneralName` name types, unless there is an instance present of that name type in the `permittedSubtrees`. The `directoryName` name type is NOT RECOMMENDED. | | \ \ \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | | \ \ \ \ \ \ \ \ `base` | See following table. | | \ \ \ \ \ \ \ \ `minimum` | MUST NOT be present. | @@ -2115,19 +2115,19 @@ Table: `GeneralName` requirements for the `base` field | --- | - | ---- | ---- | ---- | | `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | | `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | -| `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | -| `rfc822Name` | SHOULD NOT | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | -| `otherName` | SHOULD NOT | See following table. | See following table. | See following table. | +| `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | +| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | +| `otherName` | NOT RECOMMENDED | See following table. | See following table. | See following table. | | Any other value | MUST NOT | - | - | - | When an `otherName` is present within a `GeneralName` present in the `base` of a `nameConstraints` `permittedSubtrees` or `excludedSubtrees`, it MUST meet the following requirements: Table: `otherName` requirements within a `GeneralName` -| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | -| --- | - | ---- | ---- | ---- | -| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | SHOULD NOT | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | -| Any other value | SHOULD NOT | - | - | - | +| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | +| --- | - | ---- | ---- | ---- | +| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | NOT RECOMMENDED | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | +| Any other value | NOT RECOMMENDED | - | - | - | All other `otherName` `type-id`s other than those listed above: 1. MUST apply in the context of the public Internet, unless: @@ -2158,19 +2158,19 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in ##### 7.1.2.6.1 TLS Subordinate CA Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | #### 7.1.2.7 Subscriber (Server) Certificate Profile @@ -2221,11 +2221,11 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Domain Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | -| --- | - | ------ | -- | -| `countryName` | MAY | The two-letter ISO 3166-1 country code for the country associated with the Subject. | [Section 3.2.2.3](#3223-verification-of-country) | -| `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | MUST NOT | - | - | +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MAY | The two-letter ISO 3166-1 country code for the country associated with the Subject. | [Section 3.2.2.3](#3223-verification-of-country) | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | MUST NOT | - | - | ##### 7.1.2.7.3 Individual Validated @@ -2243,19 +2243,19 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Individual Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | -| --- | - | ------ | -- | -| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `postalCode` | SHOULD NOT | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `organizationName` | SHOULD NOT | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `organizationalUnitName` | SHOULD NOT | __**TBD**__ | __**TBD**__ | -| `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | SHOULD NOT | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationalUnitName` | NOT RECOMMENDED | __**TBD**__ | __**TBD**__ | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | ##### 7.1.2.7.4 Organization Validated @@ -2273,19 +2273,19 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Individual Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | -| --- | - | ------ | -- | -| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | -| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | -| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | -| `postalCode` | SHOULD NOT | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | -| `streetAddress` | SHOULD NOT | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | -| `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | -| `surname` | MUST NOT | - | - | -| `givenName` | MUST NOT | - | - | -| `organizationalUnitName` | SHOULD NOT | __**TBD**__ | __**TBD**__ | -| `commonName` | SHOULD NOT | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | SHOULD NOT | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | +| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | +| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | +| `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `surname` | MUST NOT | - | - | +| `givenName` | MUST NOT | - | - | +| `organizationalUnitName` | NOT RECOMMENDED | __**TBD**__ | __**TBD**__ | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | ##### 7.1.2.7.5 Extended Validation @@ -2300,21 +2300,21 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the ##### 7.1.2.7.6 Subscriber Certificate Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-authority-information-access) | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-certificate-policies) | -| `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-extended-key-usage) | -| `subjectAltName` | MUST | - | See [Section 7.1.2.7.12](#712712-subject-alternative-name) | -| `nameConstraints` | MUST NOT | - | - | -| `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-key-usage) | -| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-basic-constraints) | -| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| CA/Browser Forum Onion Extension | MAY | N | __**TODO**__ | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| `subjectKeyIdentifier` | SHOULD NOT | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-authority-information-access) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-certificate-policies) | +| `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-extended-key-usage) | +| `subjectAltName` | MUST | - | See [Section 7.1.2.7.12](#712712-subject-alternative-name) | +| `nameConstraints` | MUST NOT | - | - | +| `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-basic-constraints) | +| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| CA/Browser Forum Onion Extension | MAY | N | __**TODO**__ | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.7.7 Authority Information Access @@ -2337,16 +2337,16 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s ##### 7.1.2.7.9 Certificate Policies -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types). | -| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | -| \ \ **2+** | MAY | The Issuing CA MAY include additional `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the Issuing CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | -| \ \ **3** | MUST NOT | The Issuing CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | +| \ \ \ \ `policyIdentifier` | | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types). | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | +| \ \ **2+** | MAY | The Issuing CA MAY include additional `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the Issuing CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | +| \ \ **3** | MUST NOT | The Issuing CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: @@ -2357,17 +2357,17 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` ##### 7.1.2.7.10 Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | -| Any other value | - | SHOULD NOT | +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | +| Any other value | - | NOT RECOMMENDED | ##### 7.1.2.7.11 Key Usage @@ -2387,7 +2387,7 @@ Table: Key Usage for RSA Public Keys | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm MAY choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this SHOULD NOT be done by default. +**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this is NOT RECOMMENDED. Table: Key Usage for ECC Public Keys @@ -2452,34 +2452,34 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O ##### 7.1.2.8.1 OCSP Responder Extensions -| __Extension__ | __Presence__ | __Critical__ | __Description__ | -| ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.4](#71284-extended-key-usage) | -| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.5](#71285-id-pkix-ocsp-nocheck) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.6](#71286-key-usage) | -| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | -| `nameConstraints` | MUST NOT | - | - | -| `subjectAltName` | MUST NOT | - | - | -| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `authorityInformationAccess` | SHOULD NOT | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | -| `certificatePolicies` | - | - | - | -| \ \ \ \ _Prior to 2022-04-01_ | SHOULD NOT | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | -| \ \ \ \ _Effective 2022-04-01_ | MUST NOT | - | - | -| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | SHOULD NOT | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.4](#71284-extended-key-usage) | +| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.5](#71285-id-pkix-ocsp-nocheck) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.6](#71286-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | +| `nameConstraints` | MUST NOT | - | - | +| `subjectAltName` | MUST NOT | - | - | +| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | +| `certificatePolicies` | - | - | - | +| \ \ \ \ _Prior to 2022-04-01_ | NOT RECOMMENDED | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | +| \ \ \ \ _Effective 2022-04-01_ | MUST NOT | - | - | +| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.8.2 Authority Information Access -For OCSP Responder certificates, this extension SHOULD NOT be present, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties. +For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties. If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. -| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | -| -- | -- | ---- | - | - | --- | -| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | SHOULD NOT | \* | A HTTP URL of the Issuing CA's OCSP responder. | -| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | +| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| -- | -- | ---- | - | - | --- | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | ##### 7.1.2.8.3 Basic Constraints @@ -2525,13 +2525,13 @@ This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960 If present, the Certificate Policies extension MUST be formatted as follows: -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | MAY | The CA MAY include one or more `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | -| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | MAY | The CA MAY include one or more `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | +| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: @@ -2648,17 +2648,17 @@ All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-fo The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | -| --- | - | ------ | -- | -| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) | -| `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) | -| `localityName` | MAY | If present, the CA's locality. | [Section 3.2.2.1](#3221-identity) | -| `postalCode` | MAY | If present, the CA's zip or postal information. | [Section 3.2.2.1](#3221-identity) | -| `streetAddress` | MAY | If present, the CA's street address. Multiple instances MAY be present. | [Section 3.2.2.1](#3221-identity) | -| `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | -| `organizationalUnitName` | SHOULD NOT | __**TBD**__ | | -| `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | -| Any other attribute | SHOULD NOT | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) | +| `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) | +| `localityName` | MAY | If present, the CA's locality. | [Section 3.2.2.1](#3221-identity) | +| `postalCode` | MAY | If present, the CA's zip or postal information. | [Section 3.2.2.1](#3221-identity) | +| `streetAddress` | MAY | If present, the CA's street address. Multiple instances MAY be present. | [Section 3.2.2.1](#3221-identity) | +| `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `organizationalUnitName` | NOT RECOMMENDED | __**TBD**__ | | +| `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | ##### 7.1.2.10.2 Authority Information Access @@ -2717,19 +2717,19 @@ The following requirements apply to the Certificate Policies extension within CA If present, the Certificate Policies extension MUST be formatted as follows: -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | -| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | -| \ \ **2+** | SHOULD | The CA SHOULD include additional Reserved Certificate Policy Identifiers for each type of Subscriber certificate that may be issued beneath it. | -| \ \ \ \ `policyIdentifier` | MUST | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | -| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | -| \ \ **3+** | MAY | The CA MAY include additional `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | SHOULD NOT | See below for restrictions on `policyQualifiers` | -| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | +| \ \ \ \ `policyIdentifier` | | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | +| \ \ **2+** | SHOULD | The CA SHOULD include additional Reserved Certificate Policy Identifiers for each type of Subscriber certificate that may be issued beneath it. | +| \ \ \ \ `policyIdentifier` | MUST | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | +| \ \ **3+** | MAY | The CA MAY include additional `PolicyInformation` values that meet the following profile: | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | +| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: @@ -2740,7 +2740,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` ##### 7.1.2.10.6 Extended Key Usage - Non-TLS CA -The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) SHOULD NOT be present. +The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2756,17 +2756,17 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to ##### 7.1.2.10.7 Extended Key Usage - TLS CA -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | -| Any other value | - | SHOULD NOT | +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST | +| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | +| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MUST NOT | +| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MUST NOT | +| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | +| Any other value | - | NOT RECOMMENDED | ##### 7.1.2.10.8 Key Usage @@ -2808,23 +2808,23 @@ The following table contains the requirements for the `GeneralName` that appears Table: `GeneralName` requirements for the `base` field -| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | -| -- | - | ---- | ---- | -| `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | -| `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | -| `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | The CA SHOULD NOT include values within `excludedSubtrees`. | -| `rfc822Name` | SHOULD NOT | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | -| `otherName` | SHOULD NOT | See following table. | See following table. | See following table. | -| Any other value | SHOULD NOT | - | - | +| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | +| -- | - | ---- | ---- | +| `dNSName` | MAY | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | +| `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | +| `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | +| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | +| `otherName` | NOT RECOMMENDED | See following table. | See following table. | See following table. | +| Any other value | NOT RECOMMENDED | - | - | When an `otherName` is present within a `GeneralName` present in the `base` of a `nameConstraints` `permittedSubtrees` or `excludedSubtrees`, it MUST meet the following requirements: Table: `otherName` requirements within a `GeneralName` -| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | -| --- | - | ---- | ---- | ---- | -| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | SHOULD NOT | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | -| Any other value | SHOULD NOT | - | - | - | +| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | +| --- | - | ---- | ---- | ---- | +| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | NOT RECOMMENDED | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | +| Any other value | NOT RECOMMENDED | - | - | - | All other `otherName` `type-id`s other than those listed above: 1. MUST apply in the context of the public Internet, unless: @@ -2855,18 +2855,18 @@ If present, the CRL Distribution Points extension MUST be formatted as follows: Table: `CRLDistributionPoints` profile -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `CRLDistributionPoints` | | | -| \ \ **1** | MUST | The first `DistributionPoint` present in the `CRLDistributionPoints` | -| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | -| \ \ \ \ `reasons` | MUST NOT | | -| \ \ \ \ `cRLIssuer` | MUST NOT | | -| \ \ **2+** | SHOULD NOT | Additional `DistributionPoint`s SHOULD NOT be present. | -| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | -| \ \ \ \ `reasons` | MUST NOT | | -| \ \ \ \ `cRLIssuer` | MUST NOT | | -| \ \ **3** | MUST NOT | `DistributionPoints` that do not conform to the above requirements MUST NOT be present. | +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `CRLDistributionPoints` | | | +| \ \ **1** | MUST | The first `DistributionPoint` present in the `CRLDistributionPoints` | +| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | +| \ \ \ \ `reasons` | MUST NOT | | +| \ \ \ \ `cRLIssuer` | MUST NOT | | +| \ \ **2+** | NOT RECOMMENDED | Additional `DistributionPoint`s are NOT RECOMMENDED. | +| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | +| \ \ \ \ `reasons` | MUST NOT | | +| \ \ \ \ `cRLIssuer` | MUST NOT | | +| \ \ **3** | MUST NOT | `DistributionPoints` that do not conform to the above requirements MUST NOT be present. | Table: `fullName` profile From ebf167aece0156ce58befe757143bc3aea73b89f Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:31 -0400 Subject: [PATCH 20/54] 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 --- docs/BR.md | 30 ++++++++++++++++-------------- 1 file changed, 16 insertions(+), 14 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 7c0b82ec..dd3d93e5 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1869,9 +1869,9 @@ __**TBD: Remarks about audits**__ ##### 7.1.2.2.1 Cross-Certified Subordinate CA Naming -Provided that the Issuing CA has confirmed that the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the Issuing CA MAY deviate from the requirements in [Section 7.1.4](#714-name-forms) as follows: +The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-forms), or, if the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the encoded `subject` name MUST be byte-for-byte identical to the encoded `subject` name of the existing CA Certificate. -The encoded `subject` name shall be byte-for-byte identical to the encoded `subject` name of the existing CA Certificate. +**Note**: The above exception allows the CAs to issue Cross-Certified Subordinate CA Certificates, provided that the existing CA Certificate complied with the Baseline Requirements in force at time of issuance. This allows the requirements of [Section 7.1.4](#714-name-forms) to be improved over time, while still permitting Cross-Certification. If the existing CA Certificate did not comply, issuing a Cross-Certificate is not permitted. ##### 7.1.2.2.2 Cross-Certified Subordinate CA Extensions @@ -3035,20 +3035,22 @@ In addition, the following requirements apply to all Subject Attributes (i.e. th #### 7.1.4.1 Name Encoding -When encoding a `Name`, the CA SHALL ensure that: +The following requirements apply to all Certificates listed in [Section 7.1.2](#712-certificate-content-and-extensions). Specifically, this includes Technically Constrained Non-TLS Subordinate CA Certificates, as defined in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), but does not include certificates issued by such CA Certificates, as they are out of scope of these Baseline Requirements. + +For every valid Certification Path (as defined by [RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6)): + +* For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. +* For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates. + +Effective 2022-10-01, when encoding a `Name`, the CA SHALL ensure that: * Each `Name` MUST contain an `RDNSequence`. * Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`. * Each `RelativeDistinguishedName`, if present, is encoded within the `RDNSequence` in the order that it appears in [Section 7.1.4.2](#7142-subject-attribute-encoding). * For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`. - * Except where explicitly specified, each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s. + * Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s. -In addition to the above, the following requirements SHOULD be met by all newly-issued Technically Constrained Non-TLS Subordinate CA Certificates, as defined in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), and MUST be met for all other Certificates, regardless of whether the Certificate is a CA Certificate or a Subscriber Certificate. - -For every valid Certification Path (as defined by [RFC 5280, Section 6](https://tools.ietf.org/html/rfc5280#section-6)): - -* For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. -* For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to RFC 5280, Section 7.1, and including expired and revoked Certificates. +**Note**: [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-naming) provides an exception to the above `Name` encoding requirements when issuing a [Cross-Certified Subordinate CA Certificate](#7122-cross-certified-subordinate-ca-certificate-profile), as described within that section. #### 7.1.4.2 Subject Attribute Encoding @@ -3056,9 +3058,9 @@ This document defines requirements for the content and validation of a number of Table: Attribute Encoding and Order Requirements -| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | -| ---- | -- | --- | ---- | - | -| `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | | 2 | +| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | +| ---- | -- | --- | ---- | - | +| `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | | `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | | `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | | `postalCode` | `2.5.4.17` | X.520 | MUST use `UTF8String` or `PrintableString` | 40 | @@ -3078,7 +3080,7 @@ Table: Attribute Encoding and Order Requirements When explicitly stated as permitted by the relavant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). Before including such an attribute, the CA SHALL: - * Document the attributes within Section 7.1.4 of their CP/CPS, along with the applicable validation practices. + * Document the attributes within Section 7.1.4 of their CP or CPS, along with the applicable validation practices. * Ensure that the contents contain information that has been verified by the CA, independent of the Applicant. ### 7.1.6 Certificate policy object identifier From cb1eff333f730cb37881b0b977b5d21f5473a947 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:32 -0400 Subject: [PATCH 21/54] 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) --- docs/BR.md | 46 ++++++++++++++-------------------------------- 1 file changed, 14 insertions(+), 32 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index dd3d93e5..3328b477 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2111,27 +2111,19 @@ The following table contains the requirements for the `GeneralName` that appears Table: `GeneralName` requirements for the `base` field -| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | -| --- | - | ---- | ---- | ---- | -| `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | -| `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | -| `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | -| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | -| `otherName` | NOT RECOMMENDED | See following table. | See following table. | See following table. | -| Any other value | MUST NOT | - | - | - | - -When an `otherName` is present within a `GeneralName` present in the `base` of a `nameConstraints` `permittedSubtrees` or `excludedSubtrees`, it MUST meet the following requirements: - -Table: `otherName` requirements within a `GeneralName` +| __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | +| --- | - | ---- | ---- | ---- | +| `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | +| `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | +| `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | +| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | +| `otherName` | NOT RECOMMENDED | See below | See below | See below | +| Any other value | MUST NOT | - | - | - | -| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | -| --- | - | ---- | ---- | ---- | -| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | NOT RECOMMENDED | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | -| Any other value | NOT RECOMMENDED | - | - | - | +Any `otherName`, if present: -All other `otherName` `type-id`s other than those listed above: 1. MUST apply in the context of the public Internet, unless: - a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, + a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or, b. the Applicant can otherwise demonstrate the right to assert the data in a public context. 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. 3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. @@ -2814,29 +2806,19 @@ Table: `GeneralName` requirements for the `base` field | `iPAddress` | MAY | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | | `directoryName` | MAY | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | | `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | -| `otherName` | NOT RECOMMENDED | See following table. | See following table. | See following table. | -| Any other value | NOT RECOMMENDED | - | - | - -When an `otherName` is present within a `GeneralName` present in the `base` of a `nameConstraints` `permittedSubtrees` or `excludedSubtrees`, it MUST meet the following requirements: +| `otherName` | NOT RECOMMENDED | See below | See below | See below | +| Any other value | NOT RECOMMENDED | - | - | - | -Table: `otherName` requirements within a `GeneralName` +Any `otherName`, if present: -| __`type-id`__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | -| --- | - | ---- | ---- | ---- | -| `id-on-dnsSRV` (1.3.6.1.5.5.7.8.7) [RFC 4985](https://tools.ietf.org/html/rfc4985) | NOT RECOMMENDED | The CA MUST confirm that the Applicant has registered the `Name` portion or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `id-on-dnsSRV` `otherName` name is present in the `permittedSubtrees`, the CA MAY indicate one or more SRVNames, service names, or DNS names to exclude. | If no `id-on-dnsSRV` `otherName` is present in the `permittedSubtrees`, then the CA MAY include a zero-length `SRVName` to indicate no SRVNames are permitted. | -| Any other value | NOT RECOMMENDED | - | - | - | - -All other `otherName` `type-id`s other than those listed above: 1. MUST apply in the context of the public Internet, unless: - a. the extension OID falls within an OID arc for which the Applicant demonstrates ownership, or, + a. the `type-id` falls within an OID arc for which the Applicant demonstrates ownership, or, b. the Applicant can otherwise demonstrate the right to assert the data in a public context. 2. MUST NOT include semantics that will mislead the Relying Party about certificate information verified by the CA. 3. MUST be DER encoded according to the relevant ASN.1 module defining the `otherName` `type-id` and `value`. CAs SHALL NOT include additional names unless the CA is aware of a reason for including the data in the Certificate. - - #### 7.1.2.11 Common Certificate Fields This section contains several fields that are common among multiple certificate profiles. However, these fields may not be common among all certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). From e8eb51187408e9f1e3117a22e0911f0809c5593b Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:33 -0400 Subject: [PATCH 22/54] Formatting fix --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 3328b477..b20f21a6 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1933,8 +1933,8 @@ If present, the Extended Key Usage extension MUST only contain key usage purpose Each included Extended Key Usage key usage purpose: 1. MUST apply in the context of the public Internet (e.g. MUST NOT be for a service that is only valid in a privately managed network), unless: - a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or, - b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context. + a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or, + b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context. 2. MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance. 3. MUST NOT be included unless the Certificate conforms to the relevant specification defining the key usage purpose. From 69d6ee3ea1d78436b744e835f8264246c3d9da70 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:34 -0400 Subject: [PATCH 23/54] 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. --- docs/BR.md | 66 +++++++++++++++++++++++++----------------------------- 1 file changed, 31 insertions(+), 35 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index b20f21a6..d80e6f61 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1814,7 +1814,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | ---- | - | - | ----- | | `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.1.3](#71213-basic-constraints) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST NOT | N | - | | `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10 4](#712104-certificate-policies---affiliated-ca) | @@ -1885,11 +1885,11 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.3](#71223-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -1901,17 +1901,17 @@ Table: Extensions when the Subordinate CA is operated by an entity that is not t | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---restricted-cross-certified-ca) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. -[^name_constraints]: See [Section 7.1.2.10.9](#712109-name-constraints) for further requirements, including regarding criticality of this extension. +[^name_constraints]: See [Section 7.1.2.10.8](#712108-name-constraints) for further requirements, including regarding criticality of this extension. ##### 7.1.2.2.3 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA @@ -1968,11 +1968,11 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#71232-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.5](#712106-extended-key-usage---non-tls-ca) (Non-TLS CA) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-extended-key-usage)| | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2001,6 +2001,18 @@ Table: Policy Restricted | \ \ \ \ `policyQualifiers` | MUST NOT | | | \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +##### 7.1.2.3.3 Extended Key Usage + +The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | +| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | +| Any other value | - | MAY | + #### 7.1.2.4 Technically Constrained Precertificate Signing CA Certificate Profile This Certificate Profile MUST be used when issuing a CA Certificate that will be used as a Precertificate Signing CA, as described in [RFC 6962, Section 3.1](https://tools.ietf.org/html/rfc6962#section-3.1). If a CA Certificate conforms to this profile, it is considered Technically Constrained. @@ -2033,11 +2045,11 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2080,9 +2092,9 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | | `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | @@ -2156,11 +2168,11 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage---tls-ca) (TLS CA) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2730,23 +2742,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.10.6 Extended Key Usage - Non-TLS CA - -The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. - -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| `id-kp-clientAuth` | 1.3.6.1.5.5.7.3.2 | MAY | -| `id-kp-codeSigning` | 1.3.6.1.5.5.7.3.3 | MAY | -| `id-kp-emailProtection` | 1.3.6.1.5.5.7.3.4 | MAY | -| `id-kp-timeStamping` | 1.3.6.1.5.5.7.3.8 | MAY | -| `id-kp-serverAuth` | 1.3.6.1.5.5.7.3.1 | MUST NOT | -| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST NOT | -| `anyExtendedKeyUsage` | 2.5.29.37.0 | MUST NOT | -| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | -| Any other value | - | MAY | - -##### 7.1.2.10.7 Extended Key Usage - TLS CA +##### 7.1.2.10.6 Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2760,7 +2756,7 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | Any other value | - | NOT RECOMMENDED | -##### 7.1.2.10.8 Key Usage +##### 7.1.2.10.7 Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2776,7 +2772,7 @@ The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to [^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information. -##### 7.1.2.10.9 Name Constraints +##### 7.1.2.10.8 Name Constraints If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. From 05433661b8b2e4a3494d27f31bd17c4cf6db807b Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:34 -0400 Subject: [PATCH 24/54] 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. --- docs/BR.md | 27 ++++++++++++++------------- 1 file changed, 14 insertions(+), 13 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d80e6f61..6c34a7d7 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1966,19 +1966,31 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#71232-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-extended-key-usage)| | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `certificatePolicies` | MAY | N | See [Section 7.1.2.3.2](#71232-certificate-policies) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | ##### 7.1.2.3.2 Certificate Policies -If present, the Certificate Policies extension MUST be one of the following two formats: +If present, the Certificate Policies extension MUST be formatted as one of the two tables below: + + +Table: Policy Restricted + +| __Field__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `certificatePolicies` | | | +| \ \ **1+** | MUST | At least one `PolicyInformation` MUST be present in the `certificatePolicies`. Multiple `PolicyInformation` values MAY be present, if they meet the following profile. | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | | +| \ \ **2** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | + Table: No Policy Restrictions @@ -1990,17 +2002,6 @@ Table: No Policy Restrictions | \ \ \ \ `policyQualifiers` | MUST NOT | | | \ \ **2** | MUST NOT | When the `anyPolicy` policy is present, the CA MUST NOT include any further `PolicyInformation` values. | - -Table: Policy Restricted - -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1+** | MAY | The CA MAY include one or more `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | MUST NOT | | -| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | - ##### 7.1.2.3.3 Extended Key Usage The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. From 14746165777f8e0c7efd49bd7e6e665ac59e49b8 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:36 -0400 Subject: [PATCH 25/54] 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) --- docs/BR.md | 26 ++++++++++++++++++-------- 1 file changed, 18 insertions(+), 8 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 6c34a7d7..1c407026 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2345,21 +2345,31 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | __Field__ | __Presence__ | __Description__ | | --- | - | ------ | | `certificatePolicies` | | | -| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types). | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | -| \ \ **2+** | MAY | The Issuing CA MAY include additional `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the Issuing CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | -| \ \ **3** | MUST NOT | The Issuing CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +| \ \ **1+** | MUST | One or more `PolicyInformation` values meeting the following requirements. | +| \ \ \ \ `policyIdentifier` | | See below for permitted `policyIdentifier` values. | +| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for permitted `policyQualifiers`. | +| \ \ **2** | MUST NOT | The Issuing CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | -If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: +Table: Permitted `policyIdentifier` values + +| __Policy Identifier__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). | +| Any other identifier | MAY | If present, the identifier MUST be documented by the Issuing CA in its Certificate Policy and/or Certification Practice Statement. | + +This Profile RECOMMENDS that the first `PolicyInformation` value within a `certificatePolicies` contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. + + +Table: Permitted `policyQualifiers` | __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | | --- | - | - | ----- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | + +[^first_policy_note]: Although RFC 5280 allows `PolicyInformation`s to appear in any order, several client implementations have implemented logic that considers the `policyIdentifier` that matches a given filter. As such, ensuring the Reserved Certificate Policy Identifier is the first `PolicyInformation` reduces the risk of interoperability challenges. + ##### 7.1.2.7.10 Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | From ed5f01ce7a32561f1c32277b8eb9f3b7c5fa80a5 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:37 -0400 Subject: [PATCH 26/54] Indicate a max for serial numbers This incorporates Corey's https://github.com/sleevi/cabforum-docs/pull/39/commits/04c55a4cdf2f6ea068bd1f743a83b60def34dcae --- docs/BR.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 1c407026..7f27ed3b 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1787,7 +1787,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | | \ \ \ \ `validity` | See [Section 7.1.2.1.x](#7121x-root-ca-validity) | @@ -1848,7 +1848,7 @@ __**TBD: Remarks about audits**__ | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | See [Section 7.1.2.2.x](#7122x-cross-certified-subordinate-ca-validity) | @@ -1948,7 +1948,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | @@ -2026,7 +2026,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | @@ -2073,7 +2073,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | @@ -2149,7 +2149,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | @@ -2183,7 +2183,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | | @@ -2446,7 +2446,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | See [Section 7.1.2.8.x](#7128x-ocsp-responder-validity) | From 9a6a656c6ce56133dd4cd868df27cabc0f1855a5 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:38 -0400 Subject: [PATCH 27/54] 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 --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 7f27ed3b..75784c04 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2876,7 +2876,7 @@ Each `SignedCertificateTimestamp` included within the `SignedCertificateTimestam ##### 7.1.2.11.4 Subject Key Identifier -If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). CAs MUST generate a unique `subjectKeyIdentifier` for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs MAY generate the subject key identifier using an algorithm derived from the public key, or MAY generate a unique number, such by using a CSPRNG. +If present, the `subjectKeyIdentifier` MUST be set as defined within [RFC 5280, Section 4.2.1.2](https://tools.ietf.org/html/rfc5280#section-4.2.1.2). The CA MUST generate a `subjectKeyIdentifier` that is unique within the scope of all Certificates it has issued for each unique public key (the `subjectPublicKeyInfo` field of the `tbsCertificate`). For example, CAs may generate the subject key identifier using an algorithm derived from the public key, or may generate a sufficiently-large unique number, such by using a CSPRNG. ##### 7.1.2.11.5 Other Extensions From 04cadf21f2cf7447cc038180af05fc978e255e0c Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:39 -0400 Subject: [PATCH 28/54] 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 --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 75784c04..536ea1f6 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2187,7 +2187,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | | -| \ \ \ \ \ \ \ \ `notBefore` | __**TBD**__ | +| \ \ \ \ \ \ \ \ `notBefore` | A value within 48 hours of the certificate signing operation. | | \ \ \ \ \ \ \ \ `notAfter` | See [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | | \ \ \ \ `subject` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | From 099122b1b6c955a8e375cb7c8693b2128ba2c0d0 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:40 -0400 Subject: [PATCH 29/54] 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. --- docs/BR.md | 24 ++++++++++++++++++------ 1 file changed, 18 insertions(+), 6 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 536ea1f6..4add94ef 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2258,10 +2258,16 @@ Table: Individual Validated `subject` Attributes | `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `organizationalUnitName` | NOT RECOMMENDED | __**TBD**__ | __**TBD**__ | +| `organizationalUnitName` | - | - | +| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 3.2](#32-initial-identity-validation) | +| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | | `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +In addition, the following requirements apply to `subject` Attributes. + * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. + * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. + ##### 7.1.2.7.4 Organization Validated For a Subscriber Certificate to be Organization Validated, it MUST meet the following profile: @@ -2288,10 +2294,16 @@ Table: Individual Validated `subject` Attributes | `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | | `surname` | MUST NOT | - | - | | `givenName` | MUST NOT | - | - | -| `organizationalUnitName` | NOT RECOMMENDED | __**TBD**__ | __**TBD**__ | +| `organizationalUnitName` | - | - | +| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 3.2](#32-initial-identity-validation) | +| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | | `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +In addition, the following requirements apply to `subject` Attributes. + * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. + * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. + ##### 7.1.2.7.5 Extended Validation For a Subscriber Certificate to be Extended Validation, it MUST comply with the Certificate Profile specified in the then-current version of the Guidelines for the Issuance and Management of Extended Validation Certificates. @@ -2303,6 +2315,10 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | +In addition, the following requirements apply to `subject` Attributes. + * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. + * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. + ##### 7.1.2.7.6 Subscriber Certificate Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | @@ -3018,10 +3034,6 @@ If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When enc This section details encoding rules that apply to all Certificates issued by a CA. Further restrictions may be specified within [Section 7.1.2](#712-certificate-content-and-extensions), but these restrictions do not supersede these requirements. -In addition, the following requirements apply to all Subject Attributes (i.e. those attributes within the `subject` field of a `tbsCertificate`): - * Subject Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. - * Subject Attributes MUST NOT include a Domain Name or IP Address, except as specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control) or [Section 3.2.2.5](#3225-authentication-for-an-ip-address) - #### 7.1.4.1 Name Encoding The following requirements apply to all Certificates listed in [Section 7.1.2](#712-certificate-content-and-extensions). Specifically, this includes Technically Constrained Non-TLS Subordinate CA Certificates, as defined in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile), but does not include certificates issued by such CA Certificates, as they are out of scope of these Baseline Requirements. From ab5fedccbd1459243edfb38968b54dd8e0fc5616 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 14:37:01 -0400 Subject: [PATCH 30/54] 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. --- docs/BR.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 4add94ef..3ea5bb44 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2495,8 +2495,8 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | | `certificatePolicies` | - | - | - | -| \ \ \ \ _Prior to 2022-04-01_ | NOT RECOMMENDED | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | -| \ \ \ \ _Effective 2022-04-01_ | MUST NOT | - | - | +| \ \ \ \ _Prior to 2022-11-01_ | NOT RECOMMENDED | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | +| \ \ \ \ _Effective 2022-11-01_ | MUST NOT | - | - | | `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -3043,7 +3043,7 @@ For every valid Certification Path (as defined by [RFC 5280, Section 6](https:// * For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. * For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates. -Effective 2022-10-01, when encoding a `Name`, the CA SHALL ensure that: +Effective 2022-11-01, when encoding a `Name`, the CA SHALL ensure that: * Each `Name` MUST contain an `RDNSequence`. * Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`. From f51e83966deedacf93cd23647d166eac9eb84b6c Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 15:43:52 -0400 Subject: [PATCH 31/54] 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. --- docs/BR.md | 221 ++++++++++++++++++++++++++--------------------------- 1 file changed, 110 insertions(+), 111 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 3ea5bb44..c367670e 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1760,10 +1760,10 @@ Certificates MUST be of type X.509 v3. ### 7.1.2 Certificate Content and Extensions -If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280](https://tools.ietf.org/doc/html/rfc5280#appendix-B) for further issues to be aware of. +If the CA asserts compliance with these Baseline Requirements, all certificates that it issues MUST comply with one of the following certificate profiles, which incorporate, and are derived from [RFC 5280](https://tools.ietf.org/html/rfc5280). Except as explicitly noted, all normative requirements imposed by RFC 5280 shall apply, in addition to the normative requirements imposed by this document. CAs SHOULD examine [RFC 5280, Appendix B](https://tools.ietf.org/html/rfc5280#appendix-B) for further issues to be aware of. * CA Certificates - * [Section 7.1.2.1.- Root CA Certificate Profile](#7121-root-ca-certificate-profile) + * [Section 7.1.2.1 - Root CA Certificate Profile](#7121-root-ca-certificate-profile) * Subordinate CA Certificates * Cross Certificates * [Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile) @@ -1773,10 +1773,6 @@ If the CA asserts compliance with these Baseline Requirements, all certificates * [Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) * [Section 7.1.2.6 - TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile) * [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile) - * Domain Validated - * Individual Validated - * Organization Validated - * Extended Validation * [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile) * [Section 7.1.2.9 - Precertificate Profile](#7129-precertificate-profile) * __**TBD: Interoperability Testing Certs (valid/revoked/expired)?**__ @@ -1787,19 +1783,19 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | -| \ \ \ \ `validity` | See [Section 7.1.2.1.x](#7121x-root-ca-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | +| \ \ \ \ `validity` | See [Section 7.1.2.1.1](#71211-root-ca-validity) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.1.1](#71211-root-ca-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.2.1.2](#71212-root-ca-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -##### 7.1.2.1.x Root CA Validity +##### 7.1.2.1.1 Root CA Validity | __Field__ | __Minimum__ | __Maximum__ | | - | ---- | ---- | @@ -1808,20 +1804,20 @@ If the CA asserts compliance with these Baseline Requirements, all certificates **Note**: This restriction applies even in the event of generating a new Root CA Certificate for an existing `subject` and `subjectPublicKeyInfo` (e.g. reissuance). The new CA Certificate MUST conform to these rules. -##### 7.1.2.1.1 Root CA Extensions +##### 7.1.2.1.2 Root CA Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.2](#71212-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.3](#71213-basic-constraints) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.3](#71213-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-basic-constraints) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST NOT | N | - | -| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10 4](#712104-certificate-policies---affiliated-ca) | +| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.1.2 Authority Key Identifier +##### 7.1.2.1.3 Authority Key Identifier | __Field__ | __Description__ | | --- | ------- | @@ -1829,7 +1825,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | `authorityCertIssuer` | MUST NOT be present | | `authorityCertSerialNumber` | MUST NOT be present | -##### 7.1.2.1.3 Basic Constraints +##### 7.1.2.1.4 Basic Constraints | __Field__ | __Description__ | | --- | ------- | @@ -1848,32 +1844,32 @@ __**TBD: Remarks about audits**__ | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.2.x](#7122x-cross-certified-subordinate-ca-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-naming) | +| \ \ \ \ `validity` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-validity) | +| \ \ \ \ `subject` | See [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.2.2.3](#71223-cross-certified-subordinate-ca-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -##### 7.1.2.2.x Cross-Certified Subordinate CA Validity +##### 7.1.2.2.1 Cross-Certified Subordinate CA Validity | __Field__ | __Minimum__ | __Maximum__ | | -- | ---- | ---- | | `notBefore` | The earlier of one day prior to the time of signing or the earliest `notBefore` date of the existing CA Certificate(s) | The time of signing | | `notAfter` | The time of signing | Unspecified | -##### 7.1.2.2.1 Cross-Certified Subordinate CA Naming +##### 7.1.2.2.2 Cross-Certified Subordinate CA Naming The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-forms), or, if the existing CA Certificate was issued in compliance with the then-current version of the Baseline Requirements, the encoded `subject` name MUST be byte-for-byte identical to the encoded `subject` name of the existing CA Certificate. **Note**: The above exception allows the CAs to issue Cross-Certified Subordinate CA Certificates, provided that the existing CA Certificate complied with the Baseline Requirements in force at time of issuance. This allows the requirements of [Section 7.1.4](#714-name-forms) to be improved over time, while still permitting Cross-Certification. If the existing CA Certificate did not comply, issuing a Cross-Certificate is not permitted. -##### 7.1.2.2.2 Cross-Certified Subordinate CA Extensions +##### 7.1.2.2.3 Cross-Certified Subordinate CA Extensions The acceptable extensions and the requirements for those extensions in a Cross-Certified Subordinate CA vary based on whether or not the Subordinate CA is issued to and operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. @@ -1882,14 +1878,14 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.3](#71223-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -1898,22 +1894,22 @@ Table: Extensions when the Subordinate CA is operated by an entity that is not t | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.6](#712106-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---restricted-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-extended-key-usage---restricted-cross-certified-ca) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. -[^name_constraints]: See [Section 7.1.2.10.8](#712108-name-constraints) for further requirements, including regarding criticality of this extension. +[^name_constraints]: See [Section 7.1.2.10.9](#712109-name-constraints) for further requirements, including regarding criticality of this extension. -##### 7.1.2.2.3 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA +##### 7.1.2.2.4 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA When the Cross-Certified Subordinate CA is issued to and operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA, the Extended Key Usage extension MAY be encoded as follows: @@ -1924,9 +1920,9 @@ Table: Unrestricted Extended Key Usage (Affiliated Cross-Certified CA) | `anyExtendedKeyUsage` | The special extended key usage to indicate there are no restrictions applied. If present, this MUST be the only key usage present. | | Any other value | CAs MUST NOT include any other key usage with the `anyExtendedKeyUsage` key usage present. | -Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension MUST be encoded as specified in [Section 7.1.2.2.4, Extended Key Usage - Restricted Cross-Certified CA](#71224-extended-key-usage---restricted-cross-certified-ca). +Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension MUST be encoded as specified in [Section 7.1.2.2.5, Extended Key Usage - Restricted Cross-Certified CA](#71225-extended-key-usage---restricted-cross-certified-ca). -##### 7.1.2.2.4 Extended Key Usage - Restricted Cross-Certified CA +##### 7.1.2.2.5 Extended Key Usage - Restricted Cross-Certified CA If present, the Extended Key Usage extension MUST only contain key usage purposes for which the Issuing CA has verified the Cross-Certified Subordinate CA is authorized to assert. @@ -1948,11 +1944,11 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | +| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -1965,14 +1961,14 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-extended-key-usage)| -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | | `certificatePolicies` | MAY | N | See [Section 7.1.2.3.2](#71232-certificate-policies) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2026,11 +2022,11 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | +| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the `subjectPublicKeyInfo` field of the Issuing CA. See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -2043,14 +2039,14 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2063,7 +2059,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is CAs are NOT RECOMMENDED to include additional key usage purposes beyond those specified in the table above. If present, they SHOULD be equal to, or a subset of, the key usage purposes for the Issuing CA Certificate. -Any additional key usage purposes MUST conform to the requirements and restrictions specified in [Section 7.1.2.2.4, Extended Key Usage - Restricted Cross-Certified CA](#71224-extended-key-usage---restricted-cross-certified-ca). +Any additional key usage purposes MUST conform to the requirements and restrictions specified in [Section 7.1.2.2.5, Extended Key Usage - Restricted Cross-Certified CA](#71225-extended-key-usage---restricted-cross-certified-ca). #### 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile @@ -2073,11 +2069,11 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | +| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -2090,14 +2086,14 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage) | | `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2125,7 +2121,7 @@ The following table contains the requirements for the `GeneralName` that appears Table: `GeneralName` requirements for the `base` field | __Name Type__ | __Presence__ | __Permitted Subtrees__ | __Excluded Subtrees__ | __Entire Namespace Exclusion__ | -| --- | - | ---- | ---- | ---- | +| --- | -- | ---- | ---- | ---- | | `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | | `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | | `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | @@ -2149,11 +2145,11 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.x](#71210x-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | +| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | @@ -2166,14 +2162,14 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.3](#712103-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.4](#712104-certificate-policies---affiliated-ca) (Affiliated CA) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.2](#712102-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2183,7 +2179,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | | \ \ \ \ `validity` | | @@ -2264,7 +2260,8 @@ Table: Individual Validated `subject` Attributes | `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | -In addition, the following requirements apply to `subject` Attributes. +In addition, the following requirements apply to `subject` Attributes: + * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. @@ -2300,7 +2297,8 @@ Table: Individual Validated `subject` Attributes | `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | -In addition, the following requirements apply to `subject` Attributes. +In addition, the following requirements apply to `subject` Attributes: + * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. @@ -2315,7 +2313,8 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | -In addition, the following requirements apply to `subject` Attributes. +In addition, the following requirements apply to `subject` Attributes: + * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. @@ -2383,7 +2382,6 @@ Table: Permitted `policyQualifiers` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | - [^first_policy_note]: Although RFC 5280 allows `PolicyInformation`s to appear in any order, several client implementations have implemented logic that considers the `policyIdentifier` that matches a given filter. As such, ensuring the Reserved Certificate Policy Identifier is the first `PolicyInformation` reduces the risk of interoperability challenges. ##### 7.1.2.7.10 Extended Key Usage @@ -2462,46 +2460,46 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | --- | ------ | | `tbsCertificate` | | | \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159 containing at least 64 bits of output from a CSPRNG. | +| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | | \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | | \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.8.x](#7128x-ocsp-responder-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.1](#712101-ca-certificate-naming) | +| \ \ \ \ `validity` | See [Section 7.1.2.8.1](#71281-ocsp-responder-validity) | +| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | | \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | | \ \ \ \ `issuerUniqueID` | MUST NOT be present | | \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.8.1](#71281-ocsp-responder-extensions) | +| \ \ \ \ `extensions` | See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -##### 7.1.2.8.x OCSP Responder Validity +##### 7.1.2.8.1 OCSP Responder Validity | __Field__ | __Minimum__ | __Maximum__ | | -- | ---- | ---- | | `notBefore` | One day prior to the time of signing | The time of signing | | `notAfter` | The time of signing | Unspecified | -##### 7.1.2.8.1 OCSP Responder Extensions +##### 7.1.2.8.2 OCSP Responder Extensions | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.4](#71284-extended-key-usage) | -| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.5](#71285-id-pkix-ocsp-nocheck) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.6](#71286-key-usage) | -| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.3](#71283-basic-constraints) | +| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.5](#71285-extended-key-usage) | +| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.6](#71286-id-pkix-ocsp-nocheck) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.7](#71287-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.4](#71284-basic-constraints) | | `nameConstraints` | MUST NOT | - | - | | `subjectAltName` | MUST NOT | - | - | | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.2](#71282-authority-information-access) | +| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-authority-information-access) | | `certificatePolicies` | - | - | - | -| \ \ \ \ _Prior to 2022-11-01_ | NOT RECOMMENDED | N | See [Section 7.1.2.8.7](#71287-certificate-policies) | +| \ \ \ \ _Prior to 2022-11-01_ | NOT RECOMMENDED | N | See [Section 7.1.2.8.8](#71288-certificate-policies) | | \ \ \ \ _Effective 2022-11-01_ | MUST NOT | - | - | | `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.8.2 Authority Information Access +##### 7.1.2.8.3 Authority Information Access For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties. @@ -2512,7 +2510,7 @@ If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `Ac | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.8.3 Basic Constraints +##### 7.1.2.8.4 Basic Constraints OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. @@ -2523,20 +2521,20 @@ OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indi **Note**: CAs MUST observe DER encoding rules, such as not explicitly encoding DEFAULT values within OPTIONAL fields. -##### 7.1.2.8.4 Extended Key Usage +##### 7.1.2.8.5 Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | | Any other value | - | MUST NOT | -##### 7.1.2.8.5 id-pkix-ocsp-nocheck +##### 7.1.2.8.6 id-pkix-ocsp-nocheck The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5). This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1). -##### 7.1.2.8.6 Key Usage +##### 7.1.2.8.7 Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2550,9 +2548,9 @@ This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960 | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -##### 7.1.2.8.7 Certificate Policies +##### 7.1.2.8.8 Certificate Policies -**Note**: See [Section 7.1.2.8.1](#71281-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. +**Note**: See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. If present, the Certificate Policies extension MUST be formatted as follows: @@ -2666,14 +2664,14 @@ If the `authorityKeyIdentifier` extension is present in the Certificate, then th This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). -##### 7.1.2.10.x CA Certificate Validity +##### 7.1.2.10.1 CA Certificate Validity | __Field__ | __Minimum__ | __Maximum__ | | -- | ---- | ---- | | `notBefore` | One day prior to the time of signing | The time of signing | | `notAfter` | The time of signing | Unspecified | -##### 7.1.2.10.1 CA Certificate Naming +##### 7.1.2.10.2 CA Certificate Naming All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2691,7 +2689,7 @@ The following table details the acceptable `AttributeType`s that may appear with | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | -##### 7.1.2.10.2 Authority Information Access +##### 7.1.2.10.3 Authority Information Access If present, the `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. @@ -2703,14 +2701,14 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.10.3 Basic Constraints +##### 7.1.2.10.4 Basic Constraints | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be set TRUE | | `pathLenConstraint` | MAY be present | -##### 7.1.2.10.4 Certificate Policies - Affiliated CA +##### 7.1.2.10.5 Certificate Policies - Affiliated CA The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by an organization that is the same as the organization operating the Issuing CA or that is an Affiliate of the organization operating the Issuing CA. @@ -2742,7 +2740,7 @@ Table: Policy Restricted | \ \ \ \ `policyQualifiers` | MUST NOT | | | \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | -##### 7.1.2.10.5 Certificate Policies - Non-Affiliated CA +##### 7.1.2.10.6 Certificate Policies - Non-Affiliated CA The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by a CA that is an not an Affiliate of the Issuing CA. @@ -2769,7 +2767,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.10.6 Extended Key Usage +##### 7.1.2.10.7 Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2783,7 +2781,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | Any other value | - | NOT RECOMMENDED | -##### 7.1.2.10.7 Key Usage +##### 7.1.2.10.8 Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2799,7 +2797,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` [^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information. -##### 7.1.2.10.8 Name Constraints +##### 7.1.2.10.9 Name Constraints If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. @@ -2861,7 +2859,7 @@ If present, the CRL Distribution Points extension MUST be formatted as follows: Table: `CRLDistributionPoints` profile | __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | +| --- | -- | ------ | | `CRLDistributionPoints` | | | | \ \ **1** | MUST | The first `DistributionPoint` present in the `CRLDistributionPoints` | | \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | @@ -2876,7 +2874,7 @@ Table: `CRLDistributionPoints` profile Table: `fullName` profile | __Field__ | __Presence__ | __Description__ | -| ---- | - | ----- | +| --- | - | ----- | | `fullName` | | | | \ \ **1** | MUST | The first `GeneralName` present in `fullName` MUST be of type `uniformResourceIdentifier` | | \ \ \ \ `uniformResourceIdentifier` | MUST | The HTTP URL of the Issuing CA's CRL service for this certificate. | @@ -3051,7 +3049,7 @@ Effective 2022-11-01, when encoding a `Name`, the CA SHALL ensure that: * For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`. * Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s. -**Note**: [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-naming) provides an exception to the above `Name` encoding requirements when issuing a [Cross-Certified Subordinate CA Certificate](#7122-cross-certified-subordinate-ca-certificate-profile), as described within that section. +**Note**: [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) provides an exception to the above `Name` encoding requirements when issuing a [Cross-Certified Subordinate CA Certificate](#7122-cross-certified-subordinate-ca-certificate-profile), as described within that section. #### 7.1.4.2 Subject Attribute Encoding @@ -3081,6 +3079,7 @@ Table: Attribute Encoding and Order Requirements When explicitly stated as permitted by the relavant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). Before including such an attribute, the CA SHALL: + * Document the attributes within Section 7.1.4 of their CP or CPS, along with the applicable validation practices. * Ensure that the contents contain information that has been verified by the CA, independent of the Applicant. From 89541fa94fd6969e3ad8a8331a5326cd7b98b55d Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 15:51:49 -0400 Subject: [PATCH 32/54] OrganizationalUnitName fixups Fixup the OU field --- docs/BR.md | 61 +++++++++++++++++++++++++++--------------------------- 1 file changed, 30 insertions(+), 31 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index c367670e..64d1aa7a 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2244,21 +2244,21 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Individual Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | -| --- | - | ------ | -- | -| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `organizationalUnitName` | - | - | -| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 3.2](#32-initial-identity-validation) | -| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | -| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationalUnitName` | - | - | - | +| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information. | [Section 3.2](#32-initial-identity-validation) | +| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | - | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | In addition, the following requirements apply to `subject` Attributes: @@ -2281,21 +2281,21 @@ The following table details the acceptable `AttributeType`s that may appear with Table: Individual Validated `subject` Attributes -| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | -| --- | - | ------ | -- | -| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | -| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | -| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | -| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | -| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | -| `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | -| `surname` | MUST NOT | - | - | -| `givenName` | MUST NOT | - | - | -| `organizationalUnitName` | - | - | -| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 3.2](#32-initial-identity-validation) | -| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | -| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | -| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | +| `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | +| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | +| `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `surname` | MUST NOT | - | - | +| `givenName` | MUST NOT | - | - | +| `organizationalUnitName` | - | - | - | +| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information. | [Section 3.2](#32-initial-identity-validation) | +| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | - | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | In addition, the following requirements apply to `subject` Attributes: @@ -2685,7 +2685,6 @@ The following table details the acceptable `AttributeType`s that may appear with | `postalCode` | MAY | If present, the CA's zip or postal information. | [Section 3.2.2.1](#3221-identity) | | `streetAddress` | MAY | If present, the CA's street address. Multiple instances MAY be present. | [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | -| `organizationalUnitName` | NOT RECOMMENDED | __**TBD**__ | | | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | From c46d7c8bca09f7146c446e54aa9bbf94a6a12cb1 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 15:56:02 -0400 Subject: [PATCH 33/54] Remove stale TODO/TBDs --- docs/BR.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 64d1aa7a..84d9581d 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1775,7 +1775,6 @@ If the CA asserts compliance with these Baseline Requirements, all certificates * [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) - * __**TBD: Interoperability Testing Certs (valid/revoked/expired)?**__ #### 7.1.2.1 Root CA Certificate Profile @@ -1838,8 +1837,6 @@ This Certificate Profile MAY be used when issuing a CA Certificate using the sam Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance. -__**TBD: Remarks about audits**__ - | __Field__ | __Description__ | | --- | ------ | | `tbsCertificate` | | @@ -2331,7 +2328,6 @@ In addition, the following requirements apply to `subject` Attributes: | `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-key-usage) | | `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-basic-constraints) | | `crlDistributionPoints` | MAY | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| CA/Browser Forum Onion Extension | MAY | N | __**TODO**__ | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | From ca45753e4d6d34316daaa0836a0b75150ed4ba8e Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 5 May 2022 10:53:30 -0400 Subject: [PATCH 34/54] 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. --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 84d9581d..5788dc3e 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1980,7 +1980,7 @@ Table: Policy Restricted | --- | - | ------ | | `certificatePolicies` | | | | \ \ **1+** | MUST | At least one `PolicyInformation` MUST be present in the `certificatePolicies`. Multiple `PolicyInformation` values MAY be present, if they meet the following profile. | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. This identifier MUST NOT be a Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | | \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | | | \ \ **2** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | From 12b287552df50afe1b11d4d615f60c3594dce77a Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 5 May 2022 16:19:54 -0400 Subject: [PATCH 35/54] 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. --- docs/BR.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 5788dc3e..547172e8 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -967,7 +967,7 @@ When processing CAA records, CAs MUST process the issue, issuewild, and iodef pr RFC 8659 requires that CAs "MUST NOT issue a certificate unless the CA determines that either (1) the certificate request is consistent with the applicable CAA RRset or (2) an exception specified in the relevant CP or CPS applies." For issuances conforming to these Baseline Requirements, CAs MUST NOT rely on any exceptions specified in their CP or CPS unless they are one of the following: -* CAA checking is optional for certificates for which a Certificate Transparency pre-certificate was created and logged in at least two public logs, and for which CAA was checked. +* CAA checking is optional for certificates for which a Certificate Transparency Precertificate (see [Section 7.1.2.9](#7129-precertificate-profile)) was created and logged in at least two public logs, and for which CAA was checked at time of Precertificate issuance. * CAA checking is optional for certificates issued by a Technically Constrained Subordinate CA Certificate as set out in [Section 7.1.2.3](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) or [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile), where the lack of CAA checking is an explicit contractual provision in the contract with the Applicant. * For certificates issued prior to July 1, 2021, CAA checking is optional if the CA or an Affiliate of the CA is the DNS Operator (as defined in RFC 7719) of the domain's DNS. @@ -2049,14 +2049,10 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is ##### 7.1.2.4.2 Extended Key Usage -| __Key Purpose__ | __OID__ | __Presence__ | -| ---- | ---- | - | -| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST | -| Any other value | - | NOT RECOMMENDED | - -CAs are NOT RECOMMENDED to include additional key usage purposes beyond those specified in the table above. If present, they SHOULD be equal to, or a subset of, the key usage purposes for the Issuing CA Certificate. - -Any additional key usage purposes MUST conform to the requirements and restrictions specified in [Section 7.1.2.2.5, Extended Key Usage - Restricted Cross-Certified CA](#71225-extended-key-usage---restricted-cross-certified-ca). +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST | +| Any other value | - | MUST NOT | #### 7.1.2.5 Technically Constrained TLS Subordinate CA Certificate Profile @@ -2646,7 +2642,7 @@ The Precertificate Poison extension is identified by the OID 1.3.6.1.4.1.11129.2 ##### 7.1.2.9.4 Authority Key Identifier -For Precertificates issued by a Precertificate Signing CA, the `authorityKeyIdentifier`, if present in the equivalent Certificate, MAY be modified to reflect the values of the Technically Constrained Precertificate Signing CA Certificate; for example, if the Precertificate Signing CA uses a different Key Pair than the Issuing CA it is acting on behalf of. +For Precertificates issued by a Precertificate Signing CA, the `authorityKeyIdentifier`, if present in the equivalent Certificate, may be modified to reflect the values of the Technically Constrained Precertificate Signing CA Certificate; for example, if the Precertificate Signing CA uses a different Key Pair than the Issuing CA it is acting on behalf of. If the `authorityKeyIdentifier` extension is present in the Certificate, then the Precertificate MUST contain an `authorityKeyIdentifier` in the same order within the extension sequence as the Certificate, ignoring the [Precertificate Poison](#71293-precertificate-poison) extension. It MUST be byte-for-byte identical in value to the `authorityKeyIdentifier` extension of the Certificate, or MAY be modified as defined below: From f288195c0d9a6479211190b9ce304ec37511ca5b Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 5 May 2022 17:07:17 -0400 Subject: [PATCH 36/54] 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. --- docs/BR.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 547172e8..991c934c 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2118,9 +2118,8 @@ Table: `GeneralName` requirements for the `base` field | `dNSName` | MUST | The CA MUST confirm that the Applicant has registered the `dNSName` or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `dNSName` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subordinate domains to be excluded. | If no `dNSName` instance is present in the `permittedSubtrees`, then the CA MUST include a zero-length `dNSName` to indicate no domain names are permitted. | | `iPAddress` | MUST | The CA MUST confirm that the Applicant has been assigned the `iPAddress` range or has been authorized by the assigner to act on the asignee's behalf. See [Section 3.2.2.5](#3225-authentication-for-an-ip-address). | If at least one `iPAddress` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more subdivisions of those ranges to be excluded. | If no IPv4 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 8 zero octets, indicating the IPv4 range of 0.0.0.0/0 being excluded. If no IPv6 `iPAddress` is present in the `permittedSubtrees`, the CA MUST include an `iPAddress` of 32 zero octets, indicating the IPv6 range of ::0/0 being excluded. | | `directoryName` | MUST | The CA MUST confirm the Applicant's and/or Subsidiary's name attributes such that all certificates issued will comply with the relevant Certificate Profile (see [Section 7.1.2](#712-certificate-content-and-extensions)), including Name Forms (See [Section 7.1.4](#714-name-forms)). | It is NOT RECOMMENDED to include values within `excludedSubtrees`. | The CA MUST include a value within `permittedSubtrees`, and as such, this does not apply. See the Excluded Subtrees requirements for more. | -| `rfc822Name` | NOT RECOMMENDED | The CA MAY constrain to a mailbox, a particular host, or any address within a domain, as specified within [RFC 5280, Section 4.2.1.10](https://tools.ietf.org/html/rfc5280#section-4.2.1.10). For each host, domain, or Domain portion of a Mailbox (as specified within [RFC 5280, Section 4.2.1.6](https://tools.ietf.org/html/rfc5280#section-4.2.1.6)), the CA MUST confirm that the Applicant has registered the domain or has been authorized by the domain registrant to act on the registrant's behalf. See [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). | If at least one `rfc822Name` instance is present in the `permittedSubtrees`, the CA MAY indicate one or more mailboxes, hosts, or domains to be excluded. | If no `rfc822Name` instance is present in the `permittedSubtrees`, then the CA MAY include a zero-length `rfc822Name` to indicate no mailboxes are permitted. | | `otherName` | NOT RECOMMENDED | See below | See below | See below | -| Any other value | MUST NOT | - | - | - | +| Any other value | MUST NOT | - | - | - | Any `otherName`, if present: From f616d86679b72fe9cad100ee66f33374e656e86c Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Tue, 10 May 2022 12:20:53 -0400 Subject: [PATCH 37/54] 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). --- docs/BR.md | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 991c934c..32cea6d1 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2562,13 +2562,13 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` #### 7.1.2.9 Precertificate Profile -A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of an equivalent Certificate also existing, as the signature represents a binding committment by the CA that it may issue such a Certificate. +A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding committment by the CA that it may issue such a Certificate. -A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate to be equivalent to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate's `extensions` field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate. +A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate's `extensions` field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate. -Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue an equivalent Certificate, or more commonly, that an equivalent Certificate exists. A Certificate is said to be equivalent to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). +Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). -This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue an equivalent Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the equivalent Certificate conforms to these Baseline Requirements, regardless of whether they sign the equivalent Certificate. +This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue a corresponding Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the corresponding Certificate conforms to these Baseline Requirements, regardless of whether the CA signs the corresponding Certificate. A Precertificate may be issued either directly by the Issuing CA or by a Technically Constrained Precertificate Signing CA, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). If issued by a Precertificate Signing CA, then in addition to the precertificate poison and signed certificate timestamp list extensions, the Precertificate `issuer` field and, if present, `authorityKeyIdentifier` extension, may differ from the Certificate, as described below. @@ -2610,7 +2610,7 @@ Table: When the Precertificate is issued by a Precertificate Signing CA on behal | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | -**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the equivalent Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the equivalent Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they are byte-for-byte equivalent, as this would otherwise indicate there are equivalent Certificates that share the same `serialNumber`. +**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they are byte-for-byte identical, as this would otherwise indicate there are corresponding Certificates that share the same `serialNumber`. ##### 7.1.2.9.1 Directly Issued Precertificate Profile Extensions @@ -2641,9 +2641,11 @@ The Precertificate Poison extension is identified by the OID 1.3.6.1.4.1.11129.2 ##### 7.1.2.9.4 Authority Key Identifier -For Precertificates issued by a Precertificate Signing CA, the `authorityKeyIdentifier`, if present in the equivalent Certificate, may be modified to reflect the values of the Technically Constrained Precertificate Signing CA Certificate; for example, if the Precertificate Signing CA uses a different Key Pair than the Issuing CA it is acting on behalf of. +For Precertificates issued by a Precertificate Signing CA, the contents of the `authorityKeyIdentifier` extension MUST be one of the following: + +1. SHOULD be as defined in the profile below, or; +2. MAY be byte-for-byte identical with the contents of the `authorityKeyIdentifier` extension of the corresponding Certificate. -If the `authorityKeyIdentifier` extension is present in the Certificate, then the Precertificate MUST contain an `authorityKeyIdentifier` in the same order within the extension sequence as the Certificate, ignoring the [Precertificate Poison](#71293-precertificate-poison) extension. It MUST be byte-for-byte identical in value to the `authorityKeyIdentifier` extension of the Certificate, or MAY be modified as defined below: | __Field__ | __Description__ | | --- | ------- | @@ -2651,6 +2653,9 @@ If the `authorityKeyIdentifier` extension is present in the Certificate, then th | `authorityCertIssuer` | MUST NOT be present | | `authorityCertSerialNumber` | MUST NOT be present | + +**Note**: [RFC 6962](https://datatracker.ietf.org/doc/html/rfc6962) describes how the `authorityKeyIdentifier` present on a Precertificate is transformed to contain the value of the Precertificate Signing CA's `authorityKeyIdentifier` extension (i.e. reflecting the actual issuer certificate's `keyIdentifier`), thus matching the corresponding Certificate when verified by clients. These Baseline Requirements RECOMMEND the use of the Precertificate Signing CA's `keyIdentifier` in Precertificates issued by it in order to ensure consistency between the `subjectKeyIdentifier` and `authorityKeyIdentifier` of all certificates in the chain. Although [RFC 5280](https://datatracker.ietf.org/doc/html/rfc5280) does not strictly require such consistency, a number of client implementations enforce such consistency for Certificates, and this avoids any risks from Certificate Transparency Logs incorrectly implementing such checks. + #### 7.1.2.10 Common CA Fields This section contains several fields that are common among multiple CA Certificate profiles. However, these fields may not be common among all CA Certificate profiles. Before issuing a certificate, the CA MUST ensure the certificate contents, including the contents of each field, complies in whole with all of the requirements of at least one Certificate Profile documented in [Section 7.1.2](#712-certificate-content-and-extensions). From 5ad28de173a89927009d126d59cc268dfcf2a854 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 16 May 2022 14:28:51 -0400 Subject: [PATCH 38/54] 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"). --- docs/BR.md | 205 +++++++++++++++++++++++++---------------------------- 1 file changed, 95 insertions(+), 110 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 32cea6d1..d0e76057 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1809,10 +1809,10 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | ---- | - | - | ----- | | `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.3](#71213-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-basic-constraints) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST NOT | N | - | -| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) | +| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -1876,13 +1876,13 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -1892,19 +1892,19 @@ Table: Extensions when the Subordinate CA is operated by an entity that is not t | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.6](#712106-certificate-policies---non-affiliated-ca) (Non-Affiliated CA) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.6](#712105-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-extended-key-usage---restricted-cross-certified-ca) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. -[^name_constraints]: See [Section 7.1.2.10.9](#712109-name-constraints) for further requirements, including regarding criticality of this extension. +[^name_constraints]: See [Section 7.1.2.10.8](#712108-name-constraints) for further requirements, including regarding criticality of this extension. ##### 7.1.2.2.4 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA @@ -1960,12 +1960,12 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-extended-key-usage)| | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | | `certificatePolicies` | MAY | N | See [Section 7.1.2.3.2](#71232-certificate-policies) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -1973,27 +1973,33 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be If present, the Certificate Policies extension MUST be formatted as one of the two tables below: +Table: No Policy Restrictions (Affiliated CA) + +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | +| \ \ \ \ `anyPolicy` | MUST | | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + Table: Policy Restricted -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1+** | MUST | At least one `PolicyInformation` MUST be present in the `certificatePolicies`. Multiple `PolicyInformation` values MAY be present, if they meet the following profile. | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. This identifier MUST NOT be a Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | | -| \ \ **2** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST NOT | | +| \ \ \ \ `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +| \ \ \ \ Any other identifier | MAY | If present, MUST be documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | -Table: No Policy Restrictions +Table: Permitted `policyQualifiers` + +| __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | +| --- | - | - | ----- | +| `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | +| Any other qualifier | MUST NOT | - | - | -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | MUST | The `anyPolicy` (OID: 2.5.29.32.0) identifier. | -| \ \ \ \ `policyQualifiers` | MUST NOT | | -| \ \ **2** | MUST NOT | When the `anyPolicy` policy is present, the CA MUST NOT include any further `PolicyInformation` values. | ##### 7.1.2.3.3 Extended Key Usage @@ -2037,13 +2043,13 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2080,11 +2086,11 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | | `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | @@ -2155,13 +2161,13 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies---affiliated-ca) (Affiliated CA) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.8](#712108-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.7](#712107-extended-key-usage) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.9](#712109-name-constraints) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2205,7 +2211,7 @@ For a Subscriber Certificate to be Domain Validated, it MUST meet the following | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See following table. | -| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2227,7 +2233,7 @@ For a Subscriber Certificate to be Individual Validated, it MUST meet the follow | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See following table. | -| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2264,7 +2270,7 @@ For a Subscriber Certificate to be Organization Validated, it MUST meet the foll | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See following table. | -| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2302,7 +2308,7 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 9.2. | -| `certificatePolicies` | MUST be present and MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | In addition, the following requirements apply to `subject` Attributes: @@ -2348,22 +2354,18 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s ##### 7.1.2.7.9 Certificate Policies -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1+** | MUST | One or more `PolicyInformation` values meeting the following requirements. | -| \ \ \ \ `policyIdentifier` | | See below for permitted `policyIdentifier` values. | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for permitted `policyQualifiers`. | -| \ \ **2** | MUST NOT | The Issuing CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: -Table: Permitted `policyIdentifier` values +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). | +| \ \ \ \ `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +| \ \ \ \ Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | -| __Policy Identifier__ | __Presence__ | __Contents__ | -| --- | - | ------ | -| A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). | -| Any other identifier | MAY | If present, the identifier MUST be documented by the Issuing CA in its Certificate Policy and/or Certification Practice Statement. | -This Profile RECOMMENDS that the first `PolicyInformation` value within a `certificatePolicies` contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. +This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. Table: Permitted `policyQualifiers` @@ -2541,25 +2543,29 @@ This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960 ##### 7.1.2.8.8 Certificate Policies -**Note**: See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. +If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: -If present, the Certificate Policies extension MUST be formatted as follows: +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | NOT RECOMMENDED | | +| \ \ \ \ `anyPolicy` | NOT RECOMMENDED | | +| \ \ \ \ Any other identifier | NOT RECOMMENDED | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | MAY | The CA MAY include one or more `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | -| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | -If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: +Table: Permitted `policyQualifiers` | __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | | --- | - | - | ----- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | + +**Note**: See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. + +**Note**: Because the Certificate Policies extension may be used to restrict the applicable usages for a Certificate, incorrect policies may result in OCSP Responder Certificates that fail to successfully validate, resulting in invalid OCSP Responses. Including the `anyPolicy` policy can reduce this risk, but add to client processing complexity and interoperability issues. + #### 7.1.2.9 Precertificate Profile A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding committment by the CA that it may issue such a Certificate. @@ -2703,66 +2709,45 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | `cA` | MUST be set TRUE | | `pathLenConstraint` | MAY be present | -##### 7.1.2.10.5 Certificate Policies - Affiliated CA +##### 7.1.2.10.5 Certificate Policies + +If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: -The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by an organization that is the same as the organization operating the Issuing CA or that is an Affiliate of the organization operating the Issuing CA. -If present, the Certificate Policies extension MUST be one of the following two formats: +Table: No Policy Restrictions (Affiliated CA) -Table: No Policy Restrictions +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | +| \ \ \ \ `anyPolicy` | MUST | | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | MUST | The `anyPolicy` (OID: 2.5.29.32.0) identifier. | -| \ \ \ \ `policyQualifiers` | MUST NOT | | -| \ \ **2** | MUST NOT | When the `anyPolicy` policy is present, the CA MUST NOT include any further `PolicyInformation` values. | Table: Policy Restricted -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | -| \ \ \ \ `policyQualifiers` | MUST NOT | | -| \ \ **2+** | SHOULD | The CA SHOULD include additional Reserved Certificate Policy Identifiers for each type of Subscriber certificate that may be issued beneath it. | -| \ \ \ \ `policyIdentifier` | MUST | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | -| \ \ \ \ `policyQualifiers` | MUST NOT | | -| \ \ **3+** | MAY | The CA MAY include additional `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | MUST NOT | | -| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | - -##### 7.1.2.10.6 Certificate Policies - Non-Affiliated CA - -The following requirements apply to the Certificate Policies extension within CA certificates that are issued to and operated by a CA that is an not an Affiliate of the Issuing CA. - -If present, the Certificate Policies extension MUST be formatted as follows: - -| __Field__ | __Presence__ | __Description__ | -| --- | - | ------ | -| `certificatePolicies` | | | -| \ \ **1** | MUST | The first `PolicyInformation` present in the `certificatePolicies`. | -| \ \ \ \ `policyIdentifier` | | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | -| \ \ **2+** | SHOULD | The CA SHOULD include additional Reserved Certificate Policy Identifiers for each type of Subscriber certificate that may be issued beneath it. | -| \ \ \ \ `policyIdentifier` | MUST | A Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)). | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | -| \ \ **3+** | MAY | The CA MAY include additional `PolicyInformation` values that meet the following profile: | -| \ \ \ \ `policyIdentifier` | MUST | An identifier documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| \ \ \ \ `policyQualifiers` | NOT RECOMMENDED | See below for restrictions on `policyQualifiers` | -| \ \ **4** | MUST NOT | The CA MUST NOT include any additional `PolicyInformation` values that do not meet the above profile. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. | +| \ \ \ \ `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +| \ \ \ \ Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + + +This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. + If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: + +Table: Permitted `policyQualifiers` + | __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | | --- | - | - | ----- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.10.7 Extended Key Usage +##### 7.1.2.10.6 Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2776,7 +2761,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | Any other value | - | NOT RECOMMENDED | -##### 7.1.2.10.8 Key Usage +##### 7.1.2.10.7 Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2792,7 +2777,7 @@ If the `policyQualifiers` is permitted and present within a `PolicyInformation` [^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information. -##### 7.1.2.10.9 Name Constraints +##### 7.1.2.10.8 Name Constraints If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. From e7b2fbf1a7dfab9f22d574fcce9bd7495008b0ae Mon Sep 17 00:00:00 2001 From: AnetaWojtczak <104534364+AnetaWojtczak@users.noreply.github.com> Date: Tue, 16 Aug 2022 13:44:14 -0700 Subject: [PATCH 39/54] Changes to Key Usage values for Subscriber Certificates (#376) Changing dataEncipherment for RSA and KeyAgreement for ECC to not recommended. --- docs/BR.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d0e76057..6ae57896 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2402,7 +2402,7 @@ Table: Key Usage for RSA Public Keys | `digitalSignature` | Y | SHOULD | | `nonRepudiation` | N | -- | | `keyEncipherment` | Y | MAY | -| `dataEncipherment` | N | -- | +| `dataEncipherment` | Y | NOT RECOMMENDED | | `keyAgreement` | N | -- | | `keyCertSign` | N | -- | | `cRLSign` | N | -- | @@ -2419,7 +2419,7 @@ Table: Key Usage for ECC Public Keys | `nonRepudiation` | N | -- | | `keyEncipherment` | N | -- | | `dataEncipherment` | N | -- | -| `keyAgreement` | N | -- | +| `keyAgreement` | Y | NOT RECOMMENDED | | `keyCertSign` | N | -- | | `cRLSign` | N | -- | | `encipherOnly` | N | -- | From 15711d8c6ac5dfaadf074244663bc15d840e8580 Mon Sep 17 00:00:00 2001 From: AnetaWojtczak <104534364+AnetaWojtczak@users.noreply.github.com> Date: Wed, 14 Sep 2022 04:40:35 -0700 Subject: [PATCH 40/54] Definitions Update - Pending Prohibition (#388) --- docs/BR.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 6ae57896..6d7133d3 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -361,6 +361,8 @@ No stipulation. **Private Key**: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key. +**Pending Prohibition​​**: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future. + **Public Key**: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder's corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder's corresponding Private Key. **Public Key Infrastructure**: A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography. @@ -2409,7 +2411,7 @@ Table: Key Usage for RSA Public Keys | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this is NOT RECOMMENDED. +**Note**: At least one Key Usage MUST be set for RSA Public Keys. The `digitalSignature` bit is REQUIRED for use with modern protocols, such as TLS 1.3, and secure ciphersuites, while the `keyEncipherment` bit MAY be asserted to support older protocols, such as TLS 1.2, when using insecure ciphersuites. Subscribers MAY wish to ensure key separation to limit the risk from such legacy protocols, and thus a CA MAY issue a Subscriber certificate that only asserts the `keyEncipherment` bit. For most Subscribers, the `digitalSignature` bit is sufficient, while Subscribers that want to mix insecure and secure ciphersuites with the same algorithm may choose to assert both `digitalSignature` and `keyEncipherment` within the same certificate, although this is NOT RECOMMENDED. The `dataEncipherment` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384). Table: Key Usage for ECC Public Keys @@ -2425,6 +2427,8 @@ Table: Key Usage for ECC Public Keys | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | +**Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384). + ##### 7.1.2.7.12 Subject Alternative Name For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements. From 18a98c3b763573146a25c3d6dd8e299a7c6fe95a Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Wed, 14 Sep 2022 07:40:52 -0400 Subject: [PATCH 41/54] 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 --- docs/BR.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 6d7133d3..a6427822 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1756,6 +1756,8 @@ The CA SHALL enforce multi-factor authentication for all accounts capable of dir The CA SHALL meet the technical requirements set forth in [Section 2.2 - Publication of Information](#22-publication-of-information), [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking). +Prior to 2023-04-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements or the profile specified in version 1.8.4 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-04-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements. + ### 7.1.1 Version number(s) Certificates MUST be of type X.509 v3. @@ -2489,9 +2491,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | `subjectAltName` | MUST NOT | - | - | | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-authority-information-access) | -| `certificatePolicies` | - | - | - | -| \ \ \ \ _Prior to 2022-11-01_ | NOT RECOMMENDED | N | See [Section 7.1.2.8.8](#71288-certificate-policies) | -| \ \ \ \ _Effective 2022-11-01_ | MUST NOT | - | - | +| `certificatePolicies` | MUST NOT | N | See [Section 7.1.2.8.8](#71288-certificate-policies) | | `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -3025,7 +3025,7 @@ For every valid Certification Path (as defined by [RFC 5280, Section 6](https:// * For each Certificate in the Certification Path, the encoded content of the Issuer Distinguished Name field of a Certificate SHALL be byte-for-byte identical with the encoded form of the Subject Distinguished Name field of the Issuing CA certificate. * For each CA Certificate in the Certification Path, the encoded content of the Subject Distinguished Name field of a Certificate SHALL be byte-for-byte identical among all Certificates whose Subject Distinguished Names can be compared as equal according to [RFC 5280, Section 7.1](https://tools.ietf.org/html/rfc5280#section-7.1), and including expired and revoked Certificates. -Effective 2022-11-01, when encoding a `Name`, the CA SHALL ensure that: +When encoding a `Name`, the CA SHALL ensure that: * Each `Name` MUST contain an `RDNSequence`. * Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`. From 89993948ba2b1718b07b46e0c84b523663d2179a Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Wed, 5 Oct 2022 16:01:45 -0400 Subject: [PATCH 42/54] Add specification for EV attributes (#391) Co-authored-by: Corey Bonnell --- docs/BR.md | 21 ++++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index a6427822..116dd115 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3039,7 +3039,9 @@ When encoding a `Name`, the CA SHALL ensure that: This document defines requirements for the content and validation of a number of attributes that may appear within the `subject` field of a `tbsCertificate`. CAs SHALL NOT include these attributes unless their content has been validated as specified by, and only if permitted by, the relevant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions). -Table: Attribute Encoding and Order Requirements +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. + +Table: Encoding and Order Requirements for Selected Attributes | __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | | ---- | -- | --- | ---- | - | @@ -3054,10 +3056,23 @@ Table: Attribute Encoding and Order Requirements | `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 32 | | `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. - [^surname_givenname] **Note**: Although RFC 5280 specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. +CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL follow the specified encoding requirements for the attribute. + +Table: Encoding Requirements for Selected Attributes + +| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | +| ---- | -- | --- | ---- | - | +| `businessCategory` | `2.5.4.15` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | +| `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | +| `jurisdictionStateOrProvince` | `1.3.6.1.4.1.311.60.2.1.2` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | +| `jurisdictionLocality` | `1.3.6.1.4.1.311.60.2.1.1` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | +| `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None | + +[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. + #### 7.1.4.3 Other Subject Attributes When explicitly stated as permitted by the relavant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). From 3370f7b5039616315b70b82c3ecef57342f371f1 Mon Sep 17 00:00:00 2001 From: Dimitris Zacharopoulos Date: Thu, 6 Oct 2022 19:05:09 +0300 Subject: [PATCH 43/54] 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 Co-authored-by: Corey Bonnell --- docs/BR.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 116dd115..58c5fd20 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2252,7 +2252,7 @@ Table: Individual Validated `subject` Attributes | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. Multiple instances MAY be present. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | @@ -2289,13 +2289,14 @@ Table: Individual Validated `subject` Attributes | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | | `postalCode` | NOT RECOMMENDED | If present, MUST contain the Subject's zip or postal information. | [Section 3.2.2.1](#3221-identity)) | -| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. | [Section 3.2.2.1](#3221-identity) | +| `streetAddress` | NOT RECOMMENDED | If present, MUST contain the Subject's street address information. Multiple instances MAY be present.| [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | | `surname` | MUST NOT | - | - | | `givenName` | MUST NOT | - | - | | `organizationalUnitName` | - | - | - | | \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information. | [Section 3.2](#32-initial-identity-validation) | | \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | - | +| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] | `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | @@ -3031,7 +3032,7 @@ When encoding a `Name`, the CA SHALL ensure that: * Each `RelativeDistinguishedName` MUST contain exactly one `AttributeTypeAndValue`. * Each `RelativeDistinguishedName`, if present, is encoded within the `RDNSequence` in the order that it appears in [Section 7.1.4.2](#7142-subject-attribute-encoding). * For example, a `RelativeDistinguishedName` that contains a `countryName` `AttributeTypeAndValue` pair MUST be encoded within the `RDNSequence` before a `RelativeDistinguishedName` that contains a `stateOrProvinceName` `AttributeTypeAndValue`. - * Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s. + * Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s unless explicitly allowed in these Requirements. **Note**: [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) provides an exception to the above `Name` encoding requirements when issuing a [Cross-Certified Subordinate CA Certificate](#7122-cross-certified-subordinate-ca-certificate-profile), as described within that section. From 948dda6ff0a1317daff486b887451062b7002e74 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Wed, 26 Oct 2022 07:22:42 -0400 Subject: [PATCH 44/54] Add order and encoding requirement for DC attribute (#395) Co-authored-by: Corey Bonnell --- docs/BR.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/BR.md b/docs/BR.md index 58c5fd20..7a06561e 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -3046,6 +3046,7 @@ Table: Encoding and Order Requirements for Selected Attributes | __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | | ---- | -- | --- | ---- | - | +| `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 | | `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | | `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | | `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | From 50cee81640779da2847adf19d3676c2c5d81a11c Mon Sep 17 00:00:00 2001 From: Dimitris Zacharopoulos Date: Thu, 3 Nov 2022 21:42:08 +0200 Subject: [PATCH 45/54] 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 * 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 --- docs/BR.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/BR.md b/docs/BR.md index 7a06561e..d8af63fb 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2692,6 +2692,7 @@ The following table details the acceptable `AttributeType`s that may appear with | `postalCode` | MAY | If present, the CA's zip or postal information. | [Section 3.2.2.1](#3221-identity) | | `streetAddress` | MAY | If present, the CA's street address. Multiple instances MAY be present. | [Section 3.2.2.1](#3221-identity) | | `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `organizationalUnitName` | This attribute MUST NOT be included in Root CA Certificates defined in [Section 7.1.2.1](#7121-root-ca-certificate-profile) or TLS Subordinate CA Certificates defined in [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) or Technically-Constrained TLS Subordinate CA Certificates defined in [Section 7.1.2.6](#7126-tls-subordinate-ca-certificate-profile). This attribute SHOULD NOT be included in other types of CA Certificates. | - | - | | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | From 253bc269cdbe6a739103242a22503bd424da7af9 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Mon, 14 Nov 2022 14:33:23 +0000 Subject: [PATCH 46/54] 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 --- docs/BR.md | 20 +++++--------------- 1 file changed, 5 insertions(+), 15 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index d8af63fb..4b31716a 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1933,7 +1933,6 @@ Each included Extended Key Usage key usage purpose: a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or, b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context. 2. MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance. - 3. MUST NOT be included unless the Certificate conforms to the relevant specification defining the key usage purpose. CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate. @@ -2108,7 +2107,7 @@ Table: `nameConstraints` requirements | __Field__ | __Description__ | | -- | ------- | -| `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. | +| `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` name type appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. | | \ \ \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | | \ \ \ \ \ \ \ \ `base` | See following table. | | \ \ \ \ \ \ \ \ `minimum` | MUST NOT be present. | @@ -2262,10 +2261,7 @@ Table: Individual Validated `subject` Attributes | `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | -In addition, the following requirements apply to `subject` Attributes: - - * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. - * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. +In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. ##### 7.1.2.7.4 Organization Validated @@ -2300,10 +2296,7 @@ Table: Individual Validated `subject` Attributes | `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | -In addition, the following requirements apply to `subject` Attributes: - - * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. - * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. +In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. ##### 7.1.2.7.5 Extended Validation @@ -2316,10 +2309,7 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | -In addition, the following requirements apply to `subject` Attributes: - - * `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. - * `subject` Attributes other than `commonName` MUST NOT include a Domain Name or IP Address. +In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. ##### 7.1.2.7.6 Subscriber Certificate Extensions @@ -3071,7 +3061,7 @@ Table: Encoding Requirements for Selected Attributes | `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | | `jurisdictionStateOrProvince` | `1.3.6.1.4.1.311.60.2.1.2` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | | `jurisdictionLocality` | `1.3.6.1.4.1.311.60.2.1.1` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | -| `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 | | `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None | [^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. From eca3d08974058d682b39b5291bb3b3d7e133d202 Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 1 Dec 2022 17:19:25 +0000 Subject: [PATCH 47/54] Integrate newer ballots (#406) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update README (#294) Co-authored-by: Jos Purvis * 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 Co-authored-by: Ryan Sleevi Co-authored-by: Jos Purvis * 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 Co-authored-by: Wayne Thayer * 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 Co-authored-by: Ryan Sleevi * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos * 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 Co-authored-by: Ryan Sleevi * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos Purvis * 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] * 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] * 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 * Update version and date table Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Jos Purvis * 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 * Update version, table, and date Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell Co-authored-by: Jos Purvis * 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] 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] * 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] * 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 * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Jos Purvis * 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 * 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 * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos Co-authored-by: Corey Bonnell Co-authored-by: Jos Purvis * Integrate SC-48 CN requirements Co-authored-by: Jos Co-authored-by: Jos Purvis Co-authored-by: Ryan Sleevi Co-authored-by: Paul van Brouwershaven Co-authored-by: Ryan Sleevi Co-authored-by: Wayne Thayer Co-authored-by: Corey Bonnell Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Dimitris Zacharopoulos --- .github/workflows/build-draft-docs.yml | 22 +-- README.md | 4 +- docs/BR.md | 191 ++++++++++++++++--------- docs/EVG.md | 90 ++---------- 4 files changed, 154 insertions(+), 153 deletions(-) diff --git a/.github/workflows/build-draft-docs.yml b/.github/workflows/build-draft-docs.yml index 1be3e0fd..96fb4425 100644 --- a/.github/workflows/build-draft-docs.yml +++ b/.github/workflows/build-draft-docs.yml @@ -1,38 +1,38 @@ name: Build Draft Guidelines -on: [push, pull_request] +on: [push, pull_request, workflow_dispatch] jobs: build_docs: strategy: matrix: document: - - 'BR.md' - - 'EVG.md' - - 'NSR.md' + - 'BR' + - 'EVG' + - 'NSR' name: Build ${{ matrix.document }} runs-on: ubuntu-20.04 steps: - name: Checkout the code - uses: actions/checkout@v2 - - name: Checkout old version for redline (pull request) - uses: actions/checkout@v2 + uses: actions/checkout@v3 + - name: Checkout old version for redline + if: ${{ github.event_name == 'pull_request' || github.event_name == 'push' }} + uses: actions/checkout@v3 with: ref: ${{ github.event.pull_request.base.sha || github.event.push.before }} path: old/ - uses: docker://ghcr.io/sleevi/build-guidelines-action:tables id: build_doc with: - markdown_file: docs/${{ matrix.document }} - diff_file: old/docs/${{ matrix.document }} + markdown_file: docs/${{ matrix.document }}.md + diff_file: old/docs/${{ matrix.document }}.md pdf: true docx: true lint: true draft: ${{ !(github.event_name == 'push' && github.repository == 'cabforum/servercert' && github.ref == 'refs/heads/main') }} - uses: actions/upload-artifact@v2 with: - name: ${{ matrix.document }}-${{ github.event.pull_request.head.sha || github.sha }} + name: ${{ matrix.document }}-${{ github.event.pull_request.head.sha || github.sha }}-${{ github.event_name }} path: | ${{ steps.build_doc.outputs.pdf_file }} ${{ steps.build_doc.outputs.docx_file }} ${{ steps.build_doc.outputs.pdf_redline_file }} if-no-files-found: 'error' - retention-days: 21 diff --git a/README.md b/README.md index 768e2c81..bff869e5 100644 --- a/README.md +++ b/README.md @@ -8,6 +8,6 @@ In particular, the following Final Guidelines are maintained by the SCWG: * [Baseline Requirements](https://cabforum.org/baseline-requirements/) Pandoc-flavored Markdown: [docs/BR.md](docs/BR.md) * [EV SSL Certificate Guidelines](https://cabforum.org/extended-validation/) - Kramdown-flavored Markdown: [docs/EVG.md](docs/EVG.md) + Pandoc-flavored Markdown: [docs/EVG.md](docs/EVG.md) * [Network Security Requirements](https://cabforum.org/network-security-requirements/) - Kramdown-flavored Markdown: [docs/NSR.md](docs/NSR.md) + Pandoc-flavored Markdown: [docs/NSR.md](docs/NSR.md) diff --git a/docs/BR.md b/docs/BR.md index 4b31716a..aa2930f9 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,11 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates -subtitle: Version 1.7.8 +subtitle: Version 1.8.4 author: - CA/Browser Forum -date: 13 July, 2021 +date: 23 April, 2022 copyright: | - Copyright 2021 CA/Browser Forum + Copyright 2022 CA/Browser Forum This work is licensed under the Creative Commons Attribution 4.0 International license. --- @@ -121,6 +121,12 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 1.7.6 | SC44 | Clarify Acceptable Status Codes | 30-Apr-2021 | 3-Jun-2021 | | 1.7.7 | SC46 | Sunset the CAA Exception for DNS Operator | 2-Jun-2021 | 12-Jul-2021 | | 1.7.8 | SC45 | Wildcard Domain Validation | 2-Jun-2021 | 13-Jul-2021 | +| 1.7.9 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | +| 1.8.0 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | +| 1.8.1 | SC50 | Remove the requirements of 4.1.1 | 22-Nov-2021 | 23-Dec-2021 | +| 1.8.2 | SC53 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | +| 1.8.3 | SC51 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | +| 1.8.4 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -136,7 +142,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 2013-12-31 | 6.1.5 | CAs SHALL confirm that the RSA Public Key is at least 2048 bits or that one of the following ECC curves is used: P-256, P-384, or P-521. A Root CA Certificate issued prior to 31 Dec. 2010 with an RSA key size less than 2048 bits MAY still serve as a trust anchor. | | 2015-01-16 | 7.1.3 | CAs SHOULD NOT issue Subscriber Certificates utilizing the SHA-1 algorithm with an Expiry Date greater than 1 January 2017. | | 2015-04-01 | 6.3.2 | CAs SHALL NOT issue certificates with validity periods longer than 39 months, except under certain circumstances. | -| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully Qualified Domain Names. | +| 2015-04-15 | 2.2 | A CA's CPS must state whether it reviews CAA Records, and if so, its policy or practice on processing CAA records for Fully-Qualified Domain Names. | | 2015-11-01 | 7.1.4.2.1 | Issuance of Certificates with Reserved IP Address or Internal Name prohibited. | | 2016-01-01 | 7.1.3 | CAs MUST NOT issue any new Subscriber certificates or Subordinate CA certificates using the SHA-1 hash algorithm. | | 2016-06-30 | 6.1.7 | CAs MUST NOT issue Subscriber Certificates directly from Root CAs. | @@ -164,7 +170,10 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 2020-09-30 | 7.2 and 7.3 | All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code. | | 2021-07-01 | 3.2.2.8 | CAA checking is no longer optional if the CA is the DNS Operator or an Affiliate. | | 2021-07-01 | 3.2.2.4.18 and 3.2.2.4.19 | Redirects MUST be the result of one of the HTTP status code responses defined. | +| 2021-10-01 | 7.1.4.2.1 | Fully-Qualified Domain Names MUST consist solely of P-Labels and Non-Reserved LDH Labels. | | 2021-12-01 | 3.2.2.4 | CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard certificates or with Authorization Domain Names other than the FQDN. | +| 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. | +| 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | ## 1.3 PKI Participants @@ -241,6 +250,8 @@ No stipulation. ## 1.6 Definitions and Acronyms +The Definitions found in the CA/Browser Forum's Network and Certificate System Security Requirements are incorporated by reference as if fully set forth herein. + ### 1.6.1 Definitions **Affiliate**: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity. @@ -261,11 +272,11 @@ No stipulation. **Audit Report**: A report from a Qualified Auditor stating the Qualified Auditor's opinion on whether an entity's processes and controls comply with the mandatory provisions of these Requirements. -**Authorization Domain Name**: The Domain Name used to obtain authorization for certificate issuance for a given FQDN. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If the FQDN contains a wildcard character, then the CA MUST remove all wildcard labels from the left most portion of requested FQDN. The CA may prune zero or more labels from left to right until encountering a Base Domain Name and may use any one of the intermediate values for the purpose of domain validation. +**Authorization Domain Name**: The FQDN used to obtain authorization for a given FQDN to be included in a Certificate. The CA may use the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of domain validation. If a Wildcard Domain Name is to be included in a Certificate, then the CA MUST remove "`*.`" from the left-most portion of the Wildcard Domain Name to yield the corresponding FQDN. The CA may prune zero or more Domain Labels of the FQDN from left to right until encountering a Base Domain Name and may use any one of the values that were yielded by pruning (including the Base Domain Name itself) for the purpose of domain validation. **Authorized Ports**: One of the following ports: 80 (http), 443 (https), 25 (smtp), 22 (ssh). -**Base Domain Name**: The portion of an applied-for FQDN that is the first domain name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right-most domain name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name. +**Base Domain Name**: The portion of an applied-for FQDN that is the first Domain Name node left of a registry-controlled or public suffix plus the registry-controlled or public suffix (e.g. "example.co.uk" or "example.com"). For FQDNs where the right-most Domain Name node is a gTLD having ICANN Specification 13 in its registry agreement, the gTLD itself may be used as the Base Domain Name. **CAA**: From RFC 8659 (): "The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain name. CAA Resource Records allow a public CA to implement additional controls to reduce the risk of unintended certificate mis-issue." @@ -311,7 +322,9 @@ No stipulation. **Domain Contact**: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar. -**Domain Name**: The label assigned to a node in the Domain Name System. +**Domain Label**: From RFC 8499 (): "An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names." + +**Domain Name**: An ordered list of one or more Domain Labels assigned to a node in the Domain Name System. **Domain Namespace**: The set of all possible Domain Names that are subordinate to a single node in the Domain Name System. @@ -327,7 +340,7 @@ No stipulation. **Expiry Date**: The "Not After" date in a Certificate that defines the end of a Certificate's validity period. -**Fully-Qualified Domain Name**: A Domain Name that includes the labels of all superior nodes in the Internet Domain Name System. +**Fully-Qualified Domain Name**: A Domain Name that includes the Domain Labels of all superior nodes in the Internet Domain Name System. **Government Entity**: A government-operated legal entity, agency, department, ministry, branch, or similar element of the government of a country, or political subdivision within such country (such as a state, province, city, county, etc.). @@ -335,7 +348,7 @@ No stipulation. **Internal Name**: A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top Level Domain registered in IANA's Root Zone Database. -**IP Address**: A 32-bit or 128-bit label assigned to a device that uses the Internet Protocol for communication. +**IP Address**: A 32-bit or 128-bit number assigned to a device that uses the Internet Protocol for communication. **IP Address Contact**: The person(s) or entity(ies) registered with an IP Address Registration Authority as having the right to control how one or more IP Addresses are used. @@ -349,16 +362,24 @@ No stipulation. **Key Pair**: The Private Key and its associated Public Key. +**LDH Label**: From RFC 5890 (): "A string consisting of ASCII letters, digits, and the hyphen with the further restriction that the hyphen cannot appear at the beginning or end of the string. Like all DNS labels, its total length must not exceed 63 octets." + **Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system. +**Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '--' in the third and fourth positions." + **Object Identifier**: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization's applicable standard for a specific object or object class. **OCSP Responder**: An online server operated under the authority of the CA and connected to its Repository for processing Certificate status requests. See also, Online Certificate Status Protocol. +**Onion Domain Name**: A Fully Qualified Domain Name ending with the RFC 7686 ".onion" Special-Use Domain Name. For example, `2gzyxa5ihm7nsggfxnu52rck2vv4rvmdlkiu3zzui5du4xyclen53wid.onion` is an Onion Domain Name, whereas `torproject.org` is not an Onion Domain Name. + **Online Certificate Status Protocol**: An online Certificate-checking protocol that enables relying-party application software to determine the status of an identified Certificate. See also OCSP Responder. **Parent Company**: A company that Controls a Subsidiary Company. +**P-Label**: A XN-Label that contains valid output of the Punycode algorithm (as defined in RFC 3492, Section 6.3) from the fifth and subsequent positions. + **Private Key**: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key. **Pending Prohibition​​**: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future. @@ -418,11 +439,11 @@ The script outputs: **Requirements**: The Baseline Requirements found in this document. -**Reserved IP Address**: An IPv4 or IPv6 address that the IANA has marked as reserved: +**Reserved IP Address**: An IPv4 or IPv6 address that is contained in the address block of any entry in either of the following IANA registries: -[http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml](http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml) +[https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml](https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml) -[http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml](http://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xml) +[https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml](https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml) **Root CA**: The top level Certification Authority whose Root Certificate is distributed by Application Software Suppliers and that issues Subordinate CA Certificates. @@ -432,7 +453,7 @@ The script outputs: **Subject**: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber. -**Subject Identity Information**: Information that identifies the Certificate Subject. Subject Identity Information does not include a domain name listed in the `subjectAltName` extension or the Subject `commonName` field. +**Subject Identity Information**: Information that identifies the Certificate Subject. Subject Identity Information does not include a Domain Name listed in the `subjectAltName` extension or the Subject `commonName` field. **Subordinate CA**: A Certification Authority whose Certificate is signed by the Root CA, or another Subordinate CA. @@ -460,9 +481,11 @@ The script outputs: **WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website. -**Wildcard Certificate**: A Certificate containing an asterisk (\*) in the left-most position of any of the Subject Fully-Qualified Domain Names contained in the Certificate. +**Wildcard Certificate**: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate. -**Wildcard Domain Name**: A Domain Name consisting of a single asterisk character followed by a single full stop character ("\*.") followed by a Fully-Qualified Domain Name. +**Wildcard Domain Name**: A string starting with "\*." (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully-Qualified Domain Name. + +**XN-Label**: From RFC 5890 (): "The class of labels that begin with the prefix `"xn--"` (case independent), but otherwise conform to the rules for LDH labels." ### 1.6.2 Acronyms @@ -517,16 +540,24 @@ RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requi RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, March 1999. +RFC3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. + RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003. RFC3912, Request for Comments: 3912, WHOIS Protocol Specification, Daigle, September 2004. +RFC3986, Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005. + RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake-Wilson, et al, April 2006. RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al, September 2007. RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, Cooper et al, May 2008. +RFC5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. + +RFC5952, Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010. + RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, Hoffman-Andrews, November 2019. RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013. @@ -539,6 +570,8 @@ RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format, Newton, et al, March 2015. +RFC8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019. + WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.3, available at . X.509, Recommendation ITU-T X.509 (10/2012) \| ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks. @@ -563,7 +596,7 @@ The CA SHALL publicly disclose its Certificate Policy and/or Certification Pract The Certificate Policy and/or Certification Practice Statement MUST be structured in accordance with RFC 3647 and MUST include all material required by RFC 3647. -Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice. +Section 4.2 of a CA's Certificate Policy and/or Certification Practice Statement SHALL state the CA's policy or practice on processing CAA Records for Fully-Qualified Domain Names; that policy shall be consistent with these Requirements. It shall clearly specify the set of Issuer Domain Names that the CA recognizes in CAA "issue" or "issuewild" records as permitting it to issue. The CA SHALL log all actions taken, if any, consistent with its processing practice. The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version. The CA MAY fulfill this requirement by incorporating these Requirements directly into its Certificate Policy and/or Certification Practice Statements or by incorporating them by reference using a clause such as the following (which MUST include a link to the official version of these Requirements): @@ -649,8 +682,8 @@ This section defines the permitted processes and procedures for validating the A The CA SHALL confirm that prior to issuance, the CA has validated each Fully-Qualified Domain Name (FQDN) listed in the Certificate as follows: -1. When the FQDN does not contain "onion" as the rightmost label, the CA SHALL validate the FQDN using at least one of the methods listed below; and -2. When the FQDN contains "onion" as the rightmost label, the CA SHALL validate the FQDN in accordance with Appendix B. +1. When the FQDN is not an Onion Domain Name, the CA SHALL validate the FQDN using at least one of the methods listed below; and +2. When the FQDN is an Onion Domain Name, the CA SHALL validate the FQDN in accordance with Appendix B. Completed validations of Applicant authority may be valid for the issuance of multiple Certificates over time. In all cases, the validation must have been initiated within the time period specified in the relevant requirement (such as [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document) prior to Certificate issuance. For purposes of domain validation, the term Applicant includes the Applicant's Parent Company, Subsidiary Company, or Affiliate. @@ -676,7 +709,7 @@ The CA MAY resend the email, fax, SMS, or postal mail in its entirety, including The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.3 Phone Contact with Domain Contact @@ -686,7 +719,7 @@ Each phone call SHALL be made to a single number and MAY confirm control of mult CAs SHALL NOT perform validations using this method after May 31, 2019. Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.4 Constructed Email to Domain Contact @@ -704,7 +737,7 @@ The email MAY be re-sent in its entirety, including the re-use of the Random Val The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.5 Domain Authorization Document @@ -724,18 +757,18 @@ If a Random Value is used, the CA SHALL provide a Random Value unique to the Cer CAs SHALL NOT perform validations using this method after June 3, 2020. CAs MAY continue to re-use information and validations for domains validated under this method per the applicable certificate data reuse periods. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.7 DNS Change -Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a label that begins with an underscore character. +Confirming the Applicant's control over the FQDN by confirming the presence of a Random Value or Request Token for either in a DNS CNAME, TXT or CAA record for either 1) an Authorization Domain Name; or 2) an Authorization Domain Name that is prefixed with a Domain Label that begins with an underscore character. If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after i. 30 days or ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.8 IP Address @@ -759,7 +792,7 @@ This method has been retired and MUST NOT be used. Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact. This method may only be used if the CA is also the Domain Name Registrar, or an Affiliate of the Registrar, of the Base Domain Name. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.13 Email to DNS CAA Contact @@ -769,7 +802,7 @@ Each email MAY confirm control of multiple FQDNs, provided that each email addre The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.14 Email to DNS TXT Contact @@ -779,7 +812,7 @@ Each email MAY confirm control of multiple FQDNs, provided that each email addre The Random Value SHALL be unique in each email. The email MAY be re-sent in its entirety, including the re-use of the Random Value, provided that its entire contents and recipient(s) SHALL remain unchanged. The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.15 Phone Contact with Domain Contact @@ -791,7 +824,7 @@ In the event of reaching voicemail, the CA may leave the Random Value and the AD The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.16 Phone Contact with DNS TXT Record Phone Contact @@ -803,7 +836,7 @@ In the event of reaching voicemail, the CA may leave the Random Value and the AD The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.17 Phone Contact with DNS CAA Phone Contact @@ -815,7 +848,7 @@ In the event of reaching voicemail, the CA may leave the Random Value and the AD The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values. -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. ##### 3.2.2.4.18 Agreed-Upon Change to Website v2 @@ -939,9 +972,10 @@ Confirming the Applicant's control over the IP Address by performing the procedu #### 3.2.2.6 Wildcard Domain Validation -Before issuing a certificate with a wildcard character (\*) in a CN or `subjectAltName` of type DNS-ID, the CA MUST establish and follow a documented procedure that determines if the wildcard character occurs in the first label position to the left of a "registry-controlled" label or "public suffix" (e.g. "\*.com", "\*.co.uk", see RFC 6454 Section 8.2 for further explanation). +Before issuing a Wildcard Certificate, the CA MUST establish and follow a documented procedure that determines if the FQDN portion of any +Wildcard Domain Name in the Certificate is “registry-controlled” or is a “public suffix” (e.g. “\*.com”, “\*.co.uk”, see RFC 6454 Section 8.2 for further explanation). -If a wildcard would fall within the label immediately to the left of a registry-controlled or public suffix, CAs MUST refuse issuance unless the applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "\*.co.uk" or "\*.local", but MAY issue "\*.example.com" to Example Co.). +If the FQDN portion of any Wildcard Domain Name is "registry-controlled" or is a "public suffix", CAs MUST refuse issuance unless the Applicant proves its rightful control of the entire Domain Namespace. (e.g. CAs MUST NOT issue "\*.co.uk" or "\*.local", but MAY issue "\*.example.com" to Example Co.). Determination of what is "registry-controlled" versus the registerable portion of a Country Code Top-Level Domain Namespace is not standardized at the time of writing and is not a property of the DNS itself. Current best practice is to consult a "public suffix list" such as the [Public Suffix List (PSL)](), and to retrieve a fresh copy regularly. @@ -961,7 +995,7 @@ Databases maintained by the CA, its owner, or its affiliated companies do not qu #### 3.2.2.8 CAA Records -As part of the issuance process, the CA MUST check for CAA records and follow the processing instructions found, for each `dNSName` in the `subjectAltName` extension of the certificate to be issued, as specified in RFC 8659. If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater. +As part of the Certificate issuance process, the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each `dNSName` in the `subjectAltName` extension that does not contain an Onion Domain Name. If the CA issues, they MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater. This stipulation does not prevent the CA from checking CAA records at any other time. @@ -1019,7 +1053,7 @@ The CA SHALL disclose all Cross-Certified Subordinate CA Certificates that ident ### 4.1.1 Who can submit a certificate application -In accordance with [Section 5.5.2](#552-retention-period-for-archive), the CA SHALL maintain an internal database of all previously revoked Certificates and previously rejected certificate requests due to suspected phishing or other fraudulent usage or concerns. The CA SHALL use this information to identify subsequent suspicious certificate requests. +No stipulation. ### 4.1.2 Enrollment process and responsibilities @@ -1476,7 +1510,7 @@ The CA SHALL verify that the Delegated Third Party's personnel involved in the i ### 5.4.1 Types of events recorded -The CA and each Delegated Third Party SHALL record details of the actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with these Requirements. +The CA and each Delegated Third Party SHALL record events related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems. The CA and each Delegated Third Party SHALL record events related to their actions taken to process a certificate request and to issue a Certificate, including all information generated and documentation received in connection with the certificate request; the time and date; and the personnel involved. The CA SHALL make these records available to its Qualified Auditor as proof of the CA’s compliance with these Requirements. The CA SHALL record at least the following events: @@ -1485,15 +1519,17 @@ The CA SHALL record at least the following events: 2. Certificate requests, renewal, and re-key requests, and revocation; 3. Approval and rejection of certificate requests; 4. Cryptographic device lifecycle management events; - 5. Generation of Certificate Revocation Lists and OCSP entries; - 6. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles. + 5. Generation of Certificate Revocation Lists; + 6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)); and + 7. Introduction of new Certificate Profiles and retirement of existing Certificate Profiles. 2. Subscriber Certificate lifecycle management events, including: 1. Certificate requests, renewal, and re-key requests, and revocation; 2. All verification activities stipulated in these Requirements and the CA's Certification Practice Statement; 3. Approval and rejection of certificate requests; - 4. Issuance of Certificates; and - 5. Generation of Certificate Revocation Lists and OCSP entries. + 4. Issuance of Certificates; + 5. Generation of Certificate Revocation Lists; and + 6. Signing of OCSP Responses (as described in [Section 4.9](#49-certificate-revocation-and-suspension) and [Section 4.10](#410-certificate-status-services)). 3. Security events, including: 1. Successful and unsuccessful PKI system access attempts; @@ -1506,27 +1542,29 @@ The CA SHALL record at least the following events: Log records MUST include the following elements: -1. Date and time of record; +1. Date and time of event; 2. Identity of the person making the journal record; and -3. Description of the record. +3. Description of the event. -### 5.4.2 Frequency for Processing and Archiving Audit Logs +### 5.4.2 Frequency of processing audit log -### 5.4.3 Retention Period for Audit Logs +### 5.4.3 Retention period for audit log -The CA SHALL retain, for at least two years: +The CA and each Delegated Third Party SHALL retain, for at least two (2) years: 1. CA certificate and key lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (1)) after the later occurrence of: 1. the destruction of the CA Private Key; or 2. the revocation or expiration of the final CA Certificate in that set of Certificates that have an X.509v3 `basicConstraints` extension with the `cA` field set to true and which share a common Public Key corresponding to the CA Private Key; - 2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the revocation or expiration of the Subscriber Certificate; + 2. Subscriber Certificate lifecycle management event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (2)) after the expiration of the Subscriber Certificate; 3. Any security event records (as set forth in [Section 5.4.1](#541-types-of-events-recorded) (3)) after the event occurred. -### 5.4.4 Protection of Audit Log +Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past audit log events. + +### 5.4.4 Protection of audit log -### 5.4.5 Audit Log Backup Procedures +### 5.4.5 Audit log backup procedures -### 5.4.6 Audit Log Accumulation System (internal vs. external) +### 5.4.6 Audit collection System (internal vs. external) ### 5.4.7 Notification to event-causing subject @@ -1542,9 +1580,23 @@ Additionally, the CA's security program MUST include an annual Risk Assessment t ### 5.5.1 Types of records archived +The CA and each Delegated Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)). + +Additionally, the CA and each Delegated Party SHALL archive: +1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and +2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates. + ### 5.5.2 Retention period for archive -The CA SHALL retain all documentation relating to certificate requests and the verification thereof, and all Certificates and revocation thereof, for at least seven years after any Certificate based on that documentation ceases to be valid. +Archived audit logs (as set forth in [Section 5.5.1](#551-types-of-records-archived) SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per [Section 5.4.3](#543-retention-period-for-audit-log), whichever is longer. + +Additionally, the CA and each delegated party SHALL retain, for at least two (2) years: +1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in [Section 5.5.1](#551-types-of-records-archived)); and +2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in [Section 5.5.1](#551-types-of-records-archived)) after the later occurrence of: + 1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or + 2. the expiration of the Subscriber Certificates relying upon such records and documentation. + +Note: While these Requirements set the minimum retention period, the CA MAY choose a greater value as more appropriate in order to be able to investigate possible security or other types of incidents that will require retrospection and examination of past records archived. ### 5.5.3 Protection of archive @@ -2226,7 +2278,7 @@ Table: Domain Validated `subject` Attributes | __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | | --- | - | ------ | -- | | `countryName` | MAY | The two-letter ISO 3166-1 country code for the country associated with the Subject. | [Section 3.2.2.3](#3223-verification-of-country) | -| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | | Any other attribute | MUST NOT | - | - | ##### 7.1.2.7.3 Individual Validated @@ -2258,7 +2310,7 @@ Table: Individual Validated `subject` Attributes | `organizationalUnitName` | - | - | - | | \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information. | [Section 3.2](#32-initial-identity-validation) | | \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | - | -| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. @@ -2293,7 +2345,7 @@ Table: Individual Validated `subject` Attributes | \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information. | [Section 3.2](#32-initial-identity-validation) | | \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | - | | `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] -| `commonName` | NOT RECOMMENDED | If present, MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's `subjectAltName` extension. | | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. @@ -2434,7 +2486,7 @@ Table: `GeneralName` within a `subjectAltName` extension | --- | - | ------ | | `otherName` | N | - | | `rfc822Name` | N | - | -| `dNSName` | Y | MUST contain the Fully-Qualified Domain Name. The Issuing CA MUST confirm that the Applicant controls or has been granted the right to use the Domain Name through a method specified in [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). As an exception to the requirement of RFC 5280 requirements, Wildcard FQDNs are permitted. All other domain labels MUST be in the "preferred name syntax" and thus MUST NOT contain underscore characters ("\_"). MUST NOT contain an Internal Name. | +| `dNSName` | Y | The entry MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). Wildcard Domain Names MUST be validated for consistency with [Section 3.2.2.6](#3226-wildcard-domain-validation). The entry MUST NOT contain an Internal Name. The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (".") character. The zero-length Domain Label representing the root zone of the Internet Domain Name System MUST NOT be included (e.g. "example.com" MUST be encoded as "example.com" and MUST NOT be encoded as "example.com."). | | `x400Address` | N | - | | `directoryName` | N | - | | `ediPartyName` | N | - | @@ -2982,6 +3034,7 @@ In addition, the CA MAY use the following signature algorithm and encoding if al * The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.2937.0) key purposes; and/or * The new Certificate's `basicConstraints` extension has a pathLenConstraint that is zero. * If used within an OCSP response, such as the `signatureAlgorithm` of a BasicOCSPResponse: + * The `producedAt` field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and, * All unexpired, un-revoked Certificates that contain the Public Key of the CA Key Pair and that have the same Subject Name MUST also contain an `extKeyUsage` extension with the only key usage present being the id-kp-ocspSigning (OID: 1.3.6.1.5.5.7.3.9) key usage. * If used within a CRL, such as the `signatureAlgorithm` field of a CertificateList or the `signature` field of a TBSCertList: * The CRL is referenced by one or more Root CA or Subordinate CA Certificates; and, @@ -3066,7 +3119,15 @@ Table: Encoding Requirements for Selected Attributes [^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. -#### 7.1.4.3 Other Subject Attributes +#### 7.1.4.3 Subscriber Certificate Common Name Attribute + +If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)). The value of the field MUST be encoded as follows: + + * If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2. + * If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4. + * If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation. + +#### 7.1.4.4 Other Subject Attributes When explicitly stated as permitted by the relavant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). @@ -3439,32 +3500,34 @@ The DNS TXT record MUST be placed on the "`_validation-contactemail`" subdomain The DNS TXT record MUST be placed on the "`_validation-contactphone`" subdomain of the domain being validated. The entire RDATA value of this TXT record MUST be a valid Global Number as defined in RFC 3966, Section 5.1.4, or it cannot be used. -# APPENDIX B – Issuance of Certificates for .onion Domain Names +# APPENDIX B – Issuance of Certificates for Onion Domain Names -This appendix defines permissible verification procedures for including one or more RFC 7686 ".onion" special-use Domain Names in a Certificate. +This appendix defines permissible verification procedures for including one or more Onion Domain Names in a Certificate. -1. The Domain Name MUST contain at least two labels, where the right-most label is "onion", and the label immediately preceding the right-most "onion" label is a valid Version 3 Onion Address, as defined in Section 6 of the Tor Rendezvous Specification - Version 3 located at . +1. The Domain Name MUST contain at least two Domain Labels, where the rightmost Domain Label is "onion", and the Domain Label immediately preceding the rightmost "onion" Domain Label is a valid Version 3 Onion Address, as defined in Section 6 of the Tor Rendezvous Specification - Version 3 located at . -2. The CA MUST verify the Applicant’s control over the .onion Domain Name using at least one of the methods listed below: +2. The CA MUST verify the Applicant’s control over the Onion Domain Name using at least one of the methods listed below: a. The CA MAY verify the Applicant's control over the .onion service by using one of the following methods from [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control): - i. [Section 3.2.2.4.6 - Agreed-Upon Change to Website](#32246-agreed-upon-change-to-website) - ii. [Section 3.2.2.4.18 - Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2) - iii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website-acme) + i. [Section 3.2.2.4.18 - Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2) + ii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website-acme) + iii. [Section 3.2.2.4.20 - TLS Using ALPN](#322420-tls-using-alpn) When these methods are used to verify the Applicant's control over the .onion service, the CA MUST use Tor protocol to establish a connection to the .onion hidden service. The CA MUST NOT delegate or rely on a third-party to establish the connection, such as by using Tor2Web. **Note**: This section does not override or supersede any provisions specified within the respective methods. The CA MUST only use a method if it is still permitted within that section and MUST NOT issue Wildcard Certificates or use it as an Authorization Domain Name, except as specified by that method. - b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the Attributes section of the certificationRequestInfo contains: + b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion service's private key if the Attributes section of the certificationRequestInfo contains: i. A caSigningNonce attribute that contains a Random Value that is generated by the CA; and - ii. An applicantSigningNonce attribute that contains a single value with at least 64-bits of entropy that is generated by the Applicant. + ii. An applicantSigningNonce attribute that contains a single value. The CA MUST recommend to Applicants that the applicantSigningNonce value should contain at least 64 bits of entropy. The signing nonce attributes have the following format: ```ASN.1 + cabf OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) } + caSigningNonce ATTRIBUTE ::= { WITH SYNTAX OCTET STRING EQUALITY MATCHING RULE octetStringMatch @@ -3488,4 +3551,4 @@ This appendix defines permissible verification procedures for including one or m Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. -3. When a Certificate includes an FQDN where "onion" is in the right-most label of the Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this [Appendix B](#appendix-b--issuance-of-certificates-for-onion-domain-names). +3. When a Certificate includes an Onion Domain Name, the Domain Name shall not be considered an Internal Name provided that the Certificate was issued in compliance with this [Appendix B](#appendix-b--issuance-of-certificates-for-onion-domain-names). diff --git a/docs/EVG.md b/docs/EVG.md index fd1581d2..016961d1 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1,18 +1,18 @@ --- title: Guidelines for the Issuance and Management of Extended Validation Certificates -subtitle: Version 1.7.6 +subtitle: Version 1.7.9 author: - CA/Browser Forum -date: 2 June, 2021 +date: 23 April, 2022 copyright: | - Copyright 2021 CA/Browser Forum + Copyright 2022 CA/Browser Forum This work is licensed under the Creative Commons Attribution 4.0 International license. --- # Introduction -This version 1.7.4 represents the Extended Validation Guidelines, as adopted by the CA/Browser Forum as of Ballot SC35, passed by the Server Certificate Working Group on 9 September 2020, and effective as of 19 October 2020. +This version 1.7.8 represents the Extended Validation Guidelines, as adopted by the CA/Browser Forum as of Ballot SC48, passed by the Server Certificate Working Group on 22 July 2021, and effective as of 25 August 2021. The Guidelines describe an integrated set of technologies, protocols, identity proofing, lifecycle management, and auditing practices specifying the minimum requirements that must be met in order to issue and maintain Extended Validation Certificates ("EV Certificates") concerning an organization. Subject Organization information from valid EV Certificates can then be used in a special manner by certain relying-party software applications (e.g., browser software) in order to provide users with a trustworthy confirmation of the identity of the entity that controls the Web site or other services they are accessing. Although initially intended for use in establishing Web-based data communication conduits via TLS/SSL protocols, extensions are envisioned for S/MIME, time-stamping, VoIP, IM, Web services, etc. @@ -68,6 +68,9 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti | 1.7.4 | SC35 | Cleanups and Clarifications | 9-Sep-2020 | 19-Oct-2020 | | 1.7.5 | SC41 | Reformatting the BRs, EVGs, and NCSSRs | 24-Feb-2021 | 5-Apr-2021 | | 1.7.6 | SC42 | 398-day Re-use Period | 22-Apr-2021 | 2-Jun-2021 | +| 1.7.7 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | +| 1.7.8 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | +| 1.7.9 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -78,6 +81,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti | 2020-01-31 | [9.2.8](#928-subject-organization-identifier-field) | If subject:organizationIdentifier is present, the CA/Browser Forum Organization Identifier Extension MUST be present | | 2020-09-01 | [9.4](#94-maximum-validity-period-for-ev-certificate) & [Appendix F](#appendix-f--issuance-of-certificates-for-onion-domain-names) | Certificates issued MUST NOT have a Validity Period greater than 398 days. | | 2020-10-01 | [11.1.3](#1113-disclosure-of-verification-sources) | Prior to using an Incorporating Agency or Registration Agency, the CA MUST ensure the agency has been publicly disclosed | +| 2022-09-01 | [9.2.7](#927-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | **Implementers' Note**: Version 1.3 of these EV Guidelines was published on 20 November 2010 and supplemented through May 2012 when version 1.4 was published. ETSI TS 102 042 and ETSI TR 101 564 Technical Report: Guidance on ETSI TS 102 042 for Issuing Extended Validation Certificates for Auditors and CSPs reference version 1.3 of these EV Guidelines, and ETSI Draft EN 319 411-1 references version 1.4. Version 1.4.5 of Webtrust(r) for Certification Authorities – Extended Validation Audit Criteria references version 1.4.5 of these EV Guidelines. As illustrated in the Document History table above, the CA/Browser Forum continues to improve relevant industry guidelines, including this document, the Baseline Requirements, and the Network and Certificate System Security Requirements. We encourage all CAs to conform to each revision on the date specified without awaiting a corresponding update to an applicable audit criterion. In the event of a conflict between an existing audit criterion and a guideline revision, we will communicate with the audit community and attempt to resolve any uncertainty. We will respond to implementation questions directed to questions@cabforum.org. Our coordination with compliance auditors will continue as we develop guideline revision cycles that harmonize with the revision cycles for audit criteria, the compliance auditing periods and cycles of CAs, and the CA/Browser Forum's guideline implementation dates. @@ -462,7 +466,7 @@ If the combination of names or the organization name by itself exceeds 64 charac __Certificate Field__: `subject:commonName` (OID: 2.5.4.3) __Required/Optional__: Deprecated (Discouraged, but not prohibited) -__Contents__: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates except as permitted under [Appendix F](#appendix-f--issuance-of-certificates-for-onion-domain-names). +__Contents__: If present, this field MUST contain a single Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This field MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ### 9.2.3. Subject Business Category Field @@ -514,7 +518,7 @@ __Contents__: This field MUST contain the address of the physical location of th ### 9.2.7. Subject Organizational Unit Name Field __Certificate Field__: `subject:organizationalUnitName` (OID: 2.5.4.11) -__Required/Optional__: Optional +__Required/Optional/Prohibited:__ As stated in Section 7.1.4.2.2 i of the Baseline Requirements. __Contents__: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 11](#11-verification-requirements). This field MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. ### 9.2.8. Subject Organization Identifier Field @@ -646,7 +650,7 @@ If a CA includes an extension in a certificate that has a Certificate field whic __Certificate Field__: `subjectAltName:dNSName` __Required/Optional__: __Required__ -__Contents__: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). Wildcard certificates are not allowed for EV Certificates. +__Contents__: This extension MUST contain one or more host Domain Name(s) owned or controlled by the Subject and to be associated with the Subject's server. Such server MAY be owned and operated by the Subject or another entity (e.g., a hosting service). This extension MUST NOT contain a Wildcard Domain Name unless the FQDN portion of the Wildcard Domain Name is an Onion Domain Name verified in accordance with Appendix B of the Baseline Requirements. ### 9.8.2. CA/Browser Forum Organization Identifier Extension @@ -956,7 +960,7 @@ To verify the Applicant's ability to engage in business, the CA MUST verify the ### 11.7.1. Verification Requirements -1. For each Fully-Qualified Domain Name listed in a Certificate, other than a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to a Domain Name with .onion in the right-most label of the Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the .onion Domain Name in accordance with [Appendix F](#appendix-f--issuance-of-certificates-for-onion-domain-names). +1. For each Fully-Qualified Domain Name listed in a Certificate which is not an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant (or the Applicant's Parent Company, Subsidiary Company, or Affiliate, collectively referred to as "Applicant" for the purposes of this section) either is the Domain Name Registrant or has control over the FQDN using a procedure specified in Section 3.2.2.4 of the Baseline Requirements. For a Certificate issued to an Onion Domain Name, the CA SHALL confirm that, as of the date the Certificate was issued, the Applicant's control over the Onion Domain Name in accordance with Appendix B of the Baseline Requirements. 2. **Mixed Character Set Domain Names**: EV Certificates MAY include Domain Names containing mixed character sets only in compliance with the rules set forth by the domain registrar. The CA MUST visually compare any Domain Names with mixed character sets with known high risk domains. If a similarity is found, then the EV Certificate Request MUST be flagged as High Risk. The CA must perform reasonably appropriate additional authentication and verification to be certain beyond reasonable doubt that the Applicant and the target in question are the same organization. @@ -1637,75 +1641,9 @@ A CA may rely on the Contract Signer's authority to enter into the Subscriber Ag ii. is expressly authorized by [Applicant name] to sign Subscriber Agreements and approve EV Certificate requests on Applicant's behalf, and iii. has confirmed Applicant's right to use the domain(s) to be included in EV Certificates. -# Appendix F – Issuance of Certificates for .onion Domain Names - -A CA may issue an EV Certificate with .onion in the right-most label of the Domain Name provided that issuance complies with the requirements set forth in this Appendix or Appendix C of the Baseline Requirements. - -1. CAB Forum Tor Service Descriptor Hash extension (2.23.140.1.31) - - The CA MUST include the CAB Forum Tor Service Descriptor Hash extension in the `TBSCertificate` to convey hashes of keys related to .onion addresses. The CA MUST include the Tor Service Descriptor Hash extension using the following format: - - ```ASN.1 - cabf-TorServiceDescriptor OBJECT IDENTIFIER ::= { 2.23.140.1.31 } - - TorServiceDescriptorSyntax ::= - SEQUENCE (1..MAX) of TorServiceDescriptorHash - - TorServiceDescriptorHash:: = SEQUENCE { - onionURI UTF8String, - algorithm AlgorithmIdentifier, - subjectPublicKeyHash BIT STRING - } - ``` - - Where the `AlgorithmIdentifier` is a hashing algorithm (defined in RFC 6234) performed over the DER-encoding of an ASN.1 `subjectPublicKey` of the .onion service and `subjectPublicKeyHash` is the hash output. - -2. The CA MUST verify the Applicant's control over the .onion Domain Name using one of the following: - - a. The CA MAY verify the Applicant's control over the .onion service by posting a specific value at a well-known URL under RFC5785. - - b. The CA MAY verify the Applicant's control over the .onion service by having the Applicant provide a Certificate Request signed using the .onion public key if the `Attributes` section of the `certificationRequestInfo` contains: - - i. A `caSigningNonce` attribute that: - - 1. contains a single value with at least 64-bits of entropy, - 2. is generated by the CA, and - 3. delivered to the Applicant through a Verified Method of Communication and - - ii. An `applicantSigningNonce` attribute that: - - 1. contains a single value with at least 64-bits of entropy and - 2. is generated by the Applicant. - - The signing nonce attributes have the following format: - - ```ASN.1 - caSigningNonce ATTRIBUTE ::= { - WITH SYNTAX OCTET STRING - EQUALITY MATCHING RULE octetStringMatch - SINGLE VALUE TRUE - ID { cabf-caSigningNonce } - } - - cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 } - - applicantSigningNonce ATTRIBUTE ::= { - WITH SYNTAX OCTET STRING - EQUALITY MATCHING RULE octetStringMatch - SINGLE VALUE TRUE - ID { cabf-applicantSigningNonce } - } - - cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 } - ``` - -3. Each Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name MUST conform to the requirements of these Guidelines, including the content requirements in Section 7.1 of the Baseline Requirements, except that the CA MAY include a wildcard character in the Subject Alternative Name Extension and Subject Common Name Field as the left-most character in the .onion Domain Name provided inclusion of the wildcard character complies with Section 3.2.2.6 of the Baseline Requirements. - -4. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a Validity Period longer than 15 months. Effective 2020-09-01, CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a Validity Period longer than 398 days. - -5. When a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name, the Domain Name shall not be considered an Internal Name if the Certificate was issued in compliance with this [Appendix F](#appendix-f--issuance-of-certificates-for-onion-domain-names). +# Appendix F – Unused -6. On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this [Appendix F](#appendix-f--issuance-of-certificates-for-onion-domain-names). +This appendix is intentionally left blank. # Appendix G – Abstract Syntax Notation One module for EV certificates From 070bef1ba8c6c1fecabd22b774fcec453cc2658a Mon Sep 17 00:00:00 2001 From: Corey Bonnell Date: Thu, 12 Jan 2023 12:01:40 -0500 Subject: [PATCH 48/54] Integrate SC-56 and SC-58 (#409) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Update README (#294) Co-authored-by: Jos Purvis * 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 Co-authored-by: Ryan Sleevi Co-authored-by: Jos Purvis * 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 Co-authored-by: Wayne Thayer * 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 Co-authored-by: Ryan Sleevi * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos * 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 Co-authored-by: Ryan Sleevi * Fix double negative * Fix redundant "if the" Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos * Wrap xn-- to prevent ligaturization * Update dates and version numbers Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell Co-authored-by: Ryan Sleevi Co-authored-by: Jos Purvis * 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] * 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] * 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 * Update version and date table Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Jos Purvis * 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 * Update version, table, and date Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell Co-authored-by: Jos Purvis * 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] 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] * 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] * 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 * Update effective date and version number * Update ballot table in document * Fix date string Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Jos Purvis * 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 * 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 * Update version numbers and dates Co-authored-by: Dimitris Zacharopoulos Co-authored-by: Corey Bonnell Co-authored-by: Jos Purvis * 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 * Update effective dates and tables Co-authored-by: Corey Bonnell Co-authored-by: Corey Bonnell * 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 Co-authored-by: Jos Co-authored-by: Jos Purvis Co-authored-by: Ryan Sleevi Co-authored-by: Paul van Brouwershaven Co-authored-by: Ryan Sleevi Co-authored-by: Wayne Thayer Co-authored-by: Corey Bonnell Co-authored-by: Clint Wilson Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: Clint Wilson Co-authored-by: Dimitris Zacharopoulos Co-authored-by: Iñigo Barreira <92998585+barrini@users.noreply.github.com> Co-authored-by: Aaron Gable --- .github/workflows/build-draft-docs.yml | 4 +- docs/BR.md | 183 +++++++++++-------------- docs/EVG.md | 47 +++---- 3 files changed, 99 insertions(+), 135 deletions(-) diff --git a/.github/workflows/build-draft-docs.yml b/.github/workflows/build-draft-docs.yml index 96fb4425..f156aa54 100644 --- a/.github/workflows/build-draft-docs.yml +++ b/.github/workflows/build-draft-docs.yml @@ -19,7 +19,7 @@ jobs: with: ref: ${{ github.event.pull_request.base.sha || github.event.push.before }} path: old/ - - uses: docker://ghcr.io/sleevi/build-guidelines-action:tables + - uses: docker://ghcr.io/cabforum/build-guidelines-action:2.1.0 id: build_doc with: markdown_file: docs/${{ matrix.document }}.md @@ -28,7 +28,7 @@ jobs: docx: true lint: true draft: ${{ !(github.event_name == 'push' && github.repository == 'cabforum/servercert' && github.ref == 'refs/heads/main') }} - - uses: actions/upload-artifact@v2 + - uses: actions/upload-artifact@v3 with: name: ${{ matrix.document }}-${{ github.event.pull_request.head.sha || github.sha }}-${{ github.event_name }} path: | diff --git a/docs/BR.md b/docs/BR.md index aa2930f9..928e07a8 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,9 +1,10 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates -subtitle: Version 1.8.4 +subtitle: Version 1.8.6 author: - CA/Browser Forum -date: 23 April, 2022 +date: 14 December, 2022 + copyright: | Copyright 2022 CA/Browser Forum @@ -32,7 +33,7 @@ These Requirements are applicable to all Certification Authorities within a chai This certificate policy (CP) contains the requirements for the issuance and management of publicly-trusted SSL certificates, as adopted by the CA/Browser Forum. -The following Certificate Policy identifiers are reserved for use by CAs as an optional means of asserting compliance with this document (OID arc 2.23.140.1.2) as follows: +The following Certificate Policy identifiers are reserved for use by CAs to assert compliance with this document (OID arc 2.23.140.1.2) as follows: `{joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) certificate-policies(1) baseline-requirements(2) domain-validated(1)} (2.23.140.1.2.1);` and @@ -127,6 +128,9 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 1.8.2 | SC53 | Sunset for SHA-1 OCSP Signing | 26-Jan-2022 | 4-Mar-2022 | | 1.8.3 | SC51 | Reduce and Clarify Log and Records Archival Retention Requirements | 01-Mar-2022 | 15-Apr-2022 | | 1.8.4 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | +| 1.8.5 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | +| 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | + \* Effective Date and Additionally Relevant Compliance Date(s) @@ -166,7 +170,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 2020-09-01 | 6.3.2 | Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. | | 2020-09-30 | 4.9.10 | OCSP responses MUST conform to the validity period requirements specified. | | 2020-09-30 | 7.1.4.1 | Subject and Issuer Names for all possible certification paths MUST be byte-for-byte identical. | -| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Form Reserved Policy Identifier in the Certificate Policies extension. | +| 2020-09-30 | 7.1.6.4 | Subscriber Certificates MUST include a CA/Browser Forum Reserved Policy Identifier in the Certificate Policies extension. | | 2020-09-30 | 7.2 and 7.3 | All OCSP and CRL responses for Subordinate CA Certificates MUST include a meaningful reason code. | | 2021-07-01 | 3.2.2.8 | CAA checking is no longer optional if the CA is the DNS Operator or an Affiliate. | | 2021-07-01 | 3.2.2.4.18 and 3.2.2.4.19 | Redirects MUST be the result of one of the HTTP status code responses defined. | @@ -174,6 +178,7 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o | 2021-12-01 | 3.2.2.4 | CAs MUST NOT use methods 3.2.2.4.6, 3.2.2.4.18, or 3.2.2.4.19 to issue wildcard certificates or with Authorization Domain Names other than the FQDN. | | 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. | | 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | +| 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | ## 1.3 PKI Participants @@ -256,7 +261,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Affiliate**: A corporation, partnership, joint venture or other entity controlling, controlled by, or under common control with another entity, or an agency, department, political subdivision, or any entity operating under the direct control of a Government Entity. -**Applicant**: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate issues, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request. +**Applicant**: The natural person or Legal Entity that applies for (or seeks renewal of) a Certificate. Once the Certificate is issued, the Applicant is referred to as the Subscriber. For Certificates issued to devices, the Applicant is the entity that controls or operates the device named in the Certificate, even if the device is sending the actual certificate request. **Applicant Representative**: A natural person or human sponsor who is either the Applicant, employed by the Applicant, or an authorized agent who has express authority to represent the Applicant: @@ -292,21 +297,21 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Certificate Problem Report**: Complaint of suspected Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, or inappropriate conduct related to Certificates. +**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles), e.g. a Section in a CA’s CPS or a certificate template file used by CA software. + **Certificate Revocation List**: A regularly updated time-stamped list of revoked Certificates that is created and digitally signed by the CA that issued the Certificates. -**Certification Authority**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs. +**Certification Authority**: An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs. **Certification Practice Statement**: One of several documents forming the governance framework in which Certificates are created, issued, managed, and used. -**Certificate Profile**: A set of documents or files that defines requirements for Certificate content and Certificate extensions in accordance with [Section 7](#7-certificate-crl-and-ocsp-profiles). e.g. a Section in a CA’s CPS or a certificate template file used by CA software. - **Control**: "Control" (and its correlative meanings, "controlled by" and "under common control with") means possession, directly or indirectly, of the power to: (1) direct the management, personnel, finances, or plans of such entity; (2) control the election of a majority of the directors ; or (3) vote that portion of voting shares required for "control" under the law of the entity's Jurisdiction of Incorporation or Registration but in no case less than 10%. **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations. **Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two Root CAs. -**CSPRNG**: A random number generator intended for use in cryptographic system. +**CSPRNG**: A random number generator intended for use in a cryptographic system. **Delegated Third Party**: A natural person or Legal Entity that is not the CA but is authorized by the CA, and whose activities are not within the scope of the appropriate CA audits, to assist in the Certificate Management Process by performing or fulfilling one or more of the CA requirements found herein. @@ -318,8 +323,6 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **DNS TXT Record Phone Contact**: The phone number defined in [Appendix A.2.2](#a22-dns-txt-record-phone-contact). -**Domain Authorization Document**: Documentation provided by, or a CA's documentation of a communication with, a Domain Name Registrar, the Domain Name Registrant, or the person or entity listed in WHOIS as the Domain Name Registrant (including any private, anonymous, or proxy registration service) attesting to the authority of an Applicant to request a Certificate for a specific Domain Namespace. - **Domain Contact**: The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct contact with the Domain Name Registrar. **Domain Label**: From RFC 8499 (): "An ordered list of zero or more octets that makes up a portion of a domain name. Using graph theory, a label identifies one node in a portion of the graph of all possible domain names." @@ -366,7 +369,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Legal Entity**: An association, corporation, partnership, proprietorship, trust, government entity or other entity with legal standing in a country's legal system. -**Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '--' in the third and fourth positions." +**Non-Reserved LDH Label**: From RFC 5890 (): "The set of valid LDH labels that do not have '`--`' in the third and fourth positions." **Object Identifier**: A unique alphanumeric or numeric identifier registered under the International Organization for Standardization's applicable standard for a specific object or object class. @@ -475,9 +478,9 @@ The script outputs: **Valid Certificate**: A Certificate that passes the validation procedure specified in RFC 5280. -**Validation Specialists**: Someone who performs the information verification duties specified by these Requirements. +**Validation Specialist**: Someone who performs the information verification duties specified by these Requirements. -**Validity Period**: Prior to 2020-09-01, the period of time measured from the date when the Certificate is issued until the Expiry Date. For Certificates issued on or after 2020-09-01, the validity period is as defined within RFC 5280, Section 4.1.2.5: the period of time from notBefore through notAfter, inclusive. +**Validity Period**: From RFC 5280 (): "The period of time from notBefore through notAfter, inclusive." **WHOIS**: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website. @@ -528,53 +531,51 @@ ETSI TS 102 042, Electronic Signatures and Infrastructures (ESI); Policy require FIPS 140-2, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, May 25, 2001. +FIPS 140-3, Federal Information Processing Standards Publication - Security Requirements For Cryptographic Modules, Information Technology Laboratory, National Institute of Standards and Technology, March 22, 2019. + FIPS 186-4, Federal Information Processing Standards Publication - Digital Signature Standard (DSS), Information Technology Laboratory, National Institute of Standards and Technology, July 2013. ISO 21188:2006, Public key infrastructure for financial services -- Practices and policy framework. -Network and Certificate System Security Requirements, v.1.0, 1/1/2013. +Network and Certificate System Security Requirements, Version 1.7, available at . NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, . -RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels, Bradner, March 1997. - -RFC2527, Request for Comments: 2527, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, March 1999. +RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. RFC3492, Request for Comments: 3492, Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. -RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework, Chokhani, et al, November 2003. +RFC3647, Request for Comments: 3647, Internet X.509 Public Key Infrastructure: Certificate Policy and Certification Practices Framework. S. Chokhani, et al. November 2003. -RFC3912, Request for Comments: 3912, WHOIS Protocol Specification, Daigle, September 2004. +RFC3912, Request for Comments: 3912, WHOIS Protocol Specification. L. Daigle. September 2004. RFC3986, Request for Comments: 3986, Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee, et al. January 2005. -RFC4366, Request for Comments: 4366, Transport Layer Security (TLS) Extensions, Blake-Wilson, et al, April 2006. - -RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments, A. Deacon, et al, September 2007. +RFC5019, Request for Comments: 5019, The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments. A. Deacon, et al. September 2007. -RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile, Cooper et al, May 2008. +RFC5280, Request for Comments: 5280, Internet X.509 Public Key Infrastructure: Certificate and Certificate Revocation List (CRL) Profile. D. Cooper, et al. May 2008. RFC5890, Request for Comments: 5890, Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework. J. Klensin. August 2010. RFC5952, Request for Comments: 5952, A Recommendation for IPv6 Address Text Representation. S. Kawamura, et al. August 2010. -RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record, Hallam-Baker, Stradling, Hoffman-Andrews, November 2019. +RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. S. Santesson, et al. June 2013. -RFC6960, Request for Comments: 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP. Santesson, Myers, Ankney, Malpani, Galperin, Adams, June 2013. +RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, et al. June 2013. -RFC6962, Request for Comments: 6962, Certificate Transparency. B. Laurie, A. Langley, E. Kasper. June 2013. +RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, et al. June 2014. -RFC7231, Request For Comments: 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content, R. Fielding, J. Reschke. June 2014. +RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format. A. Newton, et al. March 2015. -RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect), J. Reschke. April 2015. - -RFC7482, Request for Comments: 7482, Registration Data Access Protocol (RDAP) Query Format, Newton, et al, March 2015. +RFC7538, Request For Comments: 7538, The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect). J. Reschke. April 2015. RFC8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January 2019. -WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.3, available at . +RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019. + +WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.5, available at . -X.509, Recommendation ITU-T X.509 (10/2012) \| ISO/IEC 9594-8:2014 (E), Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks. +X.509, Recommendation ITU-T X.509 (08/2005) \| ISO/IEC 9594-8:2005, Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks. ### 1.6.4 Conventions @@ -659,7 +660,7 @@ If the Subject Identity Information is to include a DBA or tradename, the CA SHA 1. Documentation provided by, or communication with, a government agency in the jurisdiction of the Applicant's legal creation, existence, or recognition; 2. A Reliable Data Source; -3. Communication with a government agency responsible for the management of such DBAs or tradenames; +3. Communication with a government agency responsible for the management of such DBAs or trade names; 4. An Attestation Letter accompanied by documentary support; or 5. A utility bill, bank statement, credit card statement, government-issued tax document, or other form of identification that the CA determines to be reliable. @@ -713,13 +714,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more ##### 3.2.2.4.3 Phone Contact with Domain Contact -Confirming the Applicant's control over the FQDN by calling the Domain Name Registrant's phone number and obtaining a response confirming the Applicant's request for validation of the FQDN. The CA MUST place the call to a phone number identified by the Domain Name Registrar as the Domain Contact. - -Each phone call SHALL be made to a single number and MAY confirm control of multiple FQDNs, provided that the phone number is identified by the Domain Registrar as a valid contact method for every Base Domain Name being verified using the phone call. - -CAs SHALL NOT perform validations using this method after May 31, 2019. Completed validations using this method SHALL continue to be valid for subsequent issuance per the applicable certificate data reuse periods. - -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates. ##### 3.2.2.4.4 Constructed Email to Domain Contact @@ -745,19 +740,7 @@ This method has been retired and MUST NOT be used. Prior validations using this ##### 3.2.2.4.6 Agreed-Upon Change to Website -Confirming the Applicant's control over the FQDN by confirming one of the following under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation, on the Authorization Domain Name that is accessible by the CA via HTTP/HTTPS over an Authorized Port: - -1. The presence of Required Website Content contained in the content of a file. The entire Required Website Content MUST NOT appear in the request used to retrieve the file or web page, or -2. The presence of the Request Token or Random Value contained in the content of a file where the Request Token or Random Value MUST NOT appear in the request. - -If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after the longer of - - i. 30 days or - ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). - -CAs SHALL NOT perform validations using this method after June 3, 2020. CAs MAY continue to re-use information and validations for domains validated under this method per the applicable certificate data reuse periods. - -**Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. +This method has been retired and MUST NOT be used. Prior validations using this method and validation data gathered according to this method SHALL NOT be used to issue certificates. ##### 3.2.2.4.7 DNS Change @@ -766,7 +749,7 @@ Confirming the Applicant's control over the FQDN by confirming the presence of a If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after i. 30 days or - ii. if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). + ii. if the Applicant submitted the Certificate request, the time frame permitted for reuse of validated information relevant to the Certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of these Guidelines or Section 11.14.3 of the EV Guidelines). **Note**: Once the FQDN has been validated using this method, the CA MAY also issue Certificates for other FQDNs that end with all the Domain Labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. @@ -830,7 +813,7 @@ The Random Value SHALL remain valid for use in a confirming response for no more Confirm the Applicant's control over the FQDN by calling the DNS TXT Record Phone Contact’s phone number and obtain a confirming response to validate the ADN. Each phone call MAY confirm control of multiple ADNs provided that the same DNS TXT Record Phone Contact phone number is listed for each ADN being verified and they provide a confirming response for each ADN. -The CA MAY NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. +The CA MUST NOT knowingly be transferred or request to be transferred as this phone number has been specifically listed for the purposes of Domain Validation. In the event of reaching voicemail, the CA may leave the Random Value and the ADN(s) being validated. The Random Value MUST be returned to the CA to approve the request. @@ -878,8 +861,7 @@ If a Random Value is used, then: 2. The Random Value MUST remain valid for use in a confirming response for no more than 30 days from its creation. The CPS MAY specify a shorter validity period for Random Values, in which case the CA MUST follow its CPS. **Note**: - * For Certificates issued prior to 2021-12-01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. - * For Certificates issued on or after 2021-12-01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. + * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.19 Agreed-Upon Change to Website - ACME @@ -898,8 +880,7 @@ If the CA follows redirects, the following apply: 3. Redirects MUST be to resource URLs accessed via Authorized Ports. **Note**: - * For Certificates issued prior to 2021-12-01, the CA MAY also issue Certificates for other FQDNs that end with all the labels of the validated FQDN. This method is suitable for validating Wildcard Domain Names. - * For Certificates issued on or after 2021-12-01, the CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. + * The CA MUST NOT issue Certificates for other FQDNs that end with all the labels of the validated FQDN unless the CA performs a separate validation for that FQDN using an authorized method. This method is NOT suitable for validating Wildcard Domain Names. ##### 3.2.2.4.20 TLS Using ALPN @@ -926,7 +907,7 @@ Confirming the Applicant's control over the requested IP Address by confirming t If a Random Value is used, the CA SHALL provide a Random Value unique to the certificate request and SHALL not use the Random Value after the longer of i. 30 days or - ii. if the Applicant submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document). + ii. if the Applicant submitted the certificate request, the time frame permitted for reuse of validated information relevant to the certificate (such as in [Section 4.2.1](#421-performing-identification-and-authentication-functions) of this document). ##### 3.2.2.5.2 Email, Fax, SMS, or Postal Mail to IP Address Contact @@ -1076,7 +1057,7 @@ The certificate request MAY include all factual information about the Applicant Applicant information MUST include, but not be limited to, at least one Fully-Qualified Domain Name or IP address to be included in the Certificate's `subjectAltName` extension. -[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself no more than 825 days prior to issuing the Certificate. Effective 2021-10-01, for validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate. +[Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in [Section 3.2](#32-initial-identity-validation) to verify certificate information, or may reuse previous validations themselves, provided that the CA obtained the data or document from a source specified under [Section 3.2](#32-initial-identity-validation) or completed the validation itself no more than 825 days prior to issuing the Certificate. For validation of Domain Names and IP Addresses according to Section 3.2.2.4 and 3.2.2.5, any reused data, document, or completed validation MUST be obtained no more than 398 days prior to issuing the Certificate. In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate. @@ -1234,17 +1215,17 @@ The CA SHALL revoke a Certificate within 24 hours if one or more of the followin The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days if one or more of the following occurs: -1. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); -2. The CA obtains evidence that the Certificate was misused; -3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use; -4. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name); -5. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name; -6. The CA is made aware of a material change in the information contained in the Certificate; -7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement; -8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; -9. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository; -10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or -11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed. +6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking); +7. The CA obtains evidence that the Certificate was misused; +8. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use; +9. The CA is made aware of any circumstance indicating that use of a Fully-Qualified Domain Name or IP address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a Domain Name Registrant's right to use the Domain Name, a relevant licensing or services agreement between the Domain Name Registrant and the Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name); +10. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name; +11. The CA is made aware of a material change in the information contained in the Certificate; +12. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement; +13. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; +14. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository; +15. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or +16. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed. #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate @@ -1329,11 +1310,6 @@ The validity interval of an OCSP response is the difference in time between the For the status of Subscriber Certificates: -Prior to 2020-09-30: -The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days. - -Effective 2020-09-30: - 1. OCSP responses MUST have a validity interval greater than or equal to eight hours; 2. OCSP responses MUST have a validity interval less than or equal to ten days; 3. For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate. @@ -1580,9 +1556,9 @@ Additionally, the CA's security program MUST include an annual Risk Assessment t ### 5.5.1 Types of records archived -The CA and each Delegated Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)). +The CA and each Delegated Third Party SHALL archive all audit logs (as set forth in [Section 5.4.1](#541-types-of-events-recorded)). -Additionally, the CA and each Delegated Party SHALL archive: +Additionally, the CA and each Delegated Third Party SHALL archive: 1. Documentation related to the security of their Certificate Systems, Certificate Management Systems, Root CA Systems, and Delegated Third Party Systems; and 2. Documentation related to their verification, issuance, and revocation of certificate requests and Certificates. @@ -1590,7 +1566,7 @@ Additionally, the CA and each Delegated Party SHALL archive: Archived audit logs (as set forth in [Section 5.5.1](#551-types-of-records-archived) SHALL be retained for a period of at least two (2) years from their record creation timestamp, or as long as they are required to be retained per [Section 5.4.3](#543-retention-period-for-audit-log), whichever is longer. -Additionally, the CA and each delegated party SHALL retain, for at least two (2) years: +Additionally, the CA and each Delegated Third Party SHALL retain, for at least two (2) years: 1. All archived documentation related to the security of Certificate Systems, Certificate Management Systems, Root CA Systems and Delegated Third Party Systems (as set forth in [Section 5.5.1](#551-types-of-records-archived)); and 2. All archived documentation relating to the verification, issuance, and revocation of certificate requests and Certificates (as set forth in [Section 5.5.1](#551-types-of-records-archived)) after the later occurrence of: 1. such records and documentation were last relied upon in the verification, issuance, or revocation of certificate requests and Certificates; or @@ -1752,7 +1728,7 @@ If the Issuing CA generated the Private Key on behalf of the Subordinate CA, the ### 6.2.7 Private key storage on cryptographic module -The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140 level 3 or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats. +The CA SHALL protect its Private Key in a system or device that has been validated as meeting at least FIPS 140-2 level 3, FIPS 140-3 level 3, or an appropriate Common Criteria Protection Profile or Security Target, EAL 4 (or higher), which includes requirements to protect the Private Key and other assets against known threats. ### 6.2.8 Activating Private Keys @@ -1760,7 +1736,7 @@ The CA SHALL protect its Private Key in a system or device that has been validat ### 6.2.10 Destroying Private Keys -### 6.2.11 Cryptographic Module Capabilities +### 6.2.11 Cryptographic Module Rating ## 6.3 Other aspects of key pair management @@ -3031,7 +3007,7 @@ In addition, the CA MAY use the following signature algorithm and encoding if al * The only differences between the new Certificate and existing Certificate are one of the following: * A new `subjectPublicKey` within the `subjectPublicKeyInfo`, using the same algorithm and key size; and/or, * A new `serialNumber`, of the same encoded length as the existing Certificate; and/or - * The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.2937.0) key purposes; and/or + * The new Certificate's `extKeyUsage` extension is present, has at least one key purpose specified, and none of the key purposes specified are the id-kp-serverAuth (OID: 1.3.6.1.5.5.7.3.1) or the anyExtendedKeyUsage (OID: 2.5.29.37.0) key purposes; and/or * The new Certificate's `basicConstraints` extension has a pathLenConstraint that is zero. * If used within an OCSP response, such as the `signatureAlgorithm` of a BasicOCSPResponse: * The `producedAt` field value of the ResponseData MUST be earlier than 2022-06-01 00:00:00 UTC; and, @@ -3164,8 +3140,6 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o 1. `reasonCode` (OID 2.5.29.21) - Effective 2020-09-30, all of the following requirements MUST be met: - If present, this extension MUST NOT be marked critical. If a CRL entry is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, this CRL entry extension MUST be present. @@ -3176,12 +3150,16 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o If a CRL entry is for a Certificate subject to these Requirements, the `CRLReason` MUST NOT be certificateHold (6). If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS. + +2. `issuingDistributionPoint` (OID 2.5.29.28) + + Effective 2023-01-15, if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point extension and MUST populate the `distributionPoint` field of that extension. ## 7.3 OCSP profile -Effective 2020-09-30, if an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present. +If an OCSP response is for a Root CA or Subordinate CA Certificate, including Cross-Certified Subordinate CA Certificates, and that certificate has been revoked, then the `revocationReason` field within the `RevokedInfo` of the `CertStatus` MUST be present. -Effective 2020-09-30, the `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions). +The `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions). ### 7.3.1 Version number(s) @@ -3193,10 +3171,9 @@ The `singleExtensions` of an OCSP response MUST NOT contain the `reasonCode` (OI The CA SHALL at all times: -1. Issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates; -2. Comply with these Requirements; -3. Comply with the audit requirements set forth in this section; and -4. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates. +1. Comply with these Requirements; +2. Comply with the audit requirements set forth in this section; and +3. Be licensed as a CA in each jurisdiction where it operates, if licensing is required by the law of such jurisdiction for the issuance of Certificates. **Implementers' Note**: Version 1.1.6 of the SSL Baseline Requirements was published on July 29, 2013. Version 2.0 of WebTrust's Principles and Criteria for Certification Authorities - SSL Baseline with Network Security and ETSI's Electronic Signatures and Infrastructures (ESI) 102 042 incorporate version 1.1.6 of these Baseline Requirements and version 1.0 of the Network and Certificate System Security Requirements. The CA/Browser Forum continues to improve the Baseline Requirements while WebTrust and ETSI also continue to update their audit criteria. We encourage all CAs to conform to each revision herein on the date specified without awaiting a corresponding update to an applicable audit criterion. In the event of a conflict between an existing audit criterion and a guideline revision, we will communicate with the audit community and attempt to resolve any uncertainty, and we will respond to implementation questions directed to . Our coordination with compliance auditors will continue as we develop guideline revision cycles that harmonize with the revision cycles for audit criteria, the compliance auditing periods and cycles of CAs, and the CA/Browser Forum's guideline implementation dates. @@ -3250,8 +3227,6 @@ The Audit Report SHALL state explicitly that it covers the relevant systems and The CA MUST make its Audit Report publicly available no later than three months after the end of the audit period. In the event of a delay greater than three months, the CA SHALL provide an explanatory letter signed by the Qualified Auditor. -For Audit Reports in which the Audit Period includes a date later than 2020-08-01, then the requirements set forth in the remainder of this [Section 8.6](#86-communication-of-results) SHALL be met. Audit Reports for Audit Periods that conclude prior to 2020-08-01 SHOULD meet these requirements. - The Audit Report MUST contain at least the following clearly-labelled information: 1. name of the organization being audited; @@ -3348,20 +3323,16 @@ The Certificate Warranties specifically include, but are not limited to, the fol ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; 3. **Accuracy of Information**: That, at the time of issuance, the CA - i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute); + i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate; ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; -4. **No Misleading Information**: That, at the time of issuance, the CA - i. implemented a procedure for reducing the likelihood that the information contained in the Certificate's subject:organizationalUnitName attribute would be misleading; +4. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA + i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.2](#712-certificate-content-and-extensions); ii. followed the procedure when issuing the Certificate; and iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; -5. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA - i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.2](#712-certificate-content-and-extensions); - ii. followed the procedure when issuing the Certificate; and - iii. accurately described the procedure in the CA's Certificate Policy and/or Certification Practice Statement; -6. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use; -7. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and -8. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in these Requirements. +5. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use; +6. **Status**: That the CA maintains a 24 x 7 publicly-accessible Repository with current information regarding the status (valid or revoked) of all unexpired Certificates; and +7. **Revocation**: That the CA will revoke the Certificate for any of the reasons specified in these Requirements. The Root CA SHALL be responsible for the performance and warranties of the Subordinate CA, for the Subordinate CA's compliance with these Requirements, and for all liabilities and indemnification obligations of the Subordinate CA under these Requirements, as if the Root CA were the Subordinate CA issuing the Certificates @@ -3434,6 +3405,8 @@ Notwithstanding any limitations on its liability to Subscribers and Relying Part ## 9.15 Compliance with applicable law +The CA SHALL issue Certificates and operate its PKI in accordance with all law applicable to its business and the Certificates it issues in every jurisdiction in which it operates. + ## 9.16 Miscellaneous provisions ### 9.16.1 Entire agreement @@ -3511,7 +3484,7 @@ This appendix defines permissible verification procedures for including one or m a. The CA MAY verify the Applicant's control over the .onion service by using one of the following methods from [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control): i. [Section 3.2.2.4.18 - Agreed-Upon Change to Website v2](#322418-agreed-upon-change-to-website-v2) - ii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website-acme) + ii. [Section 3.2.2.4.19 - Agreed-Upon Change to Website - ACME](#322419-agreed-upon-change-to-website---acme) iii. [Section 3.2.2.4.20 - TLS Using ALPN](#322420-tls-using-alpn) When these methods are used to verify the Applicant's control over the .onion service, the CA MUST use Tor protocol to establish a connection to the .onion hidden service. The CA MUST NOT delegate or rely on a third-party to establish the connection, such as by using Tor2Web. diff --git a/docs/EVG.md b/docs/EVG.md index 016961d1..4f1d5df9 100644 --- a/docs/EVG.md +++ b/docs/EVG.md @@ -1,9 +1,9 @@ --- title: Guidelines for the Issuance and Management of Extended Validation Certificates -subtitle: Version 1.7.9 +subtitle: Version 1.8.0 author: - CA/Browser Forum -date: 23 April, 2022 +date: 30 November, 2022 copyright: | Copyright 2022 CA/Browser Forum @@ -12,8 +12,6 @@ copyright: | # Introduction -This version 1.7.8 represents the Extended Validation Guidelines, as adopted by the CA/Browser Forum as of Ballot SC48, passed by the Server Certificate Working Group on 22 July 2021, and effective as of 25 August 2021. - The Guidelines describe an integrated set of technologies, protocols, identity proofing, lifecycle management, and auditing practices specifying the minimum requirements that must be met in order to issue and maintain Extended Validation Certificates ("EV Certificates") concerning an organization. Subject Organization information from valid EV Certificates can then be used in a special manner by certain relying-party software applications (e.g., browser software) in order to provide users with a trustworthy confirmation of the identity of the entity that controls the Web site or other services they are accessing. Although initially intended for use in establishing Web-based data communication conduits via TLS/SSL protocols, extensions are envisioned for S/MIME, time-stamping, VoIP, IM, Web services, etc. The primary purposes of Extended Validation Certificates are to: 1) identify the legal entity that controls a Web or service site, and 2) enable encrypted communications with that site. The secondary purposes include significantly enhancing cybersecurity by helping establish the legitimacy of an organization claiming to operate a Web site, and providing a vehicle that can be used to assist in addressing problems related to distributing malware, phishing, identity theft, and diverse forms of online fraud. @@ -71,6 +69,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti | 1.7.7 | SC47 | Sunset subject:organizationalUnitName | 30-Jun-2021 | 16-Aug-2021 | | 1.7.8 | SC48 | Domain Name and IP Address Encoding | 22-Jul-2021 | 25-Aug-2021 | | 1.7.9 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | +| 1.8.0 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -79,7 +78,7 @@ The CA/Browser Forum is a voluntary open organization of certification authoriti | **Compliance** | **Section(s)** | **Summary Description (See Full Text for Details)** | |--|--|----------| | 2020-01-31 | [9.2.8](#928-subject-organization-identifier-field) | If subject:organizationIdentifier is present, the CA/Browser Forum Organization Identifier Extension MUST be present | -| 2020-09-01 | [9.4](#94-maximum-validity-period-for-ev-certificate) & [Appendix F](#appendix-f--issuance-of-certificates-for-onion-domain-names) | Certificates issued MUST NOT have a Validity Period greater than 398 days. | +| 2020-09-01 | [9.4](#94-maximum-validity-period-for-ev-certificate) & Appendix F | Certificates issued MUST NOT have a Validity Period greater than 398 days. | | 2020-10-01 | [11.1.3](#1113-disclosure-of-verification-sources) | Prior to using an Incorporating Agency or Registration Agency, the CA MUST ensure the agency has been publicly disclosed | | 2022-09-01 | [9.2.7](#927-subject-organizational-unit-name-field) | CAs MUST NOT include the organizationalUnitName field in the Subject | @@ -153,10 +152,6 @@ Capitalized Terms are defined in the Baseline Requirements except where provided **Demand Deposit Account**: A deposit account held at a bank or other financial institution, the funds deposited in which are payable on demand. The primary purpose of demand accounts is to facilitate cashless payments by means of check, bank draft, direct debit, electronic funds transfer, etc. Usage varies among countries, but a demand deposit account is commonly known as a share draft account, a current account, or a checking account. -**Enterprise EV Certificate**: An EV Certificate that an Enterprise RA authorizes the CA to issue at third and higher domain levels. - -**Enterprise EV RA**: An RA that is authorized by the CA to authorize the CA to issue EV Certificates at third and higher domain levels. - **EV Authority**: A source other than the Certificate Approver, through which verification occurs that the Certificate Approver is expressly authorized by the Applicant, as of the date of the EV Certificate Request, to take the Request actions described in these Guidelines. **EV Certificate**: A certificate that contains subject information specified in these Guidelines and that has been validated in accordance with these Guidelines. @@ -518,8 +513,7 @@ __Contents__: This field MUST contain the address of the physical location of th ### 9.2.7. Subject Organizational Unit Name Field __Certificate Field__: `subject:organizationalUnitName` (OID: 2.5.4.11) -__Required/Optional/Prohibited:__ As stated in Section 7.1.4.2.2 i of the Baseline Requirements. -__Contents__: The CA SHALL implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information in accordance with [Section 11](#11-verification-requirements). This field MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. +__Required/Optional/Prohibited:__ __Prohibited__. ### 9.2.8. Subject Organization Identifier Field @@ -593,8 +587,7 @@ A Certificate issued to a Subscriber MUST contain one or more policy identifier( ## 9.4. Maximum Validity Period For EV Certificate -The Validity Period for an EV Certificate SHALL NOT exceed 825 days. -Effective 2020-09-01, the Validity Period for an EV Certificate SHALL NOT exceed 398 days. +The Validity Period for an EV Certificate SHALL NOT exceed 398 days. It is RECOMMENDED that EV Subscriber Certificates have a Maximum Validity Period of twelve months. @@ -679,7 +672,7 @@ CABFOrganizationIdentifier ::= SEQUENCE { registrationSchemeIdentifier PrintableString (SIZE(3)), registrationCountry PrintableString (SIZE(2)), registrationStateOrProvince [0] IMPLICIT PrintableString - OPTIONAL (SIZE(0..128)), + (SIZE(0..128)) OPTIONAL, registrationReference UTF8String } ``` @@ -1214,9 +1207,9 @@ The High Risk Certificate requirements of Section 4.2.1 of the Baseline Requirem A. If the CA has operations in the U.S., the CA MUST take reasonable steps to verify with the following US Government denied lists and regulations: - i. BIS Denied Persons List - https://www.bis.doc.gov/index.php/the-denied-persons-list - ii. BIS Denied Entities List - https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/entity-list - iii. US Treasury Department List of Specially Designated Nationals and Blocked Persons - https://www.treasury.gov/resource-center/sanctions/sdn-list/pages/default.aspx + i. BIS Denied Persons List - [https://www.bis.doc.gov/index.php/the-denied-persons-list](https://www.bis.doc.gov/index.php/the-denied-persons-list) + ii. BIS Denied Entities List - [https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/entity-list](https://www.bis.doc.gov/index.php/policy-guidance/lists-of-parties-of-concern/entity-list) + iii. US Treasury Department List of Specially Designated Nationals and Blocked Persons - [https://www.treasury.gov/resource-center/sanctions/sdn-list/pages/default.aspx](https://www.treasury.gov/resource-center/sanctions/sdn-list/pages/default.aspx) iv. US Government export regulations B. If the CA has operations in any other country, the CA MUST take reasonable steps to verify with all equivalent denied lists and export regulations (if any) in such other country. @@ -1236,8 +1229,6 @@ A CA verifying an Applicant using information of the Applicant's Parent, Subsidi ## 11.13. Final Cross-Correlation and Due Diligence -Except for Enterprise EV Certificates: - 1. The results of the verification processes and procedures outlined in these Guidelines are intended to be viewed both individually and as a group. Thus, after all of the verification processes and procedures are completed, the CA MUST have a person who is not responsible for the collection of information review all of the information and documentation assembled in support of the EV Certificate application and look for discrepancies or other details requiring further explanation. 2. The CA MUST obtain and document further explanation or clarification from the Applicant, Certificate Approver, Certificate Requester, Qualified Independent Information Sources, and/or other sources of information, as necessary, to resolve those discrepancies or details that require further explanation. 3. The CA MUST refrain from issuing an EV Certificate until the entire corpus of information and documentation assembled in support of the EV Certificate Request is such that issuance of the EV Certificate will not communicate factual information that the CA knows, or the exercise of due diligence should discover from the assembled information and documentation, to be inaccurate,. If satisfactory explanation and/or additional documentation are not received within a reasonable time, the CA MUST decline the EV Certificate Request and SHOULD notify the Applicant accordingly. @@ -1247,7 +1238,7 @@ Except for Enterprise EV Certificates: B. When the CA has utilized the services of an RA, the CA MAY rely on the language skills of the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with [Section 11.13](#1113-final-cross-correlation-and-due-diligence), Subsections (1), (2) and (3). Notwithstanding the foregoing, prior to issuing the EV Certificate, the CA MUST review the work completed by the RA and determine that all requirements have been met; or C. When the CA has utilized the services of an RA, the CA MAY rely on the RA to perform the Final Cross-Correlation and Due Diligence, provided that the RA complies with this section and is subjected to the Audit Requirements of [Section 17.5](#175-regular-self-audits) and [Section 17.6](#176-auditor-qualification). - In the case of Enterprise EV Certificates to be issued in compliance with the requirements of [Section 14.2](#142-delegation-of-functions-to-registration-authorities-and-subcontractors), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section. +In the case of EV Certificates to be issued in compliance with the requirements of [Section 14.2](#142-delegation-of-functions-to-registration-authorities-and-subcontractors), the Enterprise RA MAY perform the requirements of this Final Cross-Correlation and Due Diligence section. ## 11.14. Requirements for Re-use of Existing Documentation @@ -1295,7 +1286,7 @@ Root CA Private Keys MUST NOT be used to sign EV Certificates. # 13. Certificate Revocation and Status Checking -The requirements in Section 4.9 of the Baseline Requirements apply equally to EV Certificates. However, CAs MUST ensure that CRLs for an EV Certificate chain can be downloaded in no more than three (3) seconds over an analog telephone line under normal network conditions. +The requirements in Section 4.9 of the Baseline Requirements apply equally to EV Certificates. # 14. Employee and third party issues @@ -1343,13 +1334,13 @@ The CA SHALL verify that the Delegated Third Party's personnel involved in the i ### 14.2.2. Enterprise RAs -The CA MAY contractually authorize the Subject of a specified Valid EV Certificate to perform the RA function and authorize the CA to issue additional EV Certificates at third and higher domain levels that are contained within the domain of the original EV Certificate (also known as an Enterprise EV Certificate). In such case, the Subject SHALL be considered an Enterprise RA, and the following requirements SHALL apply: +The CA MAY contractually authorize a Subscriber to perform the RA function and authorize the CA to issue additional EV Certificates. In such case, the Subscriber SHALL be considered an Enterprise RA, and the following requirements SHALL apply: + +1. In all cases, the Subscriber MUST be an organization verified by the CA in accordance with these Guidelines; +2. The CA MUST impose these limitations as a contractual requirement with the Enterprise RA and monitor compliance by the Enterprise RA; and +3. The Final Cross-Correlation and Due Diligence requirements of [Section 11.13](#1113-final-cross-correlation-and-due-diligence) MAY be performed by a single person representing the Enterprise RA. -1. An Enterprise RA SHALL NOT authorize the CA to issue an Enterprise EV Certificate at the third or higher domain levels to any Subject other than the Enterprise RA or a business that is owned or directly controlled by the Enterprise RA; -2. In all cases, the Subject of an Enterprise EV Certificate MUST be an organization verified by the CA in accordance with these Guidelines; -3. The CA MUST impose these limitations as a contractual requirement with the Enterprise RA and monitor compliance by the Enterprise RA; -4. The Final Cross-Correlation and Due Diligence requirements of [Section 11.13](#1113-final-cross-correlation-and-due-diligence) MAY be performed by a single person representing the Enterprise RA; and -5. The audit requirements of [Section 17.1](#171-eligible-audit-schemes) SHALL apply to the Enterprise RA, except in the case where the CA maintains control over the Root CA Private Key or Subordinate CA Private Key used to issue the Enterprise EV Certificates, in which case, the Enterprise RA MAY be exempted from the audit requirements. +Enterprise RAs that authorize the issuance of EV Certificates solely for its own organization are exempted from the audit requirements of [Section 17.1](#171-eligible-audit-schemes). In all other cases, the requirements of [Section 17.1](#171-eligible-audit-schemes) SHALL apply. ### 14.2.3. Guidelines Compliance Obligation @@ -1419,7 +1410,7 @@ All requirements in Section 6.1.1.1 of the Baseline Requirements apply equally t # 18. Liability and Indemnification -CAs MAY limit their liability as described in Section 9.8 of the Baseline Requirements except that a CA MAY NOT limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate. +CAs MAY limit their liability as described in Section 9.8 of the Baseline Requirements except that a CA MUST NOT limit its liability to Subscribers or Relying Parties for legally recognized and provable claims to a monetary amount less than two thousand US dollars per Subscriber or Relying Party per EV Certificate. A CA's indemnification obligations and a Root CA's obligations with respect to subordinate CAs are set forth in Section 9.9 of the Baseline Requirements. From e3664710213801c3545f64ed8b4f7b89b6bdc3b7 Mon Sep 17 00:00:00 2001 From: AnetaWojtczak <104534364+AnetaWojtczak@users.noreply.github.com> Date: Thu, 26 Jan 2023 10:55:20 -0800 Subject: [PATCH 49/54] This PR fixes issues in section 7.1.2.7.3 and 7.1.2.7.4. (#416) --- docs/BR.md | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 928e07a8..8c76a9bc 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2283,9 +2283,7 @@ Table: Individual Validated `subject` Attributes | `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | -| `organizationalUnitName` | - | - | - | -| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information. | [Section 3.2](#32-initial-identity-validation) | -| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | - | +| `organizationalUnitName` | MUST NOT | - | - | | `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | @@ -2305,10 +2303,11 @@ All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-fo The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. -Table: Individual Validated `subject` Attributes +Table: Organization Validated `subject` Attributes | __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | | --- | - | ------ | -- | +| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | | `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | @@ -2317,10 +2316,7 @@ Table: Individual Validated `subject` Attributes | `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | | `surname` | MUST NOT | - | - | | `givenName` | MUST NOT | - | - | -| `organizationalUnitName` | - | - | - | -| \ \ \ \ _Prior to 2022-09-01_ | NOT RECOMMENDED | If present, the CA MUST implement a process that prevents an OU attribute from including a name, DBA, tradename, trademark, address, location, or other text that refers to a specific natural person or Legal Entity unless the CA has verified this information. | [Section 3.2](#32-initial-identity-validation) | -| \ \ \ \ _Effective 2022-09-01_ | MUST NOT | - | - | -| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] +| `organizationalUnitName` | MUST NOT | - | - | | `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | From 4be388ab62e7664aaea519201cf75869b2053af9 Mon Sep 17 00:00:00 2001 From: Ryan Dickson Date: Thu, 26 Jan 2023 13:56:52 -0500 Subject: [PATCH 50/54] Profiles extended effective date (#413) * Update BR.md * Update BR.md --- docs/BR.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/BR.md b/docs/BR.md index 8c76a9bc..7c3a02ba 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1784,7 +1784,7 @@ The CA SHALL enforce multi-factor authentication for all accounts capable of dir The CA SHALL meet the technical requirements set forth in [Section 2.2 - Publication of Information](#22-publication-of-information), [Section 6.1.5 - Key Sizes](#615-key-sizes), and [Section 6.1.6 - Public Key Parameters Generation and Quality Checking](#616-public-key-parameters-generation-and-quality-checking). -Prior to 2023-04-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements or the profile specified in version 1.8.4 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-04-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements. +Prior to 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements or the profile specified in version 1.8.6 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements. ### 7.1.1 Version number(s) From 0689ba59dbad9f5d2a5269051e5e0d0d1a25f3f6 Mon Sep 17 00:00:00 2001 From: Wayne Thayer Date: Thu, 26 Jan 2023 10:57:11 -0800 Subject: [PATCH 51/54] 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 Co-authored-by: Corey Bonnell --- docs/BR.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/BR.md b/docs/BR.md index 7c3a02ba..0d85f369 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -2757,6 +2757,9 @@ Table: Policy Restricted This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. +**Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary. + + If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: From aa9fc5d0b2b59504a31638e880cb81c69aefa018 Mon Sep 17 00:00:00 2001 From: Aaron Gable Date: Fri, 17 Feb 2023 03:20:02 -0800 Subject: [PATCH 52/54] 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 * 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 Co-authored-by: Ryan Dickson --- docs/BR.md | 628 +++++++++++++++++++++++++++-------------------------- 1 file changed, 317 insertions(+), 311 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 0d85f369..782caff9 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -309,7 +309,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations. -**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two Root CAs. +**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two CAs. **CSPRNG**: A random number generator intended for use in a cryptographic system. @@ -1810,28 +1810,28 @@ If the CA asserts compliance with these Baseline Requirements, all certificates #### 7.1.2.1 Root CA Certificate Profile -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | -| \ \ \ \ `validity` | See [Section 7.1.2.1.1](#71211-root-ca-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.1.2](#71212-root-ca-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | +|     `validity` | See [Section 7.1.2.1.1](#71211-root-ca-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.1.2](#71212-root-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.1.1 Root CA Validity | __Field__ | __Minimum__ | __Maximum__ | | - | ---- | ---- | | `notBefore` | One day prior to the time of signing | The time of signing | -| `notAfter` | 2922 days (e.g. 8 years) | 9132 days (e.g. 25 years) | +| `notAfter` | 2922 days (approx. 8 years) | 9132 days (approx. 25 years) | **Note**: This restriction applies even in the event of generating a new Root CA Certificate for an existing `subject` and `subjectPublicKeyInfo` (e.g. reissuance). The new CA Certificate MUST conform to these rules. @@ -1848,7 +1848,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.1.3 Authority Key Identifier +##### 7.1.2.1.3 Root CA Authority Key Identifier | __Field__ | __Description__ | | --- | ------- | @@ -1856,7 +1856,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | `authorityCertIssuer` | MUST NOT be present | | `authorityCertSerialNumber` | MUST NOT be present | -##### 7.1.2.1.4 Basic Constraints +##### 7.1.2.1.4 Root CA Basic Constraints | __Field__ | __Description__ | | --- | ------- | @@ -1869,21 +1869,21 @@ This Certificate Profile MAY be used when issuing a CA Certificate using the sam Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance. -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.2.3](#71223-cross-certified-subordinate-ca-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-validity) | +|     `subject` | See [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.2.3](#71223-cross-certified-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.2.1 Cross-Certified Subordinate CA Validity @@ -1900,10 +1900,6 @@ The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-for ##### 7.1.2.2.3 Cross-Certified Subordinate CA Extensions -The acceptable extensions and the requirements for those extensions in a Cross-Certified Subordinate CA vary based on whether or not the Subordinate CA is issued to and operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. - -Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Affiliate of the Issuing CA. - | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | @@ -1912,48 +1908,69 @@ Table: Extensions when the Subordinate CA is operated by the Issuing CA or an Af | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-extended-key-usage---unrestricted-affiliated-cross-certified-ca) | | `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | | `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -Table: Extensions when the Subordinate CA is operated by an entity that is not the Issuing CA or an Affiliate of the Issuing CA. +In addition to the above, extKeyUsage extension requirements vary based on the relationship between the Issuer and Subject organizations represented in the Cross-Certificate. + +The extKeyUsage extension MAY be "unrestricted" as described in the following table if: +- the organizationName represented in the Issuer and Subject names of the corresponding certificate are either: + - the same, or + - the organizationName represented in the Subject name is an affiliate of the organizationName represented in the Issuer name +- the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. + +Table: Cross-Certified Subordinate CA with Unrestricted EKU | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.6](#712105-certificate-policies) | -| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | -| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-extended-key-usage---restricted-cross-certified-ca) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | -| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | -| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | +| `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-cross-certified-subordinate-ca-extended-key-usage---unrestricted) | + +In all other cases, the extKeyUsage extension MUST be "restricted" as described in the following table: + +Table: Cross-Certified Subordinate CA with Restricted EKU + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) | [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. [^name_constraints]: See [Section 7.1.2.10.8](#712108-name-constraints) for further requirements, including regarding criticality of this extension. -##### 7.1.2.2.4 Extended Key Usage - Unrestricted Affiliated Cross-Certified CA +##### 7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted -When the Cross-Certified Subordinate CA is issued to and operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA, the Extended Key Usage extension MAY be encoded as follows: - -Table: Unrestricted Extended Key Usage (Affiliated Cross-Certified CA) +Table: Unrestricted Extended Key Usage Purposes (Affiliated Cross-Certified CA) | __Key Purpose__ | __Description__ | | --- | ------- | | `anyExtendedKeyUsage` | The special extended key usage to indicate there are no restrictions applied. If present, this MUST be the only key usage present. | | Any other value | CAs MUST NOT include any other key usage with the `anyExtendedKeyUsage` key usage present. | -Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension MUST be encoded as specified in [Section 7.1.2.2.5, Extended Key Usage - Restricted Cross-Certified CA](#71225-extended-key-usage---restricted-cross-certified-ca). +Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension, if present, MUST be encoded as specified in [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted). + +##### 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted + +Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively) + +| __Key Purpose__ | __Description__ | +| --- | ------- | +| `id-kp-serverAuth` | MUST be present.| +| `id-kp-clientAuth` | MAY be present.| +| `id-kp-emailProtection`| MUST NOT be present.| +| `id-kp-codeSigning` | MUST NOT be present.| +| `id-kp-timeStamping` | MUST NOT be present.| +| `anyExtendedKeyUsage` | MUST NOT be present.| +| Any other value | NOT RECOMMENDED.| -##### 7.1.2.2.5 Extended Key Usage - Restricted Cross-Certified CA +Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) -If present, the Extended Key Usage extension MUST only contain key usage purposes for which the Issuing CA has verified the Cross-Certified Subordinate CA is authorized to assert. +| __Key Purpose__ | __Description__ | +| --- | ------- | +| `id-kp-serverAuth` | MUST NOT be present.| +| `anyExtendedKeyUsage` | MUST NOT be present.| +| Any other value | MAY be present.| Each included Extended Key Usage key usage purpose: @@ -1961,6 +1978,7 @@ Each included Extended Key Usage key usage purpose: a. the key usage purpose falls within an OID arc for which the Applicant demonstrates ownership; or, b. the Applicant can otherwise demonstrate the right to assert the key usage purpose in a public context. 2. MUST NOT include semantics that will mislead the Relying Party about the certificate information verified by the CA, such as including a key usage purpose asserting storage on a smart card, where the CA is not able to verify that the corresponding Private Key is confined to such hardware due to remote issuance. + 3. MUST be verified by the Issuing CA (i.e. the Issuing CA MUST verify the Cross-Certified Subordinate CA is authorized to assert the key usage purpose). CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate. @@ -1968,21 +1986,21 @@ CAs MUST NOT include additional key usage purposes unless the CA is aware of a r This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will not be used to issue TLS certificates directly or transitively. -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.3.1](#71231-technically-constrained-non-tls-subordinate-ca-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.3.1](#71231-technically-constrained-non-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions @@ -2000,28 +2018,28 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.3.2 Certificate Policies +##### 7.1.2.3.2 Technically Constrained Non-TLS Subordinate CA Certificate Policies If present, the Certificate Policies extension MUST be formatted as one of the two tables below: Table: No Policy Restrictions (Affiliated CA) -| __Field__ | __Presence__ | __Contents__ | -| --- | - | ------ | -| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | -| \ \ \ \ `anyPolicy` | MUST | | -| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | +|     `anyPolicy` | MUST | | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | Table: Policy Restricted -| __Field__ | __Presence__ | __Contents__ | -| --- | - | ------ | -| `policyIdentifier` | MUST | One of the following policy identifiers: | -| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST NOT | | -| \ \ \ \ `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | -| \ \ \ \ Any other identifier | MAY | If present, MUST be documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST NOT | | +|     `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +|     Any other identifier | MAY | If present, MUST be documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | Table: Permitted `policyQualifiers` @@ -2032,7 +2050,7 @@ Table: Permitted `policyQualifiers` | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.3.3 Extended Key Usage +##### 7.1.2.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. @@ -2052,21 +2070,21 @@ A Precertificate Signing CA MUST only be used to sign Precertificates, as define As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is not altered as part of these modifications. As such, the Precertificate Signing CA MUST use the same signature algorithm as the Issuing CA when issuing Precertificates, and, correspondingly, MUST use a public key of the same public key algorithm as the Issuing CA, although MAY use a different CA Key Pair. -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the `subjectPublicKeyInfo` field of the Issuing CA. See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-precertificate-signing-ca-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the `subjectPublicKeyInfo` field of the Issuing CA. See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-precertificate-signing-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions @@ -2084,7 +2102,7 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.4.2 Extended Key Usage +##### 7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2095,21 +2113,21 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively. -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.5.1](#71251-technically-constrained-tls-subordinate-ca-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.5.1](#71251-technically-constrained-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions @@ -2127,24 +2145,24 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.5.2 Name Constraints +##### 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. Table: `nameConstraints` requirements -| __Field__ | __Description__ | -| -- | ------- | -| `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` name type appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. | -| \ \ \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | -| \ \ \ \ \ \ \ \ `base` | See following table. | -| \ \ \ \ \ \ \ \ `minimum` | MUST NOT be present. | -| \ \ \ \ \ \ \ \ `maximum` | MUST NOT be present. | -| `excludedSubtrees` | The `excludedSubtrees` MUST contain at least one `GeneralSubtree` for each of the `dNSName` and `iPAddress` `GeneralName` name types, unless there is an instance present of that name type in the `permittedSubtrees`. The `directoryName` name type is NOT RECOMMENDED. | -| \ \ \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | -| \ \ \ \ \ \ \ \ `base` | See following table. | -| \ \ \ \ \ \ \ \ `minimum` | MUST NOT be present. | -| \ \ \ \ \ \ \ \ `maximum` | MUST NOT be present. | +| __Field__ | __Description__ | +| -- | ------- | +| `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` name type appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. | +|     `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +|         `base` | See following table. | +|         `minimum` | MUST NOT be present. | +|         `maximum` | MUST NOT be present. | +| `excludedSubtrees` | The `excludedSubtrees` MUST contain at least one `GeneralSubtree` for each of the `dNSName` and `iPAddress` `GeneralName` name types, unless there is an instance present of that name type in the `permittedSubtrees`. The `directoryName` name type is NOT RECOMMENDED. | +|     `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +|         `base` | See following table. | +|         `minimum` | MUST NOT be present. | +|         `maximum` | MUST NOT be present. | The following table contains the requirements for the `GeneralName` that appears within the `base` of a `GeneralSubtree` in either the `permittedSubtrees` or `excludedSubtrees`. @@ -2170,21 +2188,21 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in #### 7.1.2.6 TLS Subordinate CA Certificate Profile -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.6.1](#71261-tls-subordinate-ca-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.6.1](#71261-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.6.1 TLS Subordinate CA Extensions @@ -2204,23 +2222,23 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in #### 7.1.2.7 Subscriber (Server) Certificate Profile -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | | -| \ \ \ \ \ \ \ \ `notBefore` | A value within 48 hours of the certificate signing operation. | -| \ \ \ \ \ \ \ \ `notAfter` | See [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | -| \ \ \ \ `subject` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | | +|          `notBefore` | A value within 48 hours of the certificate signing operation. | +|          `notAfter` | See [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | +|     `subject` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.7.1 Subscriber Certificate Types @@ -2343,7 +2361,7 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | | `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-certificate-policies) | | `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-extended-key-usage) | -| `subjectAltName` | MUST | - | See [Section 7.1.2.7.12](#712712-subject-alternative-name) | +| `subjectAltName` | MUST | * | See [Section 7.1.2.7.12](#712712-subject-alternative-name) | | `nameConstraints` | MUST NOT | - | - | | `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-key-usage) | | `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-basic-constraints) | @@ -2352,11 +2370,13 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- | `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.7.7 Authority Information Access +**Note**: whether or not the `subjectAltName` extension should be marked Critical depends on the contents of the Certificate's `subject` field, as detailed in [Section 7.1.2.7.12](#712712-subject-alternative-name). -The `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. +##### 7.1.2.7.7 Subscriber Certificate Authority Information Access -The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. +The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. + +The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. | __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | | -- | -- | ---- | - | - | --- | @@ -2364,24 +2384,24 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | SHOULD | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.7.8 Basic Constraints +##### 7.1.2.7.8 Subscriber Certificate Basic Constraints | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be FALSE | | `pathLenConstraint` | MUST NOT be present | -##### 7.1.2.7.9 Certificate Policies +##### 7.1.2.7.9 Subscriber Certificate Certificate Policies If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: -| __Field__ | __Presence__ | __Contents__ | -| --- | - | ------ | -| `policyIdentifier` | MUST | One of the following policy identifiers: | -| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). | -| \ \ \ \ `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | -| \ \ \ \ Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). | +|     `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +|     Any other identifier | MAY | If present, MUST be defined and documented in the CA's Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. @@ -2396,7 +2416,7 @@ Table: Permitted `policyQualifiers` [^first_policy_note]: Although RFC 5280 allows `PolicyInformation`s to appear in any order, several client implementations have implemented logic that considers the `policyIdentifier` that matches a given filter. As such, ensuring the Reserved Certificate Policy Identifier is the first `PolicyInformation` reduces the risk of interoperability challenges. -##### 7.1.2.7.10 Extended Key Usage +##### 7.1.2.7.10 Subscriber Certificate Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2410,7 +2430,7 @@ Table: Permitted `policyQualifiers` | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | Any other value | - | NOT RECOMMENDED | -##### 7.1.2.7.11 Key Usage +##### 7.1.2.7.11 Subscriber Certificate Key Usage The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key. @@ -2446,7 +2466,7 @@ Table: Key Usage for ECC Public Keys **Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384). -##### 7.1.2.7.12 Subject Alternative Name +##### 7.1.2.7.12 Subscriber Certificate Subject Alternative Name For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements. @@ -2463,28 +2483,28 @@ Table: `GeneralName` within a `subjectAltName` extension | `directoryName` | N | - | | `ediPartyName` | N | - | | `uniformResourceIdentifier` | N | - | -| `iPAddress` | Y | MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in [Section 3.2.2.5](#3225-authentication-for-an-ip-address). MUST NOT contain a Reserved IP Address. | +| `iPAddress` | Y | The entry MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in [Section 3.2.2.5](#3225-authentication-for-an-ip-address). The entry MUST NOT contain a Reserved IP Address. | | `registeredID` | N | - | #### 7.1.2.8 OCSP Responder Certificate Profile If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | MUST be v3(2) | -| \ \ \ \ `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2^159^ containing at least 64 bits of output from a CSPRNG. | -| \ \ \ \ `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | -| \ \ \ \ `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | -| \ \ \ \ `validity` | See [Section 7.1.2.8.1](#71281-ocsp-responder-validity) | -| \ \ \ \ `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | -| \ \ \ \ `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | -| \ \ \ \ `issuerUniqueID` | MUST NOT be present | -| \ \ \ \ `subjectUniqueID` | MUST NOT be present | -| \ \ \ \ `extensions` | See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.8.1](#71281-ocsp-responder-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | ##### 7.1.2.8.1 OCSP Responder Validity @@ -2511,18 +2531,18 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -##### 7.1.2.8.3 Authority Information Access +##### 7.1.2.8.3 OCSP Responder Authority Information Access For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties. -If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInformationAccessSyntax` MUST contain all required `AccessDescription`s. +If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s. | __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | | -- | -- | ---- | - | - | --- | | `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.8.4 Basic Constraints +##### 7.1.2.8.4 OCSP Responder Basic Constraints OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. @@ -2531,22 +2551,22 @@ OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indi | `cA` | MUST be FALSE | | `pathLenConstraint` | MUST NOT be present | -**Note**: CAs MUST observe DER encoding rules, such as not explicitly encoding DEFAULT values within OPTIONAL fields. +**Note**: Due to DER encoding rules regarding the encoding of DEFAULT values within OPTIONAL fields, a `basicConstraints` extension that sets the `cA` boolean to FALSE MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `3000`, the encoded representation of an empty ASN.1 `SEQUENCE` value. -##### 7.1.2.8.5 Extended Key Usage +##### 7.1.2.8.5 OCSP Responder Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | | `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | | Any other value | - | MUST NOT | -##### 7.1.2.8.6 id-pkix-ocsp-nocheck +##### 7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5). -This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1). +This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1). -##### 7.1.2.8.7 Key Usage +##### 7.1.2.8.7 OCSP Responder Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2560,17 +2580,17 @@ This extension MUST be encoded as a single ASN.1 NULL, as specified in [RFC 6960 | `encipherOnly` | N | -- | | `decipherOnly` | N | -- | -##### 7.1.2.8.8 Certificate Policies +##### 7.1.2.8.8 OCSP Responder Certificate Policies If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: -| __Field__ | __Presence__ | __Contents__ | -| --- | - | ------ | -| `policyIdentifier` | MUST | One of the following policy identifiers: | -| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | NOT RECOMMENDED | | -| \ \ \ \ `anyPolicy` | NOT RECOMMENDED | | -| \ \ \ \ Any other identifier | NOT RECOMMENDED | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | NOT RECOMMENDED | | +|     `anyPolicy` | NOT RECOMMENDED | | +|     Any other identifier | NOT RECOMMENDED | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | Table: Permitted `policyQualifiers` @@ -2587,11 +2607,11 @@ Table: Permitted `policyQualifiers` #### 7.1.2.9 Precertificate Profile -A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding committment by the CA that it may issue such a Certificate. +A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate. A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate's `extensions` field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate. -Once a Precertificate is signed, relying parties are permitted to treat this as a binding committment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). +Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue a corresponding Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the corresponding Certificate conforms to these Baseline Requirements, regardless of whether the CA signs the corresponding Certificate. @@ -2600,44 +2620,44 @@ A Precertificate may be issued either directly by the Issuing CA or by a Technic Table: When the Precertificate is issued directly by the Issuing CA -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | -| \ \ \ \ `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | -| \ \ \ \ `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | -| \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the `issuer` field of the Certificate | -| \ \ \ \ `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | -| \ \ \ \ `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | -| \ \ \ \ `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | -| \ \ \ \ `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | -| \ \ \ \ `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | -| \ \ \ \ `extensions` | See [Section 7.1.2.9.1](#71291-directly-issued-precertificate-profile-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | +|     `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | +|     `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | +|     `issuer` | Encoded value MUST be byte-for-byte identical to the `issuer` field of the Certificate | +|     `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | +|     `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | +|     `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | +|     `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +|     `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +|     `extensions` | See [Section 7.1.2.9.1](#71291-directly-issued-precertificate-profile-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA -| __Field__ | __Description__ | -| --- | ------ | -| `tbsCertificate` | | -| \ \ \ \ `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | -| \ \ \ \ `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | -| \ \ \ \ `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | -| \ \ \ \ `issuer` | Encoded value MUST be byte-for-byte identical to the `subject` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) | -| \ \ \ \ `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | -| \ \ \ \ `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | -| \ \ \ \ `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | -| \ \ \ \ `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | -| \ \ \ \ `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | -| \ \ \ \ `extensions` | See [Section 7.1.2.9.2](#71292-precertificate-ca-issued-precertificate-profile-extensions) | -| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | -| `signature` | | - -**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they are byte-for-byte identical, as this would otherwise indicate there are corresponding Certificates that share the same `serialNumber`. - -##### 7.1.2.9.1 Directly Issued Precertificate Profile Extensions +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | +|     `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | +|     `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | +|     `issuer` | Encoded value MUST be byte-for-byte identical to the `subject` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) | +|     `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | +|     `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | +|     `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | +|     `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +|     `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | +|     `extensions` | See [Section 7.1.2.9.2](#71292-precertificate-ca-issued-precertificate-profile-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same `serialNumber`. + +##### 7.1.2.9.1 Precertificate Profile Extensions - Directly Issued These extensions apply in the context of a Precertificate directly issued from a CA, and not from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). @@ -2649,7 +2669,7 @@ These extensions apply in the context of a Precertificate directly issued from a **Note**: This requirement is expressing that if the Precertificate Poison extension is removed from the Precertificate, and the Signed Certificate Timestamp List is removed from the certificate, the contents of the `extensions` field MUST be byte-for-byte identical to the Certificate. -##### 7.1.2.9.2 Precertificate CA Issued Precertificate Profile Extensions +##### 7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued These extensions apply in the context of a Precertificate from a Precertificate Signing CA Certificate, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). For such Precertificates, the `authorityKeyIdentifier`, if present in the Certificate, is modified in the Precertificate, as described in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). @@ -2662,9 +2682,11 @@ These extensions apply in the context of a Precertificate from a Precertificate ##### 7.1.2.9.3 Precertificate Poison -The Precertificate Poison extension is identified by the OID 1.3.6.1.4.1.11129.2.4.3. The contents of the extension's `extnValue` `OCTET STRING` MUST be byte-for-byte identical with the following hex-encoded bytes, `0500`, representing the encoded representation of a zero-length ASN.1 `NULL` value, as specified in [RFC 6962, Section 3.1](https://tools.ietf.org/doc/html/rfc6962#section-3.1). +The Precertificate MUST contain the Precertificate Poison extension (OID: 1.3.6.1.4.1.11129.2.4.3). + +This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6962, Section 3.1](https://tools.ietf.org/doc/html/rfc6962#section-3.1). -##### 7.1.2.9.4 Authority Key Identifier +##### 7.1.2.9.4 Precertificate Authority Key Identifier For Precertificates issued by a Precertificate Signing CA, the contents of the `authorityKeyIdentifier` extension MUST be one of the following: @@ -2710,11 +2732,11 @@ The following table details the acceptable `AttributeType`s that may appear with | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | | Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | -##### 7.1.2.10.3 Authority Information Access +##### 7.1.2.10.3 CA Certificate Authority Information Access -If present, the `AuthorityInformationAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. +If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. -The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. +The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. | __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | | -- | -- | ---- | - | - | --- | @@ -2722,36 +2744,36 @@ The `AuthorityInformationAccessSyntax` MAY contain multiple `AccessDescription`s | `id-ad-caIssuers` | 1.3.6.1.5.5.7.48.2 | `uniformResourceIdentifier` | MAY | \* | A HTTP URL of the Issuing CA's certificate. | | Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | -##### 7.1.2.10.4 Basic Constraints +##### 7.1.2.10.4 CA Certificate Basic Constraints | __Field__ | __Description__ | | --- | ------- | | `cA` | MUST be set TRUE | | `pathLenConstraint` | MAY be present | -##### 7.1.2.10.5 Certificate Policies +##### 7.1.2.10.5 CA Certificate Certificate Policies If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: Table: No Policy Restrictions (Affiliated CA) -| __Field__ | __Presence__ | __Contents__ | -| --- | - | ------ | -| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | -| \ \ \ \ `anyPolicy` | MUST | | -| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | +|     `anyPolicy` | MUST | | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | Table: Policy Restricted -| __Field__ | __Presence__ | __Contents__ | -| --- | - | ------ | -| `policyIdentifier` | MUST | One of the following policy identifiers: | -| \ \ \ \ A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. | -| \ \ \ \ `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | -| \ \ \ \ Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | -| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. | +|     `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +|     Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. @@ -2770,7 +2792,7 @@ Table: Permitted `policyQualifiers` | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | -##### 7.1.2.10.6 Extended Key Usage +##### 7.1.2.10.6 CA Certificate Extended Key Usage | __Key Purpose__ | __OID__ | __Presence__ | | ---- | ---- | - | @@ -2784,7 +2806,7 @@ Table: Permitted `policyQualifiers` | Precertificate Signing Certificate | 1.3.6.1.4.1.11129.2.4.4 | MUST NOT | | Any other value | - | NOT RECOMMENDED | -##### 7.1.2.10.7 Key Usage +##### 7.1.2.10.7 CA Certificate Key Usage | __Key Usage__ | __Permitted__ | __Required__ | | ---- | - | - | @@ -2800,25 +2822,25 @@ Table: Permitted `policyQualifiers` [^ocsp_signing]: If a CA Certificate does not assert the `digitalSignature` bit, the CA Private Key MUST NOT be used to sign an OCSP Response. See [Section 7.3](#73-ocsp-profile) for more information. -##### 7.1.2.10.8 Name Constraints +##### 7.1.2.10.8 CA Certificate Name Constraints If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. Table: `nameConstraints` requirements -| __Field__ | __Description__ | -| -- | -------- | -| `permittedSubtrees` | | -| \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | -| \ \ \ \ `base` | See following table. | -| \ \ \ \ `minimum` | MUST NOT be present. | -| \ \ \ \ `maximum` | MUST NOT be present. | -| `excludedSubtrees` | | -| \ \ `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | -| \ \ \ \ `base` | See following table. | -| \ \ \ \ `minimum` | MUST NOT be present. | -| \ \ \ \ `maximum` | MUST NOT be present. | +| __Field__ | __Description__ | +| -- | -------- | +| `permittedSubtrees` | | +|   `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +|     `base` | See following table. | +|     `minimum` | MUST NOT be present. | +|     `maximum` | MUST NOT be present. | +| `excludedSubtrees` | | +|   `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +|     `base` | See following table. | +|     `minimum` | MUST NOT be present. | +|     `maximum` | MUST NOT be present. | The following table contains the requirements for the `GeneralName` that appears within the `base` of a `GeneralSubtree` in either the `permittedSubtrees` or `excludedSubtrees`. @@ -2857,33 +2879,17 @@ This section contains several fields that are common among multiple certificate ##### 7.1.2.11.2 CRL Distribution Points -If present, the CRL Distribution Points extension MUST be formatted as follows: - -Table: `CRLDistributionPoints` profile - -| __Field__ | __Presence__ | __Description__ | -| --- | -- | ------ | -| `CRLDistributionPoints` | | | -| \ \ **1** | MUST | The first `DistributionPoint` present in the `CRLDistributionPoints` | -| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | -| \ \ \ \ `reasons` | MUST NOT | | -| \ \ \ \ `cRLIssuer` | MUST NOT | | -| \ \ **2+** | NOT RECOMMENDED | Additional `DistributionPoint`s are NOT RECOMMENDED. | -| \ \ \ \ `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | -| \ \ \ \ `reasons` | MUST NOT | | -| \ \ \ \ `cRLIssuer` | MUST NOT | | -| \ \ **3** | MUST NOT | `DistributionPoints` that do not conform to the above requirements MUST NOT be present. | - -Table: `fullName` profile - -| __Field__ | __Presence__ | __Description__ | -| --- | - | ----- | -| `fullName` | | | -| \ \ **1** | MUST | The first `GeneralName` present in `fullName` MUST be of type `uniformResourceIdentifier` | -| \ \ \ \ `uniformResourceIdentifier` | MUST | The HTTP URL of the Issuing CA's CRL service for this certificate. | -| \ \ **2+** | MAY | Additional `GeneralName`s MAY be present. If present, they MUST be of type `uniformResourceIdentifier`. | -| \ \ \ \ `uniformResourceIdentifier` | MUST | If present, the scheme of the `uniformResourceIdentifier` MUST be "http". | -| \ \ **3** | MUST NOT | `GeneralName`s that do not conform to the above requirements MUST NOT be present. | +If present, the CRL Distribution Points extension MUST contain at least one `DistributionPoint`; containing more than one is NOT RECOMMENDED. All `DistributionPoint` items must be formatted as follows: + +Table: `DistributionPoint` profile + +| __Field__ | __Presence__ | __Description__ | +| --- | -- | ------ | +| `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | +| `reasons` | MUST NOT | | +| `cRLIssuer` | MUST NOT | | + +A `fullName` MUST contain at least one `GeneralName`; it MAY contain more than one. All `GeneralName`s MUST be of type `uniformResourceIdentifier`, and the scheme of each MUST be "http". The first `GeneralName` must contain the HTTP URL of the Issuing CA's CRL service for this certificate. ##### 7.1.2.11.3 Signed Certificate Timestamp List @@ -3074,10 +3080,10 @@ Table: Encoding and Order Requirements for Selected Attributes | `organizationName` | `2.5.4.10` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | | `surname` | `2.5.4.4` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | | `givenName` | `2.5.4.42` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64[^surname_givenname] | -| `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 32 | +| `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | | `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -[^surname_givenname] **Note**: Although RFC 5280 specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. +[^surname_givenname]: **Note**: Although RFC 5280 specifies the upper bound as 32,768 characters, this was a transcription error from X.520 (08/2005). The effective (interoperable) upper bound is 64 characters. CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL follow the specified encoding requirements for the attribute. From 83711e901831f5a2edbf15b990d49c099c9b5d1e Mon Sep 17 00:00:00 2001 From: Ryan Dickson Date: Thu, 30 Mar 2023 05:16:27 -0400 Subject: [PATCH 53/54] Fix broken links (#427) * Update BR.md * Update BR.md * Update BR.md * Update BR.md * Update BR.md --- docs/BR.md | 130 +++++++++++++++++++++++++++-------------------------- 1 file changed, 67 insertions(+), 63 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index 7b32aadb..ce6ab1f0 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,12 +1,12 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates -subtitle: Version 1.8.6 +subtitle: Version 1.8.8 author: - CA/Browser Forum -date: 14 December, 2022 +date: 11 April, 2023 copyright: | - Copyright 2022 CA/Browser Forum + Copyright 2023 CA/Browser Forum This work is licensed under the Creative Commons Attribution 4.0 International license. --- @@ -130,6 +130,8 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 1.8.4 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | | 1.8.5 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | | 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | +| 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | +| 1.8.8 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -179,6 +181,8 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. | | 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | | 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | +| 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | +| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 1.8.8 | ## 1.3 PKI Participants @@ -539,7 +543,7 @@ ISO 21188:2006, Public key infrastructure for financial services -- Practices an Network and Certificate System Security Requirements, Version 1.7, available at . -NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, . +NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, . RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. @@ -1801,7 +1805,7 @@ If the CA asserts compliance with these Baseline Requirements, all certificates * [Section 7.1.2.2 - Cross-Certified Subordinate CA Certificate Profile](#7122-cross-certified-subordinate-ca-certificate-profile) * Technically Constrained CA Certificates * [Section 7.1.2.3 - Technically-Constrained Non-TLS Subordinate CA Certificate Profile](#7123-technically-constrained-non-tls-subordinate-ca-certificate-profile) - * [Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile](7124-technically-constrained-precertificate-signing-ca-certificate-profile) + * [Section 7.1.2.4 - Technically-Constrained Precertificate Signing CA Certificate Profile](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) * [Section 7.1.2.5 - Technically-Constrained TLS Subordinate CA Certificate Profile](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) * [Section 7.1.2.6 - TLS Subordinate CA Certificate Profile](#7126-tls-subordinate-ca-certificate-profile) * [Section 7.1.2.7 - Subscriber (End-Entity) Certificate Profile](#7127-subscriber-server-certificate-profile) @@ -1839,12 +1843,12 @@ If the CA asserts compliance with these Baseline Requirements, all certificates | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.3](#71213-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-basic-constraints) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.3](#71213-root-ca-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-root-ca-basic-constraints) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | `extKeyUsage` | MUST NOT | N | - | -| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | +| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -1903,13 +1907,13 @@ The `subject` MUST comply with the requirements of [Section 7.1.4](#714-name-for | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -1937,7 +1941,7 @@ Table: Cross-Certified Subordinate CA with Restricted EKU [^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. -[^name_constraints]: See [Section 7.1.2.10.8](#712108-name-constraints) for further requirements, including regarding criticality of this extension. +[^name_constraints]: See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) for further requirements, including regarding criticality of this extension. ##### 7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted @@ -2007,14 +2011,14 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-extended-key-usage)| -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `certificatePolicies` | MAY | N | See [Section 7.1.2.3.2](#71232-certificate-policies) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-technically-constrained-non-tls-subordinate-ca-extended-key-usage)| +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `certificatePolicies` | MAY | N | See [Section 7.1.2.3.2](#71232-technically-constrained-non-tls-subordinate-ca-certificate-policies) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2091,14 +2095,14 @@ As noted in RFC 6962, Section 3.2, the `signature` field of a Precertificate is | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-extended-key-usage) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-technically-constrained-precertificate-signing-ca-extended-key-usage) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2134,14 +2138,14 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | -| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-name-constraints) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) | +| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-technically-constrained-tls-subordinate-ca-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2209,14 +2213,14 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-basic-constraints) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-certificate-policies) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | | `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-key-usage) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | | `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-extended-key-usage) | -| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-authority-information-access) | -| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-name-constraints) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2260,7 +2264,7 @@ For a Subscriber Certificate to be Domain Validated, it MUST meet the following | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See following table. | -| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2282,7 +2286,7 @@ For a Subscriber Certificate to be Individual Validated, it MUST meet the follow | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See following table. | -| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2303,7 +2307,7 @@ Table: Individual Validated `subject` Attributes | `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | | `organizationalUnitName` | MUST NOT | - | - | | `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | -| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) | In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. @@ -2314,7 +2318,7 @@ For a Subscriber Certificate to be Organization Validated, it MUST meet the foll | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See following table. | -| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). @@ -2336,7 +2340,7 @@ Table: Organization Validated `subject` Attributes | `givenName` | MUST NOT | - | - | | `organizationalUnitName` | MUST NOT | - | - | | `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | -| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) | In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. @@ -2348,7 +2352,7 @@ For a Subscriber Certificate to be Extended Validation, it MUST comply with the | __Field__ | __Requirements__ | | -- | ------- | | `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 9.2. | -| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-certificate-policies). | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | | All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. @@ -2357,20 +2361,20 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | -| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-authority-information-access) | +| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-subscriber-certificate-authority-information-access) | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-certificate-policies) | -| `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-extended-key-usage) | -| `subjectAltName` | MUST | * | See [Section 7.1.2.7.12](#712712-subject-alternative-name) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies) | +| `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-subscriber-certificate-extended-key-usage) | +| `subjectAltName` | MUST | * | See [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name) | | `nameConstraints` | MUST NOT | - | - | -| `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-key-usage) | -| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-basic-constraints) | +| `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-subscriber-certificate-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-subscriber-certificate-basic-constraints) | | `crlDistributionPoints` | MAY | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | -**Note**: whether or not the `subjectAltName` extension should be marked Critical depends on the contents of the Certificate's `subject` field, as detailed in [Section 7.1.2.7.12](#712712-subject-alternative-name). +**Note**: whether or not the `subjectAltName` extension should be marked Critical depends on the contents of the Certificate's `subject` field, as detailed in [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name). ##### 7.1.2.7.7 Subscriber Certificate Authority Information Access @@ -2518,15 +2522,15 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | -| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.5](#71285-extended-key-usage) | -| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.6](#71286-id-pkix-ocsp-nocheck) | -| `keyUsage` | MUST | Y | See [Section 7.1.2.8.7](#71287-key-usage) | -| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.4](#71284-basic-constraints) | +| `extKeyUsage` | MUST | - | See [Section 7.1.2.8.5](#71285-ocsp-responder-extended-key-usage) | +| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.6](#71286-ocsp-responder-id-pkix-ocsp-nocheck) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.7](#71287-ocsp-responder-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.4](#71284-ocsp-responder-basic-constraints) | | `nameConstraints` | MUST NOT | - | - | | `subjectAltName` | MUST NOT | - | - | | `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | -| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-authority-information-access) | -| `certificatePolicies` | MUST NOT | N | See [Section 7.1.2.8.8](#71288-certificate-policies) | +| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-ocsp-responder-authority-information-access) | +| `certificatePolicies` | MUST NOT | N | See [Section 7.1.2.8.8](#71288-ocsp-responder-certificate-policies) | | `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | | Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | | Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | @@ -2632,7 +2636,7 @@ Table: When the Precertificate is issued directly by the Issuing CA |     `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | |     `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | |     `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | -|     `extensions` | See [Section 7.1.2.9.1](#71291-directly-issued-precertificate-profile-extensions) | +|     `extensions` | See [Section 7.1.2.9.1](#71291-precertificate-profile-extensions---directly-issued) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | @@ -2651,7 +2655,7 @@ Table: When the Precertificate is issued by a Precertificate Signing CA on behal |     `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | |     `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | |     `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | -|     `extensions` | See [Section 7.1.2.9.2](#71292-precertificate-ca-issued-precertificate-profile-extensions) | +|     `extensions` | See [Section 7.1.2.9.2](#71292-precertificate-profile-extensions---precertificate-ca-issued) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | @@ -2676,7 +2680,7 @@ These extensions apply in the context of a Precertificate from a Precertificate | __Extension__ | __Presence__ | __Critical__ | __Description__ | | ---- | - | - | ----- | | Precertificate Poison (OID: 1.3.6.1.4.1.11129.2.4.3) | MUST | Y | See [Section 7.1.2.9.3](#71293-precertificate-poison) | -| `authorityKeyIdentifier` | \* | \* | See [Section 7.1.2.9.4](#71294-authority-key-identifier) | +| `authorityKeyIdentifier` | \* | \* | See [Section 7.1.2.9.4](#71294-precertificate-authority-key-identifier) | | Signed Certificate Timestamp List | MUST NOT | - | | | Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate | @@ -2730,7 +2734,7 @@ The following table details the acceptable `AttributeType`s that may appear with | `organizationName` | MUST | The CA's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | | `organizationalUnitName` | This attribute MUST NOT be included in Root CA Certificates defined in [Section 7.1.2.1](#7121-root-ca-certificate-profile) or TLS Subordinate CA Certificates defined in [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) or Technically-Constrained TLS Subordinate CA Certificates defined in [Section 7.1.2.6](#7126-tls-subordinate-ca-certificate-profile). This attribute SHOULD NOT be included in other types of CA Certificates. | - | - | | `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | -| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.3](#7143-other-subject-attributes) | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) | ##### 7.1.2.10.3 CA Certificate Authority Information Access @@ -3102,7 +3106,7 @@ Table: Encoding Requirements for Selected Attributes #### 7.1.4.3 Subscriber Certificate Common Name Attribute -If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)). The value of the field MUST be encoded as follows: +If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name)). The value of the field MUST be encoded as follows: * If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2. * If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4. From 92abb91350a2be5632d1b87b9e8d1d7b2fe65f68 Mon Sep 17 00:00:00 2001 From: Ryan Dickson Date: Fri, 14 Apr 2023 06:09:12 -0400 Subject: [PATCH 54/54] Update BR.md (#429) --- docs/BR.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/docs/BR.md b/docs/BR.md index ce6ab1f0..ef99c167 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,6 +1,6 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates -subtitle: Version 1.8.8 +subtitle: Version 2.0.0 author: - CA/Browser Forum date: 11 April, 2023 @@ -131,7 +131,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 1.8.5 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | | 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | | 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | -| 1.8.8 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | +| 2.0.0 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | \* Effective Date and Additionally Relevant Compliance Date(s) @@ -182,7 +182,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | | 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | | 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | -| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 1.8.8 | +| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | ## 1.3 PKI Participants @@ -2151,7 +2151,7 @@ This Certificate Profile MAY be used when issuing a CA Certificate that will be ##### 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints -For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. +For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. Table: `nameConstraints` requirements @@ -2240,7 +2240,7 @@ CAs SHALL NOT include additional names unless the CA is aware of a reason for in |     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | |     `issuerUniqueID` | MUST NOT be present | |     `subjectUniqueID` | MUST NOT be present | -|     `extensions` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | +|     `extensions` | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | @@ -2828,7 +2828,7 @@ Table: Permitted `policyQualifiers` ##### 7.1.2.10.8 CA Certificate Name Constraints -If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatability with certain legacy applications that do not support Name Constraints is necessary. +If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. Table: `nameConstraints` requirements @@ -3114,7 +3114,7 @@ If present, this attribute MUST contain exactly one entry that is one of the val #### 7.1.4.4 Other Subject Attributes -When explicitly stated as permitted by the relavant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). +When explicitly stated as permitted by the relevant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). Before including such an attribute, the CA SHALL: