Clarification to Processing Key Usage Values During Certificate Revocation List (CRL) Validation DigiCert, Inc.
corey.bonnell@digicert.com
セコム株式会社
tadahiko.ito.public@gmail.com
Penguin Securities Pte. Ltd.
tomofumi.okubo+ietf@gmail.com
SEC lamps Public Key Infrastructure Certificate validation Security 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 .
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 () 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
  • .  Introduction
  • .  Conventions and Definitions
  • .  The Risk of Trusting CRLs Signed with Non-Certified Keys
  • .  Checking the Presence of the keyUsage Extension
  • .  Security Considerations
  • .  IANA Considerations
  • .  Normative References
  • Acknowledgments
  • Authors' Addresses
Introduction defines the profile of X.509 certificates and certificate revocation lists (CRLs) for use in the Internet. requires CRL issuer certificates to contain the keyUsage extension with the cRLSign bit asserted. However, the CRL validation algorithm specified in does not explicitly include a corresponding check for the presence of the keyUsage certificate extension. This document updates to require that check. describes the security concern that motivates this update. updates the CRL validation algorithm () to resolve this concern.
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 when, and only when, they appear in all capitals, as shown here.
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 . In particular, 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 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 () 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 .
  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 , 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.
Checking the Presence of the keyUsage Extension To remediate the security issue described in , this document specifies the following amendment to step (f) of the CRL algorithm as specified in . 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.
Security Considerations If a CA has signed certificates to be used for CRL verification but do not include the keyUsage extension in accordance with , 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.
IANA Considerations This document has no IANA actions.
Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK] Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
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 , , , , , , , , , and for their reviews and suggestions, which greatly improved the quality of this document.
Authors' Addresses DigiCert, Inc.
corey.bonnell@digicert.com
セコム株式会社
tadahiko.ito.public@gmail.com
Penguin Securities Pte. Ltd.
tomofumi.okubo+ietf@gmail.com