RFC 9286

Manifests for the Resource Public Key Infrastructure (RPKI)

📅 published June 2022, from ietf

Manifests for the Resource Public Key Infrastructure (RPKI) 🎀

Okay so bestie, RFC 9286 is the spec for manifests in the RPKI, and it is giving organized 💅. It's from the IETF, it's a Standards Track document, and it was published in June 2022. It's also the one that obsoletes RFC 6486 🫶. Authors are R. Austein (Arrcus, Inc.), G. Huston (APNIC), S. Kent (Independent), and M. Lepinski (New College Florida). The ISSN is 2070-1721 ✨.

Here's the tea: a manifest is a signed file that lists every other signed file sitting in a repository publication point (think: a directory) for a given authority. For each certificate, CRL, or other signed object that the authority publishes there, the manifest holds the file's name and a hash of its contents. So if a relying party (RP) checks the manifest against what it actually pulled down, it can spot replay attacks and sneaky in-flight changes or deletions 🦋.

The status, copyright, and feedback details are all in the RFC Editor's standard boilerplate, so check there for the official version 🌸.

Table of Contents 📚

The full outline is in the original, and it's the map for the rest of this rewrite. The parts we're doing in this batch are the Introduction and everything through Section 4, so the rest drops in soon 💖.

1. Introduction 🌈

Okay so the RPKI [RFC6480] uses a distributed repository system [RFC6481] to hold all the objects that relying parties (RPs) need. Here's the thing: every object in there is digitally signed by whoever made it, so if someone modifies a published object, RPs can catch it 🙈. BUT, signatures alone don't stop someone from swapping in a stale version (one that was valid and hasn't expired yet, but has since been replaced). They also don't stop in-flight attacks that just remove an object that should be sitting in the repository 💀. So RPKI repositories use a signed object called a "manifest" to help catch all of that 🔥.

A manifest is a signed object that lists every signed object (file) in the repository publication point (directory) tied to an authority that publishes there. Each manifest has the name of each file and a hash of its content, for every signed object that authority published at its publication point ✨. The goal is that an RP can spot unauthorized removal, stale swaps, and similar stuff caused by an on-path attack while objects are being fetched 🕵️‍♀️. Manifests are meant for Certification Authority (CA) publication points, which are directories holding subordinate certificates and Certificate Revocation Lists (CRLs) issued by that CA, plus other signed objects checked by End-Entity (EE) certificates that the CA issued 🧚.

Manifests are modeled on CRLs, because detecting stale manifests and manifest replay attacks is basically the same problem as with CRLs 👑. The manifest payload is different from a CRL, though, since RPKI repositories hold objects that CRLs don't cover, like Route Origin Authorizations (ROAs) [RFC6482] 🍓.

This document obsoletes [RFC6486] 💜.

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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they're written in ALL CAPS like that 💅.

2. Manifest Scope 🌸

A manifest tied to a CA's repository publication point includes a list of:

  • the set of certificates that this CA issued and published and that are still valid (not expired, not revoked) 🦋
  • the most recent CRL this CA issued 💖
  • every published signed object that can be verified with EE certificates [RFC6487] this CA issued, other than the manifest itself ✨

Every RPKI signed object includes the EE certificate used to verify it, inside the Cryptographic Message Syntax (CMS) [RFC5652] wrapper [RFC6488]. So, no need to publish that EE certificate separately at the CA's publication point 🫶.

If several CA instances share one publication point (this can happen when a CA does a key-rollover [RFC6489]), that publication point will contain multiple manifests. Each manifest only describes the published products of its own CA instance 👑.

3. Manifest Signing 🔥

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

The CA MUST sign only one manifest with each generated private key, and it MUST generate a new key pair for each new version of the manifest 🔐. An EE certificate used this way is called 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 needs the following data elements filled in for the manifest structure 🍓.

4.1. eContentType 🌈

The eContentType for a manifest is id-ct-rpkiManifest, with the numerical OID 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 content of a manifest is ASN.1 encoded using the Distinguished Encoding Rules (DER) [X.690]. The structure goes like this 💅:

    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
  }

Part 2 is coming next, so stay tuned, bestie 🫶💖

4.2.1. Manifest 💖

okay so the manifestNumber, thisUpdate, and nextUpdate fields are modeled after the matching fields in X.509 CRLs (see [RFC5280]) 🦋 Just like CRLs, a manifest is nominally current until the time in nextUpdate hits, or until a manifest with a greater manifest number gets issued, whichever comes first. first come, first served 💅

Because a "one-time-use" EE certificate is used to verify a manifest, the EE certificate MUST be issued with a validity period that matches the interval from thisUpdate to nextUpdate in the manifest. This keeps the CA's CRL from growing for no reason 🙄

