Address Issue cabforum#377 - CRL Reason Codes

This branch is meant to propose through the CABF balloting process that we incorporate Mozilla's CRL Revocation Reason Code requirements (https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#611-end-entity-tls-certificate-crlrevocation-reasons) into the Baseline Requirements. See Issue cabforum#377.
BenWilson-Mozilla · Jul 29, 2022 · 52a4808 · 52a4808
1 parent bbca714
commit 52a4808
Showing 1 changed file with 90 additions and 1 deletion.
diff --git a/docs/BR.md b/docs/BR.md
@@ -2311,7 +2311,96 @@ Prior to including a Reserved Certificate Policy Identifier, the CA MUST ensure
    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).
 
-   If a `reasonCode` CRL entry extension is present, the `CRLReason` MUST indicate the most appropriate reason for revocation of the certificate, as defined by the CA within its CP/CPS.
+Effective October 1, 2022, when a Subscriber Certificate is revoked for one of the reasons below, the specified CRLReason MUST be included in the reasonCode extension of the CRL entry corresponding to the Subscriber Certificate. Revocation entries that appeared on a CRL prior to October 1, 2022, do NOT need to be changed as a result of this section. When the CRLReason code is not one of the following, then the reasonCode extension MUST NOT be provided:
+
+    keyCompromise (RFC 5280 CRLReason #1);
+    privilegeWithdrawn (RFC 5280 CRLReason #9);**
+    cessationOfOperation (RFC 5280 CRLReason #5);
+    affiliationChanged (RFC 5280 CRLReason #3); or
+    superseded (RFC 5280 CRLReason #4).
+
+The Subscriber Agreement MUST inform the Subscriber 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 does not need to 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.
+
+If the Certificate is revoked for a reason not listed below, then the reasonCode extension MUST NOT be provided in the CRL.
+
+__keyCompromise__
+
+The CRLReason keyCompromise MUST be used when one or more of the following occurs:
+
+    the CA obtains verifiable evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
+    the CA is made aware of a demonstrated or proven method that exposes the Subscriber’s Private Key to Key Compromise;
+    there is clear evidence that the specific method used to generate the Private Key was flawed;
+    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 https://wiki.debian.org/TLSkeys); or
+    the Subscriber requests that the CA revoke the Certificate for this reason, with the scope of revocation being described below.
+
+The scope of revocation depends on whether the Subscriber has proven possession of the Private Key of the Certificate. A CSR alone does not prove possession of the Certificate’s Private Key for the purpose of initiating a revocation.
+
+    If anyone requesting revocation for keyCompromise has previously demonstrated or can currently demonstrate possession of the Private Key of the Certificate, then the CA MUST revoke all instances of that key across all Subscribers.
+    If the Subscriber requests that the CA revoke the Certificate for keyCompromise, and has not previously demonstrated and cannot currently demonstrate possession of the associated Private Key of that Certificate, the CA MAY revoke all Certificates associated with that Subscriber that contain that Public Key. The CA MUST NOT assume that it has evidence of Key Compromise for the purposes of revoking the Certificates of other subscribers, but MAY block issuance of future Certificates with that key.
+
+When the 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.
+
+Note: Backdating the revocationDate field is an exception to best practice described in RFC 5280 (section 5.3.2); however, this requirement specifies 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.
+
+Otherwise, the keyCompromise CRLReason MUST NOT be used.
+
+__privilegeWithdrawn__
+
+The CRLReason privilegeWithdrawn is intended to be used when there has been a Subscriber-side infraction that has not resulted in keyCompromise, such as the Subscriber provided misleading information in their certificate request or has not upheld their material obligations under the Subscriber Agreement or Terms of Use.
+
+Unless the keyCompromise CRLReason is being used, the CRLReason privilegeWithdrawn MUST be used when:
+
+    the CA obtains evidence that the certificate was misused;
+    the CA is made aware that the Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
+    the CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate fully‐qualified domain name;
+    the CA is made aware of a material change in the information contained in the Certificate;
+    the CA determines or is made aware that any of the information appearing in the Certificate is inaccurate; or
+    the CA is made aware that the original certificate request was not authorized and that the Subscriber does not retroactively grant authorization.
+
+Otherwise, the privilegeWithdrawn CRLReason MUST NOT be used.
+
+__cessationOfOperation__
+
+The CRLReason cessationOfOperation is intended to be used when 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. This revocation reason is intended to be used in the following circumstances:
+
+    the Subscriber no longer controls, or is no longer authorized to use, all of the Domain Names in the Certificate;
+    the Subscriber will no longer be using the Certificate because they are discontinuing their website; or
+    the CA is made aware of any circumstance indicating that use of a Fully‐Qualified Domain Name or IP Address in the Certificate is no longer legally permitted (e.g. a court or arbitrator has revoked a domain name registrant’s right to use the Domain Name, a relevant licensing or services agreement between the domain name registrant and the Subscriber has terminated, or the domain name registrant has failed to renew the Domain Name).
+
+Unless the keyCompromise CRLReason is being used, the CRLReason cessationOfOperation MUST be used when:
+
+    the Subscriber has requested that their Certificate be revoked for this reason; or
+    the CA has received verifiable evidence that the Subscriber no longer controls, or is no longer authorized to use, all of the Domain Names in the Certificate.
+
+Otherwise, the cessationOfOperation CRLReason MUST NOT be used.
+
+__affiliationChanged__
+
+The CRLReason affiliationChanged is intended to be used to indicate 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.
+
+Unless the keyCompromise CRLReason is being used, the CRLReason affiliationChanged MUST be used when:
+
+    the Subscriber has requested that their Certificate be revoked for this reason; or
+    the CA has replaced the Certificate due to changes in the Certificate’s subject information and the CA has not replaced the Certificate for the other reasons: keyCompromise, superseded, cessationOfOperation, or privilegeWithdrawn.
+
+Otherwise, the affiliationChanged CRLReason MUST NOT be used.
+
+__superseded__
+
+The CRLReason superseded is intended to be used to indicate when:
+
+    the Subscriber has requested a new Certificate to replace an existing Certificate; or
+    the CA obtains 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 Requirements or the CA’s CP or CPS.
+
+Unless the keyCompromise CRLReason is being used, the CRLReason superseded MUST be used when:
+
+    the Subscriber has requested that their Certificate be revoked for this reason; or
+    the CA has revoked the Certificate due to domain authorization or compliance issues other than those related to keyCompromise or privilegeWithdrawn.
+
+Otherwise, the superseded CRLReason MUST NOT be used.
 
 ## 7.3 OCSP profile