RFC 6486

Manifests for the Resource Public Key Infrastructure (RPKI)

📅 published February 2012, from ietf

RFC 6486: Manifests for the Resource Public Key Infrastructure (RPKI) 🎀

Okay bestie, so this is RFC 6486 🦋, all about manifests for the RPKI. It's from the IETF (Internet Engineering Task Force) as Request for Comments 6486, and it's a Standards Track document, so it's an actual Internet standard, not just vibes ✨. The ISSN is 2070-1721. The authors are R. Austein (ISC), G. Huston (APNIC), S. Kent (BBN), and M. Lepinski (BBN) 💜. It's dated February 2012. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅.

Abstract

okay so this doc defines a "manifest" for the Resource Public Key Infrastructure (RPKI) 🧚. A manifest is a signed object (a file) that lists every signed object (file) in the repository publication point (directory) belonging to an authority that publishes there. For each certificate, Certificate Revocation List (CRL), or other kind of signed object that this authority issued and published at that publication point, the manifest holds both the file name and a hash of the file's content 🔥. The whole point is to help a relying party (RP) catch certain attacks on a repository. If an RP checks the manifest against the signed objects it pulled from the publication point, it can spot "stale" (but still valid) data and deleted signed objects 👀.

Status of This Memo

this is an Internet Standards Track document 🎀.

It's a product of the IETF, which means it reflects the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 💜.

For the current status, any errata, and how to give feedback on this doc, go to http://www.rfc-editor.org/info/rfc6486 ✨.

Copyright (c) 2012 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 (http://trustee.ietf.org/license-info), as in effect on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as the Simplified BSD License describes 🫶.

Table of Contents

   1. Introduction ....................................................3
      1.1. Terminology ................................................3
   2. Manifest Scope ..................................................4
   3. Manifest Signing ................................................4
   4. Manifest Definition .............................................5
      4.1. eContentType ...............................................5
      4.2. eContent ...................................................5
           4.2.1. Manifest ............................................5
      4.3. Content-Type Attribute .....................................7
      4.4. Manifest Validation ........................................7
   5. Manifest Generation .............................................7
      5.1. Manifest Generation Procedure ..............................7
      5.2. Considerations for Manifest Generation .....................9
   6. Relying Party Use of Manifests ..................................9
      6.1. Tests for Determining Manifest State ......................10
      6.2. Missing Manifests .........................................11
      6.3. Invalid Manifests .........................................12
      6.4. Stale Manifests ...........................................12
      6.5. Mismatch between Manifest and Publication Point ...........13
      6.6. Hash Values Not Matching Manifests ........................14
   7. Publication Repositories .......................................15
   8. Security Considerations ........................................15
   9. IANA Considerations ............................................16
   10. Acknowledgements ..............................................16
   11. References ....................................................16
      11.1. Normative References .....................................16
      11.2. Informative References ...................................17
   Appendix A. ASN.1 Module ..........................................18

1. Introduction ✨

The Resource Public Key Infrastructure (RPKI) [RFC6480] uses a distributed repository system [RFC6481] to make a bunch of objects available to relying parties (RPs) 💅. Every object in that repository system is digitally signed by whoever created it, so RPs can detect attacks that tamper with published objects 🔍. Digital signatures don't protect against two sneakier attacks, though. One swaps in "stale" versions of signed objects (objects that were valid and haven't expired, but have since been superseded). The other removes an object that should still be in the repository 😭. To help catch those, the RPKI repository system can use a signed object called a "manifest" 🦋.

A manifest is a signed object that lists all the signed objects (files) in the repository publication point (directory) tied to an authority that publishes there. Each manifest has the file name and a hash of the file content for every signed object that authority issued and published at its repository publication point 📝. A manifest lets an RP detect unauthorized removal of objects, or stale versions swapped in at a publication point. It also helps an RP notice similar results from a man-in-the-middle attack while objects are being retrieved from the repository 👀. Manifests are meant for Certification Authority (CA) publication points in repositories. Those are directories holding subordinate certificates and Certificate Revocation Lists (CRLs) issued by that CA, plus other signed objects verified by end-entity (EE) certificates that this CA issued 🌸.

