From d513d20973493f1c17663d67500621ca59098c45 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Wed, 10 Feb 2021 19:56:06 -0500 Subject: [PATCH 01/38] 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 88e3182a65cae60a2aa22f565e0c302d55f79d1f Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 26 Jul 2021 13:04:25 -0400 Subject: [PATCH 02/38] 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 a2728277ec0392d3283cbccaede2ea019e13ed9c Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 26 Jul 2021 13:12:05 -0400 Subject: [PATCH 03/38] 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 9abc1a9e068d171f3b6bf6bf1276bf892cb25ab2 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 29 Jul 2021 18:06:23 -0400 Subject: [PATCH 04/38] 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 1cf09babad707d9dbe3d1aaa6ed3a0eacc5171b4 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 Aug 2021 13:52:27 -0400 Subject: [PATCH 05/38] 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 ce040e10d6d03572f4512cfc4a357c1b675424bd Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Wed, 4 Aug 2021 14:20:51 -0400 Subject: [PATCH 06/38] 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 1d9583aa744f709ecfcbd64c44ca9057580ddc88 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 19 Aug 2021 15:43:25 -0400 Subject: [PATCH 07/38] 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 5d4c9d7e781d0d50928a143be20fa81d0a956913 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:40:47 -0400 Subject: [PATCH 08/38] 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 954dfa00439bd5bf7f059cf7b1fa2d95bec679e8 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:45:45 -0400 Subject: [PATCH 09/38] 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 0736c582b3aa393a4aab4de8517ce19c43aaf479 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:54:54 -0400 Subject: [PATCH 10/38] 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 6087322c3dcf94bd1957b1cef0da76fb37ac6470 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:55:33 -0400 Subject: [PATCH 11/38] 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 2ef5da23800ec37f5600772e49786b4c4ed84455 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 13:57:47 -0400 Subject: [PATCH 12/38] 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 f52c7e9364325f1e39c4894dbed3d9efdfb452ae Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Fri, 20 Aug 2021 14:00:07 -0400 Subject: [PATCH 13/38] 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 c17867d19bb88e966e7f7cce893af7b835b0838f Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 21 Oct 2021 19:02:15 -0400 Subject: [PATCH 14/38] 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 3bb125d97d4c8c28b056300ba5e3a72a5473f37a Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 10:58:05 -0500 Subject: [PATCH 15/38] 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 4d37fd5655dd935e129144c458fa68dad3342501 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 11:03:26 -0500 Subject: [PATCH 16/38] 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 f9d9bfc3df38054a704842b146f3f61577a26d63 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 11:04:39 -0500 Subject: [PATCH 17/38] 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 1df9ed03ab6eb3ed22eb264c4a78a6df476c0fef Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 13 Jan 2022 11:06:59 -0500 Subject: [PATCH 18/38] 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 d369fa503c5b379e8e7cb19aed0f19e83a67b1f8 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:25 -0400 Subject: [PATCH 19/38] 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 35402abec99d0889783192db91ce34c08084f18d Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:31 -0400 Subject: [PATCH 20/38] 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 74c89be1716a1d1c70e2fc98a7f7878d5dd65f91 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:32 -0400 Subject: [PATCH 21/38] 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 8a8e60310de6c652cbf9581015d0ec0f42d4de07 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:33 -0400 Subject: [PATCH 22/38] 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 45f634bfd8c1d8c9d0b7544aabf423820fd1ac11 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:34 -0400 Subject: [PATCH 23/38] 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 90d16e177b1b0ef5bbbaccaf9470757132b08919 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:34 -0400 Subject: [PATCH 24/38] 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 4226cd3330806a65c895a2cd99b3a7cad6125275 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:36 -0400 Subject: [PATCH 25/38] 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 dd5e8fc2705ab73b42d93296d25cf56f2509c851 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:37 -0400 Subject: [PATCH 26/38] 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 feeef8ad5bfb56d0b4263882b91c0a62e8428398 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:38 -0400 Subject: [PATCH 27/38] 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 a73dd6da1688dd6338ea0c85b190952b08bf21c4 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:39 -0400 Subject: [PATCH 28/38] 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 037b36cf68313dd8a3a5d76e2a70aa9bbd71760b Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 12:18:40 -0400 Subject: [PATCH 29/38] 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 8900c4329b6af697736888678339a2da9223d704 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 14:37:01 -0400 Subject: [PATCH 30/38] 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 93505760608c2846898ac08efb38824a034e19ba Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 15:43:52 -0400 Subject: [PATCH 31/38] 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 67133bb4b1d4e85439cc8a7e11c0c30129e12979 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 15:51:49 -0400 Subject: [PATCH 32/38] 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 b5f50c26e91f0bba3ef9c3e84b4f3e56c830730a Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 2 May 2022 15:56:02 -0400 Subject: [PATCH 33/38] 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 e15c75564ab47949e9203acbae37811418845196 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 5 May 2022 10:53:30 -0400 Subject: [PATCH 34/38] 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 6be512896a3ac90ba3d1d0fb88ede09d9874c40e Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 5 May 2022 16:19:54 -0400 Subject: [PATCH 35/38] 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 c28718739c5fca9fd5092b1a5b372631cce85abb Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Thu, 5 May 2022 17:07:17 -0400 Subject: [PATCH 36/38] 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 112c9b2f1b04ebecb2cb0f71071d4d0472c31c0f Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Tue, 10 May 2022 12:20:53 -0400 Subject: [PATCH 37/38] 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 197f0964d991059609aa1acd7cb5eb6a53bfc343 Mon Sep 17 00:00:00 2001 From: Ryan Sleevi Date: Mon, 16 May 2022 14:28:51 -0400 Subject: [PATCH 38/38] 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.