RFC 9829

Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions

📅 published July 2025, from ietf

RFC 9829: Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions 🎀

Okay bestie, the header is giving: J. Snijders, B. Maddison (Workonline), and T. Buehler (OpenBSD) wrote this one 🧚. It's a Standards Track doc, so it's a real Internet Standard and not just vibes ✨. It's dated July 2025, it's published under ISSN 2070-1721, and it updates RFC 6487. The header doesn't list anything it obsoletes 💅.

Abstract ✨

Okay so this doc is all about how the Resource Public Key Infrastructure (RPKI) deals with the Certificate Revocation List (CRL) Number extension 🦋. It revises that handling and updates RFC 6487. Bestie, this is a glow-up for the whole RPKI ecosystem 💖.

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 went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚.

For the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9829 🔗.

Copyright (c) 2025 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) as they're in effect on the date of publication. Please actually read these, bestie, because they explain your rights and restrictions for this document 📜. Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Revised BSD License ⚠️.

Table of Contents 🗺️

1.  Introduction
  1.1.  Requirements Language
  1.2.  Related Work
  1.3.  Changes from RFC 6487
2.  Summary
3.  Updates to RFC 6487
  3.1.  Updates to Section 5
  3.2.  Update to Section 7.2
4.  Operational Considerations
5.  Security Considerations
6.  IANA Considerations
7.  References
  7.1.  Normative References
  7.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🌈

Okay so Section 5.2.3 of [RFC5280] describes the CRL Number extension as a monotonically increasing sequence number, and it says it "allows users to easily determine when a particular CRL supersedes another CRL" 🔢. Basically, in Public Key Infrastructures (PKIs) where Relying Parties (RPs) might run into multiple usable CRLs, the CRL Number is how an RP figures out which CRL to trust 🕵️‍♀️.

Now here's the tea ☕. In the RPKI, a well-formed manifest fileList has exactly one entry for its associated CRL, plus a collision-resistant message digest of that CRL's contents (see Section 2.2 of [RFC6481] and Section 2 of [RFC9286]). On top of that, the target of the CRL Distribution Points extension in an RPKI Resource Certificate is the same CRL object listed on the issuing Certification Authority's (CA's) current manifest (see Section 4.8.6 of [RFC6487]). Put together, these properties mean RPKI RPs can always pin down exactly one current CRL for each RPKI CA 💯. So in the RPKI, the ordering that CRL Numbers give you is fully covered by monotonically increasing manifest numbers (Section 4.2.1 of [RFC9286]), which means RPKI RPs don't even need to process CRL Number extensions at all 🙌.

So yeah, even though the CRL Number extension is mandatory in RPKI CRLs for compliance with the X.509 v2 CRL Profile (Section 5 of [RFC5280]), any use of it by RPKI RPs just adds complexity and fragility to RPKI Resource Certificate path validation 😤. This document says RPKI RPs ignore the CRL Number extension 🚫.

This document updates [RFC6487]. Check out Section 3 for the deets 👀.

1.1. Requirements Language

Okay so the BCP 14 key words are "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" 🔑. In this document they get read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🔠.

To keep up, you should already know the terms and concepts from "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile for Resource Certificate Repository Structure" [RFC6481], and "Manifests for the Resource Public Key Infrastructure (RPKI)" [RFC9286] 📖.

1.3. Changes from RFC 6487

This section is the highlight reel of the big changes between [RFC6487] and this document 🎬.

  • Revision of CRL Number handling 🔄.
  • Adjustment of step 5 of the Resource Certification Path Validation 🛠️.
  • Integration of Errata 3205 [Err3205] 🩹.

2. Summary 💎

Bestie, this section is the main takeaway. This document makes it clear that in the RPKI there is exactly one CRL that's appropriate and relevant for working out the revocation status of a given resource certificate 🎯. It's the unique CRL object that is at the same time:

  • the target of the certificate's CRL Distribution Points extension, and
  • listed in the issuing CA's current manifest fileList and has a matching hash (see Section 4.2.1 of [RFC9286]).

