MozillaWiki

CA/Revocation Reasons

< CA
Revision as of 16:23, 15 April 2022 by Jcjones (talk | contribs) (→‎Possession of Private Key: Add <code> blocks around inline code snippets)

DRAFT
The content of this page is a work in progress intended for review.

Please help improve the draft!

Ask questions or make suggestions in the discussion
or add your suggestions directly to this page.

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.

Communication to Subscribers

Section 6.1.1 of Mozilla's Root Store Policy (starting with version 2.8) requires that the Subscriber Agreement or Terms of Use for TLS end-entity certificates inform certificate subscribers about the following revocation reasons. The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) an obligation and warranty to specify the following revocation reasons when they are applicable to the reason that the subscriber is requesting that their certificate be revoked.

  • 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 become aware of or 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.
  • 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

Tools that the CA provides to the certificate subscriber MUST allow for these options to be easily specified when the certificate subscriber requests revocation of their TLS end-entity certificate.

  • 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 that a CSR (certificate signing request) alone does not prove possession of the certificate’s private key for the purpose of initiating a revocation, so the following clarification is made in regards to the 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.

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.

OCSP

Mozilla does not expect there to be CRLReasons in OCSP responses for TLS end-entity certificates.

Section 7.3.2 of the BRs says: The singleExtensions of an OCSP response MUST NOT contain the reasonCode (OID 2.5.29.21) CRL entry extension.


The BRs say the following in relation to certificateHold:

  • Section 7.2.2: the CRLReason MUST NOT be certificateHold
  • Section 7.3 (OCSP Profile): the CRLReason indicated MUST contain a value permitted for CRLs, as specified in Section 7.2.2.

Banned Revocation Reasons

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
    • RFC 5280 says: -- value 7 is not used
  • 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.allizom.org/index.php?title=CA/Revocation_Reasons&oldid=1241932"