<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
  <!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> nbsp    "&#160;">
  <!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"> zwsp   "&#8203;">
  <!ENTITY RFC6481 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6481.xml"> nbhy   "&#8209;">
  <!ENTITY RFC6482 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     "&#8288;">
]>

<rfc submissionType="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="false" 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="May" />
    <area>ops</area>
    <workgroup>sidrops</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in the
title) for use on <https://www.rfc-editor.org/search>. -->

    <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>
    <section title="Introduction" anchor="sect-1"><t> anchor="sect-1" numbered="true" toc="default">
      <name>Introduction</name>
      <t>
   The Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"/> target="RFC6480" format="default"/> makes use of a distributed repository system <xref target="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 Route
   Origination
   Origin Authorizations (ROAs) <xref target="RFC6482"/>.</t> target="RFC6482" format="default"/>.</t>
      <t>This document obsoletes <xref target="RFC6486"/>.</t> target="RFC6486" format="default"/>.</t>
      <section title="Requirements Language" anchor="sect-1.1"><t>
   The anchor="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 in BCP
   14 BCP&nbsp;14
        <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
        when, they appear in all capitals, as shown here.</t>
      </section>
    </section>
    <section title="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 this CA,</t>

	<t>the CA,</li>
        <li>the most recent CRL issued by this CA, and</t>

	<t>all and</li>
        <li>all published signed objects that are verifiable using EE
      certificates <xref target="RFC6487"/> target="RFC6487" format="default"/> issued by this CA (other than the manifest itself).</t>

	</list>
	</t> itself).</li>
      </ul>
      <t>
   Every RPKI signed object includes, in the Cryptographic Message
   Syntax (CMS) <xref target="RFC5652"/> target="RFC5652" format="default"/> wrapper of the object, the EE certificate used
   to verify it <xref target="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 <xref target="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>
    <section title="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 the
   access method Object Identifier (OID) of id-ad-signedObject.</t>
      <t>
   The CA MUST <bcp14>MUST</bcp14> sign only one manifest with each generated private key, key and MUST <bcp14>MUST</bcp14> generate a new key pair for each new version of the manifest.
   This form of use of the
   An associated EE certificate used in this fashion is termed a "one-time-use" EE certificate (see <xref target="RFC6487"/>.</t> target="RFC6487" sectionFormat="of" section="3"/>).</t>
    </section>
    <section title="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 <xref target="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>
      <section title="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 numerical object identifier OID 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>