Manifests are modeled on CRLs, because detecting stale manifests and attacks using manifest replays are pretty much the same problem as with CRLs 🔁. The manifest payload syntax is different from CRLs, though, since RPKI repositories hold objects that CRLs don't cover. For example, digitally signed objects like Route Origination Authorizations (ROAs) 🧚.

1.1. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 💜.

2. Manifest Scope 🔥

A manifest tied to a CA's repository publication point lists:

  • 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 can be verified using EE certificates [RFC6487] issued by this CA.

Every RPKI signed object includes the EE certificate used to verify it, sitting inside the Cryptographic Message Syntax (CMS) [RFC3370] wrapper of the object [RFC6488]. So there's no requirement to publish that EE certificate separately at the CA's repository publication point 🎀.

When multiple CA instances share one publication point (this can happen when an entity does a key-rollover operation [RFC6489]), the repository publication point ends up with multiple manifests. In that case, each manifest only describes the collection of published products from its own associated CA instance 🫶.

3. Manifest Signing 💅

A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of that 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 way of using the associated EE certificate is called a "one-time-use" EE certificate 🦋.

Alternatively, the CA MAY elect to use the same private key to sign a sequence of manifests. Only one manifest (issued under a single CA instance) is current at any point in time, so the associated EE certificate only verifies one object at a time. As long as the sequence of objects verified by this EE certificate is published under the same file name, this sequential, multiple use of the EE certificate is also valid. This way of using an EE certificate is called a "sequential-use" EE certificate 🌈.

4. Manifest Definition 👑

A manifest is an RPKI signed object, as specified in [RFC6488]. The RPKI signed object template needs the following data elements for the manifest structure 📝.

4.1. eContentType

The eContentType for a manifest is id-ct-rpkiManifest, with the numerical value 1.2.840.113549.1.9.16.1.26 🔢.

   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 }

4.2. eContent

The manifest content is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690]. Here's how the content of a manifest is defined 🧾:

   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
    }

4.2.1. Manifest ✨

okay so the manifestNumber, thisUpdate, and nextUpdate fields are basically copied from the vibe of X.509 CRLs (see [RFC5280]) 💅 and that's giving consistency. Just like CRLs, a manifest is technically current until the time in nextUpdate hits, OR until a newer manifest with a bigger manifest number drops, whichever happens first 🦋

If a "one-time-use" EE certificate is used to verify a manifest, the EE certificate MUST have a validity period that lines up exactly with the window from thisUpdate to nextUpdate 🎀 this is so the CA's CRL doesn't get bloated with needless junk 🙈

If a "sequential-use" EE certificate is used to verify a manifest, its validity period only needs to be no shorter than the nextUpdate time of the current manifest 🌸 ngl this longer validity opens the door to a substitution attack using a stale manifest, which is covered in Section 6.4. scary, but we're on it 😭

The data elements of the manifest structure are defined like this:

  • version: the version number of this version of the manifest specification MUST be 0 ✨
  • manifestNumber: an integer that goes up by one every time a new manifest gets issued for a given publication point 🧚 this lets an RP spot gaps in the sequence of published manifests. literally a detective tool 🔥

The ManifestNumber is modeled on the CRL specification, so it's analogous to the CRLNumber, and the guidance in [RFC5280] for CRLNumber values is the right move for picking the range of numbers you can use for manifestNumber. Manifest numbers can be expected to be 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 💜

  • thisUpdate: the time the manifest was created 🍓 it follows the same format rules as the CRL field of the same name in [RFC5280].
  • nextUpdate: the time when the next scheduled manifest will be issued 🌈 the value of nextUpdate MUST be later than the value of thisUpdate. The GeneralizedTime format is the same as what thisUpdate requires.

If the authority changes ANY of the items it has published in the repository publication point, the authority MUST issue a new manifest before the nextUpdate time 💅 If a manifest covers a CRL, the manifest's nextUpdate MUST match the CRL's nextUpdate, because the manifest gets re-issued whenever a new CRL is published 🫶 And if a "one-time-use" EE certificate verifies the manifest, then when a new manifest goes out before the current manifest's nextUpdate, the CA MUST also issue a new CRL that includes the EE certificate tied to the old manifest. no loose ends bestie 👑

  • fileHashAlg: the OID of the hash algorithm used to hash the files the authority put into the repository 🔥 the hash algorithm MUST conform to the RPKI Algorithms and Key Size Profile specification [RFC6485]. no cap, this is a must-follow.
  • fileList: a sequence of FileAndHash objects 💖 there is one FileAndHash entry for each currently valid signed object published by the authority at this publication point. Each FileAndHash is an ordered pair: the name of the file in the repository publication point (directory) that contains the object, plus a hash of that file's contents 🦋

