Issue cabforum#377 - edits to BR section 4.9.1.1

To address Issue cabforum#377 - this proposal makes minimal edits to BR section 4.9.1.1.
BenWilson-Mozilla · Sep 12, 2022 · 94a07d0 · 94a07d0
1 parent bbca714
commit 94a07d0
Showing 1 changed file with 27 additions and 16 deletions.
diff --git a/docs/BR.md b/docs/BR.md
@@ -1224,27 +1224,38 @@ No stipulation.
 
 #### 4.9.1.1 Reasons for Revoking a Subscriber Certificate
 
+Effective October 1, 2022, each new CRL entry MUST contain the RFC 5280 revocation reason code (CRLReason) indicated by this section. Otherwise, the CRLReason MUST be “unspecified (0)”.  If the CRLReason is “unspecified (0)”, then it MUST NOT be provided in the CRL entry.
+
 The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs:
 
-1. The Subscriber requests in writing that the CA revoke the Certificate;
-2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization;
-3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise;
-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 <https://wiki.debian.org/SSLkeys>);
-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.
+1. The Subscriber requests in writing that the CA revoke the Certificate
+* keyCompromise (RFC 5280 CRLReason #1) (i.e. the Subscriber's Private Key is suspected of compromise);
+* cessationOfOperation (RFC 5280 CRLReason #5) (i.e. the Subscriber will no longer be using the Certificate because they are discontinuing their website);
+* affiliationChanged (RFC 5280 CRLReason #3) (i.e. identifying information about the Subscriber in the Certificate has changed); or
+* superseded (RFC 5280 CRLReason #4) (i.e. the Subscriber requests a new certificate to replace an existing certificate).
+
+CAs MUST inform Subscribers about such revocation reasons and explain 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 (unspecified (0)) is provided. 
+
+If the Subscriber requests revocation for Key Compromise and cannot demonstrate possession of the associated Private Key of that Certificate, then 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;
+
+2. The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization (CRLReason #9, privilegeWithdrawn);
+3. The CA obtains evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (CRLReason #1, keyCompromise), and if anyone requesting revocation for Key Compromise 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;
+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 <https://wiki.debian.org/SSLkeys>) (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 if one or more of the following occurs:
 
-1. 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);
-2. The CA obtains evidence that the Certificate was misused;
-3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use;
-4. 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 Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name);
-5. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name;
-6. The CA is made aware of a material change in the information contained in the Certificate;
-7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement;
-8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate;
-9. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository;
-10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement; or
-11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed.
+1. 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);
+2. The CA obtains evidence that the Certificate was misused (CRLReason #9, privilegeWithdrawn);
+3. The CA is made aware that a Subscriber has violated one or more of its material obligations under the Subscriber Agreement or Terms of Use (CRLReason #9, privilegeWithdrawn);
+4. 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 Applicant has terminated, or the Domain Name Registrant has failed to renew the Domain Name) (CRLReason #5, cessationOfOperation);
+5. The CA is made aware that a Wildcard Certificate has been used to authenticate a fraudulently misleading subordinate Fully-Qualified Domain Name (CRLReason #9, privilegeWithdrawn);
+6. The CA is made aware of a material change in the information contained in the Certificate (CRLReason #9, privilegeWithdrawn);
+7. The CA is made aware that the Certificate was not issued in accordance with these Requirements or the CA's Certificate Policy or Certification Practice Statement (CRLReason MAY be determined by the CA);
+8. The CA determines or is made aware that any of the information appearing in the Certificate is inaccurate (CRLReason #9, privilegeWithdrawn);
+9. The CA's right to issue Certificates under these Requirements expires or is revoked or terminated, unless the CA has made arrangements to continue maintaining the CRL/OCSP Repository (CRLReason #5, cessationOfOperation);
+10. Revocation is required by the CA's Certificate Policy and/or Certification Practice Statement (CRLReason MAY be determined by the CA); or
+11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed (CRLReason #1, keyCompromise).
 
 #### 4.9.1.2 Reasons for Revoking a Subordinate CA Certificate