<!-- [rfced] Sections 4.1 and subsequent: Please review the "type"
attribute of each sourcecode element in the XML file to ensure
correctness. If the current list of preferred values
for "type" (https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, then feel free to let us
know. Also, it is acceptable to leave the "type" attribute not
set.
-->
      </section>
      <section title="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) <xref target="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>
        <section title="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 <xref target="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 certificate MUST <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 specification
      MUST
      <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, the ManifestNumber manifestNumber is analogous to the CRLNumber, and the guidance in <xref target="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 verifiers MUST <bcp14>MUST</bcp14> be able to process number values up to 20 octets.
      Conforming manifest issuers MUST NOT <bcp14>MUST NOT</bcp14> use number values longer than 20 octets.
      The issuer MUST <bcp14>MUST</bcp14> increase the value of this field monotonically for each newly-generated Manifest. newly generated manifest.
      Each RP MUST <bcp14>MUST</bcp14> verify that a purported "new" Manifest manifest contains a higher manifestNumber than previously-validated Manifests. previously validated manifests.
      If the purported "new" Manifest manifest contains an a manifestNumber value equal to or lower manifestNumber than previously-validated Manifests, manifestNumber values of previously validated manifests, the RP SHOULD <bcp14>SHOULD</bcp14> use locally cached versions of objects, as described in <xref target="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 <xref target="RFC5280"/> target="RFC5280" format="default"/> for the CRL field of the same name.
      The issuer MUST <bcp14>MUST</bcp14> ensure that the value of this field is more recent than any previously-generated Manifest. previously generated manifest.
      Each RP MUST <bcp14>MUST</bcp14> verify that this field value is greater (more recent) than the most recent Manifest manifest it has validated.
      If this field in a purported "new" Manifest manifest is smaller (less recent) than previously-validated Manifests, previously validated manifests, the RP SHOULD <bcp14>SHOULD</bcp14> use locally cached versions of objects, as described in <xref target="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 nextUpdate MUST <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 authority MUST <bcp14>MUST</bcp14> issue a
      new manifest. Even if no changes are made to objects at a
      publication point, a new manifest MUST <bcp14>MUST</bcp14> be issued before the nextUpdate
      time. Each manifest encompasses a CRL, and the nextUpdate field of the manifest SHOULD <bcp14>SHOULD</bcp14> match
      that of the CRL's nextUpdate field, as the manifest will be re-issued reissued when a new CRL is published.
      When a new manifest is issued before the time specified in nextUpdate of the
      current manifest, the CA MUST <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 used MUST <bcp14>MUST</bcp14> conform to the RPKI Algorithms and Key Size
      Profile specification <xref target="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>
        <section title="Names anchor="sect-4.2.2" numbered="true" toc="default">
          <name>Names in FileAndHash objects" anchor="sect-4.2.2"><t> Objects</name>
          <t>
   Names that appear in the fileList MUST <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 extension MUST <bcp14>MUST</bcp14> be one of those enumerated in
   the "RPKI Repository Naming Name Scheme" registry maintained by IANA
   <xref target="IANA-NAMING"/>.</t> target="IANA-NAMING" format="default"/>.</t>
          <t>
   As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.</t>
          <t>
   The example above contains a mix of uppercase and lowercase characters in the filename. CAs and RPs MUST <bcp14>MUST</bcp14> be able to perform filesystem operations in a case-sensitive, case-preserving manner.</t>
        </section>
      </section>
      <section title="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 attribute MUST <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>
      <section title="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 RP MUST <bcp14>MUST</bcp14> perform the
   following checks in addition to those specified in <xref target="RFC6488"/>:</t>

	<t><list style="numbers"><t>The target="RFC6488" format="default"/>:</t>
        <ol spacing="normal" type="1"><li>The eContentType in the EncapsulatedContentInfo is id-ad-
       rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).</t>

	<t>The 1.2.840.113549.1.9.16.1.26).</li>

<!-- [rfced] Section 4.4:  Please confirm that the OID for
id-ad-rpkiManifest is correct.  We ask because this is the same OID
as that listed for id-ct-rpkiManifest in Section 4.3.

We also see this value in Section 4.4 of RFC 6486, but please
see Section 4.8.8.1 of RFC 6487, search
<https://www.iana.org/assignments/smi-numbers/> for
"id-ad-rpkiManifest" (we see 1.3.6.1.5.5.7.48.10 there), and
advise.

If any changes related to the OID are needed, we also suggest
adding a corresponding entry in Appendix B, as there are no errata
reported for RFC 6486 to date.

Original:
 1.  The eContentType in the EncapsulatedContentInfo is id-ad-
     rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). -->

          <li>The version of the rpkiManifest is 0.</t>

	<t>In 0.</li>
          <li>In the rpkiManifest, thisUpdate precedes nextUpdate.</t>
    </list>
    </t> nextUpdate.</li>
        </ol>
        <t>Note: Although the thisUpdate and nextUpdate fields in the Manifest manifest eContent MUST <bcp14>MUST</bcp14> match the corresponding fields in the CRL associated with the Manifest, manifest, RPs MUST NOT <bcp14>MUST NOT</bcp14> reject a manifest solely because these fields are not identical.</t>