Here's the breakdown of the manifest data elements 🎀

version: The version number of this version of the manifest specification MUST be 0. ✨

manifestNumber: This is an integer that goes up by 1 each time a new manifest is issued for a given publication point. It's how an RP can spot gaps in a sequence of published manifests 👀

Since the manifest is modeled on the CRL spec, manifestNumber is analogous to CRLNumber. So the guidance in [RFC5280] for CRLNumber values is the right vibe for the range of numbers you can use here. Manifest numbers can be expected to be long integers 🔥 Manifest verifiers MUST be able to process number values up to 20 octets. Conforming manifest issuers MUST NOT use number values longer than 20 octets. The issuer MUST increase this field monotonically for each newly generated manifest. Each RP MUST verify that a purported "new" manifest has a higher manifestNumber than previously validated manifests. If the purported "new" manifest has a manifestNumber equal to or lower than the ones from previously validated manifests, the RP SHOULD use locally cached versions of objects, as described in Section 6.6 🫶

thisUpdate: This field holds the time when the manifest was created. It follows the same format constraints as the CRL field of the same name in [RFC5280] 🕰️ The issuer MUST ensure that this value is more recent than any previously generated manifest. Each RP MUST verify that this field is greater (more recent) than the most recent manifest it has validated. If this field in a purported "new" manifest is smaller (less recent) than previously validated manifests, the RP SHOULD use locally cached versions of objects, as described in Section 6.6 🙃

nextUpdate: This field holds the time at which the next scheduled manifest will be issued. The value of nextUpdate MUST be later than the value of thisUpdate. The GeneralizedTime specification is the same as the one required for thisUpdate 📅

If the authority changes any of the items it has published in the repository publication point, the authority MUST issue a new manifest. Even if nothing changes at a publication point, a new manifest MUST be issued before the nextUpdate time. Each manifest encompasses a CRL, and the nextUpdate field of the manifest SHOULD match the CRL's nextUpdate field, since the manifest gets reissued whenever a new CRL is published 🔁 When a new manifest is issued before the nextUpdate time of the current manifest, the CA MUST also issue a new CRL that revokes the EE certificate corresponding to the old manifest 💀

fileHashAlg: This field contains the OID of the hash algorithm used to hash the files the authority has placed into the repository. The hash algorithm used MUST conform to the RPKI Algorithms and Key Size Profile specification [RFC7935] 🔐

fileList: This field is a sequence of FileAndHash objects. There's 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 in question, and a hash of the file's contents 🧚

4.2.2. Names in FileAndHash Objects 🌈

Names that appear in the fileList MUST consist of one or more characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ (UNDERSCORE), followed by a single . (DOT), followed by a three-letter extension. The extension MUST be one of those enumerated in the "RPKI Repository Name Schemes" registry maintained by IANA [IANA-NAMING] 📝

As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid file name 🎀

That example mixes uppercase and lowercase characters in the file name. CAs and RPs MUST be able to perform filesystem operations in a case-sensitive, case-preserving manner. no shade to anyone's filesystem, but this part is non-negotiable 💅

4.3. Content-Type Attribute 🍓

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 ✨

4.4. Manifest Validation 🔍

To figure out whether a manifest is valid, the RP MUST perform the following checks in addition to those specified 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.
Note: Although the thisUpdate and nextUpdate fields in the manifest eContent MUST match the corresponding fields in the CRL associated with the manifest, RPs MUST NOT reject a manifest solely because these fields are not identical. 🙈

If the above procedure says the manifest is invalid, then the manifest MUST be discarded and treated as though no manifest were present. bye bye 👋

5. Manifest Generation 🛠️

5.1. Manifest Generation Procedure 🧁

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

  1. Generate a new key pair for use in a "one-time-use" EE certificate.
  2. Issue an EE certificate for this key pair. The CA MUST revoke the EE certificate used for the manifest being replaced.

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. (RPs are required to verify both of these syntactic constraints.)

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]). (RPs are required to verify this.)

