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