<!-- [rfced] Section 4.4:  Please review whether the "Note:"
paragraph in this section should be in the <aside> element.
<aside> is defined as "a container for content that is semantically
less important or tangential to the content that surrounds it"
(https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2). -->

        <t>
   If the above procedure indicates that the manifest is invalid, then
   the manifest MUST <bcp14>MUST</bcp14> be discarded and treated as though no manifest were
   present.</t>
      </section>
    </section>
    <section title="Manifest Generation" anchor="sect-5"><section title="Manifest anchor="sect-5" numbered="true" toc="default">
      <name>Manifest Generation</name>
      <section anchor="sect-5.1" numbered="true" toc="default">
        <name>Manifest Generation Procedure" anchor="sect-5.1"><t> Procedure</name>
        <t>
   For a CA publication point in the RPKI repository system, a CA MUST <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" EE certificate.</t> certificate.</li>
          <li>
            <t>Issue an EE certificate for this key pair. The CA MUST <bcp14>MUST</bcp14> revoke the EE certificate used for the manifest being replaced.
       <vspace blankLines="1"/>
            </t>
            <t>
	This EE certificate MUST <bcp14>MUST</bcp14> have an SIA extension access description
       field with an accessMethod OID value of id-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>

<!-- [rfced] Section 5.1:  Because the all-lowercase form
"id-ad-signedobject" is not used in any RFC except for one instance
in RFC 6486 (which also uses "id-ad-signedObject"), we changed
"object" to "Object".  Please let us know any concerns.

Original:
 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.

Currently:
 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. -->

            <t>
	This EE certificate <bcp14>MUST</bcp14> describe its Internet Number Resources
       (INRs) using the "inherit" attribute, rather than an explicit
       description of a resource set (see <xref target="RFC3779"/>). target="RFC3779" format="default"/>). (RPs are required to verify this.)
	<vspace blankLines="1"/>
            </t>
            <t>
    The validity interval of the EE certificate MUST <bcp14>MUST</bcp14> exactly match the thisUpdate and nextUpdate times specified in the manifest's eContent.
    (An RP MUST NOT <bcp14>MUST NOT</bcp14> consider misalignment of the validity interval misalignment in and of itself to be an error.)
            </t>

	<t>The
          </li>
          <li>The EE certificate MUST NOT <bcp14>MUST NOT</bcp14> be published in the authority's
       repository publication point.</t> point.</li>
          <li>
            <t>Construct the manifest content.<vspace blankLines="1"/> content.</t>
            <t>
	The manifest content is described in <xref target="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&nbsp;<xref target="sect-6.1" format="counter"/> through <xref target="sect-6.5" format="counter"/> describe the checks that an RP MUST <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 <xref target="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>

<!-- [rfced] Section 5.1:  We do not see "SignedData" mentioned in
Section 4 or anywhere else in this document.  Please confirm that
this citation is correct and will be clear to readers.

Original ("as specified Section 4" has been corrected):
 5.  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 is described by the manifest. -->

          <li>Because the key pair is to be used only once, the private key
        associated with this key pair MUST <bcp14>MUST</bcp14> now be destroyed.</t>

	</list>
	</t> destroyed.</li>
        </ol>
      </section>
      <section title="Considerations anchor="sect-5.2" numbered="true" toc="default">
        <name>Considerations for Manifest Generation" anchor="sect-5.2"><t> Generation</name>
        <t>
   A new manifest MUST <bcp14>MUST</bcp14> be issued and published before the
   nextUpdate time.</t>
        <t>
   An authority MUST <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 authority MUST <bcp14>MUST</bcp14> ensure that the file hash for each replaced object is updated accordingly in the new manifest. Additionally, the authority MUST <bcp14>MUST</bcp14> revoke the certificate associated with each replaced object (other than a CRL), if it is not expired.  An
   authority MAY <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 operators MUST <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 manifest MUST 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 entity MAY <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>
    <section title="Relying anchor="sect-6" numbered="true" toc="default">
      <name>Relying Party Processing of Manifests" anchor="sect-6"> Manifests</name>
      <t>Each RP MUST <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 manifest MUST NOT <bcp14>MUST NOT</bcp14> be used for validation of these objects. However, files not listed on a manifest MAY <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 RP MUST <bcp14>MUST</bcp14> retry the fetch later.</t>
      <t>
   <xref target="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.  Thus  Thus, the term "fetch" refers to an operation
   that attempts to acquire the full set of files at a publication
   point, consistent with the id-ad-rpkiManifest URI extracted from a CA
   certificate's SIA (see below).</t>

<!-- [rfced] Section 6:  We could not verify the
suggestion-vs.-mandate concept in RFC 6480.  Please confirm that this
citation is correct and will be clear to readers.