The validity interval of the EE certificate MUST exactly match the thisUpdate and nextUpdate times specified in the manifest's eContent. (An RP MUST NOT consider misalignment of the validity interval in and of itself to be an error.)

  1. The EE certificate MUST NOT be published in the authority's repository publication point. 🙅‍♀️
  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 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. (Sections 6.1 through 6.5 describe the checks that an RP MUST perform in support of the manifest content noted here.)

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. it's giving chicken-and-egg 🐣

  1. Encapsulate the manifest content using the CMS SignedData content type (as specified in 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 is described by the manifest. (RPs are required to verify the CMS signature.) 🔏
  2. Because the key pair is to be used only once, the private key associated with this key pair MUST now be destroyed. 🔥 one and done

5.2. Considerations for Manifest Generation 💭

A new manifest MUST be issued and published 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. If any named objects in the publication point are replaced, the authority MUST ensure that the file hash for each replaced object is updated accordingly in the new manifest. Additionally, the authority MUST revoke the certificate associated with each replaced object (other than a CRL), if it is not expired. 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 MUST implement some form of repository update procedure that mitigates, to the extent possible, the risk that RPs 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. stable URLs only, bestie 🔗

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). two manifests, one directory, zero drama 🧚‍♀️✨

6. Relying Party Processing of Manifests ✨

okay bestie, this is where the RP (relying party) actually does the work 💅 Every RP MUST use the current manifest of a CA to decide which listed files get added to the set of signed objects it uses for validating basic RPKI objects: certificates, ROAs, and CRLs 🎀 Any file that isn't on the manifest MUST NOT be used for validating those objects. Files that aren't listed MAY still be used to validate other signed objects, but only if that object type's profile explicitly says it's allowed (or required) 🫶 ngl, relying on unlisted files can let an attacker pull off substitution attacks, so careful!!

Remember how manifests exist to catch sneaky stuff? They help an RP notice when repository data has been messed with, when a CA or repository manager has made a mistake, or when someone is actively attacking the channel between an RP and a repository 🕵️‍♀️ So if the RP can't grab every file listed in a manifest during a fetch, the fetch counts as failed, and the RP MUST retry it later 🔁

[RFC6480] suggests (but does not mandate) that the RPKI model use incremental fetches, where an RP only grabs files that are new or changed since its last successful fetch in its local cache 🌸 This document doesn't get into the nitty-gritty of how the file transfer works between an RP and a publication point, so "fetch" here just means an attempt to get the full set of files at a publication point, based on the id-ad-rpkiManifest URI pulled from a CA certificate's SIA (more on that below) ✨

If a fetch fails, the assumption is that the next fetch will fix whatever went wrong 🦋 Until a fetch actually succeeds, an RP SHOULD use cached data from its last successful fetch. This keeps an RP from misreading what's at a publication point and accidentally treating invalid routes as valid, or the other way around 😭

The processing here is designed so that all RPs with access to the same local cache and RPKI repository data end up with the same set of validated repository files 💜 It does NOT guarantee that every RP gets the same validation results, since that depends on how each RP resolves any conflicts in the files it retrieved. Plus, RPs access repositories at different times, and some might have local cache failures, so there's no promise that every RP lands on the same acquisition or validation results 🙈

Also, there's a total "chicken and egg" situation between the manifest and the CRL for a given CA instance 🥚 If the EE certificate for the current manifest has been revoked (meaning it shows up in the current CRL), then the CA or publication point manager has made a serious error. In that case the fetch has failed, so proceed to Section 6.6. Same deal if the CRL isn't listed on a valid, current manifest acquired during a fetch: the fetch has failed, so proceed to Section 6.6, because the CRL is considered missing 💀

6.1. Manifest Processing Overview

For a given publication point, an RP MUST run a series of tests to figure out which signed object files there are acceptable 🧚 The tests in Sections 6.2 through 6.5 are performed using the manifest identified by the id-ad-rpkiManifest URI from a CA certificate's SIA. All of the files the manifest references MUST be located at the publication point given by the id-ad-caRepository URI from that same CA certificate's SIA 🍓 The manifest and the files it references MUST reside at the same publication point. If an RP runs into any files that are on a manifest but aren't at the same publication point as the manifest, the RP MUST treat the fetch as failed, and a warning MUST be issued (see Section 6.6 below) 🚨

Heads up: during CA key rollover [RFC6489], signed objects for two or more different CA instances can show up at the same publication point 👀 So manifest processing has to be done separately for each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA certificate ✨

6.2. Acquiring a Manifest for a CA

The RP MUST fetch the manifest identified by the SIA id-ad-rpkiManifest URI in the CA certificate 📥 If an RP can't retrieve a manifest using this URI, or the manifest isn't valid (Section 4.4), the RP MUST treat this as a failed fetch and proceed to Section 6.6. Otherwise, proceed to Section 6.3 🎀

6.3. Detecting Stale and/or Prematurely Issued Manifests

The RP MUST check that the current time (translated to UTC) falls between thisUpdate and nextUpdate ⏰ If it does, proceed to Section 6.4. If the current time is earlier than thisUpdate, the CA may have made an error, or the RP's local idea of time might be off. Either way, the RP MUST treat this as a failed fetch and proceed to Section 6.6. If the current time is later than nextUpdate, the manifest is stale, so the RP MUST treat this as a failed fetch. Proceed to Section 6.6. Otherwise, proceed to Section 6.4 🌈