4.3. Content-Type Attribute

The mandatory content-type attribute MUST have its attrValues field set to the same OID as eContentType 🎀 that OID is id-ct-rpkiManifest, with the numerical value 1.2.840.113549.1.9.16.1.26. ✨

4.4. Manifest Validation

To figure out whether a manifest is valid, the RP MUST run the following checks, on top of the ones in [RFC6488] 🧐

  1. The eContentType in the EncapsulatedContentInfo is id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).
  2. The version of the rpkiManifest is 0.
  3. In the rpkiManifest, thisUpdate precedes nextUpdate.

If the procedure above says the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest was present 💀 it's gone, babe, moving on 🙈

5. Manifest Generation

5.1. Manifest Generation Procedure

For a CA publication point in the RPKI repository system, a CA MUST run the following steps to generate a manifest 🌸

  1. If no key pair exists, or if a "one-time-use" EE certificate is being used with a new key pair, generate a key pair 🔑
  2. If a "one-time-use" EE certificate is being used, or if a key pair was generated in step 1, or if a "sequential-use" EE certificate is being used 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 an explicit description of a resource set (see [RFC3779]) 💜

For a "one-time-use" EE certificate, the validity times of the EE certificate MUST exactly match the thisUpdate and nextUpdate times of the manifest 🎀

For a "sequential-use" EE certificate, the validity times of the EE certificate MUST encompass the time interval from thisUpdate to nextUpdate 🫶

  1. The EE certificate MUST NOT be published in the authority's repository publication point 🙅‍♀️ it stays behind the scenes, fr fr.
  2. Construct the manifest content 🧩

The manifest content is described in Section 4.2.1. 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 covers 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 and 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 before it gets signed 🤯 the chicken and egg moment, iykyk.

  1. Encapsulate the manifest content using the CMS SignedData content type (as specified Section 4), 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 the manifest describes 🔥
  2. In the case of a key pair that is to be used only once, together with a "one-time-use" EE certificate, the private key associated with this key pair MUST now be destroyed 💅 gone forever, no crumbs left behind.

5.2. Considerations for Manifest Generation

A new manifest MUST be issued and published on or before the nextUpdate time ⏰ no late arrivals allowed, periodt.

An authority MUST issue a new manifest together with finalizing changes made to objects in the publication point 🌈 An authority MAY perform a bunch of object operations on a publication repository within the scope of a repository change before issuing a single manifest that covers ALL the operations in that change 🧚 Repository operators SHOULD implement some form of repository update procedure that mitigates, to the extent possible, the risk that RPs doing retrieval operations on the repository get exposed to inconsistent, transient, intermediate states during updates to the repository publication point (directory) and the associated manifest 🫶 this one is so important, bestie.

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, stays unchanged across manifest generation cycles 🍓

When a CA entity is doing 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). two manifests, one folder, zero drama 💜

6. Relying Party Use of Manifests

The goal of an RP is to figure out which signed objects to use for validating assertions about INRs and their use (e.g., which ROAs to use in building route filters) ✨ Ultimately, this selection is a matter of local policy. BUT in the following sections, we walk through a sequence of tests that the RP SHOULD perform to determine the manifest state of the given publication point 🔍 We then talk about the risks of using signed objects in the publication point, given that manifest state, and we also provide suitable warning text that SHOULD be placed in a user-accessible log file 📝 It's the RP's responsibility to weigh these risks against the risk of routing failure that could happen if valid data gets rejected, and to implement a suitable local policy ⚖️ Note that if a certificate is deemed unfit for use due to local policy, then any signed object validated using that certificate also SHOULD be deemed unfit for use (regardless of the status of the manifest at its own publication point) 🥺 a chain reaction, so be careful, main character energy 👑

