Zum Hauptinhalt springen

1. Einleitung

1. Einleitung​

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.