6.4. Acquiring Files Referenced by a Manifest

The RP MUST acquire all of the files enumerated in the manifest (fileList) from the publication point 📦 If there are files listed in the manifest that can't be retrieved from the publication point, the RP MUST treat this as a failed fetch. Proceed to Section 6.6. Otherwise, proceed to Section 6.5 🧺

6.5. Matching File Names and Hashes

The RP MUST verify that the hash value of each file listed in the manifest matches the value you get by hashing the file acquired from the publication point 🔍 If the computed hash of a listed file doesn't match the hash value in the manifest, the fetch has failed, and the RP MUST respond accordingly. Proceed to Section 6.6 💔

6.6. Failed Fetches

If a fetch fails for any of the reasons in Sections 6.2 through 6.5, the RP MUST issue a warning that explains the reason(s) processing ended for this CA instance 📢 It is RECOMMENDED that a human operator gets notified of this warning 🫶

Termination of processing means the RP SHOULD keep using cached versions of the objects tied to this CA instance, until they go stale or can be swapped out for objects from a successful fetch 🕰️ This also means the RP MUST NOT try to acquire and validate subordinate signed objects, like subordinate CA certificates, until the next scheduled fetch and processing run for this CA instance. no shortcuts, bestie 🙅‍♀️

7. Publication Repositories 🏠

The RPKI publication system model requires that every publication point be associated with one or more CAs, and that it be non-empty 🌷 When a publication point gets created for 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: a CRL issued by the CA [RFC6481], matching the scope of this manifest 📜

Every published signed object in the RPKI [RFC6488] gets published in the repository publication point of the CA that issued the EE certificate, and it's listed in the manifest associated with that CA certificate 💌

8. Security Considerations 🔐

Manifests give RPs an extra layer of protection 🛡️ They can help an RP figure out whether a repository object has been deleted, hidden, or otherwise removed from view, or whether a newer version of an object was suppressed and an older version got swapped in 👀

Manifests can't repair the damage from those kinds of corruption during repository retrieval 😭 But a manifest does let an RP check whether its locally maintained copy of a repository is complete and up to date, even when retrieval happens over an insecure channel 🧚 If the manifest and the retrieved repository contents don't match, the manifest can help pin down which repository objects are the difference, whether they're missing, extraneous, or superseded 🔎

The signing structure of a manifest, plus 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 if the manifest has been hidden from view 🙈 Attacks against the manifest like these are detectable within the regular schedule of manifest updates. Replay attacks happening on finer-grained time frames aren't necessarily detectable by the manifest structure, so keep that in mind 💀

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 it 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 so it points 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 💅

10. References 📚

10.1. Normative References 📚✨

okay bestie, these are the references you NEED to read before anything else, no cap 🫶 they're the docs this spec leans on, so they count as part of the deal.

10.2. Informative References 🌈

these ones are the extra reading, lowkey super helpful for the big picture 🧠 you don't have to read them, but you'll understand everything way better if you do 🙈

Appendix A. ASN.1 Module 🧩

this is the ASN.1 module, the formal blueprint for the manifest. every bit of it matters, so don't go changing spacing or anything 🙅‍♀️ it's copy-paste exact 💖

       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 🔄

okay so, in 2019 it came to light that multiple RP implementations were in a vulnerable position 😭 possibly because of perceived ambiguity in the original [RFC6486] spec. this document tries to clarify the innovative concept and application of RPKI manifests, using real-world deployment experience from the global Internet routing system, so we don't end up with future problematic cases. it's giving damage control with a happy ending 🫶

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 gave a big shoutout to George Michaelson and Randy Bush for their contributions to the manifest specification 🙌 they also thanked Mark Reynolds and Christopher Small for helping clarify manifest validation and RP behavior 💖

and a huge group thank-you to 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 🌟 the squad really showed up 💅

Authors' Addresses 🎀

these are the humans behind the document, so here's where to find them 🦋

Rob Austein
Arrcus, Inc.
Email: sra@hactrn.net


Geoff Huston
APNIC
6 Cordelia St
South Brisbane  QLD 4101
Australia
Email: gih@apnic.net


Stephen Kent
Independent
Email: kent@alum.mit.edu


Matt Lepinski
New College Florida
5800 Bay Shore Rd.
Sarasota, FL 34243
United States of America
Email: mlepinski@ncf.edu

that's the whole spec, bestie! 🌈✨ you did it 💖

📦 where this page comes from