6.1. Tests for Determining Manifest State 🔍

Okay so, for a given publication point, the RP SHOULD perform the following tests to figure out its manifest state 💅

  1. For each CA using this publication point, select the CA's current manifest. The "current" manifest is the manifest issued by this CA with the highest manifestNumber among all valid manifests, and manifest validity is defined in Section 4.4 🫶

If the publication point does not contain a valid manifest, see Section 6.2. Lacking a valid manifest, the following tests cannot be performed 🙈

  1. To verify completeness, an RP MAY check that every file at each publication point appears in one and only one current manifest, and that every file listed in a current manifest is published at the same publication point as the manifest ✨

If there exist files at the publication point that do not appear on any manifest, or files listed in a manifest that do not appear at the publication point, then see Section 6.5, but still continue with the following test 🧐

  1. Check that the current time (translated to UTC) is between thisUpdate and nextUpdate ⏰

If the current time does not lie within this interval, then see Section 6.4, but still continue with the following tests 😬

  1. Verify that the listed hash value of every file listed in each manifest matches the value obtained by hashing the file at the publication point 🔥

If the computed hash value of a file listed on the manifest does not match the hash value contained in the manifest, then see Section 6.6 💀

  1. An RP MAY check that the contents of each current manifest conform to the manifest's scope constraints, as specified in Section 2 🌸
  2. If a current manifest contains entries for objects that are not within the scope of the manifest, then the out-of-scope entries SHOULD be disregarded in the context of this manifest. If there is no other current manifest that describes these objects within that other manifest's scope, then see Section 6.2 🍓

For each signed object, if all of the following conditions hold:

  • the manifest for its publication and the associated publication point pass all of the above checks;
  • the signed object is valid; and
  • the manifests for every certificate on the certification path used to validate the signed object and the associated publication points pass all of the above checks;

then the RP can conclude that no attack against the repository system has compromised the given signed object, and the signed object MUST be treated as valid (relative to manifest checking) 👑

6.2. Missing Manifests 🫥

So the absence of a current manifest at a publication point could happen because of an error by the publisher, or because all valid manifests got deleted or corrupted (on purpose or by accident) 😵

When there's no valid manifest available, there's no protection against attacks that delete signed objects or replay old versions of signed objects. All signed objects at the publication point, and all descendant objects that are validated using a certificate at this publication point, SHOULD be viewed as suspect, but MAY be used by the RP, as per local policy 🕵️‍♀️

The main risk in using signed objects at this publication point is that a superseded (but not stale) CRL would cause an RP to improperly accept a revoked certificate as valid, and thus rely on signed objects that are validated using that certificate. This risk is somewhat mitigated if the CRL for this publication point has a short time between thisUpdate and nextUpdate (and the current time is within this interval) ⏳. The risk in discarding signed objects at this publication point is that an RP may incorrectly discard a large number of valid objects. That gives significant power to an adversary that is able to delete a manifest at the publication point 😤

Regardless of whether signed objects from this publication are deemed fit for use by an RP, this situation SHOULD result in a warning to the effect that:

"No manifest is available for <pub point name>, and thus there may have been undetected deletions or replay substitutions from the publication point."

In the case where an RP has access to a local cache of previously issued manifests that are valid, the RP MAY use the most recently previously issued valid manifests for this RPKI repository publication collection for each entity that publishes at this publication point 🗂️

6.3. Invalid Manifests 🚫

An invalid manifest could show up at a publication point because of an error by the publisher, or because a valid manifest got corrupted (maliciously or accidentally) 🥲

The invalid manifest MUST never be used, even if its manifestNumber is greater than that of other (valid) manifests. Not me being like "but it's newer!" 🙅‍♀️

There are no risks associated with using signed objects at a publication point containing an invalid manifest, provided that valid manifests that collectively cover all the signed objects are also present ✅

If an invalid manifest is present at a publication point that also contains one or more valid manifests, this situation SHOULD result in a warning to the effect that:

"An invalid manifest was found at <pub point name>, this indicates an attack against the publication point or an error by the publisher. Processing for this publication point will continue using the most recent valid manifest(s)."

