EVG

SMIME

TLS

EVG

SMIME

TLS

#### 7.1.2.2 Subordinate CA Certificate a. `certificatePolicies` This extension MUST be present and SHOULD NOT be marked critical. `certificatePolicies:policyIdentifier` Required; see [Section 7.1.6.3](#7163-subordinate-ca-certificates) for requirements on Policy Identifiers. The following fields MUST be present if the Subordinate CA is not an Affiliate of the entity that controls the Root CA. * `certificatePolicies:policyQualifiers:policyQualifierId` (Optional) `id-qt 1` [RFC5280]. * `certificatePolicies:policyQualifiers:qualifier:cPSuri` (Optional) HTTP URL for the Root CA's Certificate Policies, Certification Practice Statement, Relying Party agreement, or other pointer to online policy information provided by the CA. b. `cRLDistributionPoints` This extension MUST be present and MUST NOT be marked critical. It MUST contain the HTTP URL of the CA's CRL service. c. `authorityInformationAccess` This extension MUST be present. It MUST NOT be marked critical. It MUST contain the HTTP URL of the Issuing CA's certificate (`accessMethod` = 1.3.6.1.5.5.7.48.2). If the CA provides OCSP responses, it MUST contain the HTTP URL of the Issuing CA's OCSP responder (`accessMethod` = 1.3.6.1.5.5.7.48.1). d. `basicConstraints` This extension MUST be present and MUST be marked critical. The `cA` field MUST be set true. The `pathLenConstraint` field MAY be present. e. `keyUsage` 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. g. `extKeyUsage` This extension MUST be present and SHOULD NOT be marked critical. If the Subordinate CA will be used to issue Code Signing Certificates: * `id-kp-codeSigning` MUST be present. * `id-kp-timeStamping` MUST NOT be present. If the Subordinate CA will be used to issue Timestamp Certificates: * `id-kp-timeStamping` MUST be present. * `id-kp-codeSigning` MUST NOT be present. Additionally, the following EKUs MUST NOT be present: * `anyExtendedKeyUsage` * `id-kp-serverAuth` * `id-kp-emailProtection` Other values SHOULD NOT be present. If any other value is present, the CA MUST have a business agreement with a Platform vendor requiring that EKU in order to issue a Platform-specific code signing certificate with that EKU. h. `authorityKeyIdentifier` This extension MUST be present and MUST NOT be marked critical.

EVG

SMIME

