1. はじめに

1. はじめに

The Resource Public Key Infrastructure (RPKI) [RFC6480] uses signed objects [RFC6488] called manifests [RFC9286]. A manifest lists each file an issuer intends to include in an RPKI repository [RFC6481] and helps detect certain repository attacks. Each manifest includes a manifestNumber, which an issuer increments by one whenever it issues a new manifest. Relying Parties (RPs) verify that a newly retrieved manifest for a CA has a higher manifestNumber than the previously validated manifest.

The manifestNumber field is 20 octets long and bounded. RFC 9286 did not specify behaviour when it reaches the largest possible value, 2^159-1. Although this is practically impossible in normal operation, bugs or incorrect publication-system use could reach it. Subordinate CAs can address such cases by key rollover, but Trust Anchors (TAs) cannot do so easily because distributing a new Trust Anchor Locator (TAL) is operationally expensive.

This document updates [RFC9286] by defining how issuers and RPs handle this scenario so that an affected repository can continue to be used.

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals.