CA/Revocation Reasons

From MozillaWiki
< CA
Jump to: navigation, search

CRLReason Codes for End-Entity TLS Certificates

Mozilla's Root Store Policy (starting with version 2.8) has a section dedicated to CRLRevocation Reasons for end-entity TLS certificates; e.g. website server authentication certificates. The section was added because Mozilla believes that revocation checking is important, and there were several problems with not having such policy, including:

  • There were no policies specifying when certain revocation codes should or should not be used, and no incentive for CAs to use the correct reason codes
  • Some CAs were not using revocation reason codes at all for TLS end-entity certificates
  • Some CAs were using the same revocation code for every revocation
  • Some CAs would revoke certificates without informing their certificate subscribers about the revocation beforehand
  • There were no policies specifying the information that CAs should provide to their certificate subscribers about revocation reasons

TLS Certificates may be revoked ONLY for one of the following reasons:

  • unspecified (RFC 5280 CRLReason #0)
  • keyCompromise (RFC 5280 CRLReason #1)
  • affiliationChanged (RFC 5280 CRLReason #3)
  • superseded (RFC 5280 CRLReason #4)
  • cessationOfOperation (RFC 5280 CRLReason #5)
  • privilegeWithdrawn (RFC 5280 CRLReason #9)

The CRL reasonCode extension must be provided when any of the following reasons are used:

  • keyCompromise (RFC 5280 CRLReason #1)
  • affiliationChanged (RFC 5280 CRLReason #3)
  • superseded (RFC 5280 CRLReason #4)
  • cessationOfOperation (RFC 5280 CRLReason #5)
  • privilegeWithdrawn (RFC 5280 CRLReason #9)

If the reason for revocation is unspecified (RFC 5280 CRLReason #0), the CRL reasonCode extension must be omitted.

End Entity TLS Certificate CRLRevocation Reasons

This section applies to revocations that are performed after October 1, 2022. 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 an end entity TLS certificate (i.e. a certificate capable of being used for TLS-enabled servers) 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 end entity TLS certificate. 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 CA operator's subscriber agreement for TLS end entity certificates MUST inform certificate subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA operator provides to the certificate subscriber MUST allow for these options to be easily specified when the certificate 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 certificate subscriber as a revocation reason option, because the use of this reasonCode is determined by the CA operator 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 operator obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise;
  • the CA operator is made aware of a demonstrated or proven method that exposes the certificate subscriber’s private key to compromise;
  • there is clear evidence that the specific method used to generate the private key was flawed;
  • the CA operator is made aware of a demonstrated or proven method that can easily compute the certificate 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 certificate subscriber requests that the CA operator revoke the certificate for this reason, with the scope of revocation being described below.

The scope of revocation depends on whether the certificate 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 operator MUST revoke all instances of that key across all subscribers.
  • If the certificate subscriber requests that the CA operator 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 operator MAY revoke all certificates associated with that subscriber that contain that public key. The CA operator MUST NOT assume that it has evidence of private 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 operator obtains verifiable evidence of private 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 operator SHOULD update the CRL entry to enter keyCompromise as the CRLReason in the reasonCode extension. Additionally, the CA operator 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 policy 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 certificate 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 operator obtains evidence that the certificate was misused;
  • the CA operator is made aware that the certificate subscriber has violated one or more of its material obligations under the subscriber agreement or terms of use;
  • the CA operator is made aware that a wildcard certificate has been used to authenticate a fraudulently misleading subordinate fully‐qualified domain name;
  • the CA operator is made aware of a material change in the information contained in the certificate;
  • the CA operator determines or is made aware that any of the information appearing in the certificate is inaccurate; or
  • the CA operator 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 certificate subscriber no longer controls, or is no longer authorized to use, all of the domain names in the certificate;
  • the certificate subscriber will no longer be using the certificate because they are discontinuing their website; or
  • the CA operator 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).

Unless the keyCompromise CRLReason is being used, the CRLReason cessationOfOperation MUST be used when:

  • the certificate subscriber has requested that their certificate be revoked for this reason; or
  • the CA operator has received verifiable evidence that the certificate 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 certificate subscriber has requested that their certificate be revoked for this reason; or
  • the CA operator 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 the certificate is being replaced because:

  • the certificate subscriber has requested a new certificate;
  • the CA operator 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 operator has revoked the certificate for compliance reasons such as the certificate does not comply with the Mozilla Root Store Policy, the CA/Browser Forum's Baseline Requirements, or the CA operator’s CP or CPS.

Unless the keyCompromise CRLReason is being used, the CRLReason superseded MUST be used when:

  • the certificate subscriber has requested that their certificate be revoked for this reason; or
  • the CA operator 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.

Communication to Subscribers

Section 6.1.1 of Mozilla's Root Store Policy says: The CA operator's subscriber agreement for TLS end entity certificates MUST inform certificate subscribers about the revocation reason options listed above and provide explanation about when to choose each option. Tools that the CA operator provides to the certificate subscriber MUST allow for these options to be easily specified when the certificate 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).

Note: Mozilla has agreed that CAs may meet this requirement using incorporation by reference. For example: "Subscriber is hereby informed, and acknowledges understanding, of the reasons for revoking a Certificate, including those stated in section [x] of the CPS, which is incorporated herein by reference and made a part of this Agreement."

Revocation Reason Options:

  • No reason provided or unspecified (RFC 5280 CRLReason #0)
    • When the reason codes below do not apply to the revocation request, the subscriber must not provide a reason code other than "unspecified".
  • keyCompromise (RFC 5280 CRLReason #1)
    • The certificate subscriber must choose the "keyCompromise" revocation reason when they have reason to believe that the private key of their certificate has been compromised, e.g. an unauthorized person has had access to the private key of their certificate.
  • affiliationChanged (RFC 5280 CRLReason #3)
    • The certificate subscriber should choose the "affiliationChanged" revocation reason when their organization's name or other organizational information in the certificate has changed.
    • This option does not need to be made available by CAs who only issue DV certificates that do not include any Subject Identity information.
  • superseded (RFC 5280 CRLReason #4)
    • The certificate subscriber should choose the "superseded" revocation reason when they request a new certificate to replace their existing certificate.
  • cessationOfOperation (RFC 5280 CRLReason #5)
    • The certificate subscriber should choose the "cessationOfOperation" revocation reason when they no longer own all of the domain names in the certificate or when they will no longer be using the certificate because they are discontinuing their website.

Section 7.2.2 of the CA Browser Forum Baseline Requirements says: 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. Therefore, the CA must ensure that their CP/CPS documents are in sync with their Subscriber Agreements in regards to appropriate reasons for revocation of TLS end-entity certificates.

Tools for Requesting Revocation

Section 6.1.1 of Mozilla's Root Store Policy says: Tools that the CA operator provides to the certificate subscriber MUST allow for these options to be easily specified when the certificate 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).

  • No reason provided or unspecified (RFC 5280 CRLReason #0)
    • This must be the default value in tools provided by the CA.
    • Certificate subscribers are not required to provide a revocation reason, unless their private key has been compromised.
  • keyCompromise (RFC 5280 CRLReason #1)
  • affiliationChanged (RFC 5280 CRLReason #3)
  • superseded (RFC 5280 CRLReason #4)
  • cessationOfOperation (RFC 5280 CRLReason #5)


NOTE: The following revocation reason does not need to be documented in the CA's subscriber agreement for TLS-end-entity certificates and does not need to be made available to the certificate subscriber as a revocation reason option, because the use of this reason is determined by the CA and not the subscriber.

  • privilegeWithdrawn (RFC 5280 CRLReason #9)

Key Compromise

Section 6.1.1 of Mozilla's Root Store Policy says:
The CRLReason keyCompromise MUST be used when one or more of the following occurs: the CA operator obtains verifiable evidence that the certificate subscriber’s private key corresponding to the public key in the certificate suffered a key compromise ...
Additionally the CA operator must meet the requirements of section 4.9.1.1 of the BRs, which says:
The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: ... The CA obtains evidence that the Subscriber’s Private Key corresponding to the Public Key in the Certificate suffered a Key Compromise ...
When key compromise has been demonstrated the CA must revoke all instances of that key across all subscribers.

Section 6.1.1 of Mozilla's Root Store Policy also takes into account situations that may occur when the certificate subscriber requests that their certificate be revoked for the keyCompromise revocation reason. The policy says that a CSR (certificate signing request) alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation, and the following clarification is made in regards to the scope of revocation when the certificate subscriber requests revocation for keyCompromise revocation reason:
The scope of revocation depends on whether the certificate 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 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 certificate 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 private key compromise for the purposes of revoking the certificates of other subscribers, but MAY block issuance of future certificates with that key for that subscriber.

The reason for this language has been described and discussed in the Mozilla Dev Security Policy forum. I have copied the explanation of the situation below.

Currently, TLS issuance does not require a demonstration of key control to go from Applicant to Subscriber (e.g. CSR validation is not required). That is because for TLS, we are obtaining evidence that the domain holder authorized the key, not necessarily that the domain holder holds the key. There are plenty of debates to be had about this point, but this reflects how the system works today. Therefore, currently the following situation needs to be considered.

  1. Alice creates a CSR for good.example, using Key 1
  2. Alice applies at CA Foo with their CSR, becoming an Applicant
  3. After demonstrating control over good.example, Alice becomes a Subscriber
  4. Alice stores their CSRs on GitHub
    • The CSR for Alice is by no means a secret, as it is merely a statement of the request.
  5. Eve obtains a copy of Alice's CSR, and applies to CA Foo for evil.example
  6. The CA uses their API or Web Form and does not check the attributes from the CSR, so the CSR is not bound to any request
    • The CSR not a proof of possession instrument; it is just a way of conveying an authorized key.
  7. Eve completes the necessary challenges for evil.example, which ends up authorizing Key 1 to be used with Eve's domain
    • This means Alice could MITM Eve, but in this example Eve is the perpetrator.
  8. Eve, as Subscriber, requests that CA Foo revoke evil.example{Key 1} for Key Compromise
  9. CA Foo, on receiving the request, revokes the certificate for evil.example
  10. CA Foo then examines their systems, and sees that Key 1 is also used by Alice's good.example certificate - and revokes that as well
  11. Eve has now managed to deny service to Alice, by using the policy for abuse

In order to prevent this type of denial of service, the person requesting that a TLS certificate be revoked for keyCompromise must have previously demonstrated or must be able to currently demonstrate possession of the private key of the certificate before the CA revokes all instances of that key across all subscribers.

Scope of Revocation

The following situations may occur when a certificate subscriber requests revocation for keyCompromise.

  1. The certificate subscriber requesting the revocation demonstrates possession of the private key.
    • The CA must revoke all instances of that key across all subscribers
  2. The certificate subscriber requesting the revocation has not demonstrated possession of the private key, and the CA does not have evidence of private key compromise.
    • The CA may revoke all certificates associated with that subscriber that contain that public key
    • The CA may block issuance of future certificates with that key for that subscriber
    • Unless the CA receives verifiable evidence of private key compromise the CA must not revoke all instances of that key across all other subscribers
  3. The certificate subscriber previously requested revocation without demonstrating possession of the private key, and later sends another revocation request which does demonstrate possession of the private key.
    • After receiving the revocation request with demonstrated possession of the private key, the CA must revoke all instances of that key across all subscribers
  4. The certificate subscriber previously requested revocation without demonstrating possession of the private key, and later the CA receives evidence of private key compromise.
    • After receiving verifiable evidence of private key compromise, the CA must revoke all instances of that key across all subscribers

Possession of Private Key

Currently there is not a standard way to demonstrate possession of a certificate's private key, so here are a few ways that CAs may confirm possession of the private key:

  • Request revocation using ACME and the certificate's private key
    • Different ACME implementations have different means to accomplish this. For example:
    • certbot revoke --cert-path /PATH/TO/certificate.pem --key-path /PATH/TO/privateKey.pem --reason keyCompromise
  • Use one of these scripts/tools:
  • Compare a hash of the public key from the private key
    • First check the consistency of a private key
      • openssl rsa -in privatekey -check
    • Then compare the public key
      • openssl publicKey -in privateKey -pubout -outform pem | sha256sum
      • openssl x509 -in certificate.crt -pubkey |openssl publicKey -pubin -pubout -outform pem | sha256sum
  • Sign a message with the private key and then verify it with the public key.
    • openssl x509 -in certificate.crt -noout -pubkey > publicKey.pem
    • dd if=/dev/urandom of=random bs=32 count=1
    • openssl rsautl -sign -pkcs -inkey privateKey -in random -out signed
    • openssl rsautl -verify -pkcs -pubin -inkey publicKey.pem -in signed -out check
    • cmp random check
    • rm random check signed publicKey.pem
      • If cmp produces no output then the signature matches.

Updating CRL Entries

Section 6.1.1 says:

  • When the CA obtains verifiable evidence of private 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 policy 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.

Here are some clarifications about that paragraph:

  • The CRLReason may only be changed from a non key compromise reason to the keyCompromise reason.
  • The exception to the best practice described in RFC 5280 (section 5.3.2) only applies when the CRLReason is keyCompromise.
    • When setting the date for an initial revocation for CRLReason keyCompromise the revocationDate may be in the past.
    • Backdating for any other CRLReason is not endorsed by Mozilla.
  • The revocation date may only be changed when the current or updated CRLReason is keyCompromise.
    • The revocation date may be changed to a date that is before the current/existing revocationDate. It should never be changed to a date that is later than a previously set date.

Hierarchy of Reasons

The revocation reason codes listed in section 6.1.1 of Mozilla's Root Store Policy are listed in order of priority such that if the situation is that multiple revocation reasons apply, the revocation reason of higher priority (as per the list) should be indicated.

  1. keyCompromise (RFC 5280 CRLReason #1)
  2. privilegeWithdrawn (RFC 5280 CRLReason #9)
  3. cessationOfOperation (RFC 5280 CRLReason #5)
  4. affiliationChanged (RFC 5280 CRLReason #3)
  5. superseded (RFC 5280 CRLReason #4)

For example, if both privilegeWithdrawn and cessationOfOperation apply, then privilegeWithdrawn should be used.

Each sub-section within section 6.1.1 of Mozilla's Root Store policy ends with the sentence: "Otherwise, the <reason code> CRLReason MUST NOT be used." That sentence applies to the entire sub-section for each revocation reason code.

Treat the "intended" list within each sub-section as "SHOULD" (e.g. "The CRLReason <reason code> is intended to be used to indicate when:").

For example, if the certificate subscriber still owns the domain name and just turns off their web server without revoking their certificate for cessationOfOperation, the CA operator is not responsible for revoking the certificate unless the CA operator becomes aware of keyCompromise or the subscriber agreement not being followed, or until the CA operator receives verifiable evidence that the certificate subscriber no longer controls, or is no longer authorized to use, all of the domain names in the certificate.

OCSP

When processing an OCSP response, Firefox:

Mozilla:

  • Expects CAs to follow the BRs
  • Does not expect Mozilla Root Store Policy section 6.1.1, "End-Entity TLS Certificate CRLRevocation Reasons", to also apply to OCSP responses
  • Does not expect the OCSP response and CRL for a certificate to contain the same revocation reason code
  • Does not do anything special for an OCSP response indicating certificateHold

Banned Revocation Reasons

Section 6.1.1 of Mozilla's Root Store Policy says: If the certificate is revoked for a reason not listed ..., then the reasonCode extension MUST NOT be provided in the CRL. Therefore, the CRL reasonCode extension must not contain any of the following reasons for TLS end-entity certificates. If revocation is for one of the following, then the reasonCode extension must not be provided for that entry in the CRL.

  • unspecified (RFC 5280 CRLReason #0)
    • Section 5.3.1 of RFC 5280 says: the reason code CRL entry extension SHOULD be absent instead of using the unspecified (0) reasonCode value
    • Section 7.2.2 of the BRs says: If the reason for revocation is unspecified, CAs MUST omit reasonCode entry extension
  • cACompromise (RFC 5280 CRLReason #2)
    • cACompromise is used in revoking a CA-certificate (i.e. an intermediate certificate as opposed to 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.
    • When an intermediate certificate is revoked and added to OneCRL all certificates signed by that intermediate certificate are also treated as revoked.
      • Section 4 of the CCADB Policy says: If an intermediate certificate is revoked, the CCADB must be updated to mark it as revoked, giving the reason why, within 24 hours for a security incident, and within 7 days for any other reason.
  • certificateHold (RFC 5280 CRLReason #6)
    • Section 7.2.2 of the BRs says: If a CRL entry is for a Certificate subject to these Requirements, the CRLReason MUST NOT be certificateHold (6).
  • RFC 5280 CRLReason #7
  • removeFromCRL (RFC 5280 CRLReason #8)
    • Section 5.3.1 of RFC 5280 says: The removeFromCRL (8) reasonCode value may only appear in delta CRLs and indicates that a certificate is to be removed from a CRL because either the certificate expired or was removed from hold.
    • Since the BRs do not allow the certificateHold CRLReason to be used, the removeFromCRL reason is not applicable.
    • Additionally, section 4.10.1 of the BRs says: Revocation entries on a CRL or OCSP Response MUST NOT be removed until after the Expiry Date of the revoked Certificate.
  • aACompromise (RFC 5280 CRLReason #10)
    • Not applicable to TLS certificates, because aACompromise is used for attribute certificates when aspects of the attribute authority (AA) have been compromised.
Retrieved from "https://wiki.mozilla.org/index.php?title=CA/Revocation_Reasons&oldid=1247688"