#### 7.1.2.2 Subordinate CA certificates The issuance of end entity S/MIME Certificates by Extant S/MIME CAs is described in [Appendix B](#appendix-b---transition-of-extant-smime-cas). a. `certificatePolicies` (SHALL be present) This extension SHOULD NOT be marked critical. All `policyIdentifier`s included in this extension SHALL be included in accordance with [Section 7.1.6.3](#7163-subordinate-ca-certificates). If the value of this extension includes a `PolicyInformation` which contains a qualifier of type `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1), then the value of the qualifier SHALL be a HTTP or HTTPS URL for the Issuing CA's CP and/or CPS, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. If a qualifier of type `id-qt-unotice` (OID: 1.3.6.1.5.5.7.2.2) is included, then it SHALL contain `explicitText` and SHALL NOT contain `noticeRef`. b. `cRLDistributionPoints` (SHALL be present) This extension SHALL NOT be marked critical. It SHALL contain the HTTP URL of the CA's CRL service. c. `authorityInformationAccess` (SHOULD be present) This extension SHALL NOT be marked critical. It SHOULD contain the HTTP URL of the Issuing CA Certificate (`accessMethod` = 1.3.6.1.5.5.7.48.2). It MAY contain the HTTP URL of the Issuing CA OCSP responder (`accessMethod` = 1.3.6.1.5.5.7.48.1). d. `basicConstraints` (SHALL be present) This extension SHALL be marked critical. The `cA` field SHALL be set true. The `pathLenConstraint` field MAY be present. e. `keyUsage` (SHALL be present) This extension SHALL be marked critical. Bit positions for `keyCertSign` and `cRLSign` SHALL be set. If the Subordinate CA Private Key is used for signing OCSP responses, then the `digitalSignature` bit SHALL be set. f. `nameConstraints` (MAY be present) This extension SHOULD be marked critical[^*]. [^*]: Non-critical Name Constraints are an exception to [RFC 5280 (4.2.1.10)](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.10), however, they MAY be used until the `nameConstraints` extension is supported by Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide. g. `extKeyUsage` (MAY be present for Cross Certificates; SHALL be present otherwise) For Cross Certificates that share a Subject Distinguished Name and Subject Public Key with a Root CA Certificate operated in accordance with these Requirements, this extension MAY be present. If present, this extension SHOULD NOT be marked critical. This extension SHALL only contain usages for which the Issuing CA has verified the Cross Certificate is authorized to assert. This extension SHALL NOT contain the `anyExtendedKeyUsage` usage. For all other Subordinate CA Certificates, including Technically Constrained Subordinate CA Certificates, this extension SHALL be present and SHOULD NOT be marked critical[^**]. For Subordinate CA Certificates that will be used to issue S/MIME Certificates, the value `id-kp-emailProtection` SHALL be present. The values `id-kp-serverAuth`, `id-kp-codeSigning`, `id-kp-timeStamping`, and `anyExtendedKeyUsage` SHALL NOT be present. Other values MAY be present. [^**]: While [RFC 5280, Section 4.2.1.12](https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.12), notes that this extension will generally only appear within end-entity Certificates, these Requirements make use of this extension to further protect relying parties by limiting the scope of Subordinate Certificates, as implemented by a number of Application Software Suppliers. h. `authorityKeyIdentifier` (SHALL be present) This extension SHALL NOT be marked critical. It SHALL contain a `keyIdentifier` field and it SHALL NOT contain a `authorityCertIssuer` or `authorityCertSerialNumber` field. i. `subjectKeyIdentifier` (SHALL be present) This extension SHALL NOT be marked critical. It SHALL contain a value that is included in the `keyIdentifier` field of the `authorityKeyIdentifier` extension in Certificates issued by the Subordinate CA.

TLS

##### 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.

TLS

##### 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 Code signing and Timestamp Certificate a. `certificatePolicies` This extension MUST be present and SHOULD NOT be marked critical. * `certificatePolicies:policyIdentifier` (Required) A Policy Identifier, defined by the issuing CA, that indicates a Certificate Policy asserting the issuing CA's adherence to and compliance with these Requirements. The following fields MAY be present: * `certificatePolicies:policyQualifiers:policyQualifierId` (Recommended) `id-qt 1` [RFC 5280]. * `certificatePolicies:policyQualifiers:qualifier:cPSuri` (Optional) HTTP URL for the Subordinate CA's Certification Practice Statement, Relying Party agreement or other pointer to online information provided by the CA. b. `cRLDistributionPoints` This extension MUST be present. It MUST NOT be marked critical, and it MUST contain the HTTP URL of the CA's CRL service. c. `authorityInformationAccess` This extension MUST be present. It MUST NOT be marked critical. It MUST contain the HTTP URL of the Issuing CA's certificate (`accessMethod` = 1.3.6.1.5.5.7.48.2). If the CA provides OCSP responses, it MUST contain the HTTP URL of the Issuing CA's OCSP responder (`accessMethod` = 1.3.6.1.5.5.7.48.1). d. `basicConstraints` (optional) The `cA` field MUST NOT be true. e. `keyUsage` This extension MUST be present and MUST be marked critical. The bit position for `digitalSignature` MUST be set. Bit positions for `keyCertSign` and `cRLSign` MUST NOT be set. All other bit positions SHOULD NOT be set. f. `extKeyUsage` If the Certificate is a Code Signing Certificate, then `id-kp-codeSigning` MUST be present and the following EKUs MAY be present: * Lifetime Signing OID (`1.3.6.1.4.1.311.10.3.13`) * `id-kp-emailProtection` * Document Signing (`1.3.6.1.4.1.311.3.10.3.12`) If the Certificate is a Timestamp Certificate, then `id-kp-timeStamping` MUST be present and MUST be marked critical. Additionally, the following EKUs MUST NOT be present: * `anyExtendedKeyUsage` * `id-kp-serverAuth` Other values SHOULD NOT be present. If any other value is present, the CA MUST have a business agreement with a Platform vendor requiring that EKU in order to issue a Platform-specific code signing certificate with that EKU. g. `authorityKeyIdentifier` This extension MUST be present and MUST NOT be marked critical.