In the case where the RP has access to a local cache of previously issued (valid) manifests, an RP MAY make use of that locally cached data. Specifically, the RP MAY use the locally cached, most recent, previously issued, valid manifest issued by the entity that (appears to have) issued the invalid manifest 🧁

6.4. Stale Manifests 🥀

A manifest is considered stale if the current time is after the nextUpdate time for the manifest. This could be due to the publisher failing to promptly publish a new manifest, or due to (malicious or accidental) corruption or suppression of a more recent manifest 📉

All signed objects at the publication point issued by the entity that has published the stale manifest, and all descendant signed objects that are validated using a certificate issued by that same entity at this publication point, SHOULD be viewed as somewhat suspect, but MAY be used by the RP as per local policy 🧐

The main risk in using such signed objects is that a newer manifest exists that, if present, would show that certain objects have been removed or replaced. (For example, the new manifest might show the existence of a newer CRL and the removal of one or more revoked certificates.) So using objects from a stale manifest may cause an RP to incorrectly treat invalid objects as valid. The risk is that the CRL covered by the stale manifest has been superseded, and so an RP will improperly treat a revoked certificate as valid. This risk is somewhat mitigated if the time between the nextUpdate field of the manifest and the current time is short. The risk in discarding signed objects at this publication point is that the RP may incorrectly discard a large number of valid objects. That gives significant power to an adversary that is able to prevent the publication of a new manifest at a given publication point 🦹‍♀️

Regardless of whether signed objects from this publication are deemed fit for use by an RP, this situation SHOULD result in a warning to the effect that:

"A manifest found at <pub point name> is no longer current. It is possible that undetected deletions have occurred at this publication point."

Also, note that there is the potential for the current time to be before the thisUpdate time for the manifest. This case could be due to a publisher error or a local clock error. In such a case, this situation SHOULD result in a warning to the effect that:

"A manifest found at <pub point name> has an incorrect thisUpdate field. This could be due to publisher error, or a local clock error, and processing for this publication point will continue using this otherwise valid manifest."

6.5. Mismatch between Manifest and Publication Point 🧩

If there exist valid signed objects that do not appear in any manifest, then, provided the manifest is not stale (see Section 6.4), it's likely their omission is an error by the publisher. It's also possible this state is the result of a (malicious or accidental) replacement of a current manifest with an older, but still valid, manifest. However, regarding the right interpretation of such objects, it remains the case that if the objects were intended to be invalid, then they should have been revoked using whatever revocation mechanism is appropriate for the signed object in question. Therefore, there is little risk in using such signed objects. If the publication point contains a stale manifest, then there is a greater risk that the objects in question were revoked, along with a missing Certificate Revocation List (CRL), and the absence of that CRL is undetectable since the manifest is stale. In any case, the use of signed objects not present on a manifest, or descendant objects that are validated using such signed objects, is a matter of local policy 🫠

Regardless of whether objects not appearing on a manifest are deemed fit for use by the RP, this situation SHOULD result in a warning to the effect that:

"The following files are present in the repository at <pub point name>, but are not listed on any manifest <file list> for <pub point name>."

If there exist files listed on the manifest that do not appear in the repository, then these objects are likely to have been improperly (via malice or accident) deleted from the repository. A primary purpose of manifests is to detect such deletions 🔎 Therefore, in such a case, this situation SHOULD result in a warning to the effect that:

"The following files that should have been present in the repository at <pub point name> are missing <file list>. This indicates an attack against this publication point, or the repository, or an error by the publisher."

6.6. Hash Values Not Matching Manifests 🙈

okay bestie, so a file can show up on a manifest with a wrong hash for two reasons. Either the publisher messed up, or someone is actually attacking the publication point 👀 ngl that's a lot of vibes to hold at once.

If an object was on a previous valid manifest with a correct hash, and now it shows up with an invalid hash, it's probably been superseded by a new version that isn't available 🦋 If the RP uses it anyway, there's a risk it's treating a stale object as valid. That risk is extra spicy if the object is a CRL 💀 If the object can be validated using the RPKI, whether to use it is a matter of local policy.