Original:
 [RFC6480] suggests (but does not mandate) that the RPKI model employ
 fetches that are incremental, e.g., an RP transfers files from a
 publication point only if they are new/changed since the previous,
 successful, fetch represented in the RP's local cache. -->

      <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 RP SHOULD <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 publication point, 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 this case case, the fetch has failed; proceed to <xref target="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
           <xref target="sect-6.6"/>, target="sect-6.6" format="default"/>, because the CRL is considered missing.</t>
      <section title="Manifest anchor="sect-6.1" numbered="true" toc="default">
        <name>Manifest Processing Overview" anchor="sect-6.1"><t> Overview</name>
        <t>
        For a given publication point, an RP MUST <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&nbsp;<xref target="sect-6.2" format="counter"/> through <xref target="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 manifest MUST <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
           references MUST <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 the manifest manifest, the RP MUST <bcp14>MUST</bcp14> treat the
           fetch as failed, and a warning MUST <bcp14>MUST</bcp14> be issued (see <xref target="sect-6.6"/> target="sect-6.6" format="default"/>
           below).</t>
        <t>
        Note that, during CA key rollover <xref target="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>
      <section title="Acquiring anchor="sect-6.2" numbered="true" toc="default">
        <name>Acquiring a Manifest for a CA" anchor="sect-6.2"><t> CA</name>
        <t>

   The RP MUST <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 this URI, URI or if the manifest is not valid
      (<xref target="sect-4.4"/>), target="sect-4.4" format="default"/>), an RP MUST <bcp14>MUST</bcp14> treat this as a failed fetch and proceed
      to <xref target="sect-6.6"/>; otherwise target="sect-6.6" format="default"/>; otherwise, proceed to <xref target="sect-6.3"/>.</t>

	</section>

	<section title="Detecting Stale target="sect-6.3" format="default"/>.</t>

<!-- [rfced] Sections 6.2 through 6.5:  "an RP MUST treat this as a
failed fetch and proceed to Section 6.6" and "... RP MUST proceed to
Section 6.6" read oddly, as it appears to us that the reader and not
the RP should proceed to the section in question.  If the suggested
text is not correct, please clarify.  (If you approve the suggested
text, we will ask for AD approval related to usage of the key word
"MUST".)

Original:
 If an RP cannot retrieve a
 manifest using this URI, or if the manifest is not valid
 (Section 4.4), an RP MUST treat this as a failed fetch and proceed to
 Section 6.6; otherwise proceed to Section 6.3.
...
 If the current time is
 earlier than thisUpdate, the CA may have made an error or the RP's
 local notion of time may be in error; the RP MUST treat this as a
 failed fetch and proceed to Section 6.6.  If the current time is
 later than nextUpdate, then the manifest is stale; this is a failed
 fetch and RP MUST proceed to Section 6.6; otherwise proceed to
 Section 6.4.
...
 If there are files listed in
 the manifest that cannot be retrieved from the publication point, the
 fetch has failed and the RP MUST proceed to Section 6.6; otherwise,
 proceed to Section 6.5.
...
 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 has failed and the RP MUST proceed to
 Section 6.6.

Suggested:
 If an RP cannot retrieve a
 manifest using this URI or if the manifest is not valid
 (Section 4.4), an RP MUST treat this as a failed fetch; proceed to
 Section 6.6.  Otherwise, proceed to Section 6.3.
...
 If the current time lies within
 this interval, proceed to Section 6.4.  If the current time is
 earlier than thisUpdate, the CA may have made an error or Prematurely-issued Manifests" anchor="sect-6.3"><t> the RP's
 local notion of time may be in error.  The RP MUST treat this as a
 failed fetch; proceed to Section 6.6.  If the current time is
 later than nextUpdate, then the manifest is stale; the RP MUST treat
 this as a failed fetch.  Proceed to Section 6.6.  Otherwise, proceed
 to Section 6.4.
...
 If there are files listed in
 the manifest that cannot 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.