And here's the kicker 😭: a resource certificate can't be validated without checking the current manifest of the certificate's issuer.

3. Updates to RFC 6487 🧩

Bestie, this is where the actual edits to [RFC6487] live, so pay attention 🤓.

3.1. Updates to Section 5

This section updates Section 5 of [RFC6487] like this 📝.

  • First change:
OLD

|  Where two or more CRLs are issued by the same CA, the CRL with
|  the highest value of the "CRL Number" field supersedes all
|  other CRLs issued by this CA.

NEW

|  Per Section 5.2.3 of [RFC5280], CAs issue new CRLs using a
|  monotonically increasing sequence number in the "CRL Number"
|  extension.  It is RECOMMENDED that the "CRL Number" match the
|  "manifestNumber" of the manifest that will include this CRL
|  (see Section 4.2.1 of [RFC9286]).
  • Second change:
OLD

|  An RPKI CA MUST include the two extensions, Authority Key
|  Identifier and CRL Number, in every CRL that it issues.  RPs
|  MUST be prepared to process CRLs with these extensions.  No
|  other CRL extensions are allowed.

NEW

|  An RPKI CA MUST include exactly two extensions in every CRL
|  that it issues: an Authority Key Identifier (AKI) and a CRL
|  Number.  No other CRL extensions are allowed.
|
|  -  RPs MUST process the AKI extension.
|
|  -  RPs MUST ignore the CRL Number extension except for checking
|     that it is marked as non-critical and contains a non-
|     negative integer less than or equal to 2^159-1.

3.2. Update to Section 7.2

This section updates Section 7.2 of [RFC6487] like this 🔧.

OLD

|  5.  The issuer has not revoked the certificate.  A revoked
|      certificate is identified by the certificate's serial number
|      being listed on the issuer's current CRL, as identified by the
|      CRLDP of the certificate, the CRL is itself valid, and the
|      public key used to verify the signature on the CRL is the same
|      public key used to verify the certificate itself.

NEW

|  5.  The issuer has not revoked the certificate.  A revoked
|      certificate is identified by the certificate's serial number
|      being listed on the issuer's current CRL, as identified by the
|      issuer's current manifest and the CRLDP of the certificate.
|      The CRL is itself valid and the public key used to verify the
|      signature on the CRL is the same public key used to verify the
|      certificate itself.

4. Operational Considerations 🛎️

This doc doesn't add any new operational considerations beyond the ones in Section 9 of [RFC6487] 🙂.

5. Security Considerations 🔐

Bestie, this part is serious, so read it carefully 😱. The Security Considerations of [RFC3779], [RFC5280], and [RFC6487] all apply to Resource Certificates and CRLs 🛡️.

This document spells out that in the RPKI, the CRL listed on the certificate issuer's current manifest is the one that matters for working out the revocation status of a resource certificate 🎯. The hash in the manifest's fileList gives a cryptographic guarantee of the Certification Authority's intent that this is the most recent CRL, and that shuts down possible replay vectors 🚨. Replay attacks are not it, bestie 💀.

6. IANA Considerations 📇

This document has no IANA actions 🫶.

7. References 📚

7.1. Normative References

7.2. Informative References

Acknowledgements 💜

The authors thank Tom Harrison, whose observations kicked off this doc 🌟. They also thank Alberto Leiva, Tim Bruijnzeels, Mohamed Boucadair, Geoff Huston, and the IESG for their super valuable comments and feedback 🙏.

Authors' Addresses 📮

Job Snijders Amsterdam The Netherlands Email: job@sobornost.net

Ben Maddison Workonline Cape Town South Africa Email: benm@workonline.africa

Theo Buehler OpenBSD Switzerland Email: tb@openbsd.org

📦 where this page comes from