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 https://www.rfc-editor.org/info/rfc9286.¶

Copyright Notice

Copyright (c) 2022 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, 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

1. Introduction

The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of a distributed repository system [RFC6481] to make available a variety of objects needed by relying parties (RPs). Because all of the objects stored in the repository system are digitally signed by the entities that created them, attacks that modify these published objects are detectable by RPs. However, digital signatures alone provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not yet expired, but have since been superseded), or in-flight attacks that remove an object that should be present in the repository. To assist in the detection of such attacks, RPKI repository systems make use of a signed object called a "manifest".¶

A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an authority responsible for publishing at that publication point. Each manifest contains both the name of the file containing the object and a hash of the file content, for every signed object issued by an authority that is published at the authority's repository publication point. A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point. A manifest also is intended to allow an RP to detect similar outcomes that may result from an on-path attack during the retrieval of objects from the repository. Manifests are intended to be used in Certification Authority (CA) publication points in repositories (directories containing files that are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other signed objects that are verified by End-Entity (EE) certificates issued by this CA).¶

Manifests are modeled on CRLs, as the issues involved in detecting stale manifests and potential attacks using manifest replays, etc., are similar to those for CRLs. The syntax of the manifest payload differs from CRLs, since RPKI repositories contain objects not covered by CRLs, e.g., digitally signed objects, such as Route Origin Authorizations (ROAs) [RFC6482].¶

This document obsoletes [RFC6486].¶

2. Manifest Scope

A manifest associated with a CA's repository publication point contains a list of:¶

• the set of (non-expired, non-revoked) certificates issued and published by this CA,¶
• the most recent CRL issued by this CA, and¶
• all published signed objects that are verifiable using EE certificates [RFC6487] issued by this CA (other than the manifest itself).¶

Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) [RFC5652] wrapper of the object, the EE certificate used to verify it [RFC6488]. Thus, there is no requirement to separately publish that EE certificate at the CA's repository publication point.¶

Where multiple CA instances share a common publication point, as can occur when a CA performs a key-rollover operation [RFC6489], the repository publication point will contain multiple manifests. In this case, each manifest describes only the collection of published products of its associated CA instance.¶

3. Manifest Signing

A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of this EE certificate contains the accessMethod Object Identifier (OID) of id-ad-signedObject.¶

The CA MUST sign only one manifest with each generated private key and MUST generate a new key pair for each new version of the manifest. An associated EE certificate used in this fashion is termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]).¶

4. Manifest Definition

A manifest is an RPKI signed object, as specified in [RFC6488]. The RPKI signed object template requires specification of the following data elements in the context of the manifest structure.¶

   id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
                             rsadsi(113549) pkcs(1) pkcs9(9) 16 }

   id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

   id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }

    Manifest ::= SEQUENCE {
     version     [0] INTEGER DEFAULT 0,
     manifestNumber  INTEGER (0..MAX),
     thisUpdate      GeneralizedTime,
     nextUpdate      GeneralizedTime,
     fileHashAlg     OBJECT IDENTIFIER,
     fileList        SEQUENCE SIZE (0..MAX) OF FileAndHash
     }

   FileAndHash ::=     SEQUENCE {
     file            IA5String,
     hash            BIT STRING
  }

5. Manifest Generation

6. Relying Party Processing of Manifests

Each RP MUST use the current manifest of a CA to control addition of listed files to the set of signed objects the RP employs for validating basic RPKI objects: certificates, ROAs, and CRLs. Any files not listed on the manifest MUST NOT be used for validation of these objects. However, files not listed on a manifest MAY be employed to validate other signed objects, if the profile of the object type explicitly states that such behavior is allowed (or required). Note that relying on files not listed in a manifest may allow an attacker to effect substitution attacks against such objects.¶

As noted earlier, manifests are designed to allow an RP to detect manipulation of repository data, errors by a CA or repository manager, and/or active attacks on the communication channel between an RP and a repository. Unless all of the files enumerated in a manifest can be obtained by an RP during a fetch operation, the fetch is considered to have failed and the RP MUST retry the fetch later.¶

[RFC6480] suggests (but does not mandate) that the RPKI model employ fetches that are incremental, e.g., an RP transfers files from a publication point only if they are new/changed since the previous, successful fetch represented in the RP's local cache. This document avoids language that relies on details of the underlying file transfer mechanism employed by an RP and a publication point to effect this operation. Thus, the term "fetch" refers to an operation that attempts to acquire the full set of files at a publication point, consistent with the id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see below).¶

If a fetch fails, it is assumed that a subsequent fetch will resolve problems encountered during the fetch. Until such time as a successful fetch is executed, an RP SHOULD use cached data from a previous, successful fetch. This response is intended to prevent an RP from misinterpreting data associated with a publication point and thus possibly treating invalid routes as valid, or vice versa.¶

The processing described below is designed to cause all RPs with access to the same local cache and RPKI repository data to acquire the same set of validated repository files. It does not ensure that the RPs will achieve the same results with regard to validation of RPKI data, since that depends on how each RP resolves any conflicts that may arise in processing the retrieved files. Moreover, in operation, different RPs will access repositories at different times, and some RPs may experience local cache failures, so there is no guarantee that all RPs will achieve the same results with regard to acquisition or validation of RPKI data.¶

