| Internet-Draft | CRL Validation Clarification | January 2026 |
| Bonnell, et al. | Expires 10 July 2026 | [Page] |
RFC 5280 (Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile) defines the profile of X.509 certificates and 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.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://CBonnell.github.io/ietf-lamps-keyusage-crl-validation-clarification/draft-ietf-lamps-keyusage-crl-validation.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-lamps-keyusage-crl-validation/.¶
Source for this draft and an issue tracker can be found at https://github.com/CBonnell/lamps-keyusage-crl-validation-clarification.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 July 2026.¶
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.¶
[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.¶
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.¶
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 that RFC 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
keyUsageextension is present in the CRL issuer's certificate, verify that thecRLSignbit 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:¶
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].¶
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.¶
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, document signing certificate where the corresponding private
key is stored on the filesystem of the secretary's laptop, etc.).¶
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.¶
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.¶
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 keyUsage 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 keyUsage
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.¶
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.¶
This document has no IANA actions.¶
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 St. Johns, Mike Ounsworth, Mohamed Boucadair, Russ Housley, Serge Mister, and Tomas Gustavsson for their reviews and suggestions, which greatly improved the quality of this document.¶