randy/draft-6486bis
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

wg adoption, so -00

Browse source
This commit is contained in:
Randy Bush 2020-08-11 12:36:41 -07:00
parent dc34d73129
commit d8e3b6d1d5
1 changed files with 974 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

974
draft-ietf-sidrops-6486bis.xml Normal file
View file

@ -0,0 +1,974 @@
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc sortrefs="yes"?>
<?rfc subcompact="no"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-sidrops-6486bis-00" updates="6486" ipr="trust200902">
<front>
<title abbrev="RPKI Manifests">Manifests for the Resource Public Key Infrastructure (RPKI)</title>
<author initials="R." surname="Austein" fullname="Rob Austein">
<organization>Arrcus, Inc.</organization>
<address>
<email>sra@hactrn.net</email>
</address>
</author>
<author fullname="Geoff Huston" initials="G." surname="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 fullname="Stephen Kent" initials="S." surname="Kent">
<organization >Independent</organization>
<address>
<email>kkent@alum.mit.edu</email>
</address>
</author>
<author fullname="Matt Lepinski" initials="M." surname="Lepinski">
<organization>New College Florida</organization>
<address>
<postal>
<street>5800 Bay Shore Rd.</street>
<city>Sarasota, FL</city>
<code>34243</code>
<country>USA</country>
</postal>
<email>mlepinski@ncf.edu</email>
</address>
</author>
<date />
<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 "stale" (valid) data and deletion of signed objects.
</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="sect-1">
<t>
The Resource Public Key Infrastructure (RPKI) <xref
target="RFC6480"/> makes use of a distributed repository system
<xref target="RFC6481"/> 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
provide no protection against attacks that substitute "stale"
versions of signed objects (i.e., objects that were valid and have
not expired, but have since been superseded) or attacks that
remove an object that should be present in the repository. To
assist in the detection of such attacks, the RPKI repository
system can 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 a man-in-the-middle attack
on 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 Authorizations (ROAs).
</t>
<section title="Requirements Language">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref format="default" pageno="false"
target="RFC2119"/> <xref format="default" pageno="false"
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>
A manifest associated with a CA's repository publication point
contains a list of:
</t>
<t>
<list style="symbols">
<t>
the set of (non-expired, non-revoked) certificates issued and
published by this CA,
</t>
<t>
the most recent CRL issued by this CA, and
</t>
<t>
all published signed objects that are verifiable using EE
certificates <xref target="RFC6487"/> issued by this CA.
</t>
</list>
</t>
<t>
Every RPKI signed object includes, in the Cryptographic Message
Syntax (CMS) <xref target="RFC3370"/> wrapper of the object, the
EE certificate used to verify it <xref target="RFC6488"/>. 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 an entity performs a key-rollover operation <xref
target="RFC6489"/>, 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>
A CA's manifest is verified using an EE certificate. The
SubjectInfoAccess (SIA) field of this EE certificate contains the
access method OID of id-ad-signedObject.
</t>
<t>
The CA MAY choose to sign only one manifest with each generated
private key, and generate a new key pair for each new version of
the manifest. This form of use of the associated EE certificate
is termed a "one-time-use" EE certificate.
</t>
<t>
Alternatively, the CA MAY elect to use the same private key to
sign a sequence of manifests. Because only a single manifest
(issued under a single CA instance) is current at any point in
time, the associated EE certificate is used to verify only a
single object at a time. As long as the sequence of objects
verified by this EE certificate are published using the same file
name, then this sequential, multiple use of the EE certificate is
also valid. This form of use of an EE certificate is termed a
"sequential-use" EE certificate.
</t>
</section>
<section title="Manifest Definition" anchor="sect-4">
<t>
A manifest is an RPKI signed object, as specified in <xref
target="RFC6488"/>. 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>
The eContentType for a manifest is defined as id-ct-rpkiManifest
and has the numerical value of 1.2.840.113549.1.9.16.1.26.
</t>
<figure>
<artwork>
<![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>
</section>
<section title="eContent" anchor="sect-4.2">
<t>
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 defined as follows:
</t>
<figure>
<artwork>
<![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>
<section title="Manifest" anchor="sect-4.2.1">
<t>
The manifestNumber, thisUpdate, and nextUpdate fields are
modeled after the corresponding fields in X.509 CRLs (see
<xref target="RFC5280"/>). 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>
If a "one-time-use" EE certificate is employed to verify a
manifest, the EE certificate MUST have a validity period that
coincides with the interval from thisUpdate to nextUpdate, to
prevent needless growth of the CA's CRL.
</t>
<t>
If a "sequential-use" EE certificate is employed to verify a
manifest, the EE certificate's validity period needs to be no
shorter than the nextUpdate time of the current manifest.
The extended validity time raises the possibility of a
substitution attack using a stale manifest, as described in
<xref target="sect-6.4"/>.
</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"/>
The version number of this version of the manifest
specification MUST be 0.
</t>
<t hangText="manifestNumber:"> <vspace blankLines="0"/>
This field is an integer that is incremented 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"/>
As the manifest is modeled on the CRL specification, the
ManifestNumber is analogous to the CRLNumber, and the
guidance in <xref target="RFC5280"/> 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 be able to handle number values up to 20 octets.
Conforming manifest issuers MUST NOT use number values
longer than 20 octets.
</t>
<t hangText="thisUpdate:"> <vspace blankLines="0"/>
This field contains the time when the manifest was
created. This field has the same format constraints as
specified in <xref target="RFC5280"/> for the CRL field of
the same name.
</t>
<t hangText="nextUpdate:"><vspace blankLines="0"/>
This field contains the time at which the next scheduled
manifest will be issued. The value of nextUpdate MUST 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"/>
If the authority alters any of the items that it has
published in the repository publication point, then the
authority MUST issue a new manifest before the nextUpdate
time. If a manifest encompasses a CRL, the nextUpdate
field of the manifest MUST match that of the CRL's
nextUpdate field, as the manifest will be re-issued when a
new CRL is published. If a "one-time-use" EE certificate
is used to verify the manifest, then when a new manifest
is issued before the time specified in nextUpdate of the
current manifest, the CA MUST also issue a new CRL that
includes the EE certificate corresponding to the old
manifest.
</t>
<t hangText="fileHashAlg:"> <vspace blankLines="0"/>
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 conform to the
RPKI Algorithms and Key Size Profile specification <xref
target="RFC6485"/>.
</t>
<t hangText="fileList:"><vspace blankLines="0"/>
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>
</section>
</section>
<section title="Content-Type Attribute" anchor="sect-4.3">
<t>
The mandatory content-type attribute MUST have its attrValues
field set to the same OID as eContentType. This OID is
id-ct-rpkiManifest and has the numerical value of
1.2.840.113549.1.9.16.1.26.
</t>
</section>
<section title="Manifest Validation" anchor="sect-4.4">
<t>
To determine whether a manifest is valid, the RP MUST perform
the following checks in addition to those specified in <xref
target="RFC6488"/>:
</t>
<t>
<list style="numbers">
<t>
The eContentType in the EncapsulatedContentInfo is
id-ad-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).
</t>
<t>
The version of the rpkiManifest is 0.
</t>
<t>
In the rpkiManifest, thisUpdate precedes nextUpdate.
</t>
</list>
</t>
<t>
If the above procedure indicates that the manifest is invalid,
then the manifest MUST be discarded and treated as though no
manifest were present.
</t>
</section>
</section>
<section title="Manifest Generation" anchor="sect-5">
<section title="Manifest Generation Procedure" anchor="sect-5.1">
<t>
For a CA publication point in the RPKI repository system, a CA
MUST perform the following steps to generate a manifest:
</t>
<t>
<list style="numbers">
<t>
If no key pair exists, or if using a "one-time-use" EE
certificate with a new key pair, generate a key pair.
</t>
<t>
If using a "one-time-use" EE certificate, or if a key pair
was generated in step 1, or if using a "sequential-use" EE
certificate that will expire before the intended nextUpdate
time of this manifest, issue an EE certificate for this key
pair.<vspace blankLines="1"/> 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.
<vspace blankLines="1"/>
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"/>).
<vspace blankLines="1"/>
In the case of a "one-time-use" EE certificate, the validity
times of the EE certificate MUST exactly match the
thisUpdate and nextUpdate times of the manifest.
<vspace blankLines="1"/>
In the case of a "sequential-use" EE certificate, the
validity times of the EE certificate MUST encompass the time
interval from thisUpdate to nextUpdate.
</t>
<t>
The EE certificate MUST NOT be published in the authority's
repository publication point.
</t>
<t>
Construct the manifest content.<vspace blankLines="1"/> The
manifest content is described in <xref
target="sect-4.2.1"/>. The manifest's fileList includes the
file name and hash pair for each object issued by this CA
that has been published at this repository publication point
(directory). The collection of objects to be included in
the manifest includes all certificates issued by this CA
that are published at the CA's repository publication point,
the most recent CRL issued by the CA, and all objects
verified by EE certificates that were issued by this CA that
are published at this repository publication point.
<vspace blankLines="1"/>
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>
Encapsulate the manifest content using the CMS SignedData
content type (as specified <xref target="sect-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.
</t>
<t>
In the case of a key pair that is to be used only once, in
conjunction with a "one-time-use" EE certificate, the
private key associated with this key pair MUST now be
destroyed.
</t>
</list>
</t>
</section>
<section title="Considerations for Manifest Generation" anchor="sect-5.2">
<t>
A new manifest MUST be issued and published on or before the
nextUpdate time.
</t>
<t>
An authority MUST issue a new manifest in conjunction with the
finalization of changes made to objects in the publication
point. An authority MAY perform a number of object operations
on a publication repository within the scope of a repository
change before issuing a single manifest that covers all the
operations within the scope of this change. Repository
operators SHOULD 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 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
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 Party Processing of Manifests" anchor="sect-6">
<t>
Each RP must determine which signed objects it will use for
validating assertions about INRs and their use (e.g., which ROAs
to use in the construction of route filters). 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 retry the fetch later.
</t>
<t>
<xref target="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. 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 the term
"fetch" refers to an operation that attempts to acquire the full
set of files at a publication point, consistent with the
id-ad-rpkiManifest URI extracted from a CA certificate's SIA (see
below).
</t>
<t>
If a fetch fails, it is assumed that a subsequent fetch will
resolve problems encountered during the fetch. Until such time as
a successful fetch is executed, an RP SHOULD use cached data from
a previous, successful fetch. This response is intended to prevent
an RP from misinterpreting data associated with a publication
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 achieve
the same results with regard to validation of RPKI data. However,
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 validation of RPKI data.
</t>
<t>
Note 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 the fetch has failed; proceed
to <xref target="sect-6.7"/>. 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.7"/>, because the CRL
is considered missing.
</t>
<t>
Note that if a CA and its associated publication point are
operating properly, there will always be exactly one manifest and
one associated CRL at the publication point identified in the CA's
SIA (see below).
</t>
<section title="Manifest Processing Overview" anchor="sect-6.1">
<t>
For a given publication point, an RP MUST 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 <xref target="sect-6.6"/>) 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 be 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 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 the RP MUST treat the fetch as failed, and a
warning MUST be issued (see <xref target="sect-6.7"/> below).
</t>
<t>
A manifest SHOULD contain exactly one CRL (.crl) file and it
MUST be at the location specified in the CRLDP in the manifest's
EE certificate. If more than one .crl file appears in the
manifest, the fetch has failed and the RP MUST proceed to <xref
target="sect-6.7"/>; otherwise proceed to <xref
target="sect-6.2"/>.
</t>
<t>
Note that, during CA key rollover <xref target="RFC6489"/>,
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 a Manifest for a CA" anchor="sect-6.2">
<t>
The RP MUST 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"/>), an RP MUST treat this as a
failed fetch and, proceed to <xref target="sect-6.7"/>;
otherwise proceed to <xref target="sect-6.3"/>.
</t>
</section>
<section title="Detecting Stale and or Prematurely-issued Manifests" anchor="sect-6.3">
<t>
The RP MUST 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"/>. If
the current time is earlier than thisUpdate, the CA has made an
error; this is a failed fetch and the RP MUST proceed to <xref
target="sect-6.7"/>. If the current time is later than
nextUpdate, then the manifest is stale; this is a failed fetch
and RP MUST proceed to <xref target="sect-6.7"/>; otherwise
proceed to <xref target="sect-6.4"/>.
</t>
</section>
<section title="Acquiring Files Referenced by a Manifest" anchor="sect-6.4">
<t>
The RP MUST acquire all of the files enumerated in the manifest
(fileList) from the publication point. This includes the CRL,
each object containing an EE certificate issued by the CA, and
any subordinate CA and EE certificates. If there are files
listed in the manifest that cannot be retrieved from the
publication point, or if they fail the validity tests specified
in <xref target="RFC6488"/>, the fetch has failed and the RP
MUST proceed to <xref target="sect-6.7"/>; otherwise, proceed to
<xref target="sect-6.5"/>.
</t>
</section>
<section title="Matching File Names and Hashes" anchor="sect-6.5">
<t>
The RP MUST 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 proceed to <xref target="sect-6.7"/>; otherwise proceed to
<xref target="sect-6.6"/>.
</t>
</section>
<section title="Out of Scope Manifest Entries" anchor="sect-6.6">
<t>
If a current manifest contains entries for objects that are not
within the scope of the manifest (<xref target="sect-6.2"/>),
the fetch has failed and the RP SHOULD proceed to <xref
target="sect-6.7"/>; otherwise the fetch is deemed successful
and the RP will process the fetched objects.
</t>
</section>
<section title="Failed Fetches" anchor="sect-6.7">
<t>
If an RP does not acquire a current valid manifest, or does not
acquire current valid instances of all of the objects enumerated
in a current valid manifest as a result of a fetch, then
processing of the signed objects associated with the CA instance
has failed for this fetch cycle. The RP MUST issue a warning
indicating the reason(s) for termination of processing with
regard to this CA instance. It is RECOMMENDED that a human
operator be notified of this warning.
</t>
<t>
Termination of processing means that the RP SHOULD 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 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>
The RPKI publication system model requires that every publication
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 create and publish a manifest as well as a CRL. A CA's
manifest will always contain at least one entry, namely, the CRL
issued by the CA upon repository creation <xref
target="RFC6481"/>.
</t>
<t>
Every published signed object in the RPKI <xref target="RFC6488"/>
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>
Manifests provide an additional level of protection for RPKI RPs.
Manifests can assist an RP to determine 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 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 within finer-grained time frames are not
necessarily detectable by the manifest structure.
</t>
</section>
<section title="IANA Considerations" anchor="sect-9">
<t>
As <xref target="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>
<!--
<t>
This document registers the following in the "RPKI Signed Object"
registry created by <xref target="RFC6488"/>:
</t>
<figure>
<artwork>
<![CDATA[
Name: Manifest
OID: 1.2.840.113549.1.9.16.1.26
Reference: [TBD] (this document)
]]>
</artwork>
</figure>
<t>
This document registers the following three-letter filename
extension for "RPKI Repository Name Schemes" registry created by
<xref target="RFC6481"/>:
</t>
<figure>
<artwork>
<![CDATA[
Filename extension: mft
RPKI Object: Manifest
Reference: [RFC6481]
]]>
</artwork>
</figure>
-->
</section>
<section title="Acknowledgements" anchor="sect-10">
<t>
The authors would like to acknowledge the contributions from
George Michelson and Randy Bush in the preparation of the manifest
specification. Additionally, the authors would like to thank Mark
Reynolds and Christopher Small for assistance in clarifying
manifest validation and RP behavior. The authors also wish to
thank Job Snijders, Oleg Muravskiy, and Sean Turner for their
helpful review of this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include="reference.RFC.5280"?>
<?rfc include="reference.RFC.6481"?>
<?rfc include="reference.RFC.6485"?>
<?rfc include="reference.RFC.6487"?>
<?rfc include="reference.RFC.6488"?>
<?rfc include="reference.RFC.8174"?>
<reference anchor="X.690">
<front>
<title>ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)</title>
<author>
<organization>International International Telephone and Telegraph Consultative Committee</organization>
</author>
<date month="July" year="2002" />
</front>
<seriesInfo name="CCITT" value="Recommendation X.690" />
</reference>
<!--
<reference>
[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
-->
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3370"?>
<?rfc include="reference.RFC.3779"?>
<?rfc include="reference.RFC.6480"?>
<?rfc include="reference.RFC.6489"?>
</references>
<section title="ASN.1 Module" anchor="sect-a">
<figure>
<artwork>
<![CDATA[
RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0) 60 }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL --
-- IMPORTS NOTHING --
-- Manifest Content Type: OID
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
-- Manifest Content Type: eContent
Manifest ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
manifestNumber INTEGER (0..MAX),
thisUpdate GeneralizedTime,
nextUpdate GeneralizedTime,
fileHashAlg OBJECT IDENTIFIER,
fileList SEQUENCE SIZE (0..MAX) OF FileAndHash
}
FileAndHash ::= SEQUENCE {
file IA5String,
hash BIT STRING
}
END
]]>
</artwork>
</figure>
</section>
</back>
</rfc>