...
 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 has failed, and the RP MUST respond
 accordingly.  Proceed to Section 6.6. -->

      </section>
      <section anchor="sect-6.3" numbered="true" toc="default">
        <name>Detecting Stale and/or Prematurely Issued Manifests</name>
        <t>
        The RP <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 <xref target="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 the RP’s RP's local notion of time may be in error; the RP MUST <bcp14>MUST</bcp14> treat this as a failed fetch and proceed to <xref target="sect-6.6"/>. target="sect-6.6" format="default"/>.  If the current time is
           later than nextUpdate, then the manifest is stale; this is a failed
           fetch
           fetch, and the RP MUST <bcp14>MUST</bcp14> proceed to <xref target="sect-6.6"/>; otherwise target="sect-6.6" format="default"/>; otherwise, proceed to <xref target="sect-6.4"/>.</t> target="sect-6.4" format="default"/>.</t>
      </section>
      <section title="Acquiring anchor="sect-6.4" numbered="true" toc="default">
        <name>Acquiring Files Referenced by a Manifest" anchor="sect-6.4"><t> Manifest</name>
        <t>

   The RP MUST <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, the
      fetch has failed and the RP MUST <bcp14>MUST</bcp14> proceed to <xref target="sect-6.6"/>; target="sect-6.6" format="default"/>; otherwise,
      proceed to <xref target="sect-6.5"/>.</t> target="sect-6.5" format="default"/>.</t>
      </section>
      <section title="Matching anchor="sect-6.5" numbered="true" toc="default">
        <name>Matching File Names and Hashes" anchor="sect-6.5"><t> Hashes</name>
        <t>

   The RP MUST <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 has failed and the RP MUST <bcp14>MUST</bcp14> proceed to
      <xref target="sect-6.6"/>.</t> target="sect-6.6" format="default"/>.</t>
      </section>
      <section title="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 in 6.2-6.5, Sections&nbsp;<xref target="sect-6.2" format="counter"/> through <xref target="sect-6.5" format="counter"/>, the RP MUST <bcp14>MUST</bcp14> issue a warning indicating the reason(s) for termination of processing with regard to this CA instance.
        It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that a human operator be notified of this warning.
        </t>
        <t>
        Termination of processing means that the RP SHOULD <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 RP MUST 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>
    <section title="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 more CAs, CAs and be non-empty.  Upon
   creation of the publication point associated with a CA, the CA MUST <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 <xref target="RFC6481"/>,corresponding target="RFC6481" format="default"/>, corresponding to the scope of this manifest.</t>
      <t>
   Every published signed object in the RPKI <xref target="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>
    <section title="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 RP to determine in 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
   value allows allow an RP to determine if the manifest itself is the subject
   of attempted alteration.  The requirement for every repository
   publication point to contain at least one manifest allows an RP to
   determine if the manifest itself has been occluded from view.  Such
   attacks against the manifest are detectable within the time frame of
   the regular schedule of manifest updates.  Forms of replay attack attacks
   within finer-grained time frames are not necessarily detectable by
   the manifest structure.</t>
    </section>

    <section title="IANA Considerations" anchor="sect-9"><t>
   As anchor="sect-9" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>
 The "RPKI Signed Objects" registry was originally created and populated
 by <xref target="RFC6488" format="default"/>.  The "RPKI Repository
 Name Schemes" registry was created by <xref target="RFC6488"/> target="RFC6481"/> and
 created four of the initial three-letter filename extensions.
 IANA has updated the reference for Manifest in the "RPKI Signed Objects"
 registry to point to this document.  No other actions are are required.
      </t>

<!-- [rfced] IANA Considerations:  Per
<https://www.iana.org/assignments/rpki/>, the "RPKI Repository Name
Schemes" registry was created by RFC 6481 (not RFC 6488).  Also,
RFC 6488 does not mention the "RPKI Repository Name Schemes" registry.
We updated this sentence as follows.  Please let us know any
objections.

Original ('"RPKI Signed Object"' has been corrected):
 As [RFC6488] created and populated the registries "RPKI Signed
 Object" and three-letter filename extensions for "RPKI Repository
 Name Schemes," no new action is requested of the IANA.</t>

	</section>

	<section title="Acknowledgements" anchor="sect-10"><t> IANA.

