RFC 10007

Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation

๐Ÿ“… published June 2026, from ietf

RFC 10007 ๐ŸŽ€ Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation

okay bestie, the vibe check first ๐Ÿ’… This is RFC 10007, a Standards Track document from the Internet Engineering Task Force (IETF), published in June 2026 (ISSN 2070-1721). Three authors wrote it: Corey Bonnell from DigiCert, Inc., Tadahiko Ito (ไผŠ่—ค ๅฟ ๅฝฆ) from SECOM CO., LTD. (ใ‚ปใ‚ณใƒ ๆ ชๅผไผš็คพ), and Tomofumi Okubo (ๅคงไน…ไฟ ๆ™บๅฒ) from Penguin Securities Pte. Ltd. It updates RFC 5280, the big X.509 certificate and CRL profile, so think of it as a patch on top of that one ๐Ÿงš

Abstract โœจ

okay so RFC 5280 is the rulebook for X.509 certificates and Certificate Revocation Lists (CRLs) on the Internet ๐Ÿ“œ Section 4.2.1.3 of RFC 5280 requires CRL issuer certificates to include the keyUsage extension with the cRLSign bit asserted. BUT the CRL validation algorithm in Section 6.3 of RFC 5280 never explicitly checks whether that keyUsage extension is actually there ๐Ÿ˜ญ This document updates RFC 5280 so that check finally happens ๐Ÿซถ

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 (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 ๐ŸŒธ

okay so [RFC5280] is the profile for X.509 certificates and certificate revocation lists (CRLs) on the Internet, and it's the main character here ๐Ÿ‘‘ Section 4.2.1.3 of [RFC5280] requires CRL issuer certificates to include the keyUsage extension with the cRLSign bit asserted. However, the CRL validation algorithm in Section 6.3 of [RFC5280] doesn't explicitly check for the keyUsage certificate extension. This document updates [RFC5280] to require that check.

Section 3 is where the security worry that motivates all this lives ๐Ÿ˜ฌ

Section 4 is the fix! It updates the CRL validation algorithm (Section 6.3 of [RFC5280]) to clear up the concern โœจ

2. Conventions and Definitions ๐Ÿ“–

Here's the deal with the key words. "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are read as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Lowercase versions are just regular words, so no drama ๐Ÿ™ˆ

3. The Risk of Trusting CRLs Signed with Non-Certified Keys ๐Ÿ˜ณ

In some Public Key Infrastructures, Certification Authorities (CAs) delegate entities to sign CRLs. CRLs whose scope covers certificates that have not been signed by the CRL issuer are called "indirect CRLs" ๐Ÿฆ‹

Applications that consume CRLs follow the validation algorithm in Section 6.3 of [RFC5280]. In particular, Section 6.3.3 of [RFC5280] has this 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. It's giving "we forgot the one thing" energy ๐Ÿ’€

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 CRL issuance to other entities by issuing them a certificate that asserts the cRLSign bit in the keyUsage extension. The CA then signs certificates in the scope of the indirect CRL by including the crlDistributionPoints extension (Section 4.2.1.13 of [RFC5280]) and naming the distinguished name (DN) of the CRL issuer in the cRLIssuer field of the matching distribution point ๐Ÿ“ฎ

The CRL issuer signs CRLs that assert the indirectCRL boolean within the issuingDistributionPoint extension.

Now the plot twist. Letting certificates skip the keyUsage extension, combined with not checking for it during CRL verification, can turn into a real security issue. Here's a concrete example ๐Ÿ•ต๏ธโ€โ™€๏ธ

  1. The CA signs an end-entity CRL issuer certificate to subject X that certifies key A for signing CRLs. It does this by explicitly including the keyUsage extension and asserting the cRLSign bit, following 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 in the cRLIssuer field. This says the CRL-based revocation information for these certificates will come from subject X.
  3. The CA signs an end-entity certificate to subject X that certifies key B. This certificate has no keyUsage extension, since the certified key isn't meant for signing CRLs. It 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 it 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 under Section 6.3.3 of [RFC5280], because the CRL issuer DN matches. The check for the cRLSign bit in the keyUsage extension gets skipped, because the keyUsage extension is absent. ๐Ÿ˜ฑ

4. Checking the Presence of the keyUsage Extension ๐Ÿ”

To fix the security issue described in Section 3, this document amends step (f) of the CRL algorithm in Section 6.3.3 of [RFC5280] as follows.

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 makes sure the CRL issuer's key is certified for CRL signing. Bestie, the one exception: this check is NOT performed when the CRL issuer's key is certified using a version 1 (v1) or version 2 (v2) X.509 certificate. Those versions don't have an extensions field where the keyUsage extension could go, so there's nothing to check ๐Ÿ™ƒ

5. Security Considerations ๐Ÿšจ

Okay, this section is very serious, so buckle up ๐Ÿ˜ญ If a CA has signed certificates to be used for CRL verification but does not include the keyUsage extension in accordance with Section 4.2.1.3 of [RFC5280], then relying party applications that implemented the modified verification algorithm in this document won't be able to verify CRLs signed by the CRL issuer in question. Yikes.

It is RECOMMENDED that CAs include the keyUsage extension in certificates to be used for CRL verification. That way there are no interoperability issues where updated applications can't verify CRLs ๐Ÿซถ

If it's 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. The goal is to make sure certificates used for different purposes contain unique DNs ๐Ÿ’œ

6. IANA Considerations ๐Ÿท๏ธ

No IANA actions here, bestie ๐Ÿ™Œ 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 want to thank everyone on the LAMPS Working Group mailing list for their insightful feedback and comments ๐ŸŒˆ Special thanks 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 made this document so much better โœจ

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.
๐Ÿ“ฆ where this page comes from