Manifests for the Resource Public Key Infrastructure (RPKI)

The Resource Public Key Infrastructure (RPKI) makes use of a distributed repository system 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).

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.

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 issued by this CA. Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) wrapper of the object, the EE certificate used to verify it . 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 an entity performs a key-rollover operation , 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.

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 MAY choose to sign only one manifest with each generated private key, and 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. Alternatively, the CA MAY elect to use the same private key to sign a sequence of manifests. Because only a single manifest (issued under a single CA instance) is current at any point in time, the associated EE certificate is used to verify only a single object at a time. As long as the sequence of objects verified by this EE certificate are published using the same file name, then this sequential, multiple use of the EE certificate is also valid. This form of use of an EE certificate is termed a "sequential-use" EE certificate.

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

The eContentType for a manifest is defined as id-ct-rpkiManifest and has the numerical value of 1.2.840.113549.1.9.16.1.26.

The content of a manifest is ASN.1 encoded using the Distinguished Encoding Rules (DER) . The content of a manifest is defined as follows:

The manifestNumber, thisUpdate, and nextUpdate fields are modeled after the corresponding fields in X.509 CRLs (see ). Analogous to CRLs, a manifest is nominally current until the time specified in nextUpdate or until a manifest is issued with a greater manifest number, whichever comes first. If a "one-time-use" EE certificate is employed to verify a manifest, the EE certificate MUST have a validity period that coincides with the interval from thisUpdate to nextUpdate, to prevent needless growth of the CA's CRL. If a "sequential-use" EE certificate is employed to verify a manifest, the EE certificate's validity period needs to be no shorter than the nextUpdate time of the current manifest. The extended validity time raises the possibility of a substitution attack using a stale manifest, as described in . The data elements of the manifest structure are defined as follows: The version number of this version of the manifest specification MUST be 0. This field is an integer that is incremented each time a new manifest is issued for a given publication point. This field allows an RP to detect gaps in a sequence of published manifests. As the manifest is modeled on the CRL specification, the ManifestNumber is analogous to the CRLNumber, and the guidance in for CRLNumber values is appropriate as to the range of number values that can be used for the manifestNumber. Manifest numbers can be expected to contain long integers. Manifest verifiers MUST be able to handle number values up to 20 octets. Conforming manifest issuers MUST NOT use number values longer than 20 octets. This field contains the time when the manifest was created. This field has the same format constraints as specified in for the CRL field of the same name. This field contains the time at which the next scheduled manifest will be issued. The value of nextUpdate MUST be later than the value of thisUpdate. The specification of the GeneralizedTime value is the same as required for the thisUpdate field. If the authority alters any of the items that it has published in the repository publication point, then the authority MUST issue a new manifest before the nextUpdate time. If a manifest encompasses a CRL, the nextUpdate field of the manifest MUST match that of the CRL's nextUpdate field, as the manifest will be re-issued when a new CRL is published. If a "one-time-use" EE certificate is used to verify the manifest, then when a new manifest is issued before the time specified in nextUpdate of the current manifest, the CA MUST also issue a new CRL that includes the EE certificate corresponding to the old manifest. This field contains the OID of the hash algorithm used to hash the files that the authority has placed into the repository. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification . This field is a sequence of FileAndHash objects. There is one FileAndHash entry for each currently valid signed object that has been published by the authority (at this publication point). Each FileAndHash is an ordered pair consisting of the name of the file in the repository publication point (directory) that contains the object in question and a hash of the file's contents.

The mandatory content-type attribute MUST have its attrValues field set to the same OID as eContentType. This OID is id-ct-rpkiManifest and has the numerical value of 1.2.840.113549.1.9.16.1.26.

To determine whether a manifest is valid, the RP MUST perform the following checks in addition to those specified in : The eContentType in the EncapsulatedContentInfo is id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). The version of the rpkiManifest is 0. In the rpkiManifest, thisUpdate precedes nextUpdate. If the above procedure indicates that the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest were present.

For a CA publication point in the RPKI repository system, a CA MUST perform the following steps to generate a manifest: If no key pair exists, or if using a "one-time-use" EE certificate with a new key pair, generate a key pair. If using a "one-time-use" EE certificate, or if a key pair was generated in step 1, or if using a "sequential-use" EE certificate that will expire before the intended nextUpdate time of this manifest, issue an EE certificate for this key pair. This EE certificate MUST have an SIA extension access description field with an accessMethod OID value of id-ad-signedobject, where the associated accessLocation references the publication point of the manifest as an object URL. This EE certificate MUST describe its Internet Number Resources (INRs) using the "inherit" attribute, rather than explicit description of a resource set (see ). In the case of a "one-time-use" EE certificate, the validity times of the EE certificate MUST exactly match the thisUpdate and nextUpdate times of the manifest. In the case of a "sequential-use" EE certificate, the validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate. The EE certificate MUST NOT be published in the authority's repository publication point. Construct the manifest content. The manifest content is described in . The manifest's fileList includes the file name and hash pair for each object issued by this CA that has been published at this repository publication point (directory). The collection of objects to be included in the manifest includes all certificates issued by this CA that are published at the CA's repository publication point, the most recent CRL issued by the CA, and all objects verified by EE certificates that were issued by this CA that are published at this repository publication point. Note that the manifest does not include a self reference (i.e., its own file name and hash), since it would be impossible to compute the hash of the manifest itself prior to it being signed. Encapsulate the manifest content using the CMS SignedData content type (as specified ), sign the manifest using the private key corresponding to the subject key contained in the EE certificate, and publish the manifest in the repository system publication point that is described by the manifest. In the case of a key pair that is to be used only once, in conjunction with a "one-time-use" EE certificate, the private key associated with this key pair MUST now be destroyed.