Currently:
 The authors would like to acknowledge the contributions from George Michelson "RPKI Signed Objects" registry was originally created and Randy Bush in the preparation populated
 by [RFC6488].  The "RPKI Repository Name Schemes" registry was created
 by [RFC6481] and created four of the manifest specification.
   Additionally, initial three-letter filename extensions.
 IANA has updated the authors would like to thank Mark Reynolds and Christopher Small reference for assistance Manifest in clarifying manifest validation and RP behavior.
   The authors also wish the "RPKI Signed Objects"
 registry to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, Lars Eggert, Robert Wilton, and Benjamin Kaduk point to this document.  No other actions are are requested.

It is unclear whether "No other actions are requested" is correct, as IANA made updates to other reference entries.  Please consider whether they should be listed here.  For example:

IANA has updated the following entries to refer to this document instead of RFC 6486:

- id-mod-rpkiManifest (60) in the "SMI Security for their helpful review 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 of this document.</t> the application media type registration for rpki-manifest
-->

    </section>
  </middle>
  <back>
	<references title="Normative References">
    <references>

<!-- [rfced] Would you like to list the references in
alphanumeric order? -->

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

<!-- [rfced] Normative References:  The provided URL steers to a page
marked with "Status : Superseded".  Because the citation appears to
be general in nature, we updated this listing.  Please let us know any
objections.

Original:
 [X.690]    "X.690",
             <https://www.itu.int/rec/T-REC-X.690-199511-S!Cor1>.

Currently:
 [X.690]    International Telecommunication Union, "Information
            technology - ASN.1 encoding rules: Specification of Basic
            Encoding Rules (BER), Canonical Encoding Rules (CER) and
            Distinguished Encoding Rules (DER)", ITU-T Recommendation
            X.690, February 2021,
            <https://www.itu.int/rec/T-REC-X.690-202102-I/en>. -->

      </references>
      <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 title="Informative References">
	&RFC5652;
	&RFC3779;
	&RFC6480;
	&RFC6486;
	&RFC6489;
    </references>
    <section title="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) TBD }
]]></sourcecode>

<!-- [rfced] Appendix A:  IANA has confirmed the assignment of value
"60" for RPKIManifest, as seen in RFC 6486, and they have replaced
the reference to RFC 6486 with a pointer to this document (see
"ACTION 2" below).  Should the TBD below be replaced with 60?

Please search for "id-mod-rpkiManifest" on
<https://www.iana.org/assignments/smi-numbers/>, and advise.

Original:
 RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
                pkcs(1) pkcs9(9) smime(16) mod(0) TBD }
]]></artwork>
    </figure>
    <figure><artwork><![CDATA[

From the IANA email sent to the RFC Editor in April 2022:
ACTION 2:

In the SMI Security for S/MIME Module Identifier
(1.2.840.113549.1.9.16.0) registry, we've replaced this
registration's reference to RFC 6486 with a reference to
this document:

60 id-mod-rpkiManifest [RFC-ietf-sidrops-6486bis-11]

Please see
https://www.iana.org/assignments/smi-numbers -->

      <sourcecode type="asn.1"><![CDATA[
    DEFINITIONS EXPLICIT TAGS ::=
       BEGIN

       -- EXPORTS ALL --

       IMPORTS

         CONTENT-TYPE
         FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
           { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
             pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;

       -- Manifest Content Type

       ct-rpkiManifest CONTENT-TYPE ::=
           { TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }

       id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
           us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }

       id-ct OBJECT IDENTIFIER ::= { id-smime 1 }

       id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }

       Manifest ::= SEQUENCE {
          version        [0] INTEGER DEFAULT 0,
          manifestNumber     INTEGER (0..MAX),
          thisUpdate         GeneralizedTime,
          nextUpdate         GeneralizedTime,
          fileHashAlg        OBJECT IDENTIFIER,
          fileList           SEQUENCE SIZE (0..MAX) OF FileAndHash
          }

       FileAndHash ::= SEQUENCE {
          file  IA5String,
          hash  BIT STRING
          }

       END

]]></artwork>
    </figure>
]]></sourcecode>

