1148 lines
44 KiB
XML
1148 lines
44 KiB
XML
<?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-ymbk-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 Use of Manifests" anchor="sect-6">
|
|
|
|
<t>
|
|
The goal of an RP is to determine which signed objects to use for
|
|
validating assertions about INRs and their use (e.g., which ROAs
|
|
to use in the construction of route filters). Ultimately, this
|
|
selection is a matter of local policy. However, in the following
|
|
sections, we describe a sequence of tests that the RP SHOULD
|
|
perform to determine the manifest state of the given publication
|
|
point. We then discuss the risks associated with using signed
|
|
objects in the publication point, given the manifest state; we
|
|
also provide suitable warning text that SHOULD be placed in a
|
|
user-accessible log file. It is the responsibility of the RP to
|
|
weigh these risks against the risk of routing failure that could
|
|
occur if valid data is rejected, and to implement a suitable local
|
|
policy. Note that if a certificate is deemed unfit for use due to
|
|
local policy, then any signed object that is validated using this
|
|
certificate also SHOULD be deemed unfit for use (regardless of the
|
|
status of the manifest at its own publication point).
|
|
</t>
|
|
|
|
<section title="Tests for Determining Manifest State" anchor="sect-6.1">
|
|
|
|
<t>
|
|
For a given publication point, the RP SHOULD perform the
|
|
following tests to determine the manifest state of the
|
|
publication point:
|
|
</t>
|
|
|
|
<t>
|
|
<list style="numbers">
|
|
|
|
<t>
|
|
For each CA using this publication point, select the CA's
|
|
current manifest (the "current" manifest is the manifest
|
|
issued by this CA having the highest manifestNumber among
|
|
all valid manifests, and where manifest validity is defined
|
|
in <xref target="sect-4.4"/>).<vspace blankLines="1"/> If
|
|
the publication point does not contain a valid manifest, see
|
|
<xref target="sect-6.2"/>. Lacking a valid manifest, the
|
|
following tests cannot be performed.
|
|
</t>
|
|
|
|
<t>
|
|
To verify completeness, an RP MAY check that every file at
|
|
each publication point appears in one and only one current
|
|
manifest, and that every file listed in a current manifest
|
|
is published at the same publication point as the
|
|
manifest.<vspace blankLines="1"/> If there exist files at
|
|
the publication point that do not appear on any manifest, or
|
|
files listed in a manifest that do not appear at the
|
|
publication point, then see <xref target="sect-6.5"/>, but
|
|
still continue with the following test.
|
|
</t>
|
|
|
|
<t>
|
|
Check that the current time (translated to UTC) is between
|
|
thisUpdate and nextUpdate.<vspace blankLines="1"/> If the
|
|
current time does not lie within this interval, then see
|
|
<xref target="sect-6.4"/>, but still continue with the
|
|
following tests.
|
|
</t>
|
|
|
|
<t>
|
|
Verify that the listed hash value of every file listed in
|
|
each manifest matches the value obtained by hashing the file
|
|
at the publication point.<vspace blankLines="1"/> If the
|
|
computed hash value of a file listed on the manifest does
|
|
not match the hash value contained in the manifest, then see
|
|
<xref target="sect-6.6"/>.
|
|
</t>
|
|
|
|
<t>
|
|
An RP MAY check that the contents of each current manifest
|
|
conforms to the manifest's scope constraints, as specified
|
|
in <xref target="sect-2"/>.
|
|
</t>
|
|
|
|
<t>
|
|
If a current manifest contains entries for objects that are
|
|
not within the scope of the manifest, then the out-of-scope
|
|
entries SHOULD be disregarded in the context of this
|
|
manifest. If there is no other current manifest that
|
|
describes these objects within that other manifest's scope,
|
|
then see <xref target="sect-6.2"/>.
|
|
|
|
<list style="hanging" hangIndent="3">
|
|
|
|
<t hangText="For each signed object, if all of the following
|
|
conditions hold:">
|
|
<vspace blankLines="0"/>
|
|
|
|
<list style="symbols">
|
|
|
|
<t>
|
|
the manifest for its publication and the associated
|
|
publication point pass all of the above checks;
|
|
</t>
|
|
|
|
<t>
|
|
the signed object is valid; and
|
|
</t>
|
|
|
|
<t>
|
|
the manifests for every certificate on the
|
|
certification path used to validate the signed
|
|
object and the associated publication points pass
|
|
all of the above checks;
|
|
</t>
|
|
|
|
</list>
|
|
</t>
|
|
|
|
</list>
|
|
</t>
|
|
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
then the RP can conclude that no attack against the repository
|
|
system has compromised the given signed object, and the signed
|
|
object MUST be treated as valid (relative to manifest
|
|
checking).
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section title="Missing Manifests" anchor="sect-6.2">
|
|
|
|
<t>
|
|
The absence of a current manifest at a publication point could
|
|
occur due to an error by the publisher or due to (malicious or
|
|
accidental) deletion or corruption of all valid manifests.
|
|
</t>
|
|
|
|
|
|
<t>
|
|
When no valid manifest is available, there is no protection
|
|
against attacks that delete signed objects or replay old
|
|
versions of signed objects. All signed objects at the
|
|
publication point, and all descendant objects that are validated
|
|
using a certificate at this publication point, SHOULD be viewed
|
|
as suspect, but MAY be used by the RP, as per local policy.
|
|
</t>
|
|
|
|
<t>
|
|
The primary risk in using signed objects at this publication
|
|
point is that a superseded (but not stale) CRL would cause an RP
|
|
to improperly accept a revoked certificate as valid (and thus
|
|
rely upon signed objects that are validated using that
|
|
certificate). This risk is somewhat mitigated if the CRL for
|
|
this publication point has a short time between thisUpdate and
|
|
nextUpdate (and the current time is within this interval). The
|
|
risk in discarding signed objects at this publication point is
|
|
that an RP may incorrectly discard a large number of valid
|
|
objects. This gives significant power to an adversary that is
|
|
able to delete a manifest at the publication point.
|
|
</t>
|
|
|
|
<t>
|
|
Regardless of whether signed objects from this publication are
|
|
deemed fit for use by an RP, this situation SHOULD result in a
|
|
warning to the effect that: "No manifest is available for
|
|
<pub point name>, and thus there may have been undetected
|
|
deletions or replay substitutions from the publication point."
|
|
</t>
|
|
|
|
<t>
|
|
In the case where an RP has access to a local cache of
|
|
previously issued manifests that are valid, the RP MAY use the
|
|
most recently previously issued valid manifests for this RPKI
|
|
repository publication collection for each entity that publishes
|
|
at this publication point.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section title="Invalid Manifests" anchor="sect-6.3">
|
|
|
|
<t>
|
|
The presence of an invalid manifest at a publication point could
|
|
occur due to an error by the publisher or due to (malicious or
|
|
accidental) corruption of a valid manifest. An invalid manifest
|
|
MUST never be used, even if the manifestNumber of the invalid
|
|
manifest is greater than that of other (valid) manifests.
|
|
</t>
|
|
|
|
|
|
<t>
|
|
There are no risks associated with using signed objects at a
|
|
publication point containing an invalid manifest, provided that
|
|
valid manifests that collectively cover all the signed objects
|
|
are also present.
|
|
</t>
|
|
|
|
<t>
|
|
If an invalid manifest is present at a publication point that
|
|
also contains one or more valid manifests, this situation SHOULD
|
|
result in a warning to the effect that: "An invalid manifest was
|
|
found at <pub point name>, this indicates an attack
|
|
against the publication point or an error by the publisher.
|
|
Processing for this publication point will continue using the
|
|
most recent valid manifest(s)."
|
|
</t>
|
|
|
|
<t>
|
|
In the case where the RP has access to a local cache of
|
|
previously issued (valid) manifests, an RP MAY make use of that
|
|
locally cached data. Specifically, the RP MAY use the locally
|
|
cached, most recent, previously issued, valid manifest issued by
|
|
the entity that (appears to have) issued the invalid manifest.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section title="Stale Manifests" anchor="sect-6.4">
|
|
|
|
<t>
|
|
A manifest is considered stale if the current time is after the
|
|
nextUpdate time for the manifest. This could be due to
|
|
publisher failure to promptly publish a new manifest, or due to
|
|
(malicious or accidental) corruption or suppression of a more
|
|
recent manifest.
|
|
</t>
|
|
|
|
<t>
|
|
All signed objects at the publication point issued by the entity
|
|
that has published the stale manifest, and all descendant signed
|
|
objects that are validated using a certificate issued by the
|
|
entity that has published the stale manifest at this publication
|
|
point, SHOULD be viewed as somewhat suspect, but MAY be used by
|
|
the RP as per local policy.
|
|
</t>
|
|
|
|
<t>
|
|
The primary risk in using such signed objects is that a newer
|
|
manifest exists that, if present, would indicate that certain
|
|
objects have been removed or replaced. (For example, the new
|
|
manifest might show the existence of a newer CRL and the removal
|
|
of one or more revoked certificates). Thus, the use of objects
|
|
from a stale manifest may cause an RP to incorrectly treat
|
|
invalid objects as valid. The risk is that the CRL covered by
|
|
the stale manifest has been superseded, and thus an RP will
|
|
improperly treat a revoked certificate as valid. This risk is
|
|
somewhat mitigated if the time between the nextUpdate field of
|
|
the manifest and the current time is short. The risk in
|
|
discarding signed objects at this publication point is that the
|
|
RP may incorrectly discard a large number of valid objects.
|
|
This gives significant power to an adversary that is able to
|
|
prevent the publication of a new manifest at a given publication
|
|
point.
|
|
</t>
|
|
|
|
<t>
|
|
Regardless of whether signed objects from this publication are
|
|
deemed fit for use by an RP, this situation SHOULD result in a
|
|
warning to the effect that: "A manifest found at <pub point
|
|
name> is no longer current. It is possible that undetected
|
|
deletions have occurred at this publication point."
|
|
</t>
|
|
|
|
<t>
|
|
Note that there is also the potential for the current time to be
|
|
before the thisUpdate time for the manifest. This case could be
|
|
due to publisher error or a local clock error; in such a case,
|
|
this situation SHOULD result in a warning to the effect that: "A
|
|
manifest found at <pub point name> has an incorrect
|
|
thisUpdate field. This could be due to publisher error, or a
|
|
local clock error, and processing for this publication point
|
|
will continue using this otherwise valid manifest."
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section title="Mismatch between Manifest and Publication Point"
|
|
anchor="sect-6.5">
|
|
|
|
<t>
|
|
If there exist valid signed objects that do not appear in any
|
|
manifest, then, provided the manifest is not stale (see <xref
|
|
target="sect-6.4"/>), it is likely that their omission is an
|
|
error by the publisher. It is also possible that this state
|
|
could be the result of a (malicious or accidental) replacement
|
|
of a current manifest with an older, but still valid, manifest.
|
|
However, regarding the appropriate interpretation of such
|
|
objects, it remains the case that if the objects were intended
|
|
to be invalid, then they should have been revoked using whatever
|
|
revocation mechanism is appropriate for the signed object in
|
|
question. Therefore, there is little risk in using such signed
|
|
objects. If the publication point contains a stale manifest,
|
|
then there is a greater risk that the objects in question were
|
|
revoked, along with a missing Certificate Revocation List (CRL),
|
|
the absence of which is undetectable since the manifest is
|
|
stale. In any case, the use of signed objects not present on a
|
|
manifest, or descendant objects that are validated using such
|
|
signed objects, is a matter of local policy.
|
|
</t>
|
|
|
|
<t>
|
|
Regardless of whether objects not appearing on a manifest are
|
|
deemed fit for use by the RP, this situation SHOULD result in a
|
|
warning to the effect that: "The following files are present in
|
|
the repository at <pub point name>, but are not listed on
|
|
any manifest <file list> for <pub point name>."
|
|
</t>
|
|
|
|
<t>
|
|
If there exists files listed on the manifest that do not appear
|
|
in the repository, then these objects are likely to have been
|
|
improperly (via malice or accident) deleted from the repository.
|
|
A primary purpose of manifests is to detect such deletions.
|
|
Therefore, in such a case, this situation SHOULD result in a
|
|
warning to the effect that: "The following files that should
|
|
have been present in the repository at <pub point name>
|
|
are missing <file list>. This indicates an attack against
|
|
this publication point, or the repository, or an error by the
|
|
publisher."
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section title="Hash Values Not Matching Manifests"
|
|
anchor="sect-6.6">
|
|
|
|
<t>
|
|
A file appearing on a manifest with an incorrect hash value
|
|
could occur because of publisher error, but it also may indicate
|
|
that an attack has occurred.
|
|
</t>
|
|
|
|
<t>
|
|
If an object appeared on a previous valid manifest with a
|
|
correct hash value, and it now appears with an invalid hash
|
|
value, then it is likely that the object has been superseded by
|
|
a new (unavailable) version of the object. If the object is
|
|
used, there is a risk that the RP will be treating a stale
|
|
object as valid. This risk is more significant if the object in
|
|
question is a CRL. If the object can be validated using the
|
|
RPKI, the use of these objects is a matter of local policy.
|
|
</t>
|
|
|
|
<t>
|
|
If an object appears on a manifest with an invalid hash and has
|
|
never previously appeared on a manifest, then it is unclear
|
|
whether the available version of the object is more or less
|
|
recent than the version indicated by the manifest. If the
|
|
manifest is stale (see <xref target="sect-6.4"/>), then it
|
|
becomes more likely that the available version is more recent
|
|
than the version indicated on the manifest, but this is never
|
|
certain. Whether to use such objects is a matter of local
|
|
policy. However, in general, it is better to use a possibly
|
|
outdated version of the object than to discard the object
|
|
completely.
|
|
</t>
|
|
|
|
<t>
|
|
While it is a matter of local policy, in the case of CRLs, an RP
|
|
SHOULD endeavor to use the most recently issued valid CRL, even
|
|
where the hash value in the manifest matches an older CRL or
|
|
does not match any available CRL for a CA instance. The
|
|
thisUpdate field of the CRL can be used to establish the most
|
|
recent CRL in the case where an RP has more than one valid CRL
|
|
for a CA instance.
|
|
</t>
|
|
|
|
<t>
|
|
Regardless of whether objects with incorrect hashes are deemed
|
|
fit for use by the RP, this situation SHOULD result in a warning
|
|
to the effect that: "The following files at the repository
|
|
<pub point name> appear on a manifest with incorrect hash
|
|
values <file list>. It is possible that these objects
|
|
have been superseded by a more recent version. It is very
|
|
likely that this problem is due to an attack on the publication
|
|
point, although it also could be due to a publisher error."
|
|
</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>
|
|
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 Sean Turner for his 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>
|