SMIME

#### 7.1.2.3 Subscriber certificates a. `certificatePolicies` (SHALL be present) This extension SHOULD NOT be marked critical. It SHALL include exactly one of the reserved `policyIdentifiers` listed in [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers), and MAY contain one or more identifiers documented by the CA in its CP and/or CPS. If the value of this extension includes a `PolicyInformation` which contains a qualifier of type `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1), then the value of the qualifier SHALL be a HTTP or HTTPS URL for the Issuing CA's CP and/or CPS, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. If a qualifier of type `id-qt-unotice` (OID: 1.3.6.1.5.5.7.2.2) is included, then it SHALL contain `explicitText` and SHALL NOT contain `noticeRef`. b. `cRLDistributionPoints` (SHALL be present) This extension SHOULD NOT be marked critical. It SHALL contain at least one `distributionPoint` whose `fullName` value includes a GeneralName of type `uniformResourceIdentifier` that includes a URI where the Issuing CA's CRL can be retrieved. | Generation | Allowed URI scheme | |------|-----------------------| | Strict and Multipurpose | Every `uniformResourceIdentifier` SHALL have the URI scheme HTTP. Other schemes SHALL NOT be present. | | Legacy | At least one `uniformResourceIdentifier` SHALL have the URI scheme HTTP. Other schemes (LDAP, FTP, ...) MAY be present. | c. `authorityInformationAccess` (SHOULD be present) This extension SHALL NOT be marked critical. 1. `id-ad-ocsp` The `authorityInformationAccess` extension MAY contain one or more `accessMethod` values of type `id-ad-ocsp` that specifies the URI of the Issuing CA's OCSP responder. | Generation | Allowed URI scheme | |------|-----------------------| | Strict and Multipurpose | When provided, every `accessMethod` SHALL have the URI scheme HTTP. Other schemes SHALL NOT be present. | | Legacy | When provided, at least one `accessMethod` SHALL have the URI scheme HTTP. Other schemes (LDAP, FTP, ...) MAY be present. | 1. `id-ad-caIssuers` The `authorityInformationAccess` extension SHOULD contain at least one `accessMethod` value of type `id-ad-caIssuers` that specifies the URI of the Issuing CA's Certificate. | Generation | Allowed URI scheme | |------|-----------------------| | Strict and Multipurpose | When provided, every `accessMethod` SHALL have the URI scheme HTTP. Other schemes SHALL NOT be present. | | Legacy | When provided, at least one `accessMethod` SHALL have the URI scheme HTTP. Other schemes (LDAP, FTP, ...) MAY be present. | d. `basicConstraints` (optional) This extension MAY be present. The `cA` field SHALL NOT be true. `pathLenConstraint` field SHALL NOT be present. e. `keyUsage` (SHALL be present) This extension SHOULD be marked critical. | Generation | `rsaEncryption` | `id-ecPublicKey` |`id-Ed25519` and `id-Ed448` | |------|-----------------------|-----------------------------|-----------------------------| | Strict | For signing only, bit positions SHALL be set for `digitalSignature` and MAY be set for `nonRepudiation`.
For key management only, bit positions SHALL be set for `keyEncipherment`.
For dual use, bit positions SHALL be set for `digitalSignature` and `keyEncipherment` and MAY be set for `nonRepudiation`. |For signing only, bit positions SHALL be set for `digitalSignature` and MAY be set for `nonRepudiation`.
For key management only, bit positions SHALL be set for `keyAgreement` and MAY be set for `encipherOnly` or `decipherOnly`.
For dual use, bit positions SHALL be set for `digitalSignature` and `keyAgreement` and MAY be set for `nonRepudiation` and for `encipherOnly` or `decipherOnly` (only if `keyAgreement` is set).| Bit positions SHALL be set for `digitalSignature` and MAY be set for `nonRepudiation`. | | Multipurpose
and Legacy | For signing only, bit positions SHALL be set for `digitalSignature` and MAY be set for `nonRepudiation`.
For key management only, bit positions SHALL be set for `keyEncipherment` and MAY be set for `dataEncipherment`.
For dual use, bit positions SHALL be set for `digitalSignature` and `keyEncipherment` and MAY be set for `nonRepudiation` and `dataEncipherment`. |For signing only, bit positions SHALL be set for `digitalSignature` and MAY be set for `nonRepudiation`.
For key management only, bit positions SHALL be set for `keyAgreement` and MAY be set for `encipherOnly` or `decipherOnly`.
For dual use, bit positions SHALL be set for `digitalSignature` and `keyAgreement` and MAY be set for `nonRepudiation` and for `encipherOnly` or `decipherOnly` (only if `keyAgreement` is set).| Bit positions SHALL be set for `digitalSignature` and MAY be set for `nonRepudiation`. | Other bit positions SHALL NOT be set. f. `extKeyUsage` (SHALL be present) | Generation | `KeyPurposeId` | |------|-----------------------| | Strict | `id-kp-emailProtection` SHALL be present. Other values SHALL NOT be present. | | Multipurpose and Legacy |`id-kp-emailProtection` SHALL be present. Other values MAY be present. | The values `id-kp-serverAuth`, `id-kp-codeSigning`, `id-kp-timeStamping`, and `anyExtendedKeyUsage` SHALL NOT be present. g. `authorityKeyIdentifier` (SHALL be present) This extension SHALL NOT be marked critical. The `keyIdentifier` field SHALL be present. `authorityCertIssuer` and `authorityCertSerialNumber` fields SHALL NOT be present. h. `subjectAlternativeName` (SHALL be present) This extension SHOULD NOT be marked critical unless the `subject` field is an empty sequence. The value of this extension SHALL be encoded as specified in [Section 7.1.4.2.1](#71421-subject-alternative-name-extension). i. `smimeCapabilities` (optional) This extension MAY be present and SHALL NOT be marked critical. May indicate cryptographic capabilities of the sender of a signed S/MIME message, defined in [RFC 4262](https://datatracker.ietf.org/doc/html/rfc4262). j. `subjectDirectoryAttributes` (optional) | Generation | `subjectDirectoryAttributes` | |------|-----------------------| | Strict and Multipurpose | Prohibited | | Legacy | MAY be present and SHALL NOT be marked critical. | This extension MAY be present. This extension is used to contain verified attributes which are not part of the Subject's Distinguished Name such as dateOfBirth, placeOfBirth, gender, countryOfCitizenship, or countryOfResidence in accordance with [RFC 3739 Section 3.2.2](https://tools.ietf.org/html/rfc3739#section-3.2.2). k. qcStatements (optional) This extension MAY be present and SHALL NOT be marked critical. Indicates a Certificate that is issued as Qualified within a defined legal framework from an identified country or set of countries in accordance with [RFC 3739 Section 3.2.6](https://tools.ietf.org/html/rfc3739#section-3.2.6) and/or ETSI EN 319 412-5, Section 4. l. Legal Entity Identifier (optional) | Generation | LEI | |------|-----------------------| | `Mailbox-validated` | Prohibited | | `Organization-validated` | LEI (1.3.6.1.4.1.52266.1) MAY be present and SHALL NOT be marked critical. Role (1.3.6.1.4.1.52266.2) SHALL NOT be present.| | `Sponsor-validated` | LEI (1.3.6.1.4.1.52266.1) or for role (1.3.6.1.4.1.52266.2) MAY be present and SHALL NOT be marked critical. | | `Individual-validated` | Prohibited | The Legal Entity Identifier (LEI) is a 20-character, alpha-numeric code used in accordance with ISO 17442-1:2020, Clause 6 and ISO 17442-2:2020, Clause 4. The CA SHALL verify that the RegistrationStatus for the LEI record is ISSUED and the EntityStatus is ACTIVE. The CA SHALL only allow use of an LEI if the ValidationSources entry is FULLY_CORROBORATED. An LEI SHALL NOT be used if ValidationSources entry is PARTIALLY_CORROBORATED, PENDING, or ENTITY_SUPPLIED_ONLY. In cases where the "role" LEI is used, the CA SHALL verify that the LEI data reference is assigned to the Individual Subject whose identity has been verified in accordance with [Section 3.2.4](#324-authentication-of-individual-identity). m. Adobe Extensions (optional) | Generation | Adobe Extensions | |------|-----------------------| | Strict | Prohibited | | Multipurpose and Legacy | MAY be present and SHALL NOT be marked critical. May include the Adobe Time-stamp X509 extension (1.2.840.113583.1.1.9.1) or the Adobe ArchiveRevInfo extension (1.2.840.113583.1.1.9.2) | n. `subjectKeyIdentifier` (SHOULD be present) This extension SHALL NOT be marked critical. It SHOULD contain a value that is derived from the Public Key included in the Subscriber Certificate.

TLS

##### 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 | - | - |

TLS

SMIME

TLS

#### 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` | |

TLS

##### 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.

TLS

##### 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.

TLS

##### 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.

TLS

##### 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` | * | 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) | **Notes**: - 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). - whether or not the CRL Distribution Points extension must be present depends on 1) whether the Certificate includes an Authority Information Access extension with an id-ad-ocsp accessMethod and 2) the Certificate's validity period, as detailed in [Section 7.1.2.11.2](#712112-crl-distribution-points).

TLS

##### 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.

TLS

##### 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).

TLS

##### 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 | - |

TLS

##### 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. | Table: Permitted `policyQualifiers` | __Qualifier ID__ | __Presence__ | __Field Type__ | __Contents__ | | --- | - | - | ----- | | `id-qt-cps` (OID: 1.3.6.1.5.5.7.2.1) | MAY | `IA5String` | The HTTP or HTTPS URL for the Issuing CA's Certificate Policies, Certification Practice Statement, Relying Party Agreement, or other pointer to online policy information provided by the Issuing CA. | | Any other qualifier | MUST NOT | - | - | **Note**: See [Section 7.1.2.8.2](#71282-ocsp-responder-extensions) for applicable effective dates for when this extension may be included. **Note**: Because the Certificate Policies extension may be used to restrict the applicable usages for a Certificate, incorrect policies may result in OCSP Responder Certificates that fail to successfully validate, resulting in invalid OCSP Responses. Including the `anyPolicy` policy can reduce this risk, but add to client processing complexity and interoperability issues.

TLS

#### 7.1.2.9 Precertificate Profile A Precertificate is a signed data structure that can be submitted to a Certificate Transparency log, as defined by [RFC 6962](https://tools.ietf.org/doc/html/rfc6962). A Precertificate appears structurally identical to a Certificate, with the exception of a special critical poison extension in the `extensions` field, with the OID of `1.3.6.1.4.1.11129.2.4.3`. This extension ensures that the Precertificate will not be accepted as a Certificate by clients conforming to [RFC 5280](https://tools.ietf.org/doc/html/rfc5280). The existence of a signed Precertificate can be treated as evidence of a corresponding Certificate also existing, as the signature represents a binding commitment by the CA that it may issue such a Certificate. A Precertificate is created after a CA has decided to issue a Certificate, but prior to the actual signing of the Certificate. The CA MAY construct and sign a Precertificate corresponding to the Certificate, for purposes of submitting to Certificate Transparency Logs. The CA MAY use the returned Signed Certificate Timestamps to then alter the Certificate's `extensions` field, adding a Signed Certificate Timestamp List, as defined in [Section 7.1.2.11.3](#712113-signed-certificate-timestamp-list) and as permitted by the relevant profile, prior to signing the Certificate. Once a Precertificate is signed, relying parties are permitted to treat this as a binding commitment from the CA of the intent to issue a corresponding Certificate, or more commonly, that a corresponding Certificate exists. A Certificate is said to be corresponding to a Precertificate based upon the value of the `tbsCertificate` contents, as transformed by the process defined in [RFC 6962, Section 3.2](https://tools.ietf.org/doc/html/rfc6962#section-3.2). This profile describes the transformations that are permitted to a Certificate to construct a Precertificate. CAs MUST NOT issue a Precertificate unless they are willing to issue a corresponding Certificate, regardless of whether they have done so. Similarly, a CA MUST NOT issue a Precertificate unless the corresponding Certificate conforms to these Baseline Requirements, regardless of whether the CA signs the corresponding Certificate. A Precertificate may be issued either directly by the Issuing CA or by a Technically Constrained Precertificate Signing CA, as defined in [Section 7.1.2.4](#7124-technically-constrained-precertificate-signing-ca-certificate-profile). If issued by a Precertificate Signing CA, then in addition to the precertificate poison and signed certificate timestamp list extensions, the Precertificate `issuer` field and, if present, `authorityKeyIdentifier` extension, may differ from the Certificate, as described below. Table: When the Precertificate is issued directly by the Issuing CA | __Field__ | __Description__ | | --- | ------ | | `tbsCertificate` | | | `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | | `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | | `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | | `issuer` | Encoded value MUST be byte-for-byte identical to the `issuer` field of the Certificate | | `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | | `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | | `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | | `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | | `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | | `extensions` | See [Section 7.1.2.9.1](#71291-precertificate-profile-extensions---directly-issued) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | Table: When the Precertificate is issued by a Precertificate Signing CA on behalf of an Issuing CA | __Field__ | __Description__ | | --- | ------ | | `tbsCertificate` | | | `version` | Encoded value MUST be byte-for-byte identical to the `version` field of the Certificate | | `serialNumber` | Encoded value MUST be byte-for-byte identical to the `serialNumber` field of the Certificate | | `signature` | Encoded value MUST be byte-for-byte identical to the `signature` field of the Certificate | | `issuer` | Encoded value MUST be byte-for-byte identical to the `subject` field of the [Precertificate Signing CA Certificate](#7124-technically-constrained-precertificate-signing-ca-certificate-profile) | | `validity` | Encoded value MUST be byte-for-byte identical to the `validity` field of the Certificate | | `subject` | Encoded value MUST be byte-for-byte identical to the `subject` field of the Certificate | | `subjectPublicKeyInfo` | Encoded value MUST be byte-for-byte identical to the `subjectPublicKeyInfo` field of the Certificate | | `issuerUniqueID` | Encoded value MUST be byte-for-byte identical to the `issuerUniqueID` field of the Certificate, or omitted if omitted in the Certificate | | `subjectUniqueID` | Encoded value MUST be byte-for-byte identical to the `subjectUniqueID` field of the Certificate, or omitted if omitted in the Certificate | | `extensions` | See [Section 7.1.2.9.2](#71292-precertificate-profile-extensions---precertificate-ca-issued) | | `signatureAlgorithm` | Encoded value MUST be byte-for-byte identical to the `tbsCertificate.signature`. | | `signature` | | **Note**: This profile requires that the `serialNumber` field of the Precertificate be identical to that of the corresponding Certificate. [RFC 5280, Section 4.1.2.2](https://tools.ietf.org/doc/html/rfc5280#section-4.1.2.2) requires that the `serialNumber` of certificates be unique. For the purposes of this document, a Precertificate shall not be considered a "certificate" subject to that requirement, and thus may have the same `serialNumber` of the corresponding Certificate. However, this does not permit two Precertificates to share the same `serialNumber`, unless they correspond to the same Certificate, as this would otherwise indicate there are two corresponding Certificates that share the same `serialNumber`.

TLS

##### 7.1.2.10.2 CA Certificate Naming All `subject` names MUST be encoded as specified in [Section 7.1.4](#714-name-forms). The following table details the acceptable `AttributeType`s that may appear within the `type` field of an `AttributeTypeAndValue`, as well as the contents permitted within the `value` field. | __Attribute Name__ | __Presence__ | __Value__ | __Verification__ | | --- | - | ------ | -- | | `countryName` | MUST | The two-letter ISO 3166-1 country code for the country in which the CA's place of business is located. | [Section 3.2.2.3](#3223-verification-of-country) | | `stateOrProvinceName` | MAY | If present, the CA's state or province information. | [Section 3.2.2.1](#3221-identity) | | `localityName` | MAY | If present, the CA's locality. | [Section 3.2.2.1](#3221-identity) | | `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) |

TLS

##### 7.1.2.10.5 CA Certificate Certificate Policies If present, the Certificate Policies extension MUST contain at least one `PolicyInformation`. Each `PolicyInformation` MUST match the following profile: Table: No Policy Restrictions (Affiliated CA) | __Field__ | __Presence__ | __Contents__ | | --- | - | ------ | | `policyIdentifier` | MUST | When the Issuing CA wishes to express that there are no policy restrictions, the Subordinate CA MUST be an Affiliate of the Issuing CA. The Certificate Policies extension MUST contain only a single `PolicyInformation` value, which MUST contain the `anyPolicy` Policy Identifier. | | `anyPolicy` | MUST | | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | Table: Policy Restricted | __Field__ | __Presence__ | __Contents__ | | --- | - | ------ | | `policyIdentifier` | MUST | One of the following policy identifiers: | | A [Reserved Certificate Policy Identifier](#7161-reserved-certificate-policy-identifiers) | MUST | The CA MUST include at least one Reserved Certificate Policy Identifier (see [Section 7.1.6.1](#7161-reserved-certificate-policy-identifiers)) associated with the given Subscriber Certificate type (see [Section 7.1.2.7.1](#71271-subscriber-certificate-types)) directly or transitively issued by this Certificate. | | `anyPolicy` | MUST NOT | The `anyPolicy` Policy Identifier MUST NOT be present. | | Any other identifier | MAY | If present, MUST be defined by the CA and documented by the CA in its Certificate Policy and/or Certification Practice Statement. | | `policyQualifiers` | NOT RECOMMENDED | If present, MUST contain only permitted `policyQualifiers` from the table below. | This Profile RECOMMENDS that the first `PolicyInformation` value within the Certificate Policies extension contains the Reserved Certificate Policy Identifier (see [7.1.6.1](#7161-reserved-certificate-policy-identifiers))[^first_policy_note]. Regardless of the order of `PolicyInformation` values, the Certificate Policies extension MUST contain exactly one Reserved Certificate Policy Identifier. **Note**: policyQualifiers is NOT RECOMMENDED to be present in any Certificate issued under this Certificate Profile because this information increases the size of the Certificate without providing any value to a typical Relying Party, and the information may be obtained by other means when necessary. If the `policyQualifiers` is permitted and present within a `PolicyInformation` field, it MUST be formatted as follows: 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 | - | - |

TLS

##### 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.

TLS