diff --git a/docs/BR.md b/docs/BR.md index 22e55a92..f152d150 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,9 +1,11 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates -subtitle: Version 1.8.7 + +subtitle: Version 2.0.0 author: - CA/Browser Forum -date: 2 March, 2023 +date: 11 April, 2023 + copyright: | Copyright 2023 CA/Browser Forum @@ -130,7 +132,9 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 1.8.4 | SC54 | Onion Cleanup | 24-Mar-2022 | 23-Apr-2022 | | 1.8.5 | SC56 | 2022 Cleanup | 25-Oct-2022 | 30-Nov-2022 | | 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | -| 1.8.7 | SC61 | New CRL Entries must have a Revocation Reason Code | 2-March-2023 | 15-Jul-2023 | +| 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | +| 2.0.0 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | + \* Effective Date and Additionally Relevant Compliance Date(s) @@ -180,7 +184,9 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2022-06-01 | 7.1.3.2.1 | CAs MUST NOT sign OCSP responses using the SHA-1 hash algorithm. | | 2022-09-01 | 7.1.4.2.2 | CAs MUST NOT include the organizationalUnitName field in the Subject | | 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | -| 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries (for specific types of revocations) MUST have a revocation reason code | +| 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | +| 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | + ## 1.3 PKI Participants @@ -311,7 +317,7 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Country**: Either a member of the United Nations OR a geographic region recognized as a Sovereign State by at least two UN member nations. -**Cross Certificate**: A certificate that is used to establish a trust relationship between two Root CAs. +**Cross-Certified Subordinate CA Certificate**: A certificate that is used to establish a trust relationship between two CAs. **CSPRNG**: A random number generator intended for use in a cryptographic system. @@ -387,6 +393,8 @@ The Definitions found in the CA/Browser Forum's Network and Certificate System S **Private Key**: The key of a Key Pair that is kept secret by the holder of the Key Pair, and that is used to create Digital Signatures and/or to decrypt electronic records or files that were encrypted with the corresponding Public Key. +**Pending Prohibition​​**: The use of a behavior described with this label is highly discouraged, as it is planned to be deprecated and will likely be designated as MUST NOT in the future. + **Public Key**: The key of a Key Pair that may be publicly disclosed by the holder of the corresponding Private Key and that is used by a Relying Party to verify Digital Signatures created with the holder's corresponding Private Key and/or to encrypt messages so that they can be decrypted only with the holder's corresponding Private Key. **Public Key Infrastructure**: A set of hardware, software, people, procedures, rules, policies, and obligations used to facilitate the trustworthy creation, issuance, management, and use of Certificates and keys based on Public Key Cryptography. @@ -466,7 +474,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. @@ -539,7 +547,7 @@ ISO 21188:2006, Public key infrastructure for financial services -- Practices an Network and Certificate System Security Requirements, Version 1.7, available at . -NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, . +NIST SP 800-89, Recommendation for Obtaining Assurances for Digital Signature Applications, . RFC2119, Request for Comments: 2119, Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997. @@ -900,8 +908,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. @@ -986,8 +992,8 @@ 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 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. CAs are permitted to treat a record lookup failure as permission to issue if: @@ -1020,7 +1026,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 @@ -1071,7 +1077,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 or Reserved IP Addresses (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 @@ -1324,7 +1330,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.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. @@ -1335,7 +1341,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 @@ -1702,7 +1708,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. @@ -1786,153 +1792,1134 @@ 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). -CAs SHALL generate non-sequential Certificate serial numbers greater than zero (0) containing at least 64 bits of output from a CSPRNG. +Prior to 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements or the profile specified in version 1.8.6 of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates. Effective 2023-09-15, the CA SHALL issue Certificates in accordance with the profile specified in these Requirements. ### 7.1.1 Version number(s) Certificates MUST be of type X.509 v3. -### 7.1.2 Certificate Content and Extensions; Application of RFC 5280 +### 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#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) + * 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 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) + * [Section 7.1.2.8 - OCSP Responder Certificate Profile](#7128-ocsp-responder-certificate-profile) + * [Section 7.1.2.9 - Precertificate Profile](#7129-precertificate-profile) + +#### 7.1.2.1 Root CA Certificate Profile + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | Encoded value MUST be byte-for-byte identical to the encoded `subject` | +|     `validity` | See [Section 7.1.2.1.1](#71211-root-ca-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.1.2](#71212-root-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.1.1 Root CA Validity + +| __Field__ | __Minimum__ | __Maximum__ | +| - | ---- | ---- | +| `notBefore` | One day prior to the time of signing | The time of signing | +| `notAfter` | 2922 days (approx. 8 years) | 9132 days (approx. 25 years) | + +**Note**: This restriction applies even in the event of generating a new Root CA Certificate for an existing `subject` and `subjectPublicKeyInfo` (e.g. reissuance). The new CA Certificate MUST conform to these rules. + +##### 7.1.2.1.2 Root CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | RECOMMENDED | N | See [Section 7.1.2.1.3](#71213-root-ca-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.1.4](#71214-root-ca-basic-constraints) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST NOT | N | - | +| `certificatePolicies` | NOT RECOMMENDED | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +##### 7.1.2.1.3 Root CA 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.4 Root CA Basic Constraints + +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be set TRUE | +| `pathLenConstraint` | NOT RECOMMENDED | + +#### 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 one or more existing CA Certificate(s), whether a Root CA Certificate or Subordinate CA Certificate. + +Before issuing a Cross-Certified Subordinate CA, the Issuing CA MUST confirm that the existing CA Certificate(s) are subject to these Baseline Requirements and were issued in compliance with the then-current version of the Baseline Requirements at time of issuance. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.2.1](#71221-cross-certified-subordinate-ca-validity) | +|     `subject` | See [Section 7.1.2.2.2](#71222-cross-certified-subordinate-ca-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.2.3](#71223-cross-certified-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.2.1 Cross-Certified Subordinate CA Validity + +| __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.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.3 Cross-Certified 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.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +In addition to the above, extKeyUsage extension requirements vary based on the relationship between the Issuer and Subject organizations represented in the Cross-Certificate. + +The extKeyUsage extension MAY be "unrestricted" as described in the following table if: +- the organizationName represented in the Issuer and Subject names of the corresponding certificate are either: + - the same, or + - the organizationName represented in the Subject name is an affiliate of the organizationName represented in the Issuer name +- the corresponding CA represented by the Subject of the Cross-Certificate is operated by the same organization as the Issuing CA or an Affiliate of the Issuing CA organization. + +Table: Cross-Certified Subordinate CA with Unrestricted EKU + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `extKeyUsage` | SHOULD[^eku_ca] | N | See [Section 7.1.2.2.4](#71224-cross-certified-subordinate-ca-extended-key-usage---unrestricted) | + +In all other cases, the extKeyUsage extension MUST be "restricted" as described in the following table: + +Table: Cross-Certified Subordinate CA with Restricted EKU + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted) | + +[^eku_ca]: While [RFC 5280, Section 4.2.1.12](https://tools.ietf.org/html/rfc5280#section-4.2.1.13) notes that this extension will generally only appear within end-entity certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of CA Certificates, as implemented by a number of Application Software Suppliers. + +[^name_constraints]: See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) for further requirements, including regarding criticality of this extension. + +##### 7.1.2.2.4 Cross-Certified Subordinate CA Extended Key Usage - Unrestricted + +Table: Unrestricted Extended Key Usage Purposes (Affiliated Cross-Certified CA) + +| __Key Purpose__ | __Description__ | +| --- | ------- | +| `anyExtendedKeyUsage` | The special extended key usage to indicate there are no restrictions applied. If present, this MUST be the only key usage present. | +| Any other value | CAs MUST NOT include any other key usage with the `anyExtendedKeyUsage` key usage present. | + +Alternatively, if the Issuing CA does not use this form, then the Extended Key Usage extension, if present, MUST be encoded as specified in [Section 7.1.2.2.5](#71225-cross-certified-subordinate-ca-extended-key-usage---restricted). + +##### 7.1.2.2.5 Cross-Certified Subordinate CA Extended Key Usage - Restricted + +Table: Restricted TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs issuing TLS certificates directly or transitively) + +| __Key Purpose__ | __Description__ | +| --- | ------- | +| `id-kp-serverAuth` | MUST be present.| +| `id-kp-clientAuth` | MAY be present.| +| `id-kp-emailProtection`| MUST NOT be present.| +| `id-kp-codeSigning` | MUST NOT be present.| +| `id-kp-timeStamping` | MUST NOT be present.| +| `anyExtendedKeyUsage` | MUST NOT be present.| +| Any other value | NOT RECOMMENDED.| + +Table: Restricted Non-TLS Cross-Certified Subordinate CA Extended Key Usage Purposes (i.e., for restricted Cross-Certified Subordinate CAs not issuing TLS certificates directly or transitively) + +| __Key Purpose__ | __Description__ | +| --- | ------- | +| `id-kp-serverAuth` | MUST NOT be present.| +| `anyExtendedKeyUsage` | MUST NOT be present.| +| Any other value | MAY be present.| + +Each included Extended Key Usage key usage purpose: + + 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 be verified by the Issuing CA (i.e. the Issuing CA MUST verify the Cross-Certified Subordinate CA is authorized to assert the key usage purpose). + +CAs MUST NOT include additional key usage purposes unless the CA is aware of a reason for including the key usage purpose in the Certificate. + +#### 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. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.3.1](#71231-technically-constrained-non-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.3.1 Technically Constrained Non-TLS Subordinate CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.3.3](#71233-technically-constrained-non-tls-subordinate-ca-extended-key-usage)| +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `certificatePolicies` | MAY | N | See [Section 7.1.2.3.2](#71232-technically-constrained-non-tls-subordinate-ca-certificate-policies) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +##### 7.1.2.3.2 Technically Constrained Non-TLS Subordinate CA Certificate Policies + +If present, the Certificate Policies extension MUST be formatted as one of the two tables below: + +Table: No Policy Restrictions (Affiliated CA) + +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | +|     `anyPolicy` | MUST | | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + + +Table: Policy Restricted + +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST NOT | | +|     `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +|     Any other identifier | MAY | If present, MUST be documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + + +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.3.3 Technically Constrained Non-TLS Subordinate CA Extended Key Usage + +The Issuing CA MUST verify that the Subordinate CA Certificate is authorized to issue certificates for each included extended key usage purpose. Multiple, independent key purposes (e.g. `id-kp-timeStamping` and `id-kp-codeSigning`) are NOT RECOMMENDED. + +| __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. + +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__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | The algorithm identifier MUST be byte-for-byte identical to the algorithm identifier of the `subjectPublicKeyInfo` field of the Issuing CA. See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.4.1](#71241-technically-constrained-precertificate-signing-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.4.1 Technically Constrained Precertificate Signing CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.4.2](#71242-technically-constrained-precertificate-signing-ca-extended-key-usage) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +##### 7.1.2.4.2 Technically Constrained Precertificate Signing CA Extended Key Usage + +| __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 + +This Certificate Profile MAY be used when issuing a CA Certificate that will be considered Technically Constrained, and which will be used to issue TLS certificates directly or transitively. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.5.1](#71251-technically-constrained-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.5.1 Technically Constrained TLS Subordinate CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) | +| `nameConstraints` | MUST | \*[^name_constraints] | See [Section 7.1.2.5.2](#71252-technically-constrained-tls-subordinate-ca-name-constraints) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +##### 7.1.2.5.2 Technically Constrained TLS Subordinate CA Name Constraints + +For a TLS Subordinate CA to be Technically Constrained, Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility with certain legacy applications that do not support Name Constraints is necessary. + +Table: `nameConstraints` requirements + +| __Field__ | __Description__ | +| -- | ------- | +| `permittedSubtrees` | The `permittedSubtrees` MUST contain at least one `GeneralSubtree` for both of the `dNSName` and `iPAddress` `GeneralName` name types, UNLESS the specified `GeneralName` name type appears within the `excludedSubtrees` to exclude all names of that name type. Additionally, the `permittedSubtrees` MUST contain at least one `GeneralSubtree` of the `directoryName` `GeneralName` name type. | +|     `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +|         `base` | See following table. | +|         `minimum` | MUST NOT be present. | +|         `maximum` | MUST NOT be present. | +| `excludedSubtrees` | The `excludedSubtrees` MUST contain at least one `GeneralSubtree` for each of the `dNSName` and `iPAddress` `GeneralName` name types, unless there is an instance present of that name type in the `permittedSubtrees`. The `directoryName` name type is NOT RECOMMENDED. | +|     `GeneralSubtree` | The requirements for a `GeneralSubtree` that appears within a `permittedSubtrees`. | +|         `base` | See following table. | +|         `minimum` | MUST NOT be present. | +|         `maximum` | MUST NOT be present. | + +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)). | 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. | +| `otherName` | NOT RECOMMENDED | See below | See below | See below | +| Any other value | MUST NOT | - | - | - | + +Any `otherName`, if present: + + 1. MUST apply in the context of the public Internet, unless: + 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.6 TLS Subordinate CA Certificate Profile + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.10.1](#712101-ca-certificate-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.6.1](#71261-tls-subordinate-ca-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.6.1 TLS Subordinate CA Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `basicConstraints` | MUST | Y | See [Section 7.1.2.10.4](#712104-ca-certificate-basic-constraints) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.10.5](#712105-ca-certificate-certificate-policies) | +| `crlDistributionPoints` | MUST | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.10.7](#712107-ca-certificate-key-usage) | +| `subjectKeyIdentifier` | MUST | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `extKeyUsage` | MUST[^eku_ca] | N | See [Section 7.1.2.10.6](#712106-ca-certificate-extended-key-usage) | +| `authorityInformationAccess` | SHOULD | N | See [Section 7.1.2.10.3](#712103-ca-certificate-authority-information-access) | +| `nameConstraints` | MAY | \*[^name_constraints] | See [Section 7.1.2.10.8](#712108-ca-certificate-name-constraints) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +#### 7.1.2.7 Subscriber (Server) Certificate Profile + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | | +|          `notBefore` | A value within 48 hours of the certificate signing operation. | +|          `notAfter` | See [Section 6.3.2](#632-certificate-operational-periods-and-key-pair-usage-periods) | +|     `subject` | See [Section 7.1.2.7.1](#71271-subscriber-certificate-types) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 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.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.7.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. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +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` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | +| Any other attribute | MUST NOT | - | - | + +##### 7.1.2.7.3 Individual Validated + +For a Subscriber Certificate to be Individual Validated, it MUST meet the following profile: + +| __Field__ | __Requirements__ | +| -- | ------- | +| `subject` | See following table. | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.3` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +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) | +| `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. Multiple instances MAY be present. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationName` | NOT RECOMMENDED | If present, MUST contain the Subject's name or DBA. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `surname` | MUST | The Subject's surname. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `givenName` | MUST | The Subject's given name. | [Section 3.2.3](#323-authentication-of-individual-identity) | +| `organizationalUnitName` | MUST NOT | - | - | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) | + +In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. + +##### 7.1.2.7.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. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.2.2` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) | + +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). + +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: Organization Validated `subject` Attributes + +| __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | +| --- | - | ------ | -- | +| `domainComponent` | MAY | If present, this field MUST contain a Domain Label from a Domain Name. The `domainComponent` fields for the Domain Name MUST be in a single ordered sequence containing all Domain Labels from the Domain Name. The Domain Labels MUST be encoded in the reverse order to the on-wire representation of domain names in the DNS protocol, so that the Domain Label closest to the root is encoded first. Multiple instances MAY be present. | [Section 3.2] +| `countryName` | MUST | The two-letter ISO 3166-1 country code for the country associated with the Subject. If a Country is not represented by an official ISO 3166-1 country code, the CA MUST specify the ISO 3166-1 user-assigned code of `XX`, indicating that an official ISO 3166-1 alpha-2 code has not been assigned. | [Section 3.2.2.1](#3221-identity) | +| `stateOrProvinceName` | MUST / MAY | MUST be present if `localityName` is absent, MAY be present otherwise. If present, MUST contain the Subject's state or province information. | [Section 3.2.2.1](#3221-identity) | +| `localityName` | MUST / MAY | MUST be present if `stateOrProvinceName` is absent, MAY be present otherwise. If present, MUST contain the Subject's locality information. | [Section 3.2.2.1](#3221-identity) | +| `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. Multiple instances MAY be present.| [Section 3.2.2.1](#3221-identity) | +| `organizationName` | MUST | The Subject's name or DBA. The CA MAY include information in this field that differs slightly from the verified name, such as common variations or abbreviations, provided that the CA documents the difference and any abbreviations used are locally accepted abbreviations; e.g. if the official record shows "Company Name Incorporated", the CA MAY use "Company Name Inc." or "Company Name". | [Section 3.2.2.2](#3222-dbatradename) | +| `surname` | MUST NOT | - | - | +| `givenName` | MUST NOT | - | - | +| `organizationalUnitName` | MUST NOT | - | - | +| `commonName` | NOT RECOMMENDED | If present, MUST contain a value derived from the `subjectAltName` extension according to [Section 7.1.4.3](#7143-subscriber-certificate-common-name-attribute). | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) | + +In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. + +##### 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: + +| __Field__ | __Requirements__ | +| -- | ------- | +| `subject` | See Guidelines for the Issuance and Management of Extended Validation Certificates, Section 9.2. | +| `certificatePolicies` | MUST be present. MUST assert the [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) of `2.23.140.1.1` as a `policyIdentifier`. See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies). | +| All other extensions | See [Section 7.1.2.7.6](#71276-subscriber-certificate-extensions) and the Guidelines for the Issuance and Management of Extended Validation Certificates. | + +In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '-', and ' ' (i.e. space) characters, and/or any other indication that the value is absent, incomplete, or not applicable. + +##### 7.1.2.7.6 Subscriber Certificate Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityInformationAccess` | MUST | N | See [Section 7.1.2.7.7](#71277-subscriber-certificate-authority-information-access) | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `certificatePolicies` | MUST | N | See [Section 7.1.2.7.9](#71279-subscriber-certificate-certificate-policies) | +| `extKeyUsage` | MUST | N | See [Section 7.1.2.7.10](#712710-subscriber-certificate-extended-key-usage) | +| `subjectAltName` | MUST | * | See [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name) | +| `nameConstraints` | MUST NOT | - | - | +| `keyUsage` | SHOULD | Y | See [Section 7.1.2.7.11](#712711-subscriber-certificate-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.7.8](#71278-subscriber-certificate-basic-constraints) | +| `crlDistributionPoints` | MAY | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| `subjectKeyIdentifier` | NOT RECOMMENDED | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +**Note**: whether or not the `subjectAltName` extension should be marked Critical depends on the contents of the Certificate's `subject` field, as detailed in [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name). + +##### 7.1.2.7.7 Subscriber Certificate Authority Information Access + +The `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. + +The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. + +| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| -- | -- | ---- | - | - | --- | +| `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.7.8 Subscriber Certificate Basic Constraints + +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be FALSE | +| `pathLenConstraint` | MUST NOT be present | + +##### 7.1.2.7.9 Subscriber Certificate Certificate Policies + +If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: + +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)). | +|     `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | +|     Any other identifier | MAY | If present, MUST be defined and documented in the CA's Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + + +This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. + + +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 Subscriber Certificate 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 | - | NOT RECOMMENDED | + +##### 7.1.2.7.11 Subscriber Certificate Key Usage + +The acceptable Key Usage values vary based on whether the Certificate's `subjectPublicKeyInfo` identifies an RSA public key or an ECC public key. CAs MUST ensure the Key Usage is appropriate for the Certificate Public Key. + +Table: Key Usage for RSA Public Keys + +| __Key Usage__ | __Permitted__ | __Required__ | +| ---- | - | - | +| `digitalSignature` | Y | SHOULD | +| `nonRepudiation` | N | -- | +| `keyEncipherment` | Y | MAY | +| `dataEncipherment` | Y | NOT RECOMMENDED | +| `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 is NOT RECOMMENDED. The `dataEncipherment` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384). + +Table: Key Usage for ECC Public Keys + +| __Key Usage__ | __Permitted__ | __Required__ | +| ---- | - | - | +| `digitalSignature` | Y | MUST | +| `nonRepudiation` | N | -- | +| `keyEncipherment` | N | -- | +| `dataEncipherment` | N | -- | +| `keyAgreement` | Y | NOT RECOMMENDED | +| `keyCertSign` | N | -- | +| `cRLSign` | N | -- | +| `encipherOnly` | N | -- | +| `decipherOnly` | N | -- | + +**Note**: The `keyAgreement` bit is currently permitted, although setting it is NOT RECOMMENDED, as it is a Pending Prohibition (https://github.com/cabforum/servercert/issues/384). + +##### 7.1.2.7.12 Subscriber Certificate Subject Alternative Name + +For Subscriber Certificates, the Subject Alternative Name MUST be present and MUST contain at least one `dNSName` or `iPAddress` `GeneralName`. See below for further requirements about the permitted fields and their validation requirements. + +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 | The entry MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). Wildcard Domain Names MUST be validated for consistency with [Section 3.2.2.6](#3226-wildcard-domain-validation). The entry MUST NOT contain an Internal Name. The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of P-Labels or Non-Reserved LDH Labels joined together by a U+002E FULL STOP (".") character. The zero-length Domain Label representing the root zone of the Internet Domain Name System MUST NOT be included (e.g. "example.com" MUST be encoded as "example.com" and MUST NOT be encoded as "example.com."). | +| `x400Address` | N | - | +| `directoryName` | N | - | +| `ediPartyName` | N | - | +| `uniformResourceIdentifier` | N | - | +| `iPAddress` | Y | The entry MUST contain the IPv4 or IPv6 address that the CA has confirmed the Applicant controls or has been granted the right to use through a method specified in [Section 3.2.2.5](#3225-authentication-for-an-ip-address). The entry MUST NOT contain a Reserved IP Address. | +| `registeredID` | N | - | + +#### 7.1.2.8 OCSP Responder Certificate Profile + +If the Issuing CA does not directly sign OCSP responses, it MAY make use of an OCSP Authorized Responder, as defined by [RFC 6960](https://tools.ietf.org/html/rfc6960#section-4.2.2.2). The Issuing CA of the Responder MUST be the same as the Issuing CA for the Certificates it provides responses for. + +| __Field__ | __Description__ | +| --- | ------ | +| `tbsCertificate` | | +|     `version` | MUST be v3(2) | +|     `serialNumber` | MUST be a non-sequential number greater than zero (0) and less than 2¹⁵⁹ containing at least 64 bits of output from a CSPRNG. | +|     `signature` | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. See [Section 7.1.4.1](#7141-name-encoding) | +|     `validity` | See [Section 7.1.2.8.1](#71281-ocsp-responder-validity) | +|     `subject` | See [Section 7.1.2.10.2](#712102-ca-certificate-naming) | +|     `subjectPublicKeyInfo` | See [Section 7.1.3.1](#7131-subjectpublickeyinfo) | +|     `issuerUniqueID` | MUST NOT be present | +|     `subjectUniqueID` | MUST NOT be present | +|     `extensions` | See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | + +##### 7.1.2.8.1 OCSP Responder Validity + +| __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.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.5](#71285-ocsp-responder-extended-key-usage) | +| `id-pkix-ocsp-nocheck` | MUST | N | See [Section 7.1.2.8.6](#71286-ocsp-responder-id-pkix-ocsp-nocheck) | +| `keyUsage` | MUST | Y | See [Section 7.1.2.8.7](#71287-ocsp-responder-key-usage) | +| `basicConstraints` | MAY | Y | See [Section 7.1.2.8.4](#71284-ocsp-responder-basic-constraints) | +| `nameConstraints` | MUST NOT | - | - | +| `subjectAltName` | MUST NOT | - | - | +| `subjectKeyIdentifier` | SHOULD | N | See [Section 7.1.2.11.4](#712114-subject-key-identifier) | +| `authorityInformationAccess` | NOT RECOMMENDED | N | See [Section 7.1.2.8.3](#71283-ocsp-responder-authority-information-access) | +| `certificatePolicies` | MUST NOT | N | See [Section 7.1.2.8.8](#71288-ocsp-responder-certificate-policies) | +| `crlDistributionPoints` | MUST NOT | N | See [Section 7.1.2.11.2](#712112-crl-distribution-points) | +| Signed Certificate Timestamp List | MAY | N | See [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) | +| Any other extension | NOT RECOMMENDED | - | See [Section 7.1.2.11.5](#712115-other-extensions) | + +##### 7.1.2.8.3 OCSP Responder Authority Information Access + +For OCSP Responder certificates, this extension is NOT RECOMMENDED, as the Relying Party should already possess the necessary information. In order to validate the given Responder certificate, the Relying Party must have access to the Issuing CA's certificate, eliminating the need to provide `id-ad-caIssuers`. Similarly, because of the requirement for an OCSP Responder certificate to include the `id-pkix-ocsp-nocheck` extension, it is not necessary to provide `id-ad-ocsp`, as such responses will not be checked by Relying Parties. + +If present, the `AuthorityInformationAccesssSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `AuthorityInfoAccessSyntax` MUST contain all required `AccessDescription`s. + +| __Access Method__ | __OID__ | __Access Location__ | __Presence__ | __Maximum__ | __Description__ | +| -- | -- | ---- | - | - | --- | +| `id-ad-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | NOT RECOMMENDED | \* | A HTTP URL of the Issuing CA's OCSP responder. | +| Any other value | - | - | MUST NOT | - | No other `accessMethod`s may be used. | + +##### 7.1.2.8.4 OCSP Responder Basic Constraints + +OCSP Responder certificates MUST NOT be CA certificates. The issuing CA may indicate this one of two ways: by omission of the `basicConstraints` extension, or through the inclusion of a `basicConstraints` extension that sets the `cA` boolean to FALSE. + +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be FALSE | +| `pathLenConstraint` | MUST NOT be present | + +**Note**: Due to DER encoding rules regarding the encoding of DEFAULT values within OPTIONAL fields, a `basicConstraints` extension that sets the `cA` boolean to FALSE MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `3000`, the encoded representation of an empty ASN.1 `SEQUENCE` value. + +##### 7.1.2.8.5 OCSP Responder Extended Key Usage + +| __Key Purpose__ | __OID__ | __Presence__ | +| ---- | ---- | - | +| `id-kp-OCSPSigning` | 1.3.6.1.5.5.7.3.9 | MUST | +| Any other value | - | MUST NOT | + +##### 7.1.2.8.6 OCSP Responder id-pkix-ocsp-nocheck + +The CA MUST include the `id-pkix-ocsp-nocheck` extension (OID: 1.3.6.1.5.5.7.48.1.5). + +This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6960, Section 4.2.2.2.1](https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1). + +##### 7.1.2.8.7 OCSP Responder 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.8.8 OCSP Responder Certificate Policies + +If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: + +| __Field__ | __Presence__ | __Contents__ | +| --- | - | ------ | +| `policyIdentifier` | MUST | One of the following policy identifiers: | +|     A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | NOT RECOMMENDED | | +|     `anyPolicy` | NOT RECOMMENDED | | +|     Any other identifier | NOT RECOMMENDED | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | +| `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | + -This section specifies the additional requirements for Certificate content and extensions for Certificates. +Table: Permitted `policyQualifiers` -#### 7.1.2.1 Root CA Certificate +| __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 | - | - | -a. `basicConstraints` - This extension MUST appear as a critical extension. The `cA` field MUST be set true. The `pathLenConstraint` field SHOULD NOT be present. +**Note**: See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. -b. `keyUsage` +**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. - 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. +#### 7.1.2.9 Precertificate Profile -c. `certificatePolicies` +A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate. - This extension SHOULD NOT be present. +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. -d. `extKeyUsage` +Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). - This extension MUST NOT be present. +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. -#### 7.1.2.2 Subordinate CA 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. -a. `certificatePolicies` - This extension MUST be present and SHOULD NOT be marked critical. +Table: When the Precertificate is issued directly by the Issuing CA - `certificatePolicies:policyIdentifier` (Required) +| __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-precertificate-profile-extensions---directly-issued) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | - 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) +Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA - `id-qt 1` [RFC5280]. +| __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-profile-extensions---precertificate-ca-issued) | +| `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | +| `signature` | | - * `certificatePolicies:policyQualifiers:qualifier:cPSuri` (Optional) +**Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same `serialNumber`. - 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. +##### 7.1.2.9.1 Precertificate Profile Extensions - Directly Issued -b. `cRLDistributionPoints` +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). - This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA's CRL service. +| __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 | -c. `authorityInformationAccess` +**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. - This extension SHOULD be present. It MUST NOT be marked critical. +##### 7.1.2.9.2 Precertificate Profile Extensions - Precertificate CA Issued - 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). +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). -d. `basicConstraints` +| __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-precertificate-authority-key-identifier) | +| Signed Certificate Timestamp List | MUST NOT | - | | +| Any other extension | \* | \* | The order, criticality, and encoded values of all other extensions MUST be byte-for-byte identical to the `extensions` field of the Certificate | - This extension MUST be present and MUST be marked critical. The `cA` field MUST be set true. The `pathLenConstraint` field MAY be present. +##### 7.1.2.9.3 Precertificate Poison -e. `keyUsage` +The Precertificate MUST contain the Precertificate Poison extension (OID: 1.3.6.1.4.1.11129.2.4.3). - 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. +This extension MUST have an `extnValue` `OCTET STRING` which is exactly the hex-encoded bytes `0500`, the encoded representation of the ASN.1 NULL value, as specified in [RFC 6962, Section 3.1](https://tools.ietf.org/doc/html/rfc6962#section-3.1). -f. `nameConstraints` (optional) +##### 7.1.2.9.4 Precertificate Authority Key Identifier - If present, this extension SHOULD be marked critical[^*]. +For Precertificates issued by a Precertificate Signing CA, the contents of the `authorityKeyIdentifier` extension MUST be one of the following: -[^*]: 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. +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. -g. `extKeyUsage` (optional/required) - 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__ | __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 | - For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates: - This extension MUST be present and SHOULD NOT be marked critical[^**]. +**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. - 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. +#### 7.1.2.10 Common CA Fields - 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]). +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). -[^**]: 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. +##### 7.1.2.10.1 CA Certificate Validity -h. `authorityKeyIdentifier` (required) +| __Field__ | __Minimum__ | __Maximum__ | +| -- | ---- | ---- | +| `notBefore` | One day prior to the time of signing | The time of signing | +| `notAfter` | The time of signing | Unspecified | - 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.10.2 CA Certificate Naming -#### 7.1.2.3 Subscriber Certificate +All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). -a. `certificatePolicies` +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. - This extension MUST be present and SHOULD NOT be marked critical. +| __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` | This attribute MUST NOT be included in Root CA Certificates defined in [Section 7.1.2.1](#7121-root-ca-certificate-profile) or TLS Subordinate CA Certificates defined in [Section 7.1.2.5](#7125-technically-constrained-tls-subordinate-ca-certificate-profile) or Technically-Constrained TLS Subordinate CA Certificates defined in [Section 7.1.2.6](#7126-tls-subordinate-ca-certificate-profile). This attribute SHOULD NOT be included in other types of CA Certificates. | - | - | +| `commonName` | MUST | The contents SHOULD be an identifier for the certificate such that the certificate's Name is unique across all certificates issued by the issuing certificate. | | +| Any other attribute | NOT RECOMMENDED | - | See [Section 7.1.4.4](#7144-other-subject-attributes) | - * `certificatePolicies:policyIdentifier` (Required) +##### 7.1.2.10.3 CA Certificate Authority Information Access - 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. +If present, the `AuthorityInfoAccessSyntax` MUST contain one or more `AccessDescription`s. Each `AccessDescription` MUST only contain a permitted `accessMethod`, as detailed below, and each `accessLocation` MUST be encoded as the specified `GeneralName` type. - The following extensions MAY be present: +The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with the same `accessMethod`, if permitted for that `accessMethod`. When multiple `AccessDescription`s are present with the same `accessMethod`, each `accessLocation` MUST be unique, and each `AccessDescription` MUST be ordered in priority for that `accessMethod`, with the most-preferred `accessLocation` being the first `AccessDescription`. No ordering requirements are given for `AccessDescription`s that contain different `accessMethod`s, provided that previous requirement is satisfied. - * `certificatePolicies:policyQualifiers:policyQualifierId` (Recommended) +| __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. | - `id-qt 1` [RFC 5280]. +##### 7.1.2.10.4 CA Certificate Basic Constraints - * `certificatePolicies:policyQualifiers:qualifier:cPSuri` (Optional) +| __Field__ | __Description__ | +| --- | ------- | +| `cA` | MUST be set TRUE | +| `pathLenConstraint` | MAY be present | - HTTP URL for the Subordinate CA's Certification Practice Statement, Relying Party Agreement or other pointer to online information provided by the CA. +##### 7.1.2.10.5 CA Certificate Certificate Policies -b. `cRLDistributionPoints` +If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: - 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` +Table: No Policy Restrictions (Affiliated CA) - 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). +| __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. | -d. `basicConstraints` (optional) - The `cA` field MUST NOT be true. +Table: Policy Restricted -e. `keyUsage` (optional) +| __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. | - If present, bit positions for `keyCertSign` and `cRLSign` MUST NOT be set. -f. `extKeyUsage` (required) +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. - 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) +**Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary. - 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.4 All Certificates +If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: -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. -CAs SHALL NOT issue a Certificate with: +Table: Permitted `policyQualifiers` -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). +| __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.5 Application of RFC 5280 +##### 7.1.2.10.6 CA Certificate Extended Key Usage -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. +| __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.7 CA Certificate 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.10.8 CA Certificate Name Constraints + +If present, the Name Constraints extension MUST be encoded as follows. As an explicit exception from RFC 5280, this extension SHOULD be marked critical, but MAY be marked non-critical if compatibility 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` | 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 below | See below | See below | +| Any other value | NOT RECOMMENDED | - | - | - | + +Any `otherName`, if present: + + 1. MUST apply in the context of the public Internet, unless: + 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). + +##### 7.1.2.11.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 | + +##### 7.1.2.11.2 CRL Distribution Points + +If present, the CRL Distribution Points extension MUST contain at least one `DistributionPoint`; containing more than one is NOT RECOMMENDED. All `DistributionPoint` items must be formatted as follows: + +Table: `DistributionPoint` profile + +| __Field__ | __Presence__ | __Description__ | +| --- | -- | ------ | +| `distributionPoint` | MUST | The `DistributionPointName` MUST be a `fullName` formatted as described below. | +| `reasons` | MUST NOT | | +| `cRLIssuer` | MUST NOT | | + +A `fullName` MUST contain at least one `GeneralName`; it MAY contain more than one. All `GeneralName`s MUST be of type `uniformResourceIdentifier`, and the scheme of each MUST be "http". The first `GeneralName` must contain the HTTP URL of the Issuing CA's CRL service for this certificate. + +##### 7.1.2.11.3 Signed Certificate Timestamp List + +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.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). 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 + +All extensions and extension values not directly addressed by the applicable certificate profile: + + 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. + +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 @@ -2061,139 +3048,85 @@ If the signing key is P-521, the signature MUST use ECDSA with SHA-512. When enc ### 7.1.4 Name Forms +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.1 Name Encoding -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. +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): +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. - -#### 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 +* 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. -__Certificate Field:__ `extensions:subjectAltName` -__Required/Optional:__ Required -__Contents:__ This extension MUST contain at least one entry. Each entry MUST be one of the following types: +When encoding a `Name`, the CA SHALL ensure that: -* `dNSName`: The entry MUST contain either a Fully-Qualified Domain Name or Wildcard Domain Name that the CA has validated in accordance with [Section 3.2.2.4](#3224-validation-of-domain-authorization-or-control). Wildcard Domain Names MUST be validated for consistency with [Section 3.2.2.6](#3226-wildcard-domain-validation). The entry MUST NOT contain an Internal Name. + * 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`. + * Each `Name` MUST NOT contain more than one instance of a given `AttributeTypeAndValue` across all `RelativeDistinguishedName`s unless explicitly allowed in these Requirements. - The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name contained in the entry MUST be composed entirely of LDH Labels joined together by a U+002E FULL STOP (".") character. The zero-length Domain Label representing the root zone of the Internet Domain Name System MUST NOT be included (e.g. "example.com" MUST be encoded as "example.com" and MUST NOT be encoded as "example.com."). +**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. - The Fully-Qualified Domain Name or the FQDN portion of the Wildcard Domain Name MUST consist solely of Domain Labels that are P-Labels or Non-Reserved LDH Labels. +#### 7.1.4.2 Subject Attribute Encoding -* `iPAddress`: The entry MUST contain an IPv4 or IPv6 address that the CA has validated in accordance with [Section 3.2.2.5](#3225-authentication-for-an-ip-address). The entry MUST NOT contain a Reserved IP Address. +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). -##### 7.1.4.2.2 Subject Distinguished Name Fields +CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL encode those attributes in the relative order as they appear in the table and follow the specified encoding requirements for the attribute. -a. __Certificate Field:__ `subject:commonName` (OID 2.5.4.3) - __Required/Optional:__ __Deprecated__ (Discouraged, but not prohibited) - __Contents:__ If present, this field MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.4.2.1](#71421-subject-alternative-name-extension)). The value of the field MUST be encoded as follows: +Table: Encoding and Order Requirements for Selected Attributes - * If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2. - * If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4. - * If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation. +| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | +| ---- | -- | --- | ---- | - | +| `domainComponent` | `0.9.2342.19200300.100.1.25` | [RFC 4519](https://tools.ietf.org/html/rfc4519) | MUST use `IA5String` | 63 | +| `countryName` | `2.5.4.6` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 2 | +| `stateOrProvinceName` | `2.5.4.8` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `localityName` | `2.5.4.7` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 128 | +| `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] | +| `organizationalUnitName` | `2.5.4.11` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | +| `commonName` | `2.5.4.3` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `UTF8String` or `PrintableString` | 64 | -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. +[^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. -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. +CAs that include attributes in the Certificate `subject` field that are listed in the table below SHALL follow the specified encoding requirements for the attribute. -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). +Table: Encoding Requirements for Selected Attributes -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) (h), 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). +| __Attribute__ | __OID__ | __Specification__ | __Encoding Requirements__ | __Max Length[^maxlength]__ | +| ---- | -- | --- | ---- | - | +| `businessCategory` | `2.5.4.15` | X.520 | MUST use `UTF8String` or `PrintableString` | 128 | +| `jurisdictionCountry` | `1.3.6.1.4.1.311.60.2.1.3` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `PrintableString` | 2 | +| `jurisdictionStateOrProvince` | `1.3.6.1.4.1.311.60.2.1.2` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | +| `jurisdictionLocality` | `1.3.6.1.4.1.311.60.2.1.1` | Guidelines for the Issuance and Management of Extended Validation Certificates | MUST use `UTF8String` or `PrintableString` | 128 | +| `serialNumber` | `2.5.4.5` | [RFC 5280](https://tools.ietf.org/html/rfc5280) | MUST use `PrintableString` | 64 | +| `organizationIdentifier` | `2.5.4.97` | X.520 | MUST use `UTF8String` or `PrintableString` | None | -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) (h), 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). +[^maxlength]: **Note**: ASN.1 length limits for DirectoryString are expressed as character limits, not byte limits. -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). +#### 7.1.4.3 Subscriber Certificate Common Name Attribute -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. +If present, this attribute MUST contain exactly one entry that is one of the values contained in the Certificate's `subjectAltName` extension (see [Section 7.1.2.7.12](#712712-subscriber-certificate-subject-alternative-name)). The value of the field MUST be encoded as follows: -i. __Certificate Field:__ `subject:organizationalUnitName` (OID: 2.5.4.11) - __Required/Optional:__ __Prohibited__. + * If the value is an IPv4 address, then the value MUST be encoded as an IPv4Address as specified in RFC 3986, Section 3.2.2. + * If the value is an IPv6 address, then the value MUST be encoded in the text representation specified in RFC 5952, Section 4. + * If the value is a Fully-Qualified Domain Name or Wildcard Domain Name, then the value MUST be encoded as a character-for-character copy of the `dNSName` entry value from the `subjectAltName` extension. Specifically, all Domain Labels of the Fully-Qualified Domain Name or FQDN portion of the Wildcard Domain Name must be encoded as LDH Labels, and P-Labels MUST NOT be converted to their Unicode representation. -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.4 Other Subject Attributes -#### 7.1.4.3 Subject Information - Root Certificates and Subordinate CA Certificates +When explicitly stated as permitted by the relevant certificate profile specified within [Section 7.1.2](#712-certificate-content-and-extensions), CAs MAY include additional attributes within the `AttributeTypeAndValue` beyond those specified in [Section 7.1.4.2](#7142-subject-attribute-encoding). -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. +Before including such an attribute, the CA SHALL: -##### 7.1.4.3.1 Subject Distinguished Name Fields - -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. - -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". - -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.5 Name constraints - -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. - -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: - -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). - -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`. - -A decoded example for issuance to the domain and sub domains of `example.com` by organization `Example LLC, Boston, Massachusetts, US` would be: - -```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 -``` - -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`. + * 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 -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. @@ -2206,58 +3139,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 - -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. - -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 @@ -2274,7 +3155,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. @@ -2307,7 +3188,7 @@ Note: Backdating the revocationDate field is an exception to best practice descr ## 7.3 OCSP profile -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. +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. The `CRLReason` indicated MUST contain a value permitted for CRLs, as specified in [Section 7.2.2](#722-crl-and-crl-entry-extensions). @@ -2329,7 +3210,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 [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. @@ -2381,7 +3262,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; @@ -2477,7 +3358,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; 4. **Identity of Applicant**: That, if the Certificate contains Subject Identity Information, the CA - i. implemented a procedure to verify the identity of the Applicant in accordance with [Section 3.2](#32-initial-identity-validation) and [Section 7.1.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; 5. **Subscriber Agreement**: That, if the CA and Subscriber are not Affiliated, the Subscriber and CA are parties to a legally valid and enforceable Subscriber Agreement that satisfies these Requirements, or, if the CA and Subscriber are the same entity or are Affiliated, the Applicant Representative acknowledged the Terms of Use;