diff --git a/docs/BR.md b/docs/BR.md index f152d150..d12c005e 100644 --- a/docs/BR.md +++ b/docs/BR.md @@ -1,10 +1,9 @@ --- title: Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates - -subtitle: Version 2.0.0 +subtitle: Version 2.0.1 author: - CA/Browser Forum -date: 11 April, 2023 +date: [TBD] copyright: | @@ -134,6 +133,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 1.8.6 | SC58 | Require distributionPoint in sharded CRLs | 7-Nov-2022 | 11-Dec-2022 | | 1.8.7 | SC61 | New CRL entries must have a Revocation Reason Code | 1-Apr-2023 | 15-Jul-2023 | | 2.0.0 | SC62 | Certificate Profiles Update | 22-Apr-2023 | 15-Sep-2023 | +| 2.0.1 | SC63 | Make OCSP optional, require CRLs, and incentivize automation | TBD | 15-Mar-2024 | @@ -186,7 +186,7 @@ The following Certificate Policy identifiers are reserved for use by CAs to asse | 2023-01-15 | 7.2.2 | Sharded or partitioned CRLs MUST have a distributionPoint | | 2023-07-15 | 4.9.1.1 and 7.2.2 | New CRL entries MUST have a revocation reason code | | 2023-09-15 | Section 7 (and others) | CAs MUST use the updated Certificate Profiles passed in Version 2.0.0 | - +| 2024-03-15 | 4.9.7 | CAs MUST generate and publish CRLs. | ## 1.3 PKI Participants @@ -460,6 +460,8 @@ The script outputs: **Root Certificate**: The self-signed Certificate issued by the Root CA to identify itself and to facilitate verification of Certificates issued to its Subordinate CAs. +**Short-lived Subscriber Certificate**: For Certificates issued on or after 15 March 2024 and prior to 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 10 days (864,000 seconds). For Certificates issued on or after 15 March 2026, a Subscriber Certificate with a Validity Period less than or equal to 7 days (604,800 seconds). + **Sovereign State**: A state or country that administers its own government, and is not dependent upon, or subject to, another power. **Subject**: The natural person, device, system, unit, or Legal Entity identified in a Certificate as the Subject. The Subject is either the Subscriber or a device under the control and operation of the Subscriber. @@ -581,6 +583,8 @@ RFC8499, Request for Comments: 8499, DNS Terminology. P. Hoffman, et al. January RFC8659, Request for Comments: 8659, DNS Certification Authority Authorization (CAA) Resource Record. P. Hallam-Baker, et al. November 2019. +RFC8954, Request for Comments: 8954, Online Certificate Status Protocol (OCSP) Nonce Extension. M. Sahni, Ed. November 2020. + WebTrust for Certification Authorities, SSL Baseline with Network Security, Version 2.5, available at . X.509, Recommendation ITU-T X.509 (08/2005) \| ISO/IEC 9594-8:2005, Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks. @@ -1213,7 +1217,9 @@ No stipulation. #### 4.9.1.1 Reasons for Revoking a Subscriber Certificate -The CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: +The CA MAY support revocation of Short-lived Subscriber Certificates. + +With the exception of Short-lived Subscriber Certificates, the CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: 1. The Subscriber requests in writing, without specifying a CRLreason, that the CA revoke the Certificate (CRLReason "unspecified (0)" which results in no reasonCode extension being provided in the CRL); 2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn); @@ -1221,7 +1227,7 @@ The CA SHALL revoke a Certificate within 24 hours and use the corresponding CRLR 4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber's Private Key based on the Public Key in the Certificate (such as a Debian weak key, see ) (CRLReason #1, keyCompromise); 5. The CA obtains evidence that the validation of domain authorization or control for any Fully-Qualified Domain Name or IP address in the Certificate should not be relied upon (CRLReason #4, superseded). -The CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason if one or more of the following occurs: +With the exception of Short-lived Subscriber Certificates, the CA SHOULD revoke a certificate within 24 hours and MUST revoke a Certificate within 5 days and use the corresponding CRLReason (see Section 7.2.2) if one or more of the following occurs: 6. The Certificate no longer complies with the requirements of [Section 6.1.5](#615-key-sizes) and [Section 6.1.6](#616-public-key-parameters-generation-and-quality-checking) (CRLReason #4, superseded); 7. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn); @@ -1280,20 +1286,28 @@ No stipulation. **Note**: Following certificate issuance, a certificate may be revoked for reasons stated in [Section 4.9](#49-certificate-revocation-and-suspension). Therefore, relying parties should check the revocation status of all certificates that contain a CDP or OCSP pointer. -### 4.9.7 CRL issuance frequency (if applicable) +### 4.9.7 CRL issuance frequency -For the status of Subscriber Certificates: +CRLs must be available via a publicly-accessible HTTP URL (i.e., "published"). -If the CA publishes a CRL, then the CA SHALL update and reissue CRLs at least once every seven days, and the value of the `nextUpdate` field MUST NOT be more than ten days beyond the value of the `thisUpdate` field. +Within twenty-four (24) hours of issuing its first Certificate, the CA MUST generate and publish either: +- a full and complete CRL; OR +- partitioned (i.e., "sharded") CRLs that, when aggregated, represent the equivalent of a full and complete CRL. -For the status of Subordinate CA Certificates: +CAs issuing Subscriber Certificates: +1. MUST update and publish a new CRL at least every: + - seven (7) days if all Certificates include an Authority Information Access extension with an id-ad-ocsp accessMethod (“AIA OCSP pointer”); or + - four (4) days in all other cases; +2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. -The CA SHALL update and reissue CRLs at least: +CAs issuing CA Certificates: +1. MUST update and publish a new CRL at least every twelve (12) months; +2. MUST update and publish a new CRL within twenty-four (24) hours after recording a Certificate as revoked. - i. once every twelve months; and - ii. within 24 hours after revoking a Subordinate CA Certificate. +CAs MUST continue issuing CRLs until one of the following is true: +- all Subordinate CA Certificates containing the same Subject Public Key are expired or revoked; OR +- the corresponding Subordinate CA Private Key is destroyed. -The value of the `nextUpdate` field MUST NOT be more than twelve months beyond the value of the `thisUpdate` field. ### 4.9.8 Maximum latency for CRLs (if applicable) @@ -1301,6 +1315,8 @@ No stipulation. ### 4.9.9 On-line revocation/status checking availability +The following SHALL apply for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. + OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either: 1. Be signed by the CA that issued the Certificates whose revocation status is being checked, or @@ -1312,7 +1328,9 @@ defined by RFC6960. ### 4.9.10 On-line revocation checking requirements -OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. +The following SHALL apply for communicating the status of Certificates which include an Authority Information Access extension with an id-ad-ocsp accessMethod. + +OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019. The CA MAY process the Nonce extension (`1.3.6.1.5.5.7.48.1.2`) in accordance with RFC 8954. The validity interval of an OCSP response is the difference in time between the `thisUpdate` and `nextUpdate` field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds. @@ -1376,7 +1394,7 @@ Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the ### 4.10.2 Service availability -The CA SHALL operate and maintain its CRL and OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions. +The CA SHALL operate and maintain its CRL and optional OCSP capability with resources sufficient to provide a response time of ten seconds or less under normal operating conditions. The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates issued by the CA. @@ -1752,9 +1770,7 @@ The CA SHALL protect its Private Key in a system or device that has been validat ### 6.3.2 Certificate operational periods and key pair usage periods -Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. -Subscriber Certificates issued after 1 March 2018, but prior to 1 September 2020, MUST NOT have a Validity Period greater than 825 days. -Subscriber Certificates issued after 1 July 2016 but prior to 1 March 2018 MUST NOT have a Validity Period greater than 39 months. +Subscriber Certificates issued on or after 1 September 2020 SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days. For the purpose of calculations, a day is measured as 86,400 seconds. Any amount of time greater than this, including fractional seconds and/or leap seconds, shall represent an additional day. For this reason, Subscriber Certificates SHOULD NOT be issued for the maximum permissible time by default, in order to account for such adjustments. @@ -2373,12 +2389,14 @@ In addition, `subject` Attributes MUST NOT contain only metadata such as '.', '- | `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) | +| `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) | -**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). +**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). ##### 7.1.2.7.7 Subscriber Certificate Authority Information Access @@ -2388,7 +2406,7 @@ The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with t | __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-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | 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. | @@ -2543,7 +2561,7 @@ If the Issuing CA does not directly sign OCSP responses, it MAY make use of an O 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. +If present, the `AuthorityInfoAccessSyntax` 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__ | | -- | -- | ---- | - | - | --- | @@ -2748,7 +2766,7 @@ The `AuthorityInfoAccessSyntax` MAY contain multiple `AccessDescription`s with t | __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-ocsp` | 1.3.6.1.5.5.7.48.1 | `uniformResourceIdentifier` | MAY | \* | 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. | @@ -2887,7 +2905,20 @@ This section contains several fields that are common among multiple certificate ##### 7.1.2.11.2 CRL Distribution Points -If present, the CRL Distribution Points extension MUST contain at least one `DistributionPoint`; containing more than one is NOT RECOMMENDED. All `DistributionPoint` items must be formatted as follows: +The CRL Distribution Points extension MUST be present in: +- Subordinate CA Certificates; and +- Subscriber Certificates that 1) do not qualify as "Short-lived Subscriber Certificates" and 2) do not include an Authority Information Access extension with an id-ad-ocsp accessMethod. + +The CRL Distribution Points extension SHOULD NOT be present in: +- Root CA Certificates. + +The CRL Distribution Points extension is OPTIONAL in: +- Short-lived Subscriber Certificates. + +The CRL Distribution Points extension MUST NOT be present in: +- OCSP Responder Certificates. + +When 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 @@ -3147,44 +3178,101 @@ The following Certificate Policy identifiers are reserved for use by CAs as an o ## 7.2 CRL profile +Prior to 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements or the profile specified in Version 1.8.7 of the Baseline Requirements for the Issuance and Management of Publicly‐Trusted Certificates. Effective 2024‐03‐15, the CA SHALL issue CRLs in accordance with the profile specified in these Requirements. + +If the CA asserts compliance with these Baseline Requirements, all CRLs that it issues MUST comply with the following CRL profile, which incorporates, and is 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. + +A full and complete CRL is a CRL whose scope includes all Certificates issued by the CA. + +A partitioned CRL (sometimes referred to as a "sharded CRL") is a CRL with a constrained scope, such as all Certificates issued by the CA during a certain period of time ("temporal sharding"). Aside from the presence of the Issuing Distribution Point extension (OID 2.5.29.28) in partitioned CRLs, both CRL formats are syntactically the same from the perspective of this profile. + +Minimally, CAs MUST issue either a "full and complete" CRL or a set of "partitioned" CRLs which cover the complete set of Certificates issued by the CA. In other words, if issuing only partitioned CRLs, the combined scope of those CRLs must be equivalent to that of a full and complete CRL. + +CAs MUST NOT issue indirect CRLs (i.e., the issuer of the CRL is not the issuer of all Certificates that are included in the scope of the CRL). + +Table: CRL Fields + +| __Field__ | __Presence__ | __Description__ | +| --- | ------ | ------ | +| `tbsCertList` | | | +|     `version` | MUST | MUST be v2(1), see [Section 7.2.1](#721-version-numbers) | +|     `signature` | MUST | See [Section 7.1.3.2](#7132-signature-algorithmidentifier) | +|     `issuer` | MUST | MUST be byte-for-byte identical to the `subject` field of the Issuing CA. | +|     `thisUpdate` | MUST | Indicates the issue date of the CRL. | +|     `nextUpdate` | MUST | Indicates the date by which the next CRL will be issued. For CRLs covering Subscriber Certificates, at most 10 days after the `thisUpdate`. For other CRLs, at most 12 months after the `thisUpdate`. | +|     `revokedCertificates` | * | MUST be present if the CA has issued a Certificate that has been revoked and the corresponding entry has yet to appear on at least one regularly scheduled CRL beyond the revoked Certificate's validity period. The CA SHOULD remove an entry for a corresponding Certificate after it has appeared on at least one regularly scheduled CRL beyond the revoked Certificate's validity period. See the "revokedCertificates Component" table for additional requirements. | +|     `extensions` | MUST | See the "CRL Extensions" table for additional requirements. | +| `signatureAlgorithm` | MUST | Encoded value MUST be byte-for-byte identical to the `tbsCertList.signature`. | +| `signature` | MUST | - | +| Any other value | NOT RECOMMENDED | - | + ### 7.2.1 Version number(s) +Certificate Revocation Lists MUST be of type X.509 v2. + ### 7.2.2 CRL and CRL entry extensions -1. `reasonCode` (OID 2.5.29.21) +Table: CRL Extensions + +| __Extension__ | __Presence__ | __Critical__ | __Description__ | +| ---- | - | - | ----- | +| `authorityKeyIdentifier` | MUST | N | See [Section 7.1.2.11.1](#712111-authority-key-identifier) | +| `CRLNumber` | MUST | N | MUST contain an INTEGER greater than or equal to zero (0) and less than 2¹⁵⁹, and convey a strictly increasing sequence. | +| `IssuingDistributionPoint` | * | Y | See [Section 7.2.2.1 CRL Issuing Distribution Point](#7221-crl-issuing-distribution-point) | +| Any other extension | NOT RECOMMENDED | - | - | - If present, this extension MUST NOT be marked critical. +Table: revokedCertificates Component - 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. +| __Component__ | __Presence__ | __Description__ | +| ---- | - | ----- | +| `serialNumber` | MUST | MUST be byte-for-byte identical to the serialNumber contained in the revoked Certificate. | +| `revocationDate` | MUST | Normally, the date and time revocation occurred. See the footnote following this table for circumstances where backdating is permitted. | +| `crlEntryExtensions` | * | See the "crlEntryExtensions Component" table for additional 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. - If a CRL entry is for a Certificate not subject to these Requirements and was either issued on-or-after 2020-09-30 or has a `notBefore` on-or-after 2020-09-30, the `CRLReason` MUST NOT be certificateHold (6). - If a CRL entry is for a Certificate subject to these Requirements, the `CRLReason` MUST NOT be certificateHold (6). +**Note:** The CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the Certificate was compromised prior to the revocation date that is indicated in the CRL entry for that Certificate. Backdating the revocationDate field is an exception to best practice described in RFC 5280 (Section 5.3.2); however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised. - If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST indicate the most appropriate reason for revocation of the Certificate. - - CRLReason MUST be included in the `reasonCode` extension of the CRL entry corresponding to a Subscriber Certificate that is revoked after July 15, 2023, unless the CRLReason is "unspecified (0)". Revocation reason code entries for Subscriber Certificates revoked prior to July 15, 2023, do NOT need to be added or changed. +Table: crlEntryExtensions Component -Only the following CRLReasons MAY be present in the CRL `reasonCode` extension for Subscriber Certifificates: +| __CRL Entry Extension__ | __Presence__ | __Description__ | +| --- | - | ------ | +| `reasonCode` | * | When present (OID 2.5.29.21), MUST NOT be marked critical and MUST indicate the most appropriate reason for revocation of the Certificate.

