rfc9286xml2.original.xml   rfc9286.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.2119.xml">
<!ENTITY RFC5280 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5280.xml">
<!ENTITY RFC6481 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6481.xml">
<!ENTITY RFC6482 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6482.xml">
<!ENTITY RFC7935 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7935.xml">
<!ENTITY RFC6487 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6487.xml">
<!ENTITY RFC6488 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6488.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC5652 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.5652.xml">
<!ENTITY RFC3779 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.3779.xml">
<!ENTITY RFC6480 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6480.xml">
<!ENTITY RFC6486 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refere
nce.RFC.6486.xml">
<!ENTITY RFC6489 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6489.xml">
]>
<rfc submissionType="IETF" docName="draft-ietf-sidrops-6486bis-11" category="std
" obsoletes="6486" ipr="trust200902" consensus="true">
<!-- 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 Infr
astructure (RPKI)</title>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Arrcus, Inc.</organization>
<address><email>sra@hactrn.net</email>
</address>
</author>
<author initials="G." surname="Huston" fullname="Geoff Huston"> <!DOCTYPE rfc [
<organization>APNIC</organization> <!ENTITY nbsp "&#160;">
<address><postal><street>6 Cordelia St</street> <!ENTITY zwsp "&#8203;">
<street>South Brisbane QLD 4101</street> <!ENTITY nbhy "&#8209;">
<street>Australia</street> <!ENTITY wj "&#8288;">
</postal> ]>
<email>gih@apnic.net</email>
</address>
</author>
<author initials="S." surname="Kent" fullname="Stephen Kent"> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-sidrops-6486
<organization>Independent</organization> bis-11" number="9286" submissionType="IETF" consensus="true" category="std" obso
<address><email>kent@alum.mit.edu</email> letes="6486" ipr="trust200902" updates="" xml:lang="en" symRefs="true" sortRefs=
</address> "false" tocInclude="true" version="3">
</author>
<author initials="M." surname="Lepinski" fullname="Matt Lepinski"> <!-- xml2rfc v2v3 conversion 3.12.2 -->
<organization>New College Florida</organization> <!-- Generated by id2xml 1.5.0 on 2021-05-31T14:49:22Z -->
<address><postal><street>5800 Bay Shore Rd.</street> <front>
<street>Sarasota, FL 34243</street> <title abbrev="RPKI Manifests">Manifests for the Resource Public Key Infrast
<street>USA</street> ructure (RPKI)</title>
</postal> <seriesInfo name="RFC" value="9286"/>
<email>mlepinski@ncf.edu</email> <author initials="R." surname="Austein" fullname="Rob Austein">
</address> <organization>Arrcus, Inc.</organization>
</author> <address>
<email>sra@hactrn.net</email>
</address>
</author>
<author initials="G." surname="Huston" fullname="Geoff Huston">
<organization>APNIC</organization>
<address>
<postal>
<street>6 Cordelia St</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>
</author>
<author initials="M." surname="Lepinski" fullname="Matt Lepinski">
<organization>New College Florida</organization>
<address>
<postal>
<street>5800 Bay Shore Rd.</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 year="2022" month="May" />
<area>ops</area>
<workgroup>sidrops</workgroup>
<date/> <!-- [rfced] Please insert any keywords (beyond those that appear in the
<area>Routing Area</area> title) for use on <https://www.rfc-editor.org/search>. -->
<workgroup>SIDROPS</workgroup>
<abstract><t> <abstract>
<t>
This document defines a "manifest" for use in the Resource Public Key Infrast ructure (RPKI). This document defines a "manifest" for use in the Resource Public Key Infrast ructure (RPKI).
A manifest is a signed object (file) that contains a listing of all the signe d objects (files) in the repository publication point (directory) associated wit h an authority responsible for publishing in the repository. A manifest is a signed object (file) that contains a listing of all the signe d objects (files) in the repository publication point (directory) associated wit h an authority responsible for publishing in the repository.
For each certificate, Certificate Revocation List (CRL), or other type of sig ned objects issued by the authority that are published at this repository public ation point, the manifest contains both the name of the file containing the obje ct and a hash of the file content. For each certificate, Certificate Revocation List (CRL), or other type of sig ned objects issued by the authority that are published at this repository public ation point, the manifest contains both the name of the file containing the obje ct 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. 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 object s retrieved from a repository publication point, then the RP can detect replay a ttacks, and unauthorized in-flight modification or deletion of signed objects. Specifically, if an RP checks a manifest's contents against the signed object s retrieved from a repository publication point, then the RP can detect replay a ttacks, and unauthorized in-flight modification or deletion of signed objects.
This document obsoletes RFC 6486. This document obsoletes RFC 6486.
</t> </t>
</abstract>
</abstract> </front>
</front> <middle>
<section anchor="sect-1" numbered="true" toc="default">
<middle> <name>Introduction</name>
<section title="Introduction" anchor="sect-1"><t> <t>
The Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"/> makes The Resource Public Key Infrastructure (RPKI) <xref target="RFC6480" format="
use of a distributed repository system <xref target="RFC6481"/> to make availabl default"/> makes use of a distributed repository system <xref target="RFC6481" f
e a variety of objects needed by relying parties (RPs). ormat="default"/> to make available a variety of objects needed by relying parti
es (RPs).
Because all of the objects stored in the repository system are digitally sign ed by the entities that created them, attacks that modify these published object s are detectable by RPs. Because all of the objects stored in the repository system are digitally sign ed by the entities that created them, attacks that modify these published object s 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 tha t remove an object that should be present in the repository. 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 tha t 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". To assist in the detection of such attacks, RPKI repository systems make use of a signed object called a "manifest".
</t> </t>
<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 aut hority responsible for publishing at that publication point. A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an aut hority 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 i s published at the authority's repository 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 i s 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 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 m ay result from an on-path attack during the retrieval of objects from the reposi tory. A manifest also is intended to allow an RP to detect similar outcomes that m ay result from an on-path attack during the retrieval of objects from the reposi tory.
Manifests are intended to be used in Certification Authority (CA) publicatio n points in repositories (directories containing files that are subordinate cert ificates and Certificate Revocation Lists (CRLs) issued by this CA and other sig ned objects that are verified by End-Entity (EE) certificates issued by this CA) . Manifests are intended to be used in Certification Authority (CA) publicatio n points in repositories (directories containing files that are subordinate cert ificates and Certificate Revocation Lists (CRLs) issued by this CA and other sig ned objects that are verified by End-Entity (EE) certificates issued by this CA) .
</t> </t>
<t>
<t>
Manifests are modeled on CRLs, as the issues involved in detecting Manifests are modeled on CRLs, as the issues involved in detecting
stale manifests and potential attacks using manifest replays, etc., stale manifests and potential attacks using manifest replays, etc.,
are similar to those for CRLs. The syntax of the manifest payload are similar to those for CRLs. The syntax of the manifest payload
differs from CRLs, since RPKI repositories contain objects not differs from CRLs, since RPKI repositories contain objects not
covered by CRLs, e.g., digitally signed objects, such as Route covered by CRLs, e.g., digitally signed objects, such as Route
Origination Authorizations (ROAs) <xref target="RFC6482"/>.</t> Origin Authorizations (ROAs) <xref target="RFC6482" format="default"/>.</t>
<t>This document obsoletes <xref target="RFC6486" format="default"/>.</t>
<t>This document obsoletes <xref target="RFC6486"/>.</t> <section anchor="sect-1.1" numbered="true" toc="default">
<name>Requirements Language</name>
<section title="Requirements Language" anchor="sect-1.1"><t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
"OPTIONAL" in this document are to be interpreted as described in BCP "<bcp14>SHOULD NOT</bcp14>",
14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, the "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
y appear in all "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
capitals, as shown here.</t> are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
</section> when, they appear in all capitals, as shown here.</t>
</section>
</section> </section>
<section anchor="sect-2" numbered="true" toc="default">
<section title="Manifest Scope" anchor="sect-2"><t> <name>Manifest Scope</name>
<t>
A manifest associated with a CA's repository publication point A manifest associated with a CA's repository publication point
contains a list of:</t> contains a list of:</t>
<ul spacing="normal">
<t><list style="symbols"><t>the set of (non-expired, non-revoked) certifi <li>the set of (non-expired, non-revoked) certificates issued and
cates issued and published by this CA,</li>
published by this CA,</t> <li>the most recent CRL issued by this CA, and</li>
<li>all published signed objects that are verifiable using EE
<t>the most recent CRL issued by this CA, and</t> certificates <xref target="RFC6487" format="default"/> issued by this CA (
other than the manifest itself).</li>
<t>all published signed objects that are verifiable using EE </ul>
certificates <xref target="RFC6487"/> issued by this CA (other than the ma <t>
nifest itself).</t>
</list>
</t>
<t>
Every RPKI signed object includes, in the Cryptographic Message Every RPKI signed object includes, in the Cryptographic Message
Syntax (CMS) <xref target="RFC5652"/> wrapper of the object, the EE certifica Syntax (CMS) <xref target="RFC5652" format="default"/> wrapper of the object,
te used the EE certificate used
to verify it <xref target="RFC6488"/>. Thus, there is no requirement to sepa to verify it <xref target="RFC6488" format="default"/>. Thus, there is no re
rately quirement to separately
publish that EE certificate at the CA's repository publication point.</t> publish that EE certificate at the CA's repository publication point.</t>
<t>
<t>
Where multiple CA instances share a common publication point, as can Where multiple CA instances share a common publication point, as can
occur when a CA performs a key-rollover operation <xref target="RFC6489"/>, t he occur when a CA performs a key-rollover operation <xref target="RFC6489" form at="default"/>, the
repository publication point will contain multiple manifests. In repository publication point will contain multiple manifests. In
this case, each manifest describes only the collection of published this case, each manifest describes only the collection of published
products of its associated CA instance.</t> products of its associated CA instance.</t>
</section>
</section> <section anchor="sect-3" numbered="true" toc="default">
<name>Manifest Signing</name>
<section title="Manifest Signing" anchor="sect-3"><t> <t>
A CA's manifest is verified using an EE certificate. The A CA's manifest is verified using an EE certificate. The
SubjectInfoAccess (SIA) field of this EE certificate contains the SubjectInfoAccess (SIA) field of this EE certificate contains the
access method Object Identifier (OID) of id-ad-signedObject.</t> access method Object Identifier (OID) of id-ad-signedObject.</t>
<t>
<t> The CA <bcp14>MUST</bcp14> sign only one manifest with each generated private
The CA MUST sign only one manifest with each generated private key, and MUST key and <bcp14>MUST</bcp14> generate a new key pair for each new version of the
generate a new key pair for each new version of the manifest. manifest.
This form of use of the associated EE certificate is termed a "one-time-use" An associated EE certificate used in this fashion is termed a "one-time-use"
EE certificate <xref target="RFC6487"/>.</t> EE certificate (see <xref target="RFC6487" sectionFormat="of" section="3"/>).</t
>
</section> </section>
<section anchor="sect-4" numbered="true" toc="default">
<section title="Manifest Definition" anchor="sect-4"><t> <name>Manifest Definition</name>
A manifest is an RPKI signed object, as specified in <xref target="RFC6488"/> <t>
. The A manifest is an RPKI signed object, as specified in <xref target="RFC6488" f
ormat="default"/>. The
RPKI signed object template requires specification of the following RPKI signed object template requires specification of the following
data elements in the context of the manifest structure.</t> data elements in the context of the manifest structure.</t>
<section anchor="sect-4.1" numbered="true" toc="default">
<section title="eContentType" anchor="sect-4.1"><t> <name>eContentType</name>
<t>
The eContentType for a manifest is defined as id-ct-rpkiManifest and The eContentType for a manifest is defined as id-ct-rpkiManifest and
has the numerical object identifier of 1.2.840.113549.1.9.16.1.26.</t> has the numerical OID of 1.2.840.113549.1.9.16.1.26.</t>
<sourcecode type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 } rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
]]></artwork> ]]></sourcecode>
</figure>
</section>
<section title="eContent" anchor="sect-4.2"><t> <!-- [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 anchor="sect-4.2" numbered="true" toc="default">
<name>eContent</name>
<t>
The content of a manifest is ASN.1 encoded using the Distinguished The content of a manifest is ASN.1 encoded using the Distinguished
Encoding Rules (DER) <xref target="X.690"/>. The content of a manifest is de fined Encoding Rules (DER) <xref target="X.690" format="default"/>. The content of a manifest is defined
as follows:</t> as follows:</t>
<sourcecode type="asn.1"><![CDATA[
<figure><artwork><![CDATA[
Manifest ::= SEQUENCE { Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0, version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX), manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime, thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime, nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER, fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
} }
FileAndHash ::= SEQUENCE { FileAndHash ::= SEQUENCE {
file IA5String, file IA5String,
hash BIT STRING hash BIT STRING
} }
]]></artwork> ]]></sourcecode>
</figure> <section anchor="sect-4.2.1" numbered="true" toc="default">
<section title="Manifest" anchor="sect-4.2.1"><t> <name>Manifest</name>
<t>
The manifestNumber, thisUpdate, and nextUpdate fields are modeled The manifestNumber, thisUpdate, and nextUpdate fields are modeled
after the corresponding fields in X.509 CRLs (see <xref target="RFC5280"/>). after the corresponding fields in X.509 CRLs (see <xref target="RFC5280" form at="default"/>).
Analogous to CRLs, a manifest is nominally current until the time Analogous to CRLs, a manifest is nominally current until the time
specified in nextUpdate or until a manifest is issued with a greater specified in nextUpdate or until a manifest is issued with a greater
manifest number, whichever comes first.</t> manifest number, whichever comes first.</t>
<t>
<t> Because a "one-time-use" EE certificate is employed to verify a manifest, the
Because a "one-time-use" EE certificate is employed to verify a manifest, the EE certificate <bcp14>MUST</bcp14> be issued with a validity period that coinci
EE certificate MUST be issued with a validity period that coincides with the in des with the interval from thisUpdate to nextUpdate in the manifest, to prevent
terval from thisUpdate to nextUpdate in the manifest, to prevent needless growth needless growth of the CA's CRL.
of the CA's CRL. </t>
</t> <t>
<t>
The data elements of the manifest structure are defined as follows:</t> The data elements of the manifest structure are defined as follows:</t>
<dl newline="true" spacing="normal" indent="3">
<t><list style="hanging" hangIndent="3"><t hangText="version:"> <dt>version:</dt>
<vspace blankLines="0"/> <dd>
The version number of this version of the manifest specification The version number of this version of the manifest specification
MUST be 0. <bcp14>MUST</bcp14> be 0.
</t> </dd>
<dt>manifestNumber:</dt>
<t hangText="manifestNumber:"> <dd>
<vspace blankLines="0"/> <t>
This field is an integer that is incremented (by 1) each time a new This field is an integer that is incremented (by 1) each time a new
manifest is issued for a given publication point. This field manifest is issued for a given publication point. This field
allows an RP to detect gaps in a sequence of published manifests. allows an RP to detect gaps in a sequence of published manifests.
<vspace blankLines="1"/> </t>
As the manifest is modeled on the CRL specification, the ManifestNumber is <t>
analogous to the CRLNumber, and the guidance in <xref target="RFC5280"/> for CR As the manifest is modeled on the CRL specification, the manifestNumber is
LNumber values is appropriate as to the range of number values that can be used analogous to the CRLNumber, and the guidance in <xref target="RFC5280" format="
for the manifestNumber. 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 numbers can be expected to contain long integers.
Manifest verifiers MUST be able to process number values up to 20 octets. Manifest verifiers <bcp14>MUST</bcp14> be able to process number values up
Conforming manifest issuers MUST NOT use number values longer than 20 octe to 20 octets.
ts. Conforming manifest issuers <bcp14>MUST NOT</bcp14> use number values long
The issuer MUST increase the value of this field monotonically for each ne er than 20 octets.
wly-generated Manifest. The issuer <bcp14>MUST</bcp14> increase the value of this field monotonica
Each RP MUST verify that a purported "new" Manifest contains a higher mani lly for each newly generated manifest.
festNumber than previously-validated Manifests. Each RP <bcp14>MUST</bcp14> verify that a purported "new" manifest contain
If the purported "new" Manifest contains an equal or lower manifestNumber s a higher manifestNumber than previously validated manifests.
than previously-validated Manifests, the RP SHOULD use locally cached versions o If the purported "new" manifest contains a manifestNumber value equal to o
f objects, as described in <xref target="sect-6.6"/>. r lower than manifestNumber values of previously validated manifests, the RP <bc
</t> p14>SHOULD</bcp14> use locally cached versions of objects, as described in <xref
target="sect-6.6" format="default"/>.
<t hangText="thisUpdate:"> </t>
<vspace blankLines="0"/> </dd>
<dt>thisUpdate:</dt>
<dd>
This field contains the time when the manifest was created. This field contains the time when the manifest was created.
This field has the same format constraints as specified in <xref target="R This field has the same format constraints as specified in <xref target="R
FC5280"/> for the CRL field of the same name. FC5280" format="default"/> for the CRL field of the same name.
The issuer MUST ensure that the value of this field is more recent than an The issuer <bcp14>MUST</bcp14> ensure that the value of this field is more
y previously-generated Manifest. recent than any previously generated manifest.
Each RP MUST verify that this field value is greater (more recent) than th Each RP <bcp14>MUST</bcp14> verify that this field value is greater (more
e most recent Manifest it has validated. recent) than the most recent manifest it has validated.
If this field in a purported "new" Manifest is smaller (less recent) than If this field in a purported "new" manifest is smaller (less recent) than
previously-validated Manifests, the RP SHOULD use locally cached versions of obj previously validated manifests, the RP <bcp14>SHOULD</bcp14> use locally cached
ects, as described in <xref target="sect-6.6"/>. versions of objects, as described in <xref target="sect-6.6" format="default"/>.
</t> </dd>
<dt>nextUpdate:</dt>
<t hangText="nextUpdate:"> <dd>
<vspace blankLines="0"/> <t>
This field contains the time at which the next scheduled manifest This field contains the time at which the next scheduled manifest
will be issued. The value of nextUpdate MUST be later than the will be issued. The value of nextUpdate <bcp14>MUST</bcp14> be later than the
value of thisUpdate. The specification of the GeneralizedTime value of thisUpdate. The specification of the GeneralizedTime
value is the same as required for the thisUpdate field. 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 If the authority alters any of the items that it has published in
the repository publication point, then the authority MUST issue a the repository publication point, then the authority <bcp14>MUST</bcp14> i ssue a
new manifest. Even if no changes are made to objects at a new manifest. Even if no changes are made to objects at a
publication point, a new manifest MUST be issued before the nextUpdate publication point, a new manifest <bcp14>MUST</bcp14> be issued before the
time. Each manifest encompasses a CRL, and the nextUpdate field of the man nextUpdate
ifest SHOULD match time. Each manifest encompasses a CRL, and the nextUpdate field of the man
that of the CRL's nextUpdate field, as the manifest will be re-issued when ifest <bcp14>SHOULD</bcp14> match
a new CRL is published. that of the CRL's nextUpdate field, as the manifest will be reissued when
a new CRL is published.
When a new manifest is issued before the time specified in nextUpdate of t he When a new manifest is issued before the time specified in nextUpdate of t he
current manifest, the CA MUST also issue a new CRL that revokes current manifest, the CA <bcp14>MUST</bcp14> also issue a new CRL that rev okes
the EE certificate corresponding to the old manifest. the EE certificate corresponding to the old manifest.
</t> </t>
</dd>
<t hangText="fileHashAlg:"> <dt>fileHashAlg:</dt>
<vspace blankLines="0"/> <dd>
This field contains the OID of the hash algorithm used to hash the This field contains the OID of the hash algorithm used to hash the
files that the authority has placed into the repository. The hash files that the authority has placed into the repository. The hash
algorithm used MUST conform to the RPKI Algorithms and Key Size algorithm used <bcp14>MUST</bcp14> conform to the RPKI Algorithms and Key
Profile specification <xref target="RFC7935"/>. Size
</t> Profile specification <xref target="RFC7935" format="default"/>.
</dd>
<t hangText="fileList:"> <dt>fileList:</dt>
<vspace blankLines="0"/> <dd>
This field is a sequence of FileAndHash objects. There is one This field is a sequence of FileAndHash objects. There is one
FileAndHash entry for each currently valid signed object that has FileAndHash entry for each currently valid signed object that has
been published by the authority (at this publication point). Each been published by the authority (at this publication point). Each
FileAndHash is an ordered pair consisting of the name of the file FileAndHash is an ordered pair consisting of the name of the file
in the repository publication point (directory) that contains the in the repository publication point (directory) that contains the
object in question and a hash of the file's contents. object in question and a hash of the file's contents.
</t> </dd>
</dl>
</list> </section>
</t> <section anchor="sect-4.2.2" numbered="true" toc="default">
<name>Names in FileAndHash Objects</name>
</section> <t>
Names that appear in the fileList <bcp14>MUST</bcp14> consist of one or more
<section title="Names in FileAndHash objects" anchor="sect-4.2.2"><t>
Names that appear in the fileList MUST consist of one or more
characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _
(UNDERSCORE), followed by a single . (DOT), followed by a three- (UNDERSCORE), followed by a single . (DOT), followed by a three-
letter extension. The extension MUST be one of those enumerated in letter extension. The extension <bcp14>MUST</bcp14> be one of those enumerat
the "RPKI Repository Naming Scheme" registry maintained by IANA ed in
<xref target="IANA-NAMING"/>.</t> the "RPKI Repository Name Scheme" registry maintained by IANA
<xref target="IANA-NAMING" format="default"/>.</t>
<t> <t>
As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.</t> As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.</t>
<t>
<t> The example above contains a mix of uppercase and lowercase characters in the
The example above contains a mix of uppercase and lowercase characters in the filename. CAs and RPs <bcp14>MUST</bcp14> be able to perform filesystem operati
filename. CAs and RPs MUST be able to perform filesystem operations in a case-s ons in a case-sensitive, case-preserving manner.</t>
ensitive, case-preserving manner.</t> </section>
</section>
</section> <section anchor="sect-4.3" numbered="true" toc="default">
<name>Content-Type Attribute</name>
</section> <t>
The mandatory content-type attribute <bcp14>MUST</bcp14> have its attrValues
<section title="Content-Type Attribute" anchor="sect-4.3"><t> field
The mandatory content-type attribute MUST have its attrValues field
set to the same OID as eContentType. This OID is id-ct-rpkiManifest 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> and has the numerical value of 1.2.840.113549.1.9.16.1.26.</t>
</section>
<section anchor="sect-4.4" numbered="true" toc="default">
<name>Manifest Validation</name>
<t>
To determine whether a manifest is valid, the RP <bcp14>MUST</bcp14> perform
the
following checks in addition to those specified in <xref target="RFC6488" for
mat="default"/>:</t>
<ol spacing="normal" type="1"><li>The eContentType in the EncapsulatedCo
ntentInfo is id-ad-
rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).</li>
</section> <!-- [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.
<section title="Manifest Validation" anchor="sect-4.4"><t> We also see this value in Section 4.4 of RFC 6486, but please
To determine whether a manifest is valid, the RP MUST perform the see Section 4.8.8.1 of RFC 6487, search
following checks in addition to those specified in <xref target="RFC6488"/>:< <https://www.iana.org/assignments/smi-numbers/> for
/t> "id-ad-rpkiManifest" (we see 1.3.6.1.5.5.7.48.10 there), and
advise.
<t><list style="numbers"><t>The eContentType in the EncapsulatedContentIn If any changes related to the OID are needed, we also suggest
fo is id-ad- adding a corresponding entry in Appendix B, as there are no errata
rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).</t> reported for RFC 6486 to date.
<t>The version of the rpkiManifest is 0.</t> Original:
1. The eContentType in the EncapsulatedContentInfo is id-ad-
rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). -->
<t>In the rpkiManifest, thisUpdate precedes nextUpdate.</t> <li>The version of the rpkiManifest is 0.</li>
</list> <li>In the rpkiManifest, thisUpdate precedes nextUpdate.</li>
</t> </ol>
<t>Note: Although the thisUpdate and nextUpdate fields in the manifest e
Content <bcp14>MUST</bcp14> match the corresponding fields in the CRL associated
with the manifest, RPs <bcp14>MUST NOT</bcp14> reject a manifest solely because
these fields are not identical.</t>
<t>Note: Although the thisUpdate and nextUpdate fields in the Manifest eCont <!-- [rfced] Section 4.4: Please review whether the "Note:"
ent MUST match the corresponding fields in the CRL associated with the Manifest, paragraph in this section should be in the <aside> element.
RPs MUST NOT reject a manifest solely because these fields are not identical.</ <aside> is defined as "a container for content that is semantically
t> less important or tangential to the content that surrounds it"
(https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2). -->
<t> <t>
If the above procedure indicates that the manifest is invalid, then If the above procedure indicates that the manifest is invalid, then
the manifest MUST be discarded and treated as though no manifest were the manifest <bcp14>MUST</bcp14> be discarded and treated as though no manife st were
present.</t> present.</t>
</section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="default">
</section> <name>Manifest Generation</name>
<section anchor="sect-5.1" numbered="true" toc="default">
<section title="Manifest Generation" anchor="sect-5"><section title="Mani <name>Manifest Generation Procedure</name>
fest Generation Procedure" anchor="sect-5.1"><t> <t>
For a CA publication point in the RPKI repository system, a CA MUST For a CA publication point in the RPKI repository system, a CA <bcp14>MUST</b
cp14>
perform the following steps to generate a manifest:</t> perform the following steps to generate a manifest:</t>
<ol spacing="normal" type="1"><li>Generate a new key pair for use in a "
<t><list style="numbers"> one-time-use" EE certificate.</li>
<t>Generate a new key pair for use in a "one-time-use" EE certificate.</t <li>
> <t>Issue an EE certificate for this key pair. The CA <bcp14>MUST</bc
p14> revoke the EE certificate used for the manifest being replaced.
<t>Issue an EE certificate for this key pair. The CA MUST revoke the EE cert </t>
ificate used for the manifest being replaced. <t>
<vspace blankLines="1"/> This EE certificate <bcp14>MUST</bcp14> have an SIA extension access desc
This EE certificate MUST have an SIA extension access description ription
field with an accessMethod OID value of id-ad-signedobject, where field with an accessMethod OID value of id-ad-signedObject, where
the associated accessLocation references the publication point of the associated accessLocation references the publication point of
the manifest as an object URL. (RPs are required to verify both of these syntactic constraints.) the manifest as an object URL. (RPs are required to verify both of these syntactic constraints.)
<vspace blankLines="1"/> </t>
This EE certificate MUST describe its Internet Number Resources
(INRs) using the "inherit" attribute, rather than explicit
description of a resource set (see <xref target="RFC3779"/>). (RPs are re
quired to verify this.)
<vspace blankLines="1"/>
The validity interval of the EE certificate MUST exactly match the thisUpdat
e and nextUpdate times specified in the manifest's eContent.
(An RP MUST NOT consider misalignment of the validity interval misalignment
in and of itself to be an error.)
</t>
<t>The EE certificate MUST NOT be published in the authority's <!-- [rfced] Section 5.1: Because the all-lowercase form
repository publication point.</t> "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.
<t>Construct the manifest content.<vspace blankLines="1"/> Original:
The manifest content is described in <xref target="sect-4.2.1"/>. The 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 Reso
urces
(INRs) using the "inherit" attribute, rather than an explicit
description of a resource set (see <xref target="RFC3779" format="default
"/>). (RPs are required to verify this.)
</t>
<t>
The validity interval of the EE certificate <bcp14>MUST</bcp14> exactly matc
h the thisUpdate and nextUpdate times specified in the manifest's eContent.
(An RP <bcp14>MUST NOT</bcp14> consider misalignment of the validity interva
l in and of itself to be an error.)
</t>
</li>
<li>The EE certificate <bcp14>MUST NOT</bcp14> be published in the aut
hority's
repository publication point.</li>
<li>
<t>Construct the manifest content.</t>
<t>
The manifest content is described in <xref target="sect-4.2.1" format="de
fault"/>. The
manifest's fileList includes the file name and hash pair for each manifest's fileList includes the file name and hash pair for each
object issued by this CA that has been published at this object issued by this CA that has been published at this
repository publication point (directory). The collection of repository publication point (directory). The collection of
objects to be included in the manifest includes all certificates objects to be included in the manifest includes all certificates
issued by this CA that are published at the CA's repository issued by this CA that are published at the CA's repository
publication point, the most recent CRL issued by the CA, and all publication point, the most recent CRL issued by the CA, and all
objects verified by EE certificates that were issued by this CA objects verified by EE certificates that were issued by this CA
that are published at this repository publication point. (Sections 6.1-5 that are published at this repository publication point. (Sections&nbsp;<
describes the checks that an RP MUST perform in support of the manifest content xref target="sect-6.1" format="counter"/> through <xref target="sect-6.5" format
noted here.) ="counter"/> describe the checks that an RP <bcp14>MUST</bcp14> perform in suppo
<vspace blankLines="1"/> rt of the manifest content noted here.)
</t>
<t>
Note that the manifest does not include a self reference (i.e., Note that the manifest does not include a self reference (i.e.,
its own file name and hash), since it would be impossible to its own file name and hash), since it would be impossible to
compute the hash of the manifest itself prior to it being signed. compute the hash of the manifest itself prior to it being signed.
</t> </t>
</li>
<t> <li>
Encapsulate the manifest content using the CMS SignedData content type Encapsulate the manifest content using the CMS SignedData content type
(as specified <xref target="sect-4"/>), sign the manifest using the private key (as specified in <xref target="sect-4" format="default"/>), sign the manifest us
corresponding to the subject key contained in the EE certificate, and publish th ing the private key corresponding to the subject key contained in the EE certifi
e manifest in the repository system publication point that is described by the m cate, and publish the manifest in the repository system publication point that i
anifest. s described by the manifest.
(RPs are required to verify the CMS signature.) (RPs are required to verify the CMS signature.)
</t> </li>
<t>Because the key pair is to be used only once, the private key
associated with this key pair MUST now be destroyed.</t>
</list> <!-- [rfced] Section 5.1: We do not see "SignedData" mentioned in
</t> Section 4 or anywhere else in this document. Please confirm that
this citation is correct and will be clear to readers.
</section> 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. -->
<section title="Considerations for Manifest Generation" anchor="sect-5.2" <li>Because the key pair is to be used only once, the private key
><t> associated with this key pair <bcp14>MUST</bcp14> now be destroyed.</li>
A new manifest MUST be issued and published before the </ol>
</section>
<section anchor="sect-5.2" numbered="true" toc="default">
<name>Considerations for Manifest Generation</name>
<t>
A new manifest <bcp14>MUST</bcp14> be issued and published before the
nextUpdate time.</t> nextUpdate time.</t>
<t>
<t> An authority <bcp14>MUST</bcp14> issue a new manifest in conjunction with the
An authority MUST issue a new manifest in conjunction with the
finalization of changes made to objects in the publication point. If any nam ed objects in the publication point are replaced, finalization of changes made to objects in the publication point. If any nam ed objects in the publication point are replaced,
the authority MUST ensure that the file hash for each replaced object is upda the authority <bcp14>MUST</bcp14> ensure that the file hash for each replaced
ted accordingly in the new manifest. Additionally, the authority MUST revoke the object is updated accordingly in the new manifest. Additionally, the authority
certificate associated with each replaced object (other than a CRL), if it is n <bcp14>MUST</bcp14> revoke the certificate associated with each replaced object
ot expired. An (other than a CRL), if it is not expired. An
authority MAY perform a number of object operations on a publication authority <bcp14>MAY</bcp14> perform a number of object operations on a publi
cation
repository within the scope of a repository change before issuing a repository within the scope of a repository change before issuing a
single manifest that covers all the operations within the scope of single manifest that covers all the operations within the scope of
this change. Repository operators MUST implement some form of this change. Repository operators <bcp14>MUST</bcp14> implement some form of
repository update procedure that mitigates, to the extent possible, repository update procedure that mitigates, to the extent possible,
the risk that RPs that are performing retrieval operations on the the risk that RPs that are performing retrieval operations on the
repository are exposed to inconsistent, transient, intermediate repository are exposed to inconsistent, transient, intermediate
states during updates to the repository publication point (directory) states during updates to the repository publication point (directory)
and the associated manifest.</t> and the associated manifest.</t>
<t>
<t>
Since the manifest object URL is included in the SIA of issued Since the manifest object URL is included in the SIA of issued
certificates, a new manifest MUST NOT invalidate the manifest object certificates, a new manifest <bcp14>MUST NOT</bcp14> invalidate the manifest object
URL of previously issued certificates. This implies that the URL of previously issued certificates. This implies that the
manifest's publication name in the repository, in the form of an manifest's publication name in the repository, in the form of an
object URL, is unchanged across manifest generation cycles.</t> object URL, is unchanged across manifest generation cycles.</t>
<t>
<t> When a CA entity is performing a key rollover, the entity <bcp14>MAY</bcp14>
When a CA entity is performing a key rollover, the entity MAY choose choose
to have two CA instances simultaneously publishing into the same to have two CA instances simultaneously publishing into the same
repository publication point. In this case, there will be one repository publication point. In this case, there will be one
manifest associated with each active CA instance that is publishing manifest associated with each active CA instance that is publishing
into the common repository publication point (directory).</t> into the common repository publication point (directory).</t>
</section>
</section> </section>
<section anchor="sect-6" numbered="true" toc="default">
</section> <name>Relying Party Processing of Manifests</name>
<t>Each RP <bcp14>MUST</bcp14> use the current manifest of a CA to control
<section title="Relying Party Processing of Manifests" anchor="sect-6"> addition of listed files to the set of signed objects the RP employs for valida
<t>Each RP MUST use the current manifest of a CA to control addition of ting basic RPKI objects: certificates, ROAs, and CRLs. Any files not listed on t
listed files to the set of signed objects the RP employs for validating basic RP he manifest <bcp14>MUST NOT</bcp14> be used for validation of these objects. How
KI objects: certificates, ROAs, and CRLs. Any files not listed on the manifest M ever, files not listed on a manifest <bcp14>MAY</bcp14> be employed to validate
UST NOT be used for validation of these objects. However, files not listed on a other signed objects, if the profile of the object type explicitly states that s
manifest MAY be employed to validate other signed objects, if the profile of the uch behavior is allowed (or required). Note that relying on files not listed in
object type explicitly states that such behavior is allowed (or required). Note a manifest may allow an attacker to effect substitution attacks against such obj
that relying on files not listed in a manifest may allow an attacker to effect ects.</t>
substitution attacks against such objects.</t> <t>As noted earlier, manifests are designed to allow an RP to detect manip
ulation of
<t>As noted earlier, manifests are designed to allow an RP to detect man
ipulation of
repository data, errors by a CA or repository manager, and/or active repository data, errors by a CA or repository manager, and/or active
attacks on the communication channel between an RP and a repository. attacks on the communication channel between an RP and a repository.
Unless all of the files enumerated in a manifest can be obtained by 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 an RP during a fetch operation, the fetch is considered to have
failed and the RP MUST retry the fetch later.</t> failed and the RP <bcp14>MUST</bcp14> retry the fetch later.</t>
<t>
<t> <xref target="RFC6480" format="default"/> suggests (but does not mandate) tha
<xref target="RFC6480"/> suggests (but does not mandate) that the RPKI model t the RPKI model employ
employ
fetches that are incremental, e.g., an RP transfers files from a fetches that are incremental, e.g., an RP transfers files from a
publication point only if they are new/changed since the previous, publication point only if they are new/changed since the previous,
successful, fetch represented in the RP's local cache. This document successful fetch represented in the RP's local cache. This document
avoids language that relies on details of the underlying file avoids language that relies on details of the underlying file
transfer mechanism employed by an RP and a publication point to transfer mechanism employed by an RP and a publication point to
effect this operation. Thus the term "fetch" refers to an operation effect this operation. Thus, the term "fetch" refers to an operation
that attempts to acquire the full set of files at a publication that attempts to acquire the full set of files at a publication
point, consistent with the id-ad-rpkiManifest URI extracted from a CA point, consistent with the id-ad-rpkiManifest URI extracted from a CA
certificate's SIA (see below).</t> certificate's SIA (see below).</t>
<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 If a fetch fails, it is assumed that a subsequent fetch will resolve
problems encountered during the fetch. Until such time as a problems encountered during the fetch. Until such time as a
successful fetch is executed, an RP SHOULD use cached data from a successful fetch is executed, an RP <bcp14>SHOULD</bcp14> use cached data from a
previous, successful fetch. This response is intended to prevent an previous, successful fetch. This response is intended to prevent an
RP from misinterpreting data associated with a publication point, and RP from misinterpreting data associated with a publication point and
thus possibly treating invalid routes as valid, or vice versa.</t> thus possibly treating invalid routes as valid, or vice versa.</t>
<t>
<t>
The processing described below is designed to cause all RPs with The processing described below is designed to cause all RPs with
access to the same local cache and RPKI repository data to acquire 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 same set of validated repository files. It does not ensure that
the RPs will achieve the same results with regard to validation of the RPs will achieve the same results with regard to validation of
RPKI data, since that depends on how each RP resolves any conflicts RPKI data, since that depends on how each RP resolves any conflicts
that may arise in processing the retrieved files. Moreover, in that may arise in processing the retrieved files. Moreover, in
operation, different RPs will access repositories at different times, operation, different RPs will access repositories at different times,
and some RPs may experience local cache failures, so there is no and some RPs may experience local cache failures, so there is no
guarantee that all RPs will achieve the same results with regard to guarantee that all RPs will achieve the same results with regard to
acquisition or validation of RPKI data.</t> acquisition or validation of RPKI data.</t>
<t>
<t>
Note also that there is a "chicken and egg" relationship between the 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 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 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 CRL, then the CA or publication point manager has made a serious
error. In this case the fetch has failed; proceed to <xref target="s ect-6.6"/>. error. In this case, the fetch has failed; proceed to <xref target=" sect-6.6" format="default"/>.
Similarly, if the CRL is not listed on a valid, current manifest, Similarly, if the CRL is not listed on a valid, current manifest,
acquired during a fetch, the fetch has failed; proceed to acquired during a fetch, the fetch has failed; proceed to
<xref target="sect-6.6"/>, because the CRL is considered missing.</t> <xref target="sect-6.6" format="default"/>, because the CRL is consid
ered missing.</t>
<section title="Manifest Processing Overview" anchor="sect-6.1"><t> <section anchor="sect-6.1" numbered="true" toc="default">
For a given publication point, an RP MUST perform a series of tests <name>Manifest Processing Overview</name>
<t>
For a given publication point, an RP <bcp14>MUST</bcp14> perform a serie
s of tests
to determine which signed object files at the publication point are to determine which signed object files at the publication point are
acceptable. The tests described below (<xref target="sect-6.2"/> to <xref target="sect-6.5"/>) acceptable. The tests described below (Sections&nbsp;<xref target="s ect-6.2" format="counter"/> through <xref target="sect-6.5" format="counter"/>)
are to be performed using the manifest identified by the id-ad- are to be performed using the manifest identified by the id-ad-
rpkiManifest URI extracted from a CA certificate's SIA. All of the rpkiManifest URI extracted from a CA certificate's SIA. All of the
files referenced by the manifest MUST be located at the files referenced by the manifest <bcp14>MUST</bcp14> be located at th e
publication point specified by the id-ad-caRepository URI from the publication point specified by the id-ad-caRepository URI from the
(same) CA certificate's SIA. The manifest and the files it (same) CA certificate's SIA. The manifest and the files it
references MUST reside at the same publication point. If an RP references <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 encounters any files that appear on a manifest but do not reside at
the same publication point as the manifest the RP MUST treat the the same publication point as the manifest, the RP <bcp14>MUST</bcp14
fetch as failed, and a warning MUST be issued (see <xref target="sect > treat the
-6.6"/> fetch as failed, and a warning <bcp14>MUST</bcp14> be issued (see <xr
ef target="sect-6.6" format="default"/>
below).</t> below).</t>
<t>
<t> Note that, during CA key rollover <xref target="RFC6489" format="default
Note that, during CA key rollover <xref target="RFC6489"/>, signed objec "/>, signed objects for two
ts for two
or more different CA instances will appear at the same publication or more different CA instances will appear at the same publication
point. Manifest processing is to be performed separately for each CA point. Manifest processing is to be performed separately for each CA
instance, guided by the SIA id-ad-rpkiManifest URI in each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA
certificate.</t> certificate.</t>
</section>
<section anchor="sect-6.2" numbered="true" toc="default">
<name>Acquiring a Manifest for a CA</name>
<t>
</section> The RP <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 or if the manifest is not valid
(<xref target="sect-4.4" format="default"/>), an RP <bcp14>MUST</bcp14> tr
eat this as a failed fetch and proceed
to <xref target="sect-6.6" format="default"/>; otherwise, proceed to <xref
target="sect-6.3" format="default"/>.</t>
<section title="Acquiring a Manifest for a CA" anchor="sect-6.2"><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".)
The RP MUST fetch the manifest identified by the SIA id-ad- Original:
rpkiManifest URI in the CA certificate. If an RP cannot retrieve a If an RP cannot retrieve a
manifest using this URI, or if the manifest is not valid manifest using this URI, or if the manifest is not valid
(<xref target="sect-4.4"/>), an RP MUST treat this as a failed fetch and p (Section 4.4), an RP MUST treat this as a failed fetch and proceed to
roceed Section 6.6; otherwise proceed to Section 6.3.
to <xref target="sect-6.6"/>; otherwise proceed to <xref target="sect-6.3" ...
/>.</t> 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.
</section> 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 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 title="Detecting Stale and or Prematurely-issued Manifests" anch </section>
or="sect-6.3"><t> <section anchor="sect-6.3" numbered="true" toc="default">
The RP MUST check that the current time (translated to UTC) is <name>Detecting Stale and/or Prematurely Issued Manifests</name>
<t>
The RP <bcp14>MUST</bcp14> check that the current time (translated to UT
C) is
between thisUpdate and nextUpdate. If the current time lies within between thisUpdate and nextUpdate. If the current time lies within
this interval, proceed to <xref target="sect-6.4"/>. If the current this interval, proceed to <xref target="sect-6.4" format="default"/>.
time is If the current time is
earlier than thisUpdate, the CA may have made an error or the RP’s lo earlier than thisUpdate, the CA may have made an error or the RP's lo
cal notion of time may be in error; the RP MUST treat this as a failed fetch and cal notion of time may be in error; the RP <bcp14>MUST</bcp14> treat this as a f
proceed to <xref target="sect-6.6"/>. If the current time is ailed fetch and proceed to <xref target="sect-6.6" format="default"/>. If the c
urrent time is
later than nextUpdate, then the manifest is stale; this is a failed later than nextUpdate, then the manifest is stale; this is a failed
fetch and RP MUST proceed to <xref target="sect-6.6"/>; otherwise pro fetch, and the RP <bcp14>MUST</bcp14> proceed to <xref target="sect-6
ceed to <xref target="sect-6.4"/>.</t> .6" format="default"/>; otherwise, proceed to <xref target="sect-6.4" format="de
fault"/>.</t>
</section> </section>
<section anchor="sect-6.4" numbered="true" toc="default">
<section title="Acquiring Files Referenced by a Manifest" anchor="sect-6. <name>Acquiring Files Referenced by a Manifest</name>
4"><t> <t>
The RP MUST acquire all of the files enumerated in the manifest The RP <bcp14>MUST</bcp14> acquire all of the files enumerated in the manifes t
(fileList) from the publication point. If there are files listed in (fileList) from the publication point. If there are files listed in
the manifest that cannot be retrieved from the publication point, the the manifest that cannot be retrieved from the publication point, the
fetch has failed and the RP MUST proceed to <xref target="sect-6.6"/>; oth fetch has failed and the RP <bcp14>MUST</bcp14> proceed to <xref target="s
erwise, ect-6.6" format="default"/>; otherwise,
proceed to <xref target="sect-6.5"/>.</t> proceed to <xref target="sect-6.5" format="default"/>.</t>
</section>
</section> <section anchor="sect-6.5" numbered="true" toc="default">
<name>Matching File Names and Hashes</name>
<section title="Matching File Names and Hashes" anchor="sect-6.5"><t> <t>
The RP MUST verify that the hash value of each file listed in the The RP <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 manifest matches the value obtained by hashing the file acquired from
the publication point. If the computed hash value of a file listed the publication point. If the computed hash value of a file listed
on the manifest does not match the hash value contained in the on the manifest does not match the hash value contained in the
manifest, then the fetch has failed and the RP MUST proceed to manifest, then the fetch has failed and the RP <bcp14>MUST</bcp14> proceed
<xref target="sect-6.6"/>.</t> to
<xref target="sect-6.6" format="default"/>.</t>
</section> </section>
<section anchor="sect-6.6" numbered="true" toc="default">
<section title="Failed Fetches" anchor="sect-6.6"> <name>Failed Fetches</name>
<t> <t>
If a fetch fails for any of the reasons cited in 6.2-6.5, the RP MUST is If a fetch fails for any of the reasons cited in Sections&nbsp;<xref tar
sue a warning indicating the reason(s) for termination of processing with regard get="sect-6.2" format="counter"/> through <xref target="sect-6.5" format="counte
to this CA instance. r"/>, the RP <bcp14>MUST</bcp14> issue a warning indicating the reason(s) for te
It is RECOMMENDED that a human operator be notified of this warning. rmination of processing with regard to this CA instance.
</t> It is <bcp14>RECOMMENDED</bcp14> that a human operator be notified of th
is warning.
<t>
Termination of processing means that the RP SHOULD continue to use cache
d versions of the objects associated with this CA instance, until such time as t
hey become stale or they can be replaced by objects from a successful fetch.
This implies that the RP MUST NOT try to acquire and validate subordinat
e signed objects, e.g., subordinate CA certificates, until the next interval whe
n the RP is scheduled to fetch and process data for this CA instance.
</t> </t>
<t>
</section> Termination of processing means that the RP <bcp14>SHOULD</bcp14> contin
ue to use cached versions of the objects associated with this CA instance, until
</section> such time as they become stale or they can be replaced by objects from a succes
sful fetch.
<section title="Publication Repositories" anchor="sect-7"><t> This implies that the RP <bcp14>MUST NOT</bcp14> try to acquire and vali
date subordinate signed objects, e.g., subordinate CA certificates, until the ne
xt interval when the RP is scheduled to fetch and process data for this CA insta
nce.
</t>
</section>
</section>
<section anchor="sect-7" numbered="true" toc="default">
<name>Publication Repositories</name>
<t>
The RPKI publication system model requires that every publication The RPKI publication system model requires that every publication
point be associated with one or more CAs, and be non-empty. Upon point be associated with one or more CAs and be non-empty. Upon
creation of the publication point associated with a CA, the CA MUST creation of the publication point associated with a CA, the CA <bcp14>MUST</b
cp14>
create and publish a manifest as well as a CRL. A CA's manifest will 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= always contain at least one entry, i.e., a CRL issued by the CA <xref target=
"RFC6481"/>,corresponding to the scope of this manifest.</t> "RFC6481" format="default"/>, corresponding to the scope of this manifest.</t>
<t>
<t> Every published signed object in the RPKI <xref target="RFC6488" format="defa
Every published signed object in the RPKI <xref target="RFC6488"/> is publish ult"/> is published in
ed in
the repository publication point of the CA that issued the EE the repository publication point of the CA that issued the EE
certificate, and is listed in the manifest associated with that CA certificate, and is listed in the manifest associated with that CA
certificate.</t> certificate.</t>
</section>
</section> <section anchor="sect-8" numbered="true" toc="default">
<name>Security Considerations</name>
<section title="Security Considerations" anchor="sect-8"><t> <t>
Manifests provide an additional level of protection for RPKI RPs. Manifests provide an additional level of protection for RPKI RPs.
Manifests can assist an RP to determine if a repository object has Manifests can assist an RP in determining if a repository object has
been deleted, occluded, or otherwise removed from view, or if a been deleted, occluded, or otherwise removed from view, or if a
publication of a newer version of an object has been suppressed (and publication of a newer version of an object has been suppressed (and
an older version of the object has been substituted).</t> an older version of the object has been substituted).</t>
<t>
<t>
Manifests cannot repair the effects of such forms of corruption of Manifests cannot repair the effects of such forms of corruption of
repository retrieval operations. However, a manifest enables an RP repository retrieval operations. However, a manifest enables an RP
to determine if a locally maintained copy of a repository is a to determine if a locally maintained copy of a repository is a
complete and up-to-date copy, even when the repository retrieval complete and up-to-date copy, even when the repository retrieval
operation is conducted over an insecure channel. In cases where the operation is conducted over an insecure channel. In cases where the
manifest and the retrieved repository contents differ, the manifest manifest and the retrieved repository contents differ, the manifest
can assist in determining which repository objects form the can assist in determining which repository objects form the
difference set in terms of missing, extraneous, or superseded difference set in terms of missing, extraneous, or superseded
objects.</t> objects.</t>
<t>
<t>
The signing structure of a manifest and the use of the nextUpdate The signing structure of a manifest and the use of the nextUpdate
value allows an RP to determine if the manifest itself is the subject value allow an RP to determine if the manifest itself is the subject
of attempted alteration. The requirement for every repository of attempted alteration. The requirement for every repository
publication point to contain at least one manifest allows an RP to publication point to contain at least one manifest allows an RP to
determine if the manifest itself has been occluded from view. Such determine if the manifest itself has been occluded from view. Such
attacks against the manifest are detectable within the time frame of attacks against the manifest are detectable within the time frame of
the regular schedule of manifest updates. Forms of replay attack the regular schedule of manifest updates. Forms of replay attacks
within finer-grained time frames are not necessarily detectable by within finer-grained time frames are not necessarily detectable by
the manifest structure.</t> the manifest structure.</t>
</section>
</section> <section 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="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>
<section title="IANA Considerations" anchor="sect-9"><t> <!-- [rfced] IANA Considerations: Per
As <xref target="RFC6488"/> created and populated the registries "RPKI Signed <https://www.iana.org/assignments/rpki/>, the "RPKI Repository Name
Object" and three-letter filename extensions for "RPKI Repository Name Schemes, Schemes" registry was created by RFC 6481 (not RFC 6488). Also,
" no new action is requested of the IANA.</t> RFC 6488 does not mention the "RPKI Repository Name Schemes" registry.
We updated this sentence as follows. Please let us know any
objections.
</section> 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.
<section title="Acknowledgements" anchor="sect-10"><t> Currently:
The authors would like to acknowledge the contributions from George Michelson The "RPKI Signed Objects" registry was originally created and populated
and Randy Bush in the preparation of the manifest specification. by [RFC6488]. The "RPKI Repository Name Schemes" registry was created
Additionally, the authors would like to thank Mark Reynolds and Christopher S by [RFC6481] and created four of the initial three-letter filename extensions.
mall for assistance in clarifying manifest validation and RP behavior. IANA has updated the reference for Manifest in the "RPKI Signed Objects"
The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, registry to point to this document. No other actions are are requested.
Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, Roman Dan
yliw, Lars Eggert, Robert Wilton, and Benjamin Kaduk for their helpful review of
this document.</t>
</section>
</middle> 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 list ed here. For example:
<back> IANA has updated the following entries to refer to this document instead of RFC
<references title="Normative References"> 6486:
<reference anchor="IANA-NAMING" target="https://www.iana.org/assignments/
rpki/rpki.xhtml#name-schemes"><front>
<title>RPKI Repository Name Schemes</title>
<author>
</author>
<date/> - id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module Identifier (1.
</front> 2.840.113549.1.9.16.0)" registry
</reference> - id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS Content Type (1.2.
&RFC2119; 840.113549.1.9.16.1)" registry
&RFC5280;
&RFC6481;
&RFC6482;
&RFC7935;
&RFC6487;
&RFC6488;
&RFC8174;
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690-199511 - the Security Considerations of the application media type registration for rpk
-S!Cor1"> i-manifest
<front> -->
<title>X.690</title>
<author></author>
<date />
</front>
</reference>
</references> </section>
</middle>
<back>
<references>
<references title="Informative References"> <!-- [rfced] Would you like to list the references in
&RFC5652; alphanumeric order? -->
&RFC3779;
&RFC6480; <name>References</name>
&RFC6486; <references>
&RFC6489; <name>Normative References</name>
</references>
<section title="ASN.1 Module" anchor="sect-a"><figure><artwork><![CDATA[ <reference anchor="IANA-NAMING" target="https://www.iana.org/assignments
/rpki/">
<front>
<title>RPKI Repository Name Schemes</title>
<author><organization>IANA</organization></author>
<date/>
</front>
</reference>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5280.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6481.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6482.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7935.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6487.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6488.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<reference anchor="X.690" target="https://www.itu.int/rec/T-REC-X.690-20
2102-I/en">
<front>
<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</organiz
ation></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.R
FC.5652.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.3779.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6480.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6486.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6489.xml"/>
</references>
</references>
<section 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) RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) TBD } pkcs(1) pkcs9(9) smime(16) mod(0) TBD }
]]></artwork> ]]></sourcecode>
</figure>
<figure><artwork><![CDATA[ <!-- [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 }
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 ::= DEFINITIONS EXPLICIT TAGS ::=
BEGIN BEGIN
-- EXPORTS ALL -- -- EXPORTS ALL --
IMPORTS IMPORTS
CONTENT-TYPE CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- in [RFC6268] FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
skipping to change at line 693 skipping to change at line 872
fileHashAlg OBJECT IDENTIFIER, fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
} }
FileAndHash ::= SEQUENCE { FileAndHash ::= SEQUENCE {
file IA5String, file IA5String,
hash BIT STRING hash BIT STRING
} }
END END
]]></sourcecode>
]]></artwork> <!-- [rfced] Appendix A: We see that RFC 6268 is not cited anywhere
</figure> in this document or listed in the References section. Would you like
</section> 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"?
<section title="Changes since RFC 6486" anchor="sect-b"> Original (double dash modified so that xml2rfc doesn't confuse it
<t> with a comment):
In 2019, it came to light that multiple Relying Party implementations FROM CryptographicMessageSyntax-2010 - in [RFC6268] -->
</section>
<section anchor="sect-b" numbered="true" toc="default">
<name>Changes since RFC 6486</name>
<t>
In 2019, it came to light that multiple RP implementations
were in a vulnerable position, possibly due to perceived ambiguity in were in a vulnerable position, possibly due to perceived ambiguity in
the original <xref target="RFC6486"/> specification. the original <xref target="RFC6486" format="default"/> specification.
This document attempts to clarify the innovative concept and application This document attempts to clarify the innovative concept and application
of RPKI Manifests in light of real-world deployment experience in the of RPKI manifests in light of real-world deployment experience in the
global Internet routing system, to avoid future problematic cases. global Internet routing system, to avoid future problematic cases.
</t> </t>
<t>
<t>
The following list summarizes the changes between RFC 6486 and this docume nt: The following list summarizes the changes between RFC 6486 and this docume nt:
</t> </t>
<ul spacing="normal">
<t> <li>
<list style="symbols"> Forbidding "sequential-use" EE certificates and instead mandating "one
<t> -time-use"
Forbid "sequential-use" EE certificates, instead mandate "one-time-use
"
EE certificates. EE certificates.
</t> </li>
<t> <li>
Clarify that Manifest EE certificates are to be issued with a validity Clarifying that manifest EE certificates are to be issued with a validit
period which coincides with the interval specified in the Manifest y
period that coincides with the interval specified in the manifest
eContent, which coincides with the CRL's thisUpdate and nextUpdate. eContent, which coincides with the CRL's thisUpdate and nextUpdate.
</t> </li>
<t> <li>
Clarify the manifestNumber is monotonically incremented in steps of 1. Clarifying that the manifestNumber is monotonically incremented in step
</t> s of 1.
<t> </li>
Recommend CA issuers to coincidence the applicable CRL's nextUpdate <li>
with the Manifest's nextUpdate. Recommending that CA issuers coincide the applicable CRL's nextUpdate
</t> with the manifest's nextUpdate.
<t> </li>
The set of valid characters in FileAndHash filenames was constrained. <li>
</t> Constraining the set of valid characters in FileAndHash filenames.
<t> </li>
Clarifications that an RP unable to obtain the full set of files listed <li>
on a Manifest is considered a failure state, in which case cached data Clarifying that an RP unable to obtain the full set of files listed
on a manifest is considered to be in a failure state, in which case cac
hed data
from a previous attempt should be used (if available). from a previous attempt should be used (if available).
</t> </li>
<t> <li>
Clarifications on the requirement for a current CRL to be present, list Clarifying the requirement for a current CRL to be present, listed,
ed,
and verified. and verified.
</t> </li>
<t> <li>
Removed the notion of 'local policy'. Removing the notion of "local policy".
</t> </li>
</list> </ul>
</t>
<!-- [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>
<section anchor="sect-10" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
The authors would like to acknowledge the contributions from <contact fullnam
e="George Michaelson"/> and <contact fullname="Randy Bush"/> in the preparation
of the manifest specification.
Additionally, the authors would like to thank <contact fullname="Mark Reynold
s"/> and <contact fullname="Christopher Small"/> for assistance in clarifying ma
nifest validation and RP behavior.
The authors also wish to thank <contact fullname="Tim Bruijnzeels"/>, <contac
t fullname="Job Snijders"/>, <contact fullname="Oleg Muravskiy"/>, <contact full
name="Sean Turner"/>, <contact fullname="Adianto Wibisono"/>, <contact fullname=
"Murray Kucherawy"/>, <contact fullname="Francesca Palombini"/>, <contact fullna
me="Roman Danyliw"/>, <contact fullname="Lars Eggert"/>, <contact fullname="Robe
rt Wilton"/>, and <contact fullname="Benjamin Kaduk"/> for their helpful review
of this document.</t>
</back> <!-- [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> </rfc>
 End of changes. 129 change blocks. 
570 lines changed or deleted 867 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

mirror server hosted at Truenetwork, Russian Federation.