Note also that there is a "chicken and egg" relationship between the manifest and the CRL for a given CA instance. If the EE certificate for the current manifest is revoked, i.e., it appears in the current CRL, then the CA or publication point manager has made a serious error. In this case, the fetch has failed; proceed to Section 6.6. Similarly, if the CRL is not listed on a valid, current manifest, acquired during a fetch, the fetch has failed; proceed to Section 6.6, because the CRL is considered missing.¶

7. Publication Repositories

The RPKI publication system model requires that every publication point be associated with one or more CAs and be non-empty. Upon creation of the publication point associated with a CA, the CA MUST create and publish a manifest as well as a CRL. A CA's manifest will always contain at least one entry, i.e., a CRL issued by the CA [RFC6481], corresponding to the scope of this manifest.¶

Every published signed object in the RPKI [RFC6488] is published in the repository publication point of the CA that issued the EE certificate, and is listed in the manifest associated with that CA certificate.¶

8. Security Considerations

Manifests provide an additional level of protection for RPKI RPs. Manifests can assist an RP in determining if a repository object has been deleted, occluded, or otherwise removed from view, or if a publication of a newer version of an object has been suppressed (and an older version of the object has been substituted).¶

Manifests cannot repair the effects of such forms of corruption of repository retrieval operations. However, a manifest enables an RP to determine if a locally maintained copy of a repository is a complete and up-to-date copy, even when the repository retrieval operation is conducted over an insecure channel. In cases where the manifest and the retrieved repository contents differ, the manifest can assist in determining which repository objects form the difference set in terms of missing, extraneous, or superseded objects.¶

The signing structure of a manifest and the use of the nextUpdate value allow an RP to determine if the manifest itself is the subject of attempted alteration. The requirement for every repository publication point to contain at least one manifest allows an RP to determine if the manifest itself has been occluded from view. Such attacks against the manifest are detectable within the time frame of the regular schedule of manifest updates. Forms of replay attacks within finer-grained time frames are not necessarily detectable by the manifest structure.¶

9. IANA Considerations

The "RPKI Signed Objects" registry was originally created and populated by [RFC6488]. The "RPKI Repository Name Schemes" registry was created by [RFC6481] and created four of the initial three-letter file name extensions. IANA has updated the reference for the "Manifest" row in the "RPKI Signed Objects" registry to point to this document.¶

IANA has also updated the following entries to refer to this document instead of RFC 6486:¶

• id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry¶
• id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry¶
• the "Security considerations" entry in the application media type registration for rpki-manifest¶

No other actions are required.¶

Appendix A. ASN.1 Module

    RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
                   pkcs(1) pkcs9(9) smime(16) mod(0) 60 }

DEFINITIONS EXPLICIT TAGS ::=
   BEGIN

   -- EXPORTS ALL --

   IMPORTS

     CONTENT-TYPE
     FROM CryptographicMessageSyntax-2010 -- in RFC 6268
       { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
         pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

   -- Manifest Content Type

   ct-rpkiManifest CONTENT-TYPE ::=
       { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }

   id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
       us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }

   id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

   id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }

   Manifest ::= SEQUENCE {
      version        [0] INTEGER DEFAULT 0,
      manifestNumber     INTEGER (0..MAX),
      thisUpdate         GeneralizedTime,
      nextUpdate         GeneralizedTime,
      fileHashAlg        OBJECT IDENTIFIER,
      fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash
      }

   FileAndHash ::= SEQUENCE {
      file  IA5String,
      hash  BIT STRING
      }

   END

Appendix B. Changes since RFC 6486

In 2019, it came to light that multiple RP implementations were in a vulnerable position, possibly due to perceived ambiguity in the original [RFC6486] specification. This document attempts to clarify the innovative concept and application of RPKI manifests in light of real-world deployment experience in the global Internet routing system, to avoid future problematic cases.¶

The following list summarizes the changes between RFC 6486 and this document:¶

• Forbidding "sequential-use" EE certificates and instead mandating "one-time-use" EE certificates.¶
• Clarifying that manifest EE certificates are to be issued with a validity period that coincides with the interval specified in the manifest eContent, which coincides with the CRL's thisUpdate and nextUpdate.¶
• Clarifying that the manifestNumber is monotonically incremented in steps of 1.¶
• Recommending that CA issuers include the applicable CRL's nextUpdate with the manifest's nextUpdate.¶
• Constraining the set of valid characters in FileAndHash file names.¶
• Clarifying that an RP unable to obtain the full set of files listed on a manifest is considered to be in a failure state, in which case cached data from a previous attempt should be used (if available).¶
• Clarifying the requirement for a current CRL to be present, listed, and verified.¶
• Removing the notion of "local policy".¶

Acknowledgements

The authors would like to acknowledge the contributions from George Michaelson and Randy Bush in the preparation of the manifest specification. Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior. The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, Lars Eggert, Robert Wilton, and Benjamin Kaduk for their helpful review of this document.¶

Authors' Addresses