Banned CRL Revocation Reason Codes for TLS End-Entity Certificates

[Kathleen Wilson]

All,

I would like to answer a question here about why the "DRAFT Policy about CRLRevocation Reason Codes for TLS End-Entity Certificates" bans the other reason codes.

In the draft policy, these reason codes are allowed:

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

And the following reason codes are banned for TLS end-entity certificates. Meaning that if revocation is for one of the following, then the reasonCode extension MUST NOT be provided for that entry in the CRL.

• unspecified (0)
• cACompromise  (2)
• certificateHold (6)
• "-- value 7 is not used"
  
• removeFromCRL  (8)
• aACompromise  (10)

These banned reason codes are either already banned by the BRs or they are not applicable to end-entity TLS certificates. Below is a detailed explanation for each of them.

unspecified (0)
Section 7.2.2 of the BRs says: “The CRLReason indicated MUST NOT be unspecified (0). If the reason for revocation is unspecified, CAs MUST omit reasonCode entry extension”

cACompromise  (2)

This reason code is used when revoking an intermediate certificate.
When an intermediate certificate is revoked and added to OneCRL all certificates signed by that intermediate certificate are also treated as revoked.

https://www.ccadb.org/policy#4-intermediate-certificates 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."

Section 4.1 of Mozilla's Root Store Policy says: "If the revocation of an intermediate certificate chaining up to a root in Mozilla’s root program is due to a security concern, as well as performing the actions defined in the CCADB Policy, a security bug must be filed in Bugzilla."

certificateHold (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).”

removeFromCRL  (8)
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  (10)
Not applicable to TLS certificates. aACompromise is used for attribute certificates when aspects of the attribute authority (AA) have been compromised.

I hope this detailed explanation is helpful.

Thanks,

Kathleen

[Matthias van de Meent]

On Wed, Feb 23, 2022 at 11:10 PM Kathleen Wilson <kwi...@mozilla.com> wrote:

These banned reason codes are either already banned by the BRs or they are not applicable to end-entity TLS certificates. Below is a detailed explanation for each of them.

[...]
cACompromise  (2)

This reason code is used when revoking an intermediate certificate.
When an intermediate certificate is revoked and added to OneCRL all certificates signed by that intermediate certificate are also treated as revoked.

https://www.ccadb.org/policy#4-intermediate-certificates 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."

Section 4.1 of Mozilla's Root Store Policy says: "If the revocation of an intermediate certificate chaining up to a root in Mozilla’s root program is due to a security concern, as well as performing the actions defined in the CCADB Policy, a security bug must be filed in Bugzilla."

Is batch revoking leaf certificates because its CA (be it key or infrastructure) was compromised (e.g. DigiNotar) not supposed to use cACompromise as OCSP response? As in, in such cases there might have been no affiliation that could have changed, no new certificate subject information to supersede the revoked, no given privilige to withdraw, and no operation that is being ceased. Additionally, the key compromised is not that of the leaf certificate. Why not allow the use of cACompromise in such situations to allow accurate OSCP responses?

Note that this allows the relying party to evict the OCSP caches of the signing certificate; potentially improving on the revocation latency induced by the OneCRL distribution process (Firefox's default "security.onecrl.maximum_staleness_in_seconds" setting is 108000, or 30 hours), and improves securty by faster revocation marking of the parent ca when OneCRL is not included in the program.

- Matthias

[Rob Stradling]

Hi Matthias.  That's an interesting idea, but I don't think it's compatible with how the X.509 specification defines that reason code.  My understanding is that cACompromise can only be used in a revocation entry for a CA Certificate.  Here's the relevant section from the 2008 edition of X.509:

8.5.2.2 Reason code extension

This CRL entry extension field identifies a reason for the certificate revocation. The reason code may be used by

applications to decide, based on local policy, how to react to posted revocations.

[ASN.1 definition elided]

The following reason code values indicate why a certificate was revoked:

  - 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.

A certificate may be placed on hold by issuing a CRL entry with a reason code of certificateHold. The certificate hold

notice may include an optional hold instruction code to convey additional information to certificate users (see 8.5.2.3).

Once a hold has been issued, it may be handled in one of three ways:

  a) it may remain on the CRL with no further action, causing users to reject transactions issued during the

hold period; or,

  b) it may be replaced by a (final) revocation for the same certificate, in which case the reason shall be one

of the standard reasons for revocation, the revocation date shall be the date the certificate was placed on

hold, and the optional instruction code extension field shall not appear; or,

  c) it may be explicitly released and the entry removed from the CRL.

The removeFromCRL reason code is for use with delta-CRLs (see 8.6) only and indicates that an existing CRL entry

should now be removed owing to certificate expiration or hold release. An entry with this reason code shall be used in

delta-CRLs for which the corresponding base CRL or any subsequent (delta or complete for scope) CRL contains an

entry for the same certificate with reason code certificateHold.

This extension is always non-critical.

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Matthias van de Meent <matt...@thisisntrocket.science>
Sent: 24 February 2022 00:18
To: Kathleen Wilson <kwi...@mozilla.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Banned CRL Revocation Reason Codes for TLS End-Entity Certificates

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAT_OQs5_5eL69UCiBV4a5w5bYWqPaj%2Baty5DMbZ58SvVcHcxQ%40mail.gmail.com.