A new manifest MUST be issued and published on or before the nextUpdate time. An authority MUST issue a new manifest in conjunction with the finalization of changes made to objects in the publication point. An authority MAY perform a number of object operations on a publication repository within the scope of a repository change before issuing a single manifest that covers all the operations within the scope of this change. Repository operators SHOULD implement some form of repository update procedure that mitigates, to the extent possible, the risk that RPs that are performing retrieval operations on the repository are exposed to inconsistent, transient, intermediate states during updates to the repository publication point (directory) and the associated manifest. Since the manifest object URL is included in the SIA of issued certificates, a new manifest MUST NOT invalidate the manifest object URL of previously issued certificates. This implies that the manifest's publication name in the repository, in the form of an object URL, is unchanged across manifest generation cycles. When a CA entity is performing a key rollover, the entity MAY choose to have two CA instances simultaneously publishing into the same repository publication point. In this case, there will be one manifest associated with each active CA instance that is publishing into the common repository publication point (directory).

Each RP must determine which signed objects it will use for validating assertions about INRs and their use (e.g., which ROAs to use in the construction of route filters). Manifests are designed to allow an RP to detect manipulation of repository data and/or errors by a CA or repository manager. Unless _all_ of the files enumerated in a manifest can be obtained by an RP (either from a publication point or from a local cache), an RP MUST ignore the data associated with the publication point. This stringent response is needed 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 achieve the same results with regard to validation of RPKI data. However, 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 validation of RPKI data Note 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 all signed objects associated with the CA instance MUST be ignored. Similarly, if the CRL is not listed on a valid, current manifest, all signed objects associated with the CA instance MUST be ignored, because the CRL is considered missing.

For a given publication point, an RP MUST perform a series of tests to determine which signed object files at the publication point are acceptable. The tests described below are to be performed using the manifest identified by the id-ad-rpkiManifest URI extracted from a CA certificate's SIA. All of the files referenced by the manifest MUST be be located at the publication point specified by the id-ad-caRepository URI from the (same) certificate's SIA. If the manifest and the files it references do not reside at the same publication point, an RP MUST *???* A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be at the location specified in the CRLDP in the manifest's EE certificate. If more than one .crl file appears in the manifest, only file names matching the CRL specified by the CRLDP will be processed. If more than one .crl entry appears in the manifest, and matches the CRLDP, the first one encountered MUST be used. Any other .crl files MUST be ignored and a warning MUST be issued. Note that, during CA key rollover [RFC6489], signed objects for two or more different CA instances will appear at the same publication point. Manifest processing is to be performed separately for each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA certificate. Note also that the processing described here will be performed using locally cached files if an RP does not detect newer versions of the files in the RPKI repository system.

Acquire the manifest identified by the SIA id-ad-rpkiManifest URI in the CA certificate. If an RP cannot retrieve a manifest using this URI, or if the manifest is not valid (Section 4.4), an RP SHOULD examine the most recent, cached manifest matching this URI. If that manifest is current () proceed to . If the publication point does not contain a valid manifest, and the cached manifest is not current, proceed to .

Check that the current time (translated to UTC) is between thisUpdate and nextUpdate. If the current time lies within this interval, proceed to . If the current time is earlier than thisUpdate, the CA has made an error. If the RP cache contains a current manifest, use that manifest instead and issue a warning. If an RP has no access to a current manifest, processing stops and a warning MUST be issued. If the current time is later than nextUpdate, then the manifest is stale. If the RP cache contains a current manifest, use that manifest instead and issue a warning.If no current manifest is available, proceed to .

Acquire all files enumerated in the manifest (fileList) from the publication point. This includes the CRL, each object containing an EE certificate issued by the C, and all subordinate CA and EE certificates. If there are files listed in the manifest that cannot be retrieved from the publication point, or if they fail the validity tests specified in , the RP SHOULD examine its cache to determine if these files are available locally. If all of the missing/invalid files are available from the RP's cache, i.e., each file name matches the list extracted from the manifest, the RP SHOULD use the cached files to replace those missing from the publication point, and proceed to . However, if _any_ of the missing/invalid files cannot be replaced in this fashion, then proceed to .

Verify that the hash value of every file listed in the manifest matches the value obtained by hashing the file acquired from the publication point or local cache. If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then an RP SHOULD examine its local cache to determine if the same file is available. The RP SHOULD use cached files to replace any (damaged) downloaded files, so long as the hash of the cached file matches the hash from the manifest. If any of the files with hash mismatches cannot be replaced in this fashion, proceed to 6.7. Otherwise proceed to .

If a current manifest contains entries for objects that are not within the scope of the manifest (), then the out-of-scope entries MUST be disregarded.

If an RP cannot acquire a current, valid manifest, or acquire current, valid instances of all of the objects enumerated in a current valid manifest, then processing of the signed objects associated with the CA has failed. The RP MUST issue a warning indicating the reason(s) for termination of processing with regard to this CA. Termination or processing means that all of the ROAs and subordinate certificates (CA and EE) MUST be considered invalid. This implies that the RP MUST not try to acquire and validate _subordinate_ signed objects, until the next interval when the RP is scheduled to process data for this part of the RPKI repository system.

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, namely, the CRL issued by the CA upon repository creation . Every published signed object in the RPKI 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.

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.

As 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.

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 Job Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of this document.