Asia Pacific Network Information Centre

6 Cordelia St South Brisbane 4101 Australia QLD tomh@apnic.net

Asia-Pacific Network Information Centre

6 Cordelia St South Brisbane QLD 4101 Australia ggm@apnic.net

BSD Software Development

Amsterdam The Netherlands job@bsd.nl https://www.bsd.nl

OPS sidrops The Resource Public Key Infrastructure (RPKI) makes use of signed objects called "manifests", each of which includes a "manifest number". This document updates RFC 9286 by specifying issuer and Relying Party (RP) behaviour when a manifest number reaches the largest possible value, a situation not considered in RFC 9286.

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
  • .  Requirements Language
• .  Manifest Number Handling
• .  Manifest Filenames
• .  Manifest SIA Verification
• .  Comparison with RFC 8488
• .  General Repository Handling
• .  Operational Considerations
• .  Security Considerations
• .  IANA Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgements
• Authors' Addresses

Introduction The Resource Public Key Infrastructure (RPKI) makes use of signed objects called "manifests" . A manifest lists each file that an issuer intends to include within an RPKI repository . Manifests can also be used to detect certain forms of attack against a repository. Manifests include a "manifest number" (manifestNumber), which an issuer must increment by one whenever it issues a new manifest, and Relying Parties (RPs) are required to verify that a newly retrieved manifest for a given Certification Authority (CA) has a higher manifestNumber than the previously validated manifest (). However, the manifestNumber field is 20 octets in length (i.e., bounded), and no behaviour is specified for when a manifestNumber reaches the largest possible value (2¹⁵⁹-1). When that value is reached, some RP implementations will accept a new manifest for the CA only once the current manifest has expired, while others will not accept a new manifest at all. While it is practically impossible for an issuer to reach the largest possible value under normal operating conditions (it would require that the issuer issue one manifest per second for 23,171,956,451,847,141,650,870 quintillion years), there is still a chance that it could be reached due to bugs in the issuance or publication systems or incorrect/inadvertent use of those systems. For example:

• Incrementing by large values when issuing manifests, such that the time to reach that largest value is reduced.
• Reissuing new manifests in an infinite delay-free loop, such that the manifestNumber increases by a large value in a comparatively short period of time.
• Inadvertently setting the manifestNumber to the largest possible value, such that the issuer will no longer be able to publish usable manifests for that repository.

These scenarios might also arise in combination and be more severe as a result. For example, a CA might increase the manifestNumber by a large value on reissuance and also reissue the manifest more frequently than is necessary. For a subordinate CA, the risk of repository invalidation due to such a problem can be addressed by the issuer using the key rollover process to get a new CA certificate. RPs will treat this new certificate as though it represents a distinct CA; the manifestNumber can be reset at that point. However, this option is not available for RPKI Trust Anchors (TAs). If a TA publishes a manifest with the largest-possible manifestNumber value, then it is difficult to rely on the TA after that point, since (as described previously) some RPs will not accept a new manifest until the current one has expired, while others will reject all new manifests indefinitely. Particularly in the case of TAs, the manifest validity period may be quite long, too. Issuing a new TA and distributing the associated Trust Anchor Locator (TAL) to clients would involve a large amount of work for TA operators and RPs. Additionally, depending on the RP implementation being used, there would be a limited degree of RPKI protection by way of that TA for the time between the issuance of the problematic manifest and the installation of the new TAL. In order to avoid these problems, this document updates by defining how issuers and RPs can handle this scenario in order to facilitate ongoing use of an affected repository.

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 when, and only when, they appear in all capitals, as shown here.

Manifest Number Handling For a given CA, an RP MUST NOT reject a new manifest issued by that CA on the basis of it not having a higher manifestNumber than a previously validated manifest if the new manifest has a different filename from that of the previously validated manifest. 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 is an update to the requirements set out in . With this behaviour, it is possible for a CA to be configured such that, any time it issues a new manifest, it uses a new filename for that manifest. If a CA were configured in this way, the manifestNumber validation set out in would have no purpose. To avoid this outcome, CAs SHOULD NOT use new filenames for manifests except in situations where such a change is necessary to address the invalidity problem described in this document. Similarly, an RP MUST alert its operators when a manifest filename changes for a given CA. requires that RPs perform 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 implements the behaviour in this section will momentarily omit the manifestNumber check following a manifest filename change. So long as the RP still performs the second check described above, it will be protected against replay attacks.

