<?xmlversion='1.0' encoding='utf-8'?>version="1.0" encoding="UTF-8"?> <!DOCTYPE rfcSYSTEM "rfc2629.dtd"[ <!ENTITYRFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">nbsp " "> <!ENTITYRFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">zwsp "​"> <!ENTITYRFC6481 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml">nbhy "‑"> <!ENTITYRFC6482 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml"> <!ENTITY RFC7935 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7935.xml"> <!ENTITY RFC6487 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"> <!ENTITY RFC6488 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"> <!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"> <!ENTITY RFC3779 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"> <!ENTITY RFC6480 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"> <!ENTITY RFC6486 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6486.xml"> <!ENTITY RFC6489 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6489.xml">wj "⁠"> ]> <rfcsubmissionType="IETF"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sidrops-6486bis-11" number="9286" submissionType="IETF" consensus="true" category="std" obsoletes="6486" ipr="trust200902"consensus="true">updates="" xml:lang="en" symRefs="true" sortRefs="true" tocInclude="true" version="3"> <!-- xml2rfc v2v3 conversion 3.12.2 --> <!-- Generated by id2xml 1.5.0 on 2021-05-31T14:49:22Z --><?rfc strict="yes"?> <?rfc compact="yes"?> <?rfc subcompact="no"?> <?rfc symrefs="yes"?> <?rfc sortrefs="no"?> <?rfc text-list-symbols="o*+-"?> <?rfc toc="yes"?><front> <title abbrev="RPKI Manifests">Manifests for the Resource Public Key Infrastructure (RPKI)</title> <seriesInfo name="RFC" value="9286"/> <author initials="R." surname="Austein" fullname="Rob Austein"> <organization>Arrcus, Inc.</organization><address><email>sra@hactrn.net</email><address> <email>sra@hactrn.net</email> </address> </author> <author initials="G." surname="Huston" fullname="Geoff Huston"> <organization>APNIC</organization><address><postal><street>6<address> <postal> <street>6 Cordelia St</street><street>South Brisbane QLD 4101</street> <street>Australia</street><city>South Brisbane</city> <code>QLD 4101</code> <country>Australia</country> </postal> <email>gih@apnic.net</email> </address> </author> <author initials="S." surname="Kent" fullname="Stephen Kent"> <organization>Independent</organization><address><email>kent@alum.mit.edu</email><address> <email>kent@alum.mit.edu</email> </address> </author> <author initials="M." surname="Lepinski" fullname="Matt Lepinski"> <organization>New College Florida</organization><address><postal><street>5800<address> <postal> <street>5800 Bay Shore Rd.</street><street>Sarasota, FL 34243</street> <street>USA</street><city>Sarasota</city> <region>FL</region> <code>34243</code> <country>United States of America</country> </postal> <email>mlepinski@ncf.edu</email> </address> </author><date/> <area>Routing Area</area> <workgroup>SIDROPS</workgroup> <abstract><t><date year="2022" month="June" /> <area>ops</area> <workgroup>sidrops</workgroup> <abstract> <t> This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. </t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="sect-1"><t>anchor="sect-1" numbered="true" toc="default"> <name>Introduction</name> <t> The Resource Public Key Infrastructure (RPKI) <xreftarget="RFC6480"/>target="RFC6480" format="default"/> makes use of a distributed repository system <xreftarget="RFC6481"/>target="RFC6481" format="default"/> to make available a variety of objects needed by relying parties (RPs). Because all of the objects stored in the repository system are digitally signed by the entities that created them, attacks that modify these published objects are detectable by RPs. However, digital signatures alone provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not yet expired, but have since been superseded), or in-flight attacks that remove an object that should be present in the repository. To assist in the detection of such attacks, RPKI repository systems make use of a signed object called a "manifest". </t> <t> A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an authority responsible for publishing at that publication point. Each manifest contains both the name of the file containing the object and a hash of the file content, for every signed object issued by an authority that is published at the authority's repository publication point. A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point. A manifest also is intended to allow an RP to detect similar outcomes that may result from an on-path attack during the retrieval of objects from the repository. Manifests are intended to be used in Certification Authority (CA) publication points in repositories (directories containing files that are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other signed objects that are verified by End-Entity (EE) certificates issued by this CA). </t> <t> 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 RouteOriginationOrigin Authorizations (ROAs) <xreftarget="RFC6482"/>.</t>target="RFC6482" format="default"/>.</t> <t>This document obsoletes <xreftarget="RFC6486"/>.</t>target="RFC6486" format="default"/>.</t> <sectiontitle="Requirements Language" anchor="sect-1.1"><t> Theanchor="sect-1.1" numbered="true" toc="default"> <name>Requirements Language</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section> </section> <sectiontitle="Manifest Scope" anchor="sect-2"><t>anchor="sect-2" numbered="true" toc="default"> <name>Manifest Scope</name> <t> A manifest associated with a CA's repository publication point contains a list of:</t><t><list style="symbols"><t>the<ul spacing="normal"> <li>the set of (non-expired, non-revoked) certificates issued and published by thisCA,</t> <t>theCA,</li> <li>the most recent CRL issued by this CA,and</t> <t>alland</li> <li>all published signed objects that are verifiable using EE certificates <xreftarget="RFC6487"/>target="RFC6487" format="default"/> issued by this CA (other than the manifestitself).</t> </list> </t>itself).</li> </ul> <t> Every RPKI signed object includes, in the Cryptographic Message Syntax (CMS) <xreftarget="RFC5652"/>target="RFC5652" format="default"/> wrapper of the object, the EE certificate used to verify it <xreftarget="RFC6488"/>.target="RFC6488" format="default"/>. Thus, there is no requirement to separately publish that EE certificate at the CA's repository publication point.</t> <t> Where multiple CA instances share a common publication point, as can occur when a CA performs a key-rollover operation <xreftarget="RFC6489"/>,target="RFC6489" format="default"/>, 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.</t> </section> <sectiontitle="Manifest Signing" anchor="sect-3"><t>anchor="sect-3" numbered="true" toc="default"> <name>Manifest Signing</name> <t> A CA's manifest is verified using an EE certificate. The SubjectInfoAccess (SIA) field of this EE certificate contains theaccess methodaccessMethod Object Identifier (OID) of id-ad-signedObject.</t> <t> The CAMUST<bcp14>MUST</bcp14> sign only one manifest with each generated privatekey,key andMUST<bcp14>MUST</bcp14> generate a new key pair for each new version of the manifest.This form of use of theAn associated EE certificate used in this fashion is termed a "one-time-use" EE certificate (see <xreftarget="RFC6487"/>.</t>target="RFC6487" sectionFormat="of" section="3"/>).</t> </section> <sectiontitle="Manifest Definition" anchor="sect-4"><t>anchor="sect-4" numbered="true" toc="default"> <name>Manifest Definition</name> <t> A manifest is an RPKI signed object, as specified in <xreftarget="RFC6488"/>.target="RFC6488" format="default"/>. The RPKI signed object template requires specification of the following data elements in the context of the manifest structure.</t> <sectiontitle="eContentType" anchor="sect-4.1"><t>anchor="sect-4.1" numbered="true" toc="default"> <name>eContentType</name> <t> The eContentType for a manifest is defined as id-ct-rpkiManifest and has the numericalobject identifierOID of 1.2.840.113549.1.9.16.1.26.</t><figure><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ 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 }]]></artwork> </figure>]]></sourcecode> </section> <sectiontitle="eContent" anchor="sect-4.2"><t>anchor="sect-4.2" numbered="true" toc="default"> <name>eContent</name> <t> The content of a manifest is ASN.1 encoded using the Distinguished Encoding Rules (DER) <xreftarget="X.690"/>.target="X.690" format="default"/>. The content of a manifest is defined as follows:</t><figure><artwork><![CDATA[<sourcecode type="asn.1"><![CDATA[ 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 }]]></artwork> </figure>]]></sourcecode> <sectiontitle="Manifest" anchor="sect-4.2.1"><t>anchor="sect-4.2.1" numbered="true" toc="default"> <name>Manifest</name> <t> The manifestNumber, thisUpdate, and nextUpdate fields are modeled after the corresponding fields in X.509 CRLs (see <xreftarget="RFC5280"/>).target="RFC5280" format="default"/>). 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.</t> <t> Because a "one-time-use" EE certificate is employed to verify a manifest, the EE certificateMUST<bcp14>MUST</bcp14> be issued with a validity period that coincides with the interval from thisUpdate to nextUpdate in the manifest, to prevent needless growth of the CA's CRL. </t> <t> The data elements of the manifest structure are defined as follows:</t><t><list style="hanging" hangIndent="3"><t hangText="version:"> <vspace blankLines="0"/><dl newline="true" spacing="normal" indent="3"> <dt>version:</dt> <dd> The version number of this version of the manifest specificationMUST<bcp14>MUST</bcp14> be 0.</t> <t hangText="manifestNumber:"> <vspace blankLines="0"/></dd> <dt>manifestNumber:</dt> <dd> <t> This field is an integer that is incremented (by 1) 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.<vspace blankLines="1"/></t> <t> As the manifest is modeled on the CRL specification, theManifestNumbermanifestNumber is analogous to the CRLNumber, and the guidance in <xreftarget="RFC5280"/>target="RFC5280" format="default"/> 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 verifiersMUST<bcp14>MUST</bcp14> be able to process number values up to 20 octets. Conforming manifest issuersMUST NOT<bcp14>MUST NOT</bcp14> use number values longer than 20 octets. The issuerMUST<bcp14>MUST</bcp14> increase the value of this field monotonically for eachnewly-generated Manifest.newly generated manifest. Each RPMUST<bcp14>MUST</bcp14> verify that a purported "new"Manifestmanifest contains a higher manifestNumber thanpreviously-validated Manifests.previously validated manifests. If the purported "new"Manifestmanifest containsana manifestNumber value equal to or lowermanifestNumberthanpreviously-validated Manifests,manifestNumber values of previously validated manifests, the RPSHOULD<bcp14>SHOULD</bcp14> use locally cached versions of objects, as described in <xreftarget="sect-6.6"/>.target="sect-6.6" format="default"/>. </t><t hangText="thisUpdate:"> <vspace blankLines="0"/></dd> <dt>thisUpdate:</dt> <dd> This field contains the time when the manifest was created. This field has the same format constraints as specified in <xreftarget="RFC5280"/>target="RFC5280" format="default"/> for the CRL field of the same name. The issuerMUST<bcp14>MUST</bcp14> ensure that the value of this field is more recent than anypreviously-generated Manifest.previously generated manifest. Each RPMUST<bcp14>MUST</bcp14> verify that this field value is greater (more recent) than the most recentManifestmanifest it has validated. If this field in a purported "new"Manifestmanifest is smaller (less recent) thanpreviously-validated Manifests,previously validated manifests, the RPSHOULD<bcp14>SHOULD</bcp14> use locally cached versions of objects, as described in <xreftarget="sect-6.6"/>. </t> <t hangText="nextUpdate:"> <vspace blankLines="0"/>target="sect-6.6" format="default"/>. </dd> <dt>nextUpdate:</dt> <dd> <t> This field contains the time at which the next scheduled manifest will be issued. The value of nextUpdateMUST<bcp14>MUST</bcp14> be later than the value of thisUpdate. The specification of the GeneralizedTime value is the same as required for the thisUpdate field.<vspace blankLines="1"/></t> <t> If the authority alters any of the items that it has published in the repository publication point, then the authorityMUST<bcp14>MUST</bcp14> issue a new manifest. Even if no changes are made to objects at a publication point, a new manifestMUST<bcp14>MUST</bcp14> be issued before the nextUpdate time. Each manifest encompasses a CRL, and the nextUpdate field of the manifestSHOULD<bcp14>SHOULD</bcp14> match that of the CRL's nextUpdate field, as the manifest will bere-issuedreissued when a new CRL is published. When a new manifest is issued before the time specified in nextUpdate of the current manifest, the CAMUST<bcp14>MUST</bcp14> also issue a new CRL that revokes the EE certificate corresponding to the old manifest. </t><t hangText="fileHashAlg:"> <vspace blankLines="0"/></dd> <dt>fileHashAlg:</dt> <dd> 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 usedMUST<bcp14>MUST</bcp14> conform to the RPKI Algorithms and Key Size Profile specification <xreftarget="RFC7935"/>. </t> <t hangText="fileList:"> <vspace blankLines="0"/>target="RFC7935" format="default"/>. </dd> <dt>fileList:</dt> <dd> 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.</t> </list> </t></dd> </dl> </section> <sectiontitle="Namesanchor="sect-4.2.2" numbered="true" toc="default"> <name>Names in FileAndHashobjects" anchor="sect-4.2.2"><t>Objects</name> <t> Names that appear in the fileListMUST<bcp14>MUST</bcp14> 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 extensionMUST<bcp14>MUST</bcp14> be one of those enumerated in the "RPKI RepositoryNaming Scheme"Name Schemes" registry maintained by IANA <xreftarget="IANA-NAMING"/>.</t>target="IANA-NAMING" format="default"/>.</t> <t> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a validfilename.</t>file name.</t> <t> The example above contains a mix of uppercase and lowercase characters in thefilename.file name. CAs and RPsMUST<bcp14>MUST</bcp14> be able to perform filesystem operations in a case-sensitive, case-preserving manner.</t> </section> </section> <sectiontitle="Content-Type Attribute" anchor="sect-4.3"><t>anchor="sect-4.3" numbered="true" toc="default"> <name>Content-Type Attribute</name> <t> The mandatory content-type attributeMUST<bcp14>MUST</bcp14> 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.</t> </section> <sectiontitle="Manifest Validation" anchor="sect-4.4"><t>anchor="sect-4.4" numbered="true" toc="default"> <name>Manifest Validation</name> <t> To determine whether a manifest is valid, the RPMUST<bcp14>MUST</bcp14> perform the following checks in addition to those specified in <xreftarget="RFC6488"/>:</t> <t><list style="numbers"><t>Thetarget="RFC6488" format="default"/>:</t> <ol spacing="normal" type="1"><li>The eContentType in the EncapsulatedContentInfo is id-ad- rpkiManifest (OID1.2.840.113549.1.9.16.1.26).</t> <t>The1.2.840.113549.1.9.16.1.26).</li> <li>The version of the rpkiManifest is0.</t> <t>In0.</li> <li>In the rpkiManifest, thisUpdate precedesnextUpdate.</t> </list> </t>nextUpdate.</li> </ol> <t>Note: Although the thisUpdate and nextUpdate fields in theManifestmanifest eContentMUST<bcp14>MUST</bcp14> match the corresponding fields in the CRL associated with theManifest,manifest, RPsMUST NOT<bcp14>MUST NOT</bcp14> reject a manifest solely because these fields are not identical.</t> <t> If the above procedure indicates that the manifest is invalid, then the manifestMUST<bcp14>MUST</bcp14> be discarded and treated as though no manifest were present.</t> </section> </section> <sectiontitle="Manifest Generation" anchor="sect-5"><section title="Manifestanchor="sect-5" numbered="true" toc="default"> <name>Manifest Generation</name> <section anchor="sect-5.1" numbered="true" toc="default"> <name>Manifest GenerationProcedure" anchor="sect-5.1"><t>Procedure</name> <t> For a CA publication point in the RPKI repository system, a CAMUST<bcp14>MUST</bcp14> perform the following steps to generate a manifest:</t><t><list style="numbers"> <t>Generate<ol spacing="normal" type="1"><li>Generate a new key pair for use in a "one-time-use" EEcertificate.</t>certificate.</li> <li> <t>Issue an EE certificate for this key pair. The CAMUST<bcp14>MUST</bcp14> revoke the EE certificate used for the manifest being replaced.<vspace blankLines="1"/></t> <t> This EE certificateMUST<bcp14>MUST</bcp14> have an SIA extension access description field with an accessMethod OID value ofid-ad-signedobject,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.)<vspace blankLines="1"/></t> <t> This EE certificateMUST<bcp14>MUST</bcp14> describe its Internet Number Resources (INRs) using the "inherit" attribute, rather than an explicit description of a resource set (see <xreftarget="RFC3779"/>).target="RFC3779" format="default"/>). (RPs are required to verify this.)<vspace blankLines="1"/></t> <t> The validity interval of the EE certificateMUST<bcp14>MUST</bcp14> exactly match the thisUpdate and nextUpdate times specified in the manifest's eContent. (An RPMUST NOT<bcp14>MUST NOT</bcp14> consider misalignment of the validity intervalmisalignmentin and of itself to be an error.) </t><t>The</li> <li>The EE certificateMUST NOT<bcp14>MUST NOT</bcp14> be published in the authority's repository publicationpoint.</t>point.</li> <li> <t>Construct the manifestcontent.<vspace blankLines="1"/>content.</t> <t> The manifest content is described in <xreftarget="sect-4.2.1"/>.target="sect-4.2.1" format="default"/>. 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-5 describes(Sections <xref target="sect-6.1" format="counter"/> through <xref target="sect-6.5" format="counter"/> describe the checks that an RPMUST<bcp14>MUST</bcp14> perform in support of the manifest content noted here.)<vspace blankLines="1"/></t> <t> 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. </t><t></li> <li> Encapsulate the manifest content using the CMS SignedData content type (as specified in <xreftarget="sect-4"/>),target="sect-4" format="default"/>), 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.)</t> <t>Because</li> <li>Because the key pair is to be used only once, the private key associated with this key pairMUST<bcp14>MUST</bcp14> now bedestroyed.</t> </list> </t>destroyed.</li> </ol> </section> <sectiontitle="Considerationsanchor="sect-5.2" numbered="true" toc="default"> <name>Considerations for ManifestGeneration" anchor="sect-5.2"><t>Generation</name> <t> A new manifestMUST<bcp14>MUST</bcp14> be issued and published before the nextUpdate time.</t> <t> An authorityMUST<bcp14>MUST</bcp14> 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 authorityMUST<bcp14>MUST</bcp14> ensure that the file hash for each replaced object is updated accordingly in the new manifest. Additionally, the authorityMUST<bcp14>MUST</bcp14> revoke the certificate associated with each replaced object (other than a CRL), if it is not expired. An authorityMAY<bcp14>MAY</bcp14> 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 operatorsMUST<bcp14>MUST</bcp14> 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.</t> <t> Since the manifest object URL is included in the SIA of issued certificates, a new manifestMUST NOT<bcp14>MUST NOT</bcp14> 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.</t> <t> When a CA entity is performing a key rollover, the entityMAY<bcp14>MAY</bcp14> 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).</t> </section> </section> <sectiontitle="Relyinganchor="sect-6" numbered="true" toc="default"> <name>Relying Party Processing ofManifests" anchor="sect-6">Manifests</name> <t>Each RPMUST<bcp14>MUST</bcp14> 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 manifestMUST NOT<bcp14>MUST NOT</bcp14> be used for validation of these objects. However, files not listed on a manifestMAY<bcp14>MAY</bcp14> 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.</t> <t>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 RPMUST<bcp14>MUST</bcp14> retry the fetch later.</t> <t> <xreftarget="RFC6480"/>target="RFC6480" format="default"/> 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,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.ThusThus, 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).</t> <t> 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 RPSHOULD<bcp14>SHOULD</bcp14> use cached data from a previous, successful fetch. This response is intended to prevent an RP from misinterpreting data associated with a publicationpoint,point and thus possibly treating invalid routes as valid, or vice versa.</t> <t> 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.</t> <t> 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 thiscasecase, the fetch has failed; proceed to <xreftarget="sect-6.6"/>.target="sect-6.6" format="default"/>. Similarly, if the CRL is not listed on a valid, current manifest, acquired during a fetch, the fetch has failed; proceed to <xreftarget="sect-6.6"/>,target="sect-6.6" format="default"/>, because the CRL is considered missing.</t> <sectiontitle="Manifestanchor="sect-6.1" numbered="true" toc="default"> <name>Manifest ProcessingOverview" anchor="sect-6.1"><t>Overview</name> <t> For a given publication point, an RPMUST<bcp14>MUST</bcp14> perform a series of tests to determine which signed object files at the publication point are acceptable. The tests described below(<xref target="sect-6.2"/> to(Sections <xref target="sect-6.2" format="counter"/> through <xreftarget="sect-6.5"/>)target="sect-6.5" format="counter"/>) 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 manifestMUST<bcp14>MUST</bcp14> be located at the publication point specified by the id-ad-caRepository URI from the (same) CA certificate's SIA. The manifest and the files it referencesMUST<bcp14>MUST</bcp14> reside at the same publication point. If an RP encounters any files that appear on a manifest but do not reside at the same publication point as themanifestmanifest, the RPMUST<bcp14>MUST</bcp14> treat the fetch as failed, and a warningMUST<bcp14>MUST</bcp14> be issued (see <xreftarget="sect-6.6"/>target="sect-6.6" format="default"/> below).</t> <t> Note that, during CA key rollover <xreftarget="RFC6489"/>,target="RFC6489" format="default"/>, 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.</t> </section> <sectiontitle="Acquiringanchor="sect-6.2" numbered="true" toc="default"> <name>Acquiring a Manifest for aCA" anchor="sect-6.2"><t>CA</name> <t> The RPMUST<bcp14>MUST</bcp14> fetch the manifest identified by the SIA id-ad- rpkiManifest URI in the CA certificate. If an RP cannot retrieve a manifest using thisURI,URI or if the manifest is not valid (<xreftarget="sect-4.4"/>),target="sect-4.4" format="default"/>), an RPMUST<bcp14>MUST</bcp14> treat this as a failedfetch andfetch; proceed to <xreftarget="sect-6.6"/>; otherwisetarget="sect-6.6" format="default"/>. Otherwise, proceed to <xreftarget="sect-6.3"/>.</t>target="sect-6.3" format="default"/>.</t> </section> <sectiontitle="Detectinganchor="sect-6.3" numbered="true" toc="default"> <name>Detecting Staleand or Prematurely-issued Manifests" anchor="sect-6.3"><t>and/or Prematurely Issued Manifests</name> <t> The RPMUST<bcp14>MUST</bcp14> check that the current time (translated to UTC) is between thisUpdate and nextUpdate. If the current time lies within this interval, proceed to <xreftarget="sect-6.4"/>.target="sect-6.4" format="default"/>. If the current time is earlier than thisUpdate, the CA may have made an error or theRP’sRP's local notion of time may be inerror; theerror. The RPMUST<bcp14>MUST</bcp14> treat this as a failedfetch andfetch; proceed to <xreftarget="sect-6.6"/>.target="sect-6.6" format="default"/>. If the current time is later than nextUpdate, then the manifest is stale; the RP <bcp14>MUST</bcp14> treat thisisas a failedfetch and RP MUST proceedfetch. Proceed to <xreftarget="sect-6.6"/>; otherwisetarget="sect-6.6" format="default"/>. Otherwise, proceed to <xreftarget="sect-6.4"/>.</t>target="sect-6.4" format="default"/>.</t> </section> <sectiontitle="Acquiringanchor="sect-6.4" numbered="true" toc="default"> <name>Acquiring Files Referenced by aManifest" anchor="sect-6.4"><t>Manifest</name> <t> The RPMUST<bcp14>MUST</bcp14> acquire all of the files enumerated in the manifest (fileList) from the publication point. If there are files listed in the manifest that cannot be retrieved from the publication point, thefetch has failed and theRPMUST proceed<bcp14>MUST</bcp14> treat this as a failed fetch. Proceed to <xreftarget="sect-6.6"/>; otherwise,target="sect-6.6" format="default"/>. Otherwise, proceed to <xreftarget="sect-6.5"/>.</t>target="sect-6.5" format="default"/>.</t> </section> <sectiontitle="Matchinganchor="sect-6.5" numbered="true" toc="default"> <name>Matching File Names andHashes" anchor="sect-6.5"><t>Hashes</name> <t> The RPMUST<bcp14>MUST</bcp14> verify that the hash value of each file listed in the manifest matches the value obtained by hashing the file acquired from 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 the fetch hasfailedfailed, and the RPMUST proceed<bcp14>MUST</bcp14> respond accordingly. Proceed to <xreftarget="sect-6.6"/>.</t>target="sect-6.6" format="default"/>.</t> </section> <sectiontitle="Failed Fetches" anchor="sect-6.6">anchor="sect-6.6" numbered="true" toc="default"> <name>Failed Fetches</name> <t> If a fetch fails for any of the reasons cited in6.2-6.5,Sections <xref target="sect-6.2" format="counter"/> through <xref target="sect-6.5" format="counter"/>, the RPMUST<bcp14>MUST</bcp14> issue a warning indicating the reason(s) for termination of processing with regard to this CA instance. It isRECOMMENDED<bcp14>RECOMMENDED</bcp14> that a human operator be notified of this warning. </t> <t> Termination of processing means that the RPSHOULD<bcp14>SHOULD</bcp14> continue to use cached versions of the objects associated with this CA instance, until such time as they become stale or they can be replaced by objects from a successful fetch. This implies that the RPMUST NOT<bcp14>MUST NOT</bcp14> try to acquire and validate subordinate signed objects, e.g., subordinate CA certificates, until the next interval when the RP is scheduled to fetch and process data for this CA instance. </t> </section> </section> <sectiontitle="Publication Repositories" anchor="sect-7"><t>anchor="sect-7" numbered="true" toc="default"> <name>Publication Repositories</name> <t> The RPKI publication system model requires that every publication point be associated with one or moreCAs,CAs and be non-empty. Upon creation of the publication point associated with a CA, the CAMUST<bcp14>MUST</bcp14> 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 <xreftarget="RFC6481"/>,correspondingtarget="RFC6481" format="default"/>, corresponding to the scope of this manifest.</t> <t> Every published signed object in the RPKI <xreftarget="RFC6488"/>target="RFC6488" format="default"/> 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.</t> </section> <sectiontitle="Security Considerations" anchor="sect-8"><t>anchor="sect-8" numbered="true" toc="default"> <name>Security Considerations</name> <t> Manifests provide an additional level of protection for RPKI RPs. Manifests can assist an RPto determinein determining if a repository object has been deleted, occluded, or otherwise removed from view, or if a publication of a newer version of an object has been suppressed (and an older version of the object has been substituted).</t> <t> 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.</t> <t> The signing structure of a manifest and the use of the nextUpdate valueallowsallow 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 replayattackattacks within finer-grained time frames are not necessarily detectable by the manifest structure.</t> </section> <sectiontitle="IANA Considerations" anchor="sect-9"><t> As <xref target="RFC6488"/> created and populated the registriesanchor="sect-9" numbered="true" toc="default"> <name>IANA Considerations</name> <t> The "RPKI SignedObject"Objects" registry was originally created andthree-letter filename extensions forpopulated by <xref target="RFC6488" format="default"/>. The "RPKI Repository NameSchemes," no new action is requestedSchemes" registry was created by <xref target="RFC6481"/> and created four of theIANA.</t> </section> <section title="Acknowledgements" anchor="sect-10"><t> The authors would like to acknowledgeinitial three-letter file name extensions. IANA has updated thecontributions from George Michelson and Randy Bushreference for the "Manifest" row in thepreparation"RPKI Signed Objects" registry to point to this document. </t> <t> IANA has also updated the following entries to refer to this document instead of RFC 6486:</t> <ul spacing="normal"> <li>id-mod-rpkiManifest (60) in themanifest specification. Additionally,"SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry</li> <li>id-ct-rpkiManifest (26) in theauthors would like to thank Mark Reynolds and Christopher Small"SMI Security forassistanceS/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry</li> <li>the "Security considerations" entry inclarifying manifest validation and RP behavior. The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, Lars Eggert, Robert Wilton, and Benjamin Kadukthe application media type registration fortheir helpful review of this document.</t>rpki-manifest</li> </ul> <t>No other actions are required.</t> </section> </middle> <back><references title="Normative References"><references> <name>References</name> <references> <name>Normative References</name> <reference anchor="IANA-NAMING"target="https://www.iana.org/assignments/rpki/rpki.xhtml#name-schemes"><front>target="https://www.iana.org/assignments/rpki/"> <front> <title>RPKI Repository Name Schemes</title><author> </author><author><organization>IANA</organization></author> <date/> </front> </reference>&RFC2119; &RFC5280; &RFC6481; &RFC6482; &RFC7935; &RFC6487; &RFC6488; &RFC8174;<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6482.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7935.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6487.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6488.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <reference anchor="X.690"target="https://www.itu.int/rec/T-REC-X.690-199511-S!Cor1">target="https://www.itu.int/rec/T-REC-X.690-202102-I/en"> <front><title>X.690</title> <author></author><title>Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)</title> <author><organization>International Telecommunication Union</organization></author> <date/>month="February" year="2021"/> </front> <refcontent>ITU-T Recommendation X.690</refcontent> </reference> </references><references title="Informative References"> &RFC5652; &RFC3779; &RFC6480; &RFC6486; &RFC6489;<references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5652.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3779.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6480.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6486.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6489.xml"/> </references> </references> <sectiontitle="ASN.1 Module" anchor="sect-a"><figure><artwork><![CDATA[anchor="sect-a" numbered="true" toc="default"> <name>ASN.1 Module</name> <sourcecode type="asn.1"><![CDATA[ RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) mod(0)TBD60 }]]></artwork> </figure> <figure><artwork><![CDATA[]]></sourcecode> <sourcecode type="asn.1"><![CDATA[ DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL -- IMPORTS CONTENT-TYPE FROM CryptographicMessageSyntax-2010 -- in[RFC6268]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]]></artwork> </figure>]]></sourcecode> </section> <sectiontitle="Changesanchor="sect-b" numbered="true" toc="default"> <name>Changes since RFC6486" anchor="sect-b">6486</name> <t> In 2019, it came to light that multipleRelying PartyRP implementations were in a vulnerable position, possibly due to perceived ambiguity in the original <xreftarget="RFC6486"/>target="RFC6486" format="default"/> specification. This document attempts to clarify the innovative concept and application of RPKIManifestsmanifests in light of real-world deployment experience in the global Internet routing system, to avoid future problematic cases. </t> <t> The following list summarizes the changes between RFC 6486 and this document: </t><t> <list style="symbols"> <t> Forbid<ul spacing="normal"> <li> Forbidding "sequential-use" EEcertificates,certificates and insteadmandatemandating "one-time-use" EE certificates.</t> <t> Clarify</li> <li> Clarifying thatManifestmanifest EE certificates are to be issued with a validity periodwhichthat coincides with the interval specified in theManifestmanifest eContent, which coincides with the CRL's thisUpdate and nextUpdate.</t> <t> Clarify</li> <li> Clarifying that the manifestNumber is monotonically incremented in steps of 1.</t> <t> Recommend</li> <li> Recommending that CA issuersto coincidenceinclude the applicable CRL's nextUpdate with theManifest'smanifest's nextUpdate.</t> <t> The</li> <li> Constraining the set of valid characters in FileAndHashfilenames was constrained. </t> <t> Clarificationsfile names. </li> <li> Clarifying that an RP unable to obtain the full set of files listed on aManifestmanifest is considered to be in a failure state, in which case cached data from a previous attempt should be used (if available).</t> <t> Clarifications on</li> <li> Clarifying the requirement for a current CRL to be present, listed, and verified.</t> <t> Removed</li> <li> Removing the notion of'local policy'. </t> </list> </t>"local policy". </li> </ul> </section> <section anchor="sect-10" numbered="false" toc="default"> <name>Acknowledgements</name> <t> The authors would like to acknowledge the contributions from <contact fullname="George Michaelson"/> and <contact fullname="Randy Bush"/> in the preparation of the manifest specification. Additionally, the authors would like to thank <contact fullname="Mark Reynolds"/> and <contact fullname="Christopher Small"/> for assistance in clarifying manifest validation and RP behavior. The authors also wish to thank <contact fullname="Tim Bruijnzeels"/>, <contact fullname="Job Snijders"/>, <contact fullname="Oleg Muravskiy"/>, <contact fullname="Sean Turner"/>, <contact fullname="Adianto Wibisono"/>, <contact fullname="Murray Kucherawy"/>, <contact fullname="Francesca Palombini"/>, <contact fullname="Roman Danyliw"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Robert Wilton"/>, and <contact fullname="Benjamin Kaduk"/> for their helpful review of this document.</t> </section> </back> </rfc>