Is there any authoritative definition of the various reasons possible in a CRL file? Section 6.3.2(b) of RFC5280 lists a few:
I've looked and looked and can't find any reputable explanation of what these statuses each technically mean and I don't want to just assume their meaning given how the reason is phrased.
[Disclaimer: I work as a software developer on the software that powers one of the trusted public CAs, and many corporate internal PKIs]
tl;dr: to my knowledge, there are no formal guidelines for which revocation reason should be used in which situation, it's up to the discretion of the administrator or operator of each CA.
Typically, cert revocations are done by humans who have to choose one of those revocation reasons from a drop-down menu in the GUI. That means deciding which bucket a certain edge-case falls into may vary from one organization / CA to another, or may be entirely up to the discretion of the IT guy who is revoking the certificate for your ID badge, email access, web server, wtv.
I found a really old article by Microsoft giving a bit of a text description of each reason -- search for "Revocation Reasons" on the page. (Microsoft built CA software as part of the Active Directory suite, so I assume this is accompanying documentation intended for Windows Domain Admins). See Appendix A at the bottom for the full list.
The CA/Browser Forum (CAB Forum) dictates policy for how publicly-trusted CAs and browsers need to behave with respect to certificates. Here is the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015. If you go to section 13.1.5 Reasons for Revoking a Subscriber Certificate (see Appendix B below), there is a list of situations in which the CA is required to revoke a certificate, but no mention of which reason code they're supposed to use.
tl;dr again: to my knowledge, there are no formal guidelines for which revocation reason should be used in which situation, it's up to the discretion of the administrator or operator of each CA.
Appendix A: some guidance from Microsoft on when to use each revocation reason:
- KeyCompromise. The token or disk location where the private key associated with the certificate has been compromised and is in the possession of an unauthorized individual. This can include the case where a laptop is stolen, or a smart card is lost.
CACompromise. The token or disk location where the CA's private key is stored has been compromised and is in the possession of an unauthorized individual. When a CA's private key is revoked, this results in all certificates issued by the CA that are signed using the private key associated with the revoked certificate being considered revoked.
AffiliationChanged. The user has terminated his or her relationship with the organization indicated in the Distinguished Name attribute of the certificate. This revocation code is typically used when an individual is terminated or has resigned from an organization. You do not have to revoke a certificate when a user changes departments, unless your security policy requires different certificate be issued by a departmental CA.
Superseded. A replacement certificate has been issued to a user, and the reason does not fall under the previous reasons. This revocation reason is typically used when a smart card fails, the password for a token is forgotten by a user, or the user has changed their legal name.
CessationOfOperation. If a CA is decommissioned, no longer to be used, the CA's certificate should be revoked with this reason code. Do not revoke the CA's certificate if the CA no longer issues new certificates, yet still publishes CRLs for the currently issued certificates.
CertificateHold. A temporary revocation that indicates that a CA will not vouch for a certificate at a specific point in time. Once a certificate is revoked with a CertificateHold reason code, the certificate can then be revoked with another Reason Code, or unrevoked and returned to use.
Note: While CertificateHold allows a certificate to be "unrevoked", it is not recommended to place a hold on a certificate, as it becomes difficult to determine if a certificate was valid for a specific time.
RemoveFromCRL. If a certificate is revoked with the CertificateHold reason code, it is possible to "unrevoke" a certificate. The unrevoking process still lists the certificate in the CRL, but with the reason code set to RemoveFromCRL.
Note: This is specific to the CertificateHold reason and is only used in DeltaCRLs.
Unspecified. It is possible to revoke a certificate without providing a specific reason code. While it is possible to revoke a certificate with the Unspecified reason code, this is not recommended, as it does not provide an audit trail as to why a certificate is revoked.
Appendix B: 13.1.5 Reasons for Revoking a Subscriber Certificate from CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015:
CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.2.5, April 2015:
The Subscriber requests in writing that the CA revoke the Certificate;
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 Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise (also see Section 10.2.4) or no longer complies with the requirements of Appendix A;
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 or Terms of Use Agreement;
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 is made aware that the Certificate was not issued in accordance with these Requirements or the CA’s Certificate Policy or Certification Practice Statement;
The CA determines that any of the information appearing in the Certificate is inaccurate or misleading;
The CA ceases operations for any reason and has not made arrangements for another CA to provide revocation support for the Certificate;
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;
The CA is made aware of a possible compromise of the Private Key of the Subordinate CA used for issuing the Certificate;
Revocation is required by the CA’s Certificate Policy and/or Certification Practice Statement; or
The technical content or format of the Certificate presents an unacceptable risk to Application Software Suppliers or Relying Parties (e.g. the CA/Browser Forum might determine that a deprecated cryptographic/signature algorithm or key size presents an unacceptable risk and that such Certificates should be revoked and replaced by CAs within a given period of time).
In ITU-T-X.509-201210 they are explained in section 8.5.3.1 (Reason code extension) as:
– unspecified can be used to revoke certificates for reasons other than the specific codes.
– keyCompromise is used in revoking an end-entity certificate; it indicates that it is known or suspected that the subject's private key, or other aspects of the subject validated in the certificate, have been compromised.
– cACompromise is used in revoking a CA-certificate; it indicates that it is known or suspected that the subject's private key, or other aspects of the subject validated in the certificate, have been compromised.
– affiliationChanged indicates that the subject's name or other information in the certificate has been modified but there is no cause to suspect that the private key has been compromised.
– superseded indicates that the certificate has been superseded but there is no cause to suspect that the private key has been compromised.
– cessationOfOperation indicates that the certificate is no longer needed for the purpose for which it was issued but there is no cause to suspect that the private key has been compromised.
– privilegeWithdrawn indicates that a certificate (public-key or attribute certificate) was revoked because a privilege contained within that certificate has been withdrawn.
– aACompromise indicates that it is known or suspected that aspects of the AA validated in the attribute certificate have been compromised.
And they also explain hold and remove; but hold just means "temporarily revoked" and "remove" is placed on delta-CRLs to say "uh, that hold was cancelled". Per X.509 the subsequent "full" CRL simply won't list the certificate any longer.
It's also noteworthy that technically this extension is entirely optional. Both RFCs 3280 and 5280 say that a conforming CA "SHOULD" provide the reason code. X.509 has very little to say about when to use it, just what it means if it was used.