Manifest Filenames A CA specifies its manifest URI by way of a Subject Information Access (SIA) entry with an accessMethod of id-ad-rpkiManifest (). For the purposes of this document, the manifest filename is the final segment of the path of the accessLocation URI from that SIA entry. states that a CA may include in its certificate multiple id-ad-rpkiManifest SIA entries. 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 does not appear in any of the id-ad-rpkiManifest SIA entries in the CA certificate that is currently being validated, then the manifest filename has changed for the purposes of this document. The corollary of the behaviour defined in the previous paragraph is that a CA that includes multiple id-ad-rpkiManifest SIA entries in its certificate and wants to rely on the behaviour defined in this document MUST ensure that none of the manifest filenames in the previous CA certificate appear in the newly issued CA certificate. If one of the manifest filenames from the previous CA certificate appears in the newly issued CA certificate, then an RP that is using that manifest filename for comparisons will determine that the manifest filename for the CA has not changed and will therefore not reset its stored manifestNumber for the CA.

Manifest SIA Verification To avoid certain forms of replay attack, RPs MUST verify that the URI in the accessLocation in 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) "publish" element or the path presented by remote rsync servers. If this verification check is unsuccessful, then the fetch has failed, and the RP MUST proceed per .

Comparison with RFC 8488 describes a manifest-selection approach for RPs that involves collecting all unexpired valid manifests for a CA and then selecting from that collection the manifest that has the highest manifestNumber. The approach set out in this document is different from that approach.

General Repository Handling contains a specific update to for the handling of manifest numbers, in order to address one potential permanent invalidity scenario. RPs that encounter other permanent invalidity scenarios should also consider how those can be addressed such that the scenario does not require the relevant CA or TA to perform a key rollover operation. For example, in the event that an RP recognises that a permanent invalidity scenario has occurred, the RP could alert the operator and provide an option to the operator to stop relying on cached data for the affected repository so that the CA can rectify the problem.

Operational Considerations CA software may opt to support the manifest number reset functionality in various ways. For example, it could change the manifest filename when the manifestNumber reaches a certain threshold, or it could alert the operator in this scenario and request confirmation that the filename should be changed.

Security Considerations The RPKI primarily exists to support and improve security of the global Internet routing system. Reliability improvements to the RPKI itself, such as outlined in this document, strengthen its dependability (see ). See regarding the effect of skipping the manifestNumber check with respect to replay attacks. To protect against replay attacks in the absence of this check, RPs should ensure that they are verifying the thisUpdate value per the requirements of . describes an additional protection against certain forms of replay attack. Although this document updates , the security considerations from remain relevant.

IANA Considerations This document has no IANA actions.

References Normative References 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. This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] 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. In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files. This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. Informative References This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines a profile for the structure of the Resource Public Key Infrastructure (RPKI) distributed repository. Each individual repository publication point is a directory that contains files that correspond to X.509/PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile defines the object (file) naming scheme, the contents of repository publication points (directories), and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and to facilitate certification path construction. [STANDARDS-TRACK] This document describes how a Certification Authority (CA) in the Resource Public Key Infrastructure (RPKI) performs a planned rollover of its key pair. This document also notes the implications of this key rollover procedure for relying parties (RPs). In general, RPs are expected to maintain a local cache of the objects that have been published in the RPKI repository, and thus the way in which a CA performs key rollover impacts RPs. This memo documents an Internet Best Current Practice. This document describes an approach to validating the content of the Resource Public Key Infrastructure (RPKI) certificate tree, as it is implemented in the RIPE NCC RPKI Validator. This approach is independent of a particular object retrieval mechanism, which allows it to be used with repositories available over the rsync protocol, the RPKI Repository Delta Protocol (RRDP), and repositories that use a mix of both. This document defines a Trust Anchor Locator (TAL) for the Resource Public Key Infrastructure (RPKI). The TAL allows Relying Parties in the RPKI to download the current Trust Anchor (TA) Certification Authority (CA) certificate from one or more locations and verify that the key of this self-signed certificate matches the key on the TAL. Thus, Relying Parties can be configured with TA keys but can allow these TAs to change the content of their CA certificate. In particular, it allows TAs to change the set of IP Address Delegations and/or Autonomous System Identifier Delegations included in the extension(s) (RFC 3779) of their certificate. This document obsoletes the previous definition of the TAL as provided in RFC 7730 by adding support for Uniform Resource Identifiers (URIs) (RFC 3986) that use HTTP over TLS (HTTPS) (RFC 7230) as the scheme.

Acknowledgements The authors would like to thank , , , , , , , , , , , , , , , , and for their review and feedback on this document.

Authors' Addresses Asia Pacific Network Information Centre

6 Cordelia St South Brisbane 4101 Australia QLD tomh@apnic.net

Asia-Pacific Network Information Centre

6 Cordelia St South Brisbane QLD 4101 Australia ggm@apnic.net

BSD Software Development

Amsterdam The Netherlands job@bsd.nl https://www.bsd.nl