<!-- [rfced] Appendix A:  We see that RFC 6268 is not cited anywhere
in this document or listed in the References section.  Would you like
to cite it somewhere in text?  If yes, should RFC 6268 be listed as
a Normative Reference or Informative?  If you do not wish to cite it
anywhere, may we change "in [RFC6268]" to "in RFC 6268"?

Original (double dash modified so that xml2rfc doesn't confuse it
  with a comment):
 FROM CryptographicMessageSyntax-2010 - in [RFC6268] -->

    </section>
    <section title="Changes anchor="sect-b" numbered="true" toc="default">
      <name>Changes since RFC 6486" anchor="sect-b"> 6486</name>
      <t>
       In 2019, it came to light that multiple Relying Party RP implementations
       were in a vulnerable position, possibly due to perceived ambiguity in
       the original <xref target="RFC6486"/> target="RFC6486" format="default"/> specification.
       This document attempts to clarify the innovative concept and application
       of RPKI Manifests manifests 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" EE certificates, certificates and instead mandate mandating "one-time-use"
          EE certificates.
       </t>
       <t>
	 Clarify
       </li>
        <li>
	 Clarifying that Manifest manifest EE certificates are to be issued with a validity
	 period which that coincides with the interval specified in the Manifest manifest
         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 issuers to coincidence coincide the applicable CRL's nextUpdate
         with the Manifest's manifest's nextUpdate.
       </t>
       <t>
	 The
       </li>
        <li>
	 Constraining the set of valid characters in FileAndHash filenames was constrained.
       </t>
       <t>
         Clarifications filenames.
       </li>
        <li>
         Clarifying that an RP unable to obtain the full set of files listed
         on a Manifest manifest 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>

<!-- [rfced] Appendix B:  We changed "CA issuers to coincidence the"
to "CA issuers coincide the".  If this update is incorrect, please
clarify "to coincidence".

Original:
 *  Recommend CA issuers to coincidence the applicable CRL's
    nextUpdate with the Manifest's nextUpdate.

Currently:
 *  Recommending that CA issuers coincide the applicable CRL's
    nextUpdate with the manifest's nextUpdate. -->

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

<!-- [rfced] Acknowledgements:  As RFCs 6486 and 8914 are the only
RFCs to date that use the spelling "George Michelson", we changed it
to "George Michaelson" per RFCs 6481, 6487, 6489, and 7935.  In addition,
it matches what appears in the datatracker <https://datatracker.ietf.org/person/George%20G.%20Michaelson>.
Please let us know any concerns.

Original:
 The authors would like to acknowledge the contributions from George
 Michelson and Randy Bush in the preparation of the manifest
 specification.

Currently:
 The authors would like to acknowledge the contributions from George
 Michaelson and Randy Bush in the preparation of the manifest
 specification. -->

    </section>
  </back>

<!-- [rfced] Please review the "Inclusive Language" portion of the
online Style Guide at
<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
and let us know if any changes are needed. Note that our script did not
flag any terms. -->

<!-- [rfced] Please let us know if any changes are needed for the
following:

a) The following terms were used inconsistently in this document.
We chose to use the latter forms.  Please let us know any objections.

 Manifest (approx. 16 instances in running text; introduced in this
   document (and resulting in, for example, "the manifest" and
   "the Manifest") /
   manifest (more than 100 instances in running text)
   (per RFC 6486, which uses consistent capitalization)

 ManifestNumber (1 instance in text) /
   manifestNumber (7 instances in text)*

 * "... the
    ManifestNumber is analogous to the CRLNumber, and the guidance in
    [RFC5280] for CRLNumber values is appropriate as to the range of
    number values that can be used for the manifestNumber."

    (We also see one instance of "ManifestNumber" in RFC 6486, but it
     appears to be an oversight.)

b) The following terms appear to be used inconsistently in this
document.  Please let us know which form is preferred.

 access method / accessMethod
   ("access method Object Identifier (OID) of id-ad-signedObject",
    "accessMethod OID value of id-ad-signedobject")

 file name / filename -->

</rfc>

mirror server hosted at Truenetwork, Russian Federation.