RFC 9981

Resource Public Key Infrastructure (RPKI) Manifest Number Handling

📅 published May 2026, from ietf

RFC 9981: Resource Public Key Infrastructure (RPKI) Manifest Number Handling ✨🎀

Part 1 of 2 💖 okay bestie, this is the RPKI manifest number spec, and it's an update to RFC 9286 💅

  • Published by: the Internet Engineering Task Force (IETF) 🌈
  • Request for Comments: 9981
  • Authors: T. Harrison, G. Michaelson (APNIC), and J. Snijders (BSD) 🫶
  • Category: Standards Track 🔥
  • Date: May 2026 🍓
  • Updates: RFC 9286
  • ISSN: 2070-1721

Abstract 🦋

RPKI uses signed objects called "manifests", and each one has a "manifest number". This document updates RFC 9286 by saying what issuers and Relying Parties (RPs) should do when a manifest number hits the largest possible value. RFC 9286 never considered that situation 😭

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). More info on Internet Standards is in Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to give feedback is at https://www.rfc-editor.org/info/rfc9981. ✨

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, since 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
  1.1.  Requirements Language
2.  Manifest Number Handling
3.  Manifest Filenames
4.  Manifest SIA Verification
5.  Comparison with RFC 8488
6.  General Repository Handling
7.  Operational Considerations
8.  Security Considerations
9.  IANA Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🧚

okay so the RPKI [RFC6480] uses signed objects [RFC6488] called "manifests" [RFC9286]. A manifest lists each file that an issuer wants to include in an RPKI repository [RFC6481]. Manifests can also help detect certain attacks against a repository 🕵️‍♀️ Each manifest has a "manifest number" (manifestNumber), which an issuer must increment by one every time it issues a new manifest. RPs are required to check that a newly retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously validated manifest (Section 4.2.1 of [RFC9286]). ✨

BUT here's the plot twist 😭 the manifestNumber field is 20 octets long, so it's bounded, and nothing says what happens when the manifestNumber reaches the largest possible value (2^159-1). When that happens, some RP implementations will only accept a new manifest for the CA once the current one has expired, and others won't accept a new manifest at all. Yikes 💀

Realistically it's basically impossible for an issuer to get there under normal conditions. It would take issuing one manifest per second for 23,171,956,451,847,141,650,870 quintillion years 🌌 But it could still happen because of bugs in the issuance or publication systems, or incorrect or accidental use of those systems. For example:

  • Incrementing by large values when issuing manifests, so the time to reach that largest value gets way shorter.
  • Reissuing new manifests in an infinite delay-free loop, so the manifestNumber jumps by a large value in a short amount of time.
  • Accidentally setting the manifestNumber to the largest possible value, so the issuer can't publish usable manifests for that repository anymore.

These scenarios could also happen together and be even worse. For example, a CA might increase the manifestNumber by a large value on reissuance and also reissue the manifest more often than it needs to. Chaos energy 🌪️

For a subordinate CA, the repository-invalidation risk from this problem can be handled by the issuer using the key rollover process [RFC6489] to get a new CA certificate. RPs will treat this new certificate as though it represents a distinct CA, so the manifestNumber can be reset at that point. Phew 🫶

BUT this option isn't available for RPKI Trust Anchors (TAs) 😩 If a TA publishes a manifest with the largest-possible manifestNumber value, it's hard to rely on that TA after that point. Remember, some RPs won't accept a new manifest until the current one expires, while others will reject all new manifests forever. TA manifest validity periods can also be pretty long. Issuing a new TA and sending the related Trust Anchor Locator (TAL) [RFC8630] to clients would be a huge amount of work for TA operators and RPs. On top of that, depending on which RP implementation is being used, there would be only limited RPKI protection through that TA between the time the problematic manifest is issued and the time the new TAL gets installed. Not ideal, bestie 🙈

To avoid all of this, this document updates [RFC9286] by defining how issuers and RPs can handle this scenario so the affected repository keeps working. 🦋👑

1.1. Requirements Language 🎀

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. 💅

2. Manifest Number Handling 🔢

For a given CA, an RP MUST NOT reject a new manifest issued by that CA just because it doesn't have a higher manifestNumber than a previously validated manifest, if the new manifest has a different filename from the previously validated one. In other words, an RP has to reset its stored manifestNumber for a given CA if the CA changes the filename of its manifest. This updates the requirements in Section 4.2.1 of [RFC9286]. ✨

Now, if that's allowed, a CA could be set up so that every time it issues a new manifest, it uses a new filename. If a CA were set up like that, the manifestNumber validation in Section 4.2.1 of [RFC9286] would have no purpose at all 🙃 To avoid that, CAs SHOULD NOT use new filenames for manifests except when the change is needed to fix the invalidity problem described in this document. Also, an RP MUST alert its operators when a manifest filename changes for a given CA. 🚨

[RFC9286] requires RPs to run two replay-related checks on newly retrieved manifests:

  1. Check that the purported new manifest has a greater manifestNumber than the cached manifest, and
  2. Check that the purported new manifest has a more recent thisUpdate than the cached manifest.

An RP that follows the behaviour in this section will skip the manifestNumber check for a moment after a manifest filename change. As long as the RP still does the second check above, it's still protected against replay attacks 🛡️🩷

3. Manifest Filenames 📁