If an object shows up on a manifest with an invalid hash and it has never been on a manifest before, then it's unclear whether the available version is newer or older than the one the manifest points to 🤷‍♀️ If the manifest is stale (see Section 6.4), it becomes more likely that the available version is the newer one, but that's never certain. Whether to use these objects is still a matter of local policy. Generally though, using a possibly outdated version is better than tossing the object completely ✨

For CRLs, it's a matter of local policy too, but an RP SHOULD endeavor to use the most recently issued valid CRL 👑 That's true even when the hash in the manifest matches an older CRL, or doesn't match any available CRL for a CA instance. If an RP has more than one valid CRL for a CA instance, the thisUpdate field of the CRL can be used to figure out which one is the most recent 🧚

No matter whether the RP decides objects with incorrect hashes are fit to use, this situation SHOULD result in a warning that says something like this:

"The following files at the repository <pub point name> appear on a manifest with incorrect hash values <file list>. It is possible that these objects have been superseded by a more recent version. It is very likely that this problem is due to an attack on the publication point, although it also could be due to a publisher error."

7. Publication Repositories 📦

okay so the RPKI publication model says every publication point has to be linked to one or more CAs, and it can't be empty 🌸 When a publication point gets created for a CA, the CA MUST create and publish a manifest AND a CRL. A CA's manifest will always have at least one entry, which is the CRL the CA issued when the repository was created [RFC6481] 🎀

Every published signed object in the RPKI [RFC6488] gets published in the repository publication point of the CA that issued its EE certificate. It's also listed on the manifest tied to that CA certificate. Very organized, very iconic 💅

8. Security Considerations 🔐

okay this section is giving drama and I'm here for it 😭 Manifests add an extra layer of protection for RPKI RPs. They can help an RP figure out whether a repository object has been deleted, hidden, or otherwise removed from view. They can also reveal when a newer version of an object was held back and an older version got swapped in 👀

Manifests can't fix the damage caused by that kind of corruption during repository retrieval. But a manifest lets an RP check whether its local copy of a repository is complete and up to date, even when the retrieval happens over an insecure channel 🫶 When the manifest and the retrieved repository contents don't match, the manifest can help sort out which objects are missing, extra, or superseded.

The signing structure of a manifest, along with the nextUpdate value, lets an RP tell whether the manifest itself has been tampered with 🙈 The rule that every repository publication point has to contain at least one manifest lets an RP tell whether the manifest has been hidden from view. These attacks on the manifest can be detected within the regular schedule of manifest updates. Replay attacks happening on finer time scales aren't necessarily detectable by the manifest structure 💀 so keep that in mind, bestie.

9. IANA Considerations 🧾

This document registers the following in the "RPKI Signed Object" registry created by [RFC6488]:

   Name: Manifest
   OID: 1.2.840.113549.1.9.16.1.26
   Reference: [RFC6486] (this document)

This document also registers the following three-letter filename extension for the "RPKI Repository Name Schemes" registry created by [RFC6481]:

   Filename extension: mft
   RPKI Object: Manifest
   Reference: [RFC6481]

10. Acknowledgements 💜

The authors want to give a shoutout to George Michelson and Randy Bush for their contributions to the manifest specification 🌈 They also want to thank Mark Reynolds and Christopher Small for helping clarify manifest validation and RP behavior. And a big thank you to Sean Turner for his helpful review of this document 🫶

11. References 📚

11.1. Normative References

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
  • [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, February 2012.
  • [RFC6485] Huston, G., "A Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)", RFC 6485, February 2012.
  • [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
  • [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, February 2012.
  • [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER).

11.2. Informative References

  • [RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
  • [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
  • [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
  • [RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.

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 NOTHING --

   -- Manifest Content Type: OID

   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 Content Type: eContent

   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

Authors' Addresses 🎀

   Rob Austein
   Internet Systems Consortium

   EMail: sra@hactrn.net
   Geoff Huston
   APNIC
   6 Cordelia St
   South Brisbane, QLD  4101
   Australia

   EMail: gih@apnic.net
   URI:   http://www.apnic.net
   Stephen Kent
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   USA

   EMail: kent@bbn.com
   Matt Lepinski
   BBN Technologies
   10 Moulton St.
   Cambridge, MA  02138
   USA

   EMail: mlepinski@bbn.com
📦 where this page comes from