CRL key usage check: Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation
Requiring that CRL issuer certificates explicitly carry the cRLSign capability.
Bonnell, C., Ito, T., and T. Okubo, "Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation", RFC 10007, DOI 10.17487/RFC10007, June 2026, <https://www.rfc-editor.org/info/rfc10007>.
@misc{rfc10007,
series = {Request for Comments},
number = 10007,
howpublished = {RFC 10007},
publisher = {RFC Editor},
doi = {10.17487/RFC10007},
url = {https://www.rfc-editor.org/info/rfc10007},
author = {C. Bonnell and T. Ito and T. Okubo},
title = {{Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation}},
pagetotal = 6,
year = 2026,
month = jun,
} RFC text
Contents
Internet Engineering Task Force (IETF) C. Bonnell
Request for Comments: 10007 DigiCert, Inc.
Updates: 5280 伊藤 忠彦 (T. Ito)
Category: Standards Track セコム株式会社 (SECOM CO., LTD.)
ISSN: 2070-1721 大久保 智史 (T. Okubo)
Penguin Securities Pte. Ltd.
June 2026
Clarification to Processing Key Usage Values During Certificate
Revocation List (CRL) Validation
Abstract
RFC 5280 defines the profile of X.509 certificates and Certificate
Revocation Lists (CRLs) for use in the Internet. Section 4.2.1.3 of
RFC 5280 requires CRL issuer certificates to contain the keyUsage
extension with the cRLSign bit asserted. However, the CRL validation
algorithm specified in Section 6.3 of RFC 5280 does not explicitly
include a corresponding check for the presence of the keyUsage
certificate extension. This document updates RFC 5280 to require
that check.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc10007.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents
1. Introduction
2. Conventions and Definitions
3. The Risk of Trusting CRLs Signed with Non-Certified Keys
4. Checking the Presence of the keyUsage Extension
5. Security Considerations
6. IANA Considerations
7. Normative References
Acknowledgments
Authors' Addresses
1. Introduction
[RFC5280] defines the profile of X.509 certificates and certificate
revocation lists (CRLs) for use in the Internet. Section 4.2.1.3 of
[RFC5280] requires CRL issuer certificates to contain the keyUsage
extension with the cRLSign bit asserted. However, the CRL validation
algorithm specified in Section 6.3 of [RFC5280] does not explicitly
include a corresponding check for the presence of the keyUsage
certificate extension. This document updates [RFC5280] to require
that check.
Section 3 describes the security concern that motivates this update.
Section 4 updates the CRL validation algorithm (Section 6.3 of
[RFC5280]) to resolve this concern.
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. The Risk of Trusting CRLs Signed with Non-Certified Keys
In some Public Key Infrastructures, entities are delegated by
Certification Authorities (CAs) to sign CRLs. CRLs whose scope
encompasses certificates that have not been signed by the CRL issuer
are known as "indirect CRLs".
Applications that consume CRLs follow the validation algorithm as
specified in Section 6.3 of [RFC5280]. In particular, Section 6.3.3
of [RFC5280] contains the following step for CRL validation:
| (f) Obtain and validate the certification path for the issuer of
| the complete CRL. The trust anchor for the certification path
| MUST be the same as the trust anchor used to validate the target
| certificate. If a key usage extension is present in the CRL
| issuer's certificate, verify that the cRLSign bit is set.
This step does not explicitly specify a check for the presence of the
keyUsage extension itself.
Similarly, the certificate profile in Section 4 of [RFC5280] does not
require the inclusion of the keyUsage extension in a certificate if
the certified public key is not used for verifying the signatures of
other certificates or CRLs.
CAs can delegate the issuance of CRLs to other entities by issuing to
the entity a certificate that asserts the cRLSign bit in the keyUsage
extension. The CA will then sign certificates that fall within the
scope of the indirect CRL by including the crlDistributionPoints
extension (Section 4.2.1.13 of [RFC5280]) and specifying the
distinguished name (DN) of the CRL issuer in the cRLIssuer field of
the corresponding distribution point.
The CRL issuer signs CRLs that assert the indirectCRL boolean within
the issuingDistributionPoint extension.
The allowance for the issuance of certificates without the keyUsage
extension and the lack of a check for the inclusion of the keyUsage
extension during CRL verification can manifest in a security issue.
A concrete example is described below:
1. The CA signs an end-entity CRL issuer certificate to subject X
that certifies key A for signing CRLs by explicitly including the
keyUsage extension and asserting the cRLSign bit in accordance
with Section 4.2.1.3 of [RFC5280].
2. The CA signs one or more certificates that include the
crlDistributionPoints extension with the DN for subject X
included in the cRLIssuer field. This indicates that the CRL-
based revocation information for these certificates will be
provided by subject X.
3. The CA signs an end-entity certificate to subject X that
certifies key B. This certificate contains no key usage
extension, as the certified key is not intended to be used for
signing CRLs and could be a "mundane" certificate of any type
(e.g., S/MIME, a document signing certificate where the
corresponding private key is stored on the file system of the
secretary's laptop, etc.).
4. Subject X signs a CRL using key B and publishes the CRL at the
distributionPoint field specified in the crlDistributionPoints
extension of the certificates signed in step 2.
5. Relying parties download the CRL published in step 4. The CRL
validates successfully according to Section 6.3.3 of [RFC5280],
as the CRL issuer DN matches, and the check for the presence of
the cRLSign bit in the keyUsage extension is skipped because the
keyUsage extension is absent.
4. Checking the Presence of the keyUsage Extension
To remediate the security issue described in Section 3, this document
specifies the following amendment to step (f) of the CRL algorithm as
specified in Section 6.3.3 of [RFC5280].
_OLD:_
| (f) Obtain and validate the certification path for the issuer of
| the complete CRL. The trust anchor for the certification path
| MUST be the same as the trust anchor used to validate the target
| certificate. If a key usage extension is present in the CRL
| issuer's certificate, verify that the cRLSign bit is set.
_NEW:_
| (f) Obtain and validate the certification path for the issuer of
| the complete CRL. The trust anchor for the certification path
| MUST be the same as the trust anchor used to validate the target
| certificate. If the version of the CRL issuer's certificate is
| version 3 (v3), then verify that the key usage extension is
| present and verify that the cRLSign bit is set.
This change ensures that the CRL issuer's key is certified for CRL
signing. However, this check is not performed if the CRL issuer's
key is certified using a version 1 (v1) or version 2 (v2) X.509
certificate, as these versions do not have an extensions field where
the key usage extension can be included.
5. Security Considerations
If a CA has signed certificates to be used for CRL verification but
do not include the keyUsage extension in accordance with
Section 4.2.1.3 of [RFC5280], then relying party applications that
have implemented the modified verification algorithm as specified in
this document will be unable to verify CRLs signed by the CRL issuer
in question.
It is RECOMMENDED that CAs include the keyUsage extension in
certificates to be used for CRL verification to ensure that there are
no interoperability issues where updated applications are unable to
verify CRLs.
If it is not possible to update the profile of CRL issuer
certificates, then the policy management authority of the affected
Public Key Infrastructure SHOULD update the subject naming
requirements to ensure that certificates to be used for different
purposes contain unique DNs.
6. IANA Considerations
This document has no IANA actions.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
Acknowledgments
The authors would like to thank the participants on the LAMPS Working
Group mailing list for their insightful feedback and comments. In
particular, the authors extend sincere appreciation to Carl Wallace,
David Hook, Deb Cooley, John Gray, Michael StJohns, Mike Ounsworth,
Mohamed Boucadair, Russ Housley, Serge Mister, and Tomas Gustavsson
for their reviews and suggestions, which greatly improved the quality
of this document.
Authors' Addresses
Corey Bonnell
DigiCert, Inc.
Email: corey.bonnell@digicert.com
Tadahiko Ito
SECOM CO., LTD.
Email: tadahiko.ito.public@gmail.com
Additional contact information:
伊藤 忠彦
セコム株式会社
Tomofumi Okubo
Penguin Securities Pte. Ltd.
Email: tomofumi.okubo+ietf@gmail.com
Additional contact information:
大久保 智史
Penguin Securities Pte. Ltd.
AI ELI5
On this page
§1Introduction
RFC 5280 is the standard for X.509 certificates and Certificate Revocation Lists (CRLs) used on the Internet. Section 4.2.1.3 of RFC 5280 requires that CRL issuer certificates contain the keyUsage extension with the cRLSign bit asserted. This formally delegates the right to sign CRLs to that certificate holder.
However, the CRL validation algorithm in Section 6.3 of RFC 5280 does not explicitly include a check for the presence of the keyUsage extension. It only checks the cRLSign bit if the extension happens to be present. This document updates RFC 5280 to require that check, eliminating an unintended security gap.
X.509 certificates and revocation lists are how the Internet checks if digital IDs are legitimate. The rule says CRL signers must have permission, but the checking step was missing.
§2Background on CRL Issuance
In a Public Key Infrastructure (PKI), a Certificate Authority (CA) can delegate the responsibility for issuing and signing Certificate Revocation Lists to other entities. This delegation occurs through the issuance of a certificate that asserts the cRLSign bit in the keyUsage extension, which indicates that the certified key may be used to sign CRLs.
When a CA delegates CRL issuance this way, the CRL issuer publishes lists of revoked certificates. These CRLs are downloaded by applications (called relying parties) that need to check whether certificates are still valid. The relying party validates the CRL by checking that the CRL was signed by an entity that holds a proper CRL issuer certificate.
Some CRLs are indirect CRLs: they revoke certificates that were not signed by the CRL issuer's CA, but by the original CA. This design allows a single CRL issuer to manage revocations for multiple CAs.
A big company delegates someone to publish the list of broken ID cards, and they give that person a special ID saying they can do this job.
§3The Security Vulnerability
The gap arises from two separate flexibility rules in RFC 5280:
- A certificate issuer is not required to include the keyUsage extension if the certified public key is not used for signing other certificates or CRLs.
- The CRL validation algorithm says "if a key usage extension is present, verify that the cRLSign bit is set," but does not require the extension to be present in the first place.
These rules combined create an attack scenario: a Certificate Authority (CA) can issue two certificates to the same subject with two different keys:
- Certificate 1: Includes the keyUsage extension with cRLSign set, used for delegating CRL signing authority.
- Certificate 2: Contains no keyUsage extension, used for a different purpose (e.g., S/MIME signing or document signing on a secretary's laptop).
An attacker who compromises the key from Certificate 2 can then use it to sign CRLs. Because Certificate 2 lacks the keyUsage extension, the CRL validation algorithm skips the permission check and accepts the CRL as valid, even though the key was not authorized for CRL signing.
A company could accidentally give someone two ID cards: one with permission to revoke certifications, one without. An attacker could steal the second one and use it to revoke certifications anyway, because the check for permission was skipped.
§4The Algorithm Fix
This specification updates step (f) of the CRL validation algorithm in Section 6.3.3 of RFC 5280. The change applies only to version 3 (v3) X.509 certificates, which support extensions:
OLD algorithm step (f): "Obtain and validate the certification path for the issuer of the complete CRL. The trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate. If a key usage extension is present in the CRL issuer's certificate, verify that the cRLSign bit is set."
NEW algorithm step (f): "Obtain and validate the certification path for the issuer of the complete CRL. The trust anchor for the certification path MUST be the same as the trust anchor used to validate the target certificate. If the version of the CRL issuer's certificate is version 3 (v3), then verify that the key usage extension is present and verify that the cRLSign bit is set."
The new check explicitly requires the keyUsage extension to be present in v3 certificates and mandates that the cRLSign bit be asserted. Certificates in versions 1 (v1) or 2 (v2) are exempt from this requirement because those versions do not support the extensions field.
Now the check says: for modern ID cards (version 3), you must have permission written on the card. If the card doesn't say you can revoke certifications, it's not allowed.
§6Implementation and Compatibility
The updated algorithm only applies to version 3 (v3) X.509 certificates, which have an extensions field. Version 1 and 2 certificates, which predate extensions and cannot include the keyUsage extension, are exempt from this check. This maintains backward compatibility with older certificate chains that may still be in use.
When implementing the new check, applications validate the CRL by examining the CRL issuer's certificate. If the certificate is v3, the application must verify that the keyUsage extension is present and that the cRLSign bit is asserted. If either condition fails, the CRL is rejected.
The specification encourages CAs to include the keyUsage extension in all certificates used for CRL signing to ensure proper validation. This is the expected practice and aligns with RFC 5280's requirement (Section 4.2.1.3) that CRL issuer certificates contain this extension.
Modern ID cards (version 3) must have the permission written on them. Older cards without a permission section are still okay because they can't have extensions anyway.
§7Security Implications
The new requirement closes a security loophole but introduces a potential interoperability concern: if a CA has issued v3 CRL issuer certificates without the keyUsage extension (in violation of RFC 5280's requirement), applications implementing the updated validation algorithm will be unable to verify CRLs signed by those certificates.
To avoid such incompatibility, RFC 5280 recommends that CAs include the keyUsage extension in certificates intended for CRL verification. Additionally, if CAs have non-compliant certificates already in the wild, the policy authority managing the Public Key Infrastructure (PKI) should consider updating subject naming requirements: by ensuring that certificates used for different purposes (e.g., CRL signing versus document signing) have unique distinguished names, subject name uniqueness acts as a secondary protection against the attack.
Some old ID cards without permission might stop working, so companies should issue proper ones. If they can't update the cards, they can at least make sure different cards have different names so mixing them up is harder.