A CA specifies its manifest URI through a Subject Information Access (SIA) entry with an accessMethod of id-ad-rpkiManifest (Section 4.8.8.1 of [RFC6487]). For this document, the manifest filename is the final segment of the path of the accessLocation URI in that SIA entry. 🌷

Section 4.8.8.1 of [RFC6487] says a CA may put multiple id-ad-rpkiManifest SIA entries in its certificate. For comparisons, an RP may use the filename from any one of the id-ad- rpkiManifest SIA entries in the previously validated CA certificate. If that filename doesn't show up in any of the id-ad-rpkiManifest SIA entries in the CA certificate currently being validated, then the manifest filename has changed for the purposes of this document. 🧐

The flip side of what the previous paragraph describes: a CA that has multiple id-ad-rpkiManifest SIA entries in its certificate, and that wants to rely on the behaviour defined in this document, MUST ensure that none of the manifest filenames from the previous CA certificate appear in the newly issued CA certificate. If one of the manifest filenames from the previous CA certificate does show up in the newly issued CA certificate, then an RP that uses that filename for comparisons will decide the manifest filename for the CA hasn't changed, so it won't reset its stored manifestNumber for the CA. Oops, no reset for you 😬

4. Manifest SIA Verification 🔍

To avoid certain kinds of replay attack, RPs MUST verify that the URI in the accessLocation of one of the id-ad-signedObject accessMethod instances in the manifest's SIA extension exactly matches the URI presented in the RPKI Repository Delta Protocol (RRDP) [RFC8182] "publish" element, or the path presented by remote rsync servers. If this verification check fails, then the fetch has failed, and the RP MUST proceed per Section 6.6 of [RFC9286]. 🧩

5. Comparison with RFC 8488 ⚖️

Section 3.2.1 of [RFC8488] describes a manifest-selection approach for RPs. It collects all unexpired valid manifests for a CA, then picks the one with the highest manifestNumber from that collection. The approach in this document is different from that one. 💕

6. General Repository Handling 🗂️

Section 2 has a specific update to [RFC9286] for handling manifest numbers, so that one potential permanent invalidity scenario can be addressed. RPs that run into other permanent invalidity scenarios should also think about how to handle those so the scenario doesn't force the relevant CA or TA to do a key rollover. For example, if an RP notices that a permanent invalidity scenario has happened, it could alert the operator and give them an option to stop relying on cached data for the affected repository, so the CA can fix the problem. 🔧✨

7. Operational Considerations 🛠️

CA software can support the manifest number reset functionality in a few different ways. For example, it could change the manifest filename once the manifestNumber reaches a certain threshold, or it could alert the operator in this scenario and ask them to confirm that the filename should change. 🌈

To be continued… 🧚💜

8. Security Considerations 🔐✨

Okay bestie, the RPKI exists to support and improve the security of the global Internet routing system 💖, so any reliability upgrade to the RPKI itself is a security glow-up too. Stuff like what's outlined in this document strengthens its dependability (see Section 8 of [RFC6480]). Iconic. 👑

See Section 2, Paragraph 3 for what happens when you skip the manifestNumber check, since that's where replay attacks come in 🙈. To protect against replay attacks without that check, RPs should ensure they're verifying the thisUpdate value per the requirements of [RFC9286]. Not optional vibes, just good hygiene 💅.

Section 4 describes an additional protection against certain forms of replay attack 🛡️. Lowkey a bonus layer.

Also, although this document updates [RFC9286], the security considerations from [RFC9286] are still relevant. So don't forget them 😭🫶.

9. IANA Considerations 🦋

Good news, this one's short and sweet: this document has no IANA actions. 🌸

10. References 📚

10.1. 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>.

[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, <https://www.rfc-editor.org/info/rfc6487>.

[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, <https://www.rfc-editor.org/info/rfc6488>.

[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>.

[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, <https://www.rfc-editor.org/info/rfc8182>.

[RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, <https://www.rfc-editor.org/info/rfc9286>.

10.2. Informative References

[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.

[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, <https://www.rfc-editor.org/info/rfc6481>.

[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, DOI 10.17487/RFC6489, February 2012, <https://www.rfc-editor.org/info/rfc6489>.

[RFC8488] Muravskiy, O. and T. Bruijnzeels, "RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) Certificate Tree Validation", RFC 8488, DOI 10.17487/RFC8488, December 2018, <https://www.rfc-editor.org/info/rfc8488>.

[RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, August 2019, <https://www.rfc-editor.org/info/rfc8630>.

Acknowledgements 🫶

The authors would like to thank Theo Buehler, Ben Maddison, Rob Austein, Tim Bruijnzeels, Russ Housley, Mohamed Boucadair, Luigi Iannone, Daniele Ceccarelli, Darren Dukes, Maria Ines Robles, Barry Leiba, Éric Vyncke, Gorry Fairhurst, Andy Newton, Roman Danyliw, Mike Bishop, and Deb Cooley for their review and feedback on this document. Main character reviewers, honestly 👑💖.

Authors' Addresses 🧚

Tom Harrison
Asia Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: tomh@apnic.net
George G. Michaelson
Asia-Pacific Network Information Centre
6 Cordelia St
South Brisbane QLD 4101
Australia
Email: ggm@apnic.net
Job Snijders
BSD Software Development
Amsterdam
The Netherlands
Email: job@bsd.nl
URI:   https://www.bsd.nl
📦 where this page comes from