Manifests for the Resource Public Key Infrastructure (RPKI)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 June 2022.¶

Copyright Notice

Copyright (c) 2021 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 provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not expired, but have since been superseded) or attacks that remove an object that should be present in the repository. To assist in the detection of such attacks, the RPKI repository system can 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 a man-in-the-middle attack on 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 Origination Authorizations (ROAs).¶

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) [RFC3370] 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 access method 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. This form of use of the associated EE certificate is termed a "one-time-use" EE certificate [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 to determine 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 allows 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 attack within finer-grained time frames are not necessarily detectable by the manifest structure.¶

9. IANA Considerations

As [RFC6488] created and populated the registries "RPKI Signed Object" and three-letter filename extensions for "RPKI Repository Name Schemes," no new action is requested of the IANA.¶

10. Acknowledgements

The authors would like to acknowledge the contributions from George Michelson 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, and Sean Turner for their helpful review of this document.¶

Appendix A. ASN.1 Module

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

        DEFINITIONS EXPLICIT TAGS ::=
           BEGIN

           -- EXPORTS ALL --

           IMPORTS

             CONTENT-TYPE
             FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
               { 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 to RFC 6486

In 2019 it came to light that multiple Relying Party 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:¶

• Forbid "sequential-use" EE certificates, instead mandate "one-time-use" EE certificates.¶
• Emphasize a recommendation for EE certificates to have a validity period that coincides with the interval specified in the Manifest eContent.¶
• Clarify the manifestNumber is monotonically incremented in steps of 1.¶
• Recommend CA issuers to coincidence the applicable CRL's nextUpdate with the Manifest's nextUpdate.¶
• The set of valid characters in FileAndHash filenames was constrained.¶
• Clarifications that an RP unable to obtain the full set of files listed on a Manifest is considered a failure state, in which case cached data from a previous attempt should be used (if available).¶
• Clarifications on the requirement for a current CRL to be present, listed, and verified.¶
• Removed the notion of 'local policy'.¶

Authors' Addresses