All, Building on a previous discussion here in MDSP, Addressing Current Limitations of CRL Revocation Reason Codes <https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/SIqvgTmKnno/m/UPsTMDGAAwAJ>, I would like to have a discussion about which CRL revocation reason codes are applicable to TLS. My goals for this discussion are:
- Specify when certain revocation codes should or should not be used. - Determine when CAs should be required to put revocation codes into CRLs. - Begin drafting policy language about CRL revocation reason codes. For reference, please see the “Revocation Reasons” section of the 2009 paper, “Troubleshooting Certificate Status and Revocation <https://docs.microsoft.com/en-us/previous-versions/tn-archive/cc700843(v=technet.10)?redirectedfrom=MSDN>”, by Brian Komar and David B. Cross, Microsoft Corporation. For this discussion, I do not want to debate these meanings, but rather I would like to use those meanings as reference to help us determine which revocation reason codes should and should-not be used for TLS end-entity certificates. I propose that the following revocation reason codes are NOT applicable to TLS server (end-entity) certificates, meaning that they MUST NOT be used in CRLs for TLS server certificates. - Unspecified (0) - cACompromise (2) - cessationOfOperation (5) - certificateHold (6) - value 7 is not used - removeFromCRL (8) - aACompromise (10) I propose that only the following existing revocation reason codes ARE applicable to TLS server (end-entity) certificates, meaning that CRL entries for TLS server certificates must either have one of these reason codes or NO reason code. - keyCompromise (1) - affiliationChanged (3) - superseded (4) - privilegeWithdrawn (9) == Below is the beginning of potential policy text relating to these reason codes, and is only intended for TLS server (end-entity) certificate revocations. Note that much of this text is copied from section 4.9.1.1 of the BRs. *keyCompromise (1)* The CRLReason keyCompromise (1) MUST be used when the CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise, or 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) If someone other than the Subscriber requests revocation by providing verifiable evidence that the Subscriber's Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise, then the CA MUST make the information regarding its intent to revoke available to the Subscriber before revoking the certificate, and the CA MUST use the keyCompromise (1) CRLReason. The CRLReason keyCompromise (1) MAY be used when one or more of the following occurs: - The Subscriber requests that the CA revoke the Certificate for this reason code; - The Subscriber notifies the CA that the original certificate request was not authorized and does not retroactively grant authorization; - 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. *affiliationChanged (3)* The CRLReason affiliationChanged (3) MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason, otherwise this CRLReason MUST NOT be used. *superseded (4)* The CRLReason superseded (4) MUST be used when the certificate subscriber has requested that their certificate be revoked for this reason, otherwise this CRLReason MUST NOT be used. *privilegeWithdrawn (9)* The CRLReason privilegeWithdrawn (9) SHOULD be used if one or more of the following occurs, and the CA MUST make the information regarding its intent to revoke available to the Subscriber before revoking the certificate. Otherwise this CRLReason MUST NOT be used. - The CA obtains evidence that the Certificate was misused; - 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; - 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); - 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 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. == I will greatly appreciate your thoughtful and constructive feedback on these proposals. Thanks, Kathleen -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9085ddee-5bea-4dec-9c08-08d70e3cfae9n%40mozilla.org.