MUST be present unless the CRL entry is for a Certificate not technically capable of causing issuance and either 1) the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023 or 2) the reason for revocation (i.e., reasonCode) is unspecified (0).

See the "CRLReasons" table for additional requirements. | +| Any other value | NOT RECOMMENDED | - | - * **keyCompromise (RFC 5280 CRLReason #1):** Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised; - * **affiliationChanged (RFC 5280 CRLReason #3):** Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised; - * **superseded (RFC 5280 CRLReason #4):** Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS; - * **cessationOfOperation (RFC 5280 CRLReason #5):** Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate; or - * **privilegeWithdrawn (RFC 5280 CRLReason #9):** Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use. +Table: CRLReasons + +| __RFC 5280 reasonCode__ | __RFC 5280 reasonCode value__ | __Description__ | +| --- | - | ------ | +| unspecified | 0 | Represented by the omission of a reasonCode. MUST be omitted if the CRL entry is for a Certificate not technically capable of causing issuance unless the CRL entry is for a Subscriber Certificate subject to these Requirements revoked prior to July 15, 2023. +| keyCompromise | 1 | Indicates that it is known or suspected that the Subscriber’s Private Key has been compromised. | +| affiliationChanged | 3 | Indicates that the Subject's name or other Subject Identity Information in the Certificate has changed, but there is no cause to suspect that the Certificate's Private Key has been compromised. | +| superseded | 4 | Indicates that the Certificate is being replaced because: the Subscriber has requested a new Certificate, the CA has reasonable evidence that the validation of domain authorization or control for any fully‐qualified domain name or IP address in the Certificate should not be relied upon, or the CA has revoked the Certificate for compliance reasons such as the Certificate does not comply with these Baseline Requirements or the CA's CP or CPS. | +| cessationOfOperation | 5 | Indicates that the website with the Certificate is shut down prior to the expiration of the Certificate, or if the Subscriber no longer owns or controls the Domain Name in the Certificate prior to the expiration of the Certificate. +| certificateHold | 6 | MUST NOT be included if the CRL entry is for 1) a Certificate subject to these Requirements, or 2) a Certificate not subject to these Requirements and was either A) issued on-or-after 2020-09-30 or B) has a `notBefore` on-or-after 2020-09-30. +| privilegeWithdrawn | 9 | Indicates that there has been a subscriber-side infraction that has not resulted in keyCompromise, such as the Certificate Subscriber provided misleading information in their Certificate Request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use. | The Subscriber Agreement, or an online resource referenced therein, MUST inform Subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA provides to the Subscriber MUST allow for these options to be easily specified when the Subscriber requests revocation of their Certificate, with the default value being that no revocation reason is provided (i.e. the default corresponds to the CRLReason “unspecified (0)” which results in no reasonCode extension being provided in the CRL). The privilegeWithdrawn reasonCode SHOULD NOT be made available to the Subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA and not the Subscriber. -When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension. Additionally, the CA SHOULD update the revocation date in a CRL entry when it is determined that the private key of the certificate was compromised prior to the revocation date that is indicated in the CRL entry for that certificate. +When a CA obtains verifiable evidence of Key Compromise for a Certificate whose CRL entry does not contain a reasonCode extension or has a reasonCode extension with a non-keyCompromise reason, the CA SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension. + +#### 7.2.2.1 CRL Issuing Distribution Point + +Partitioned CRLs MUST contain an Issuing Distribution Point extension. The `distributionPoint` field of the Issuing Distribution Point extension MUST be present. Additionally, the `fullName` field of the DistributionPointName value MUST be present, and its value MUST conform to the following requirements: + +1. If a Certificate within the scope of the CRL contains a CRL Distribution Points extension, then at least one of the `uniformResourceIdentifiers` in the CRL Distribution Points's `fullName` field MUST be included in the `fullName` field of the CRL's Issuing Distribution Point extension. The encoding of the `uniformResourceIdentifier` value in the Issuing Distribution Point extension SHALL be byte-for-byte identical to the encoding used in the Certificate's CRL Distribution Points extension. +2. Other GeneralNames of type `uniformResourceIdentifier` MAY be included. +3. Non-`uniformResourceIdentifier` GeneralName types MUST NOT be included. + +The `indirectCRL` and `onlyContainsAttributeCerts` fields MUST be set to `FALSE` (i.e., not asserted). + +The CA MAY set either of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields to `TRUE`, depending on the scope of the CRL. + +The CA MUST NOT assert both of the `onlyContainsUserCerts` and `onlyContainsCACerts` fields. -Note: Backdating the revocationDate field is an exception to best practice described in RFC 5280 (section 5.3.2); however, these requirements specify the use of the revocationDate field to support TLS implementations that process the revocationDate field as the date when the Certificate is first considered to be compromised. - -2. `issuingDistributionPoint` (OID 2.5.29.28) +The `onlySomeReasons` field SHOULD NOT be included; if included, then the CA MUST provide another CRL whose scope encompasses all revocations regardless of reason code. - Effective 2023-01-15, if a CRL does not contain entries for all revoked unexpired certificates issued by the CRL issuer, then it MUST contain a critical Issuing Distribution Point extension and MUST populate the `distributionPoint` field of that extension. +This extension is NOT RECOMMENDED for full and complete CRLs. ## 7.3 OCSP profile