< draft-ietf-sidr-rpki-manifests-03.txt   draft-ietf-sidr-rpki-manifests-04.txt >
Secure Inter-Domain Routing R. Austein Secure Inter-Domain Routing R. Austein
Internet-Draft ISC Internet-Draft ISC
Intended status: Standards Track G. Huston Intended status: Standards Track G. Huston
Expires: March 28, 2009 APNIC Expires: April 28, 2009 APNIC
S. Kent S. Kent
M. Lepinski M. Lepinski
BBN BBN
September 24, 2008 October 25, 2008
Manifests for the Resource Public Key Infrastructure Manifests for the Resource Public Key Infrastructure
draft-ietf-sidr-rpki-manifests-03.txt draft-ietf-sidr-rpki-manifests-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 28, 2009. This Internet-Draft will expire on April 28, 2009.
Abstract Abstract
This document defines a "manifest" for use in the Resource Public Key This document defines a "manifest" for use in the Resource Public Key
Infrastructure. A manifest is a signed object that contains a Infrastructure. A manifest is a signed object that contains a
listing of all the signed objects in the repository publication point listing of all the signed objects in the repository publication point
associated with an authority responsible for publishing in the associated with an authority responsible for publishing in the
repository. For each certificate, or other forms of signed objects repository. For each certificate, or other forms of signed objects
issued by the authority that are published at this repository issued by the authority that are published at this repository
publication point, the manifest contains both the name of the file publication point, the manifest contains both the name of the file
skipping to change at page 2, line 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 4 3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . . 4
4. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . . . 5 4. Manifest Syntax . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 5 4.1. Signed-Data Content Type . . . . . . . . . . . . . . . . . 5
4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. version . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 5 4.1.2. digestAlgorithms . . . . . . . . . . . . . . . . . . . 5
4.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 5 4.1.3. encapContentInfo . . . . . . . . . . . . . . . . . . . 6
4.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 8 4.1.4. certificates . . . . . . . . . . . . . . . . . . . . . 8
4.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1.5. crls . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 8 4.1.6. signerInfos . . . . . . . . . . . . . . . . . . . . . 8
4.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. ASN.1 . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 13 5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 13
5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 13 5.1. CA Manifest Generation . . . . . . . . . . . . . . . . . . 13
5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 14 5.2. End Entity Manifest Generation . . . . . . . . . . . . . . 14
5.3. Common Considerations for Manifest Generation . . . . . . 15 5.3. Common Considerations for Manifest Generation . . . . . . 15
6. Processing Certificate Requests . . . . . . . . . . . . . . . 15 6. Processing Certificate Requests . . . . . . . . . . . . . . . 16
7. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 16 7. Manifest Validation . . . . . . . . . . . . . . . . . . . . . 16
8. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 17 8. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 18
8.1. Tests for Determining Manifest State . . . . . . . . . . . 18 8.1. Tests for Determining Manifest State . . . . . . . . . . . 18
8.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 19 8.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 19
8.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 19 8.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 20
8.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 20 8.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 20
8.5. Mismatch between Manifest and Publication Point . . . . . 21 8.5. Mismatch between Manifest and Publication Point . . . . . 21
8.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 21 8.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 22
9. Publication Repositories . . . . . . . . . . . . . . . . . . . 22 9. Publication Repositories . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13. Normative References . . . . . . . . . . . . . . . . . . . . . 24 13. Normative References . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Intellectual Property and Copyright Statements . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27
1. Introduction 1. Introduction
The Resource Public Key Infrastructure (RPKI) [ID.SIDR-ARCH] makes The Resource Public Key Infrastructure (RPKI) [ID.sidr-arch] makes
use of a distributed repository system [ID.SIDR-REPOSITORY] to make use of a distributed repository system [ID.sidr-repos-struct] to make
available a variety of objects needed by relying parties (RPs) such available a variety of objects needed by relying parties (RPs) such
as Internet service providers (ISPs). Because all of the objects as Internet service providers (ISPs). Because all of the objects
stored in the repository system are digitally signed by the entities stored in the repository system are digitally signed by the entities
that created them, attacks that modify these objects are detectable that created them, attacks that modify these objects are detectable
by RPs. However, digital signatures provide no protection against by RPs. However, digital signatures provide no protection against
attacks that substitute "stale" versions of signed objects (i.e., attacks that substitute "stale" versions of signed objects (i.e.,
objects that were valid but have since been superceded) or attacks objects that were valid and have not expired, but have since been
that remove an object that should be present in the repository. To superseded) or attacks that remove an object that should be present
assist in the detection of such attacks, the RPKI repository system in the repository. To assist in the detection of such attacks, the
will make use of a new signed object called a "manifest." RPKI repository system will make use of a new signed object called a
"manifest".
A manifest is an object that lists of all of the other signed objects A manifest is a signed object that contains a listing of all the
issued by the authority responsible for a publication point in the signed objects in the repository publication point associated with an
repository system. For each certificate, Certificate Revocation List authority responsible for publishing in the repository. For each
(CRL), or other signed object, such as a Route Origination Authority certificate, Certificate Revocation List (CRL), or other signed
(ROA), issued by the authority, the manifest contains both the name object, such as a Route Origination Authorization (ROA), issued by an
of the file containing the object, and a hash of the file content. authority, the authority's manifest contains both the name of the
file containing the object, and a hash of the file content.
Manifests allow a RP to obtain sufficient information to detect Manifests allow a RP to obtain sufficient information to detect
whether the retrieval of objects from an RPKI repository has been whether the retrieval of objects from an RPKI repository has been
compromised by unauthorized object removal, or by the substitution of compromised by unauthorized object removal, or by the substitution of
"stale" versions of objects. Manifests are designed to be used both "stale" versions of objects. Manifests are designed to be used both
for Certification Authority (CA) publication points in repositories, for Certification Authority (CA) publication points in repositories,
that contain subordinate certificates, CRLs and other signed objects, that contain subordinate certificates, CRLs and other signed objects,
and End Entity (EE) publication points in repositories that contain and End Entity (EE) publication points in repositories that contain
signed objects. signed objects.
Manifests are modelled on CRLs, as the issues involved in detecting Manifests are modeled on CRLs, as the issues involved in detecting
stale manifests, and detection of potential attacks using manifest stale manifests, and detection of potential attacks using manifest
replays, etc are similar to those for CRLs. The syntax of the replays, etc are similar to those for CRLs. The syntax of the
manifest payload differs from CRLs, since RPKI repositories can manifest payload differs from CRLs, since RPKI repositories can
contain objects not covered by CRLs, such as digitally signed contain objects not covered by CRLs, such as digitally signed
objects, such as ROAs. objects, such as ROAs.
1.1. Terminology 1.1. Terminology
It is assumed that the reader is familiar with the terms and concepts It is assumed that the reader is familiar with the terms and concepts
described in "Internet X.509 Public Key Infrastructure Certificate described in "Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile" [RFC5280]and "X.509 and Certificate Revocation List (CRL) Profile" [RFC5280]and "X.509
Extensions for IP Addresses and AS Identifiers" [RFC3779]. Extensions for IP Addresses and AS Identifiers" [RFC3779].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
2. Manifest Scope 2. Manifest Scope
In the case of a CA's manifest of its associated publication In the case of a CA's manifest for its associated publication
repository, the manifest contains the current published certificates repository, the manifest contains the current published certificates
issued by this CA, the most recent CRL issued by this CA, and all issued by this CA, the most recent CRL issued by this CA, and all
objects that are signed using a "single-use" EE certificate ((i.e., objects that are signed using a "single-use" EE certificate (i.e.,
the SIA extension of the EE certificate has an accessMethod OID of the SIA extension of the EE certificate has an accessMethod OID of
id-ad-signedObject), where the EE certificate was issued by this CA. id-ad-signedObject), where the EE certificate was issued by this CA.
In the case where multiple CAs share a common publication point, as In the case where multiple CAs share a common publication point, as
may be the case when an entity performs a staged key-rollover may be the case when an entity performs a staged key-rollover
operation, the respository publication will contain multiple operation, the repository publication will contain multiple
manifests. Each manifest describes only the collection of products manifests. In such a scenario, each manifest describes only the
of its associated CA. collection of published products of its associated CA.
In the case of a "multi-use" EE certificate, where an EE has a In the case of a "multi-use" EE certificate, where an EE has a
defined publication repository (i.e., the SIA extension of the EE defined publication repository (i.e., the SIA extension of the EE
certificate has an accessMethod OID of id-ad-signedObjectRepository), certificate has an accessMethod OID of id-ad-signedObjectRepository),
the EE's manifest contains all published objects that have been the EE's manifest contains all published objects that have been
signed by the EE's key pair, and the accessMethod id-as-rpkiManifest signed by the EE's key, and the accessMethod id-as-rpkiManifest
points to the publication point of the EE's manifest. points to the publication point of the EE's manifest.
3. Manifest Signing 3. Manifest Signing
A CA's manifest is signed using an EE certificate that is designated A CA's manifest is verified using an EE certificate that is
in [ID.SIDR-CERTPROFILE] as a "single-use" EE certificate. The SIA designated in [ID.sidr-res-certs] as a "single-use" EE certificate.
field of the "single-use" EE certificate contains the access method The SIA field of the "single-use" EE certificate contains the access
OID of id-ad-signedObject. method OID of id-ad-signedObject.
The CA MAY chose to sign only one manifest with the EE certificate, The CA MAY chose to sign only one manifest with the private key of
and generate a new EE certificate for each new version of the the EE certificate, and generate a new EE certificate for each new
manifest. This form of use of a "single-use" EE certificate is version of the manifest. This form of use of a "single-use" EE
termed a "one-time-use" EE certificate. certificate is termed a "one-time-use" EE certificate.
Alternatively the CA MAY chose to use the same EE certificate to sign Alternatively the CA MAY chose to use the same EE certificate's
a sequence of manifests. Because only a single manifest is current private key to sign a sequence of manifests. Because only a single
at any point in time, the EE certificate is only ever used to sign a manifest is current at any point in time, the EE certificate is used
single object at a time. As long as the sequence of objects signed only to verify a single object at a time. As long as the sequence of
by this EE certificate are published as the same named object, so objects signed by this EE certificate's private key are published as
that the SIA accessMethod id-ad-signedObject value can refer to the the same named object, so that the SIA accessMethod id-ad-
current instance of the sequence of such objects, then this signedObject value can refer to the current instance of the sequence
sequential multiple use of this "single-use" EE certificate is also of such objects, then this sequential multiple use of this "single-
valid. This form of use of a "single-use" EE certificate is termed a use" EE certificate is also valid. This form of use of a "single-
"sequential-use" EE certificate. use" EE certificate is termed a "sequential-use" EE certificate.
A "multi-use" EE's manifest of it's publication repository MUST be A "multi-use" EE's manifest of it's publication repository is signed
signed by the EE certificate itself. with the private key of the EE certificate.
4. Manifest Syntax 4. Manifest Syntax
A manifest is a Cryptographic Message Syntax (CMS) [RFC3852] signed- A manifest is a Cryptographic Message Syntax (CMS) [RFC3852] signed-
data object. The general format of a CMS object is: data object. The general format of a CMS object is:
ContentInfo ::= SEQUENCE { ContentInfo ::= SEQUENCE {
contentType ContentType, contentType ContentType,
content [0] EXPLICIT ANY DEFINED BY contentType } content [0] EXPLICIT ANY DEFINED BY contentType }
skipping to change at page 6, line 43 skipping to change at page 6, line 48
fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash fileList SEQUENCE OF (SIZE 0..MAX) FileAndHash
} }
FileAndHash ::= SEQUENCE { FileAndHash ::= SEQUENCE {
file IA5String file IA5String
hash BIT STRING hash BIT STRING
} }
4.1.3.2.1. Manifest 4.1.3.2.1. Manifest
The manifestNumber, thisUpdate, and nextUpdate fields are modelled The manifestNumber, thisUpdate, and nextUpdate fields are modeled
after the corresponding fields in X.509 CRLs (see [RFC5280]). after the corresponding fields in X.509 CRLs (see [RFC5280]).
Analogous to CRLS, a manifest is nominally valid until the time Analogous to CRLS, a manifest is nominally valid 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. The revoked EE certificate manifest number, whichever comes first. The revoked EE certificate
for the previous manifest's signature will be removed from the CRL for the previous manifest's signature will be removed from the CRL
when it expires. when it expires.
In the case of "one-time-use" EE certificates being used to sign a If a "one-time-use" EE certificate is employed to verify a manifest,
manifest, it is RECOMMENDED that the EE certificate have an validity the EE certificate MUST have an validity period that coincides with
period that coincides with the interval from thisUpdate to the interval from thisUpdate to nextUpdate, to prevent needless
nextUpdate, to prevent needless growth of the CA's CRL. growth of the CA's CRL.
In the case of "sequential-use EE certificates to sign a manifest the If a "sequential-use EE certificate is employed to verify a manifest,
EE certificate's validity period should reflect the CA's key the EE certificate's validity period needs to be no shorter than the
management policies. nextUpdate time of the current manifest. The extended validity time
raises the possibility of a substitution attack using a stale
manifest, as described in Section 8.4.
4.1.3.2.1.1. version 4.1.3.2.1.1. version
The version number of the rpkiManifest MUST be 0. The version number of the rpkiManifest MUST be 0.
4.1.3.2.1.2. manifestNumber 4.1.3.2.1.2. manifestNumber
The manifestNumber field is a sequence number that is incremented The manifestNumber field is a sequence number that is incremented
each time a new manifest is issued for a given publication point. each time a new manifest is issued for a given publication point.
This field is used to allow a RP to detect gaps in a sequence of This field is used to allow a RP to detect gaps in a sequence of
skipping to change at page 7, line 32 skipping to change at page 7, line 39
4.1.3.2.1.3. thisUpdate 4.1.3.2.1.3. thisUpdate
The thisUpdate field contains the time when the manifest was created. The thisUpdate field contains the time when the manifest was created.
4.1.3.2.1.4. nextUpdate 4.1.3.2.1.4. nextUpdate
The nextUpdate field contains the time at which the next scheduled The nextUpdate field contains the time at which the next scheduled
manifest will be issued. The value of nextUpdate MUST be later than manifest will be issued. The value of nextUpdate MUST be later than
the value of thisUpdate. If the authority alters any of the items in the value of thisUpdate. If the authority alters any of the items in
the repository publication point, then the authority MUST issue a new the repository publication point, then the authority MUST issue a new
manifest before the nextUpdate time. In such a case, when the manifest before the nextUpdate time. If a manifest encompasses a
authority issues the new manifest, and when "one-time-use" EE CRL, the nextUpdate field of the manifest MUST match that of the CRL,
certificates are being used to sign the manifest, the CA MUST also as the manifest will be reissued when a new CRL is published. When a
issue a new CRL that includes the EE certificate corresponding to the "one-time-use" EE certificate is being used to verify the manifest,
old 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.
4.1.3.2.1.5. fileHashAlg 4.1.3.2.1.5. fileHashAlg
The fileHashAlg field contains the OID of the hash algorithm used to The fileHashAlg field contains the OID of the hash algorithm used to
hash the files that the authority has placed into the repository. hash the files that the authority has placed into the repository.
The mandatory to implement hash algorithm is SHA-256 and its OID is The mandatory to implement hash algorithm is SHA-256 and its OID is
2.16.840.1.101.3.4.2.1. [RFC4055]. 2.16.840.1.101.3.4.2.1. [RFC4055].
4.1.3.2.1.6. fileList 4.1.3.2.1.6. fileList
skipping to change at page 14, line 8 skipping to change at page 14, line 15
* In the case of a "sequential-use" EE certificate the validity * In the case of a "sequential-use" EE certificate the validity
times of the EE certificate MUST encompass the time interval times of the EE certificate MUST encompass the time interval
from thisUpdate to nextUpdate. from thisUpdate to nextUpdate.
3. The EE certificate SHOULD NOT be published in the authority's 3. The EE certificate SHOULD NOT be published in the authority's
repository publication point. repository publication point.
4. Construct the manifest content. Note that the manifest does not 4. Construct the manifest content. Note that the manifest does not
include a self reference (i.e., its own file name and hash), include a self reference (i.e., its own file name and hash),
since it would be impossible to compute the hash of the manifest since it would be impossible to compute the hash of the manifest
itself prior to it being signed. itself prior to it being signed. The manifest content is
described in Section 4.1.3.2.1. The manifest's fileList includes
the file names and hash pair for all objects associated with this
CA that have been published at the CA's repository publication
point. The collection of objects to be included in the manifest
includes all subordinate 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
"single-use" EE certificates that were issued by this CA that are
published at the CA's repository publication point.
5. Encapsulate the Manifest content using the CMS SignedData content 5. Encapsulate the Manifest content using the CMS SignedData content
type (as specified in Section Section 4), sign the manifest using type (as specified in Section Section 4), sign the manifest using
the EE certificate, and publish the manifest in repository system the private key corresponding to the EE certificate, and publish
publication point that is described by the manifest. the manifest in repository system publication point that is
described by the manifest.
6. In the case of a key pair that is to be used only once, in 6. 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 conjunction with a "one-time-use" EE certificate, the private key
associated with this key pair SHOULD now be destroyed. associated with this key pair SHOULD now be destroyed.
5.2. End Entity Manifest Generation 5.2. End Entity Manifest Generation
EE repository publication points are only used in conjunction with EE repository publication points are only used in conjunction with
"multi-use" EE Certificates. In this case the EE Certificate has two "multi-use" EE Certificates. In this case the EE Certificate has two
accessMethods specified in its SIA field. The id-ad- accessMethods specified in its SIA field. The id-ad-
signedObjectRepository accessMethod has an associated accessLocation signedObjectRepository accessMethod has an associated accessLocation
that points to the repository publication point of the objects signed that points to the repository publication point of the objects signed
by this EE certificate, as specified in [ID.SIDR-CERTPROFILE]. The by this EE certificate, as specified in [ID.sidr-res-certs]. The id-
id-ad-rpkiManifest accessMethod has an associated access location ad-rpkiManifest accessMethod has an associated access location that
that points to the manifest object as an object URL, that is points to the manifest object as an object URL, that is associated
associated with this repository publication point. This manifest with this repository publication point. This manifest describes all
describes all the signed objects that are to be found in that the signed objects that are to be found in that publication point
publication point that have been signed by this EE certificate, and that have been signed by this EE certificate, and the hash value of
the hash value of each product (excluding the manifest itself). each product (excluding the manifest itself).
To create a manifest, each "multi-use" EE MUST perform the following To create a manifest, each "multi-use" EE MUST perform the following
steps:. steps:.
o Construct the Manifest content. Note that the manifest does not o Construct the Manifest content. Note that the manifest does not
include a self reference (i.e., its own file name and hash), since 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 it would be impossible to compute the hash of the manifest itself
prior to it being signed. prior to it being signed. The manifest content is described in
Section 4.1.3.2.1. The manifest's fileList includes the file
names and hash pair for all objects verified using that EE
certificate that have been published at the EE's repository
publication point.
o Encapsulate the Manifest content using the CMS SignedData content o Encapsulate the Manifest content using the CMS SignedData content
type (as specified in Section Section 4), sign the manifest using type (as specified in Section Section 4), sign the manifest using
the EE certificate, and publish the manifest in repository system the EE certificate, and publish the manifest in repository system
publication point that is described by the manifest. publication point that is described by the manifest.
"Single Use" EE certificates (EE certificates with an SIA "Single Use" EE certificates (EE certificates with an SIA
accessMethod OID of id-as-signedObject) do not have repository accessMethod OID of id-as-signedObject) do not have repository
publication points. The object signed by the "Single Use" EE publication points. The object signed by the "Single Use" EE
certificate is published in the repository publication point of the certificate is published in the repository publication point of the
skipping to change at page 15, line 36 skipping to change at page 16, line 11
the manifest's publication name in the repository, in the form of the manifest's publication name in the repository, in the form of
an object URL, is one that is unchanged across manifest generation an object URL, is one that is unchanged across manifest generation
cycles. cycles.
o In the case of a CA publication point manifest, when the entity is o In the case of a CA publication point manifest, when the entity is
performing a key rollover the entity MAY chose to have multiple performing a key rollover the entity MAY chose to have multiple
CAs publishing at the same publication point. In this case there CAs publishing at the same publication point. In this case there
will be one manifest associated with each active CA that is will be one manifest associated with each active CA that is
publishing into the common repository publication point. publishing into the common repository publication point.
o In the case of an EE publication point the manifest is associated o In the case of an EE publication point the manifest lists all
all published objects signed by that EE certificate. Multiple EEs published objects verified using that EE certificate. Multiple
may share a common repository publication point, in which case EEs may share a common repository publication point, in which case
there will be one manifest associated with each active EE that is there will be one manifest associated with each active EE that is
publishing into the common repository publication point. publishing into the common repository publication point.
6. Processing Certificate Requests 6. Processing Certificate Requests
When an EE certificate is intended for use in verifying multiple When an EE certificate is intended for use in verifying multiple
objects, the certificate request for the EE certificate MUST include objects, the certificate request for the EE certificate MUST include
in the SIA of the request an access method OID of id-ad- in the SIA of the request an access method OID of id-ad-
signedObjectRepository where the associated access location refers to signedObjectRepository where the associated access location refers to
the publication point for objects signed by this EE certificate, and the publication point for objects signed by this EE certificate, and
MUST include in the SIA of the request an access method OID of id-ad- MUST include in the SIA of the request an access method OID of id-ad-
rpkiManifest, where the associated access location refers to the rpkiManifest, where the associated access location refers to the
publication point of the manifest that is associated with published publication point of the manifest that is associated with published
objects that are verified using this EE certificate objects that are verified using this EE certificate
[ID.SIDR-CERTPROFILE]. [ID.sidr-res-certs].
When an EE certificate is used to sign a single object, the When an EE certificate is used to sign a single object, the
certificate request for the EE certificate MUST include in the SIA of certificate request for the EE certificate MUST include in the SIA of
the request an access method OID of id-ad-signedObject, where the the request an access method OID of id-ad-signedObject, where the
associated access location refers to the publication point of the associated access location refers to the publication point of the
single object that is verified using this EE certificate. The single object that is verified using this EE certificate. The
certificate request MUST NOT include in the SIA of the request the certificate request MUST NOT include in the SIA of the request the
access method OID of id-ad-rpkiManifest. access method OID of id-ad-rpkiManifest.
In accordance with the provisions of [ID.SIDR-CERTPROFILE], all In accordance with the provisions of [ID.sidr-res-certs], all
certificate issuance requests for a CA certificate SHOULD include in certificate issuance requests for a CA certificate SHOULD include in
the SIA of the request the id-ad-caRepository access method, and also the SIA of the request the id-ad-caRepository access method, and also
the id-ad-rpkiManifest access method that references the intended the id-ad-rpkiManifest access method that references the intended
publication point of the manifest in the associated access location publication point of the manifest in the associated access location
in the request. in the request.
The issuer MUST either honor these values in the issued certificate The issuer MUST either honor these values in the issued certificate
or reject the request entirely. or reject the request entirely.
7. Manifest Validation 7. Manifest Validation
skipping to change at page 17, line 32 skipping to change at page 17, line 50
1.2.840.113549.1.9.3) and the MessageDigest attribute (OID 1.2.840.113549.1.9.3) and the MessageDigest attribute (OID
1.2.840.113549.1.9.4). 1.2.840.113549.1.9.4).
m. The unsignedAttrs field in the SignerInfo object is omitted. m. The unsignedAttrs field in the SignerInfo object is omitted.
2. Use the public key in the EE certificate to verify the signature 2. Use the public key in the EE certificate to verify the signature
on the Manifest. on the Manifest.
3. Verify that the EE certificate is a valid end-entity certificate 3. Verify that the EE certificate is a valid end-entity certificate
in the resource PKI by constructing a valid certificate path to a in the resource PKI by constructing a valid certificate path to a
trust anchor. (See [ID.RESCERT] for more details.) trust anchor. (See [ID.sidr-res-certs] for more details.)
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 MUST be discarded and treated as though no manifest were
present. present.
8. Relying Party Use of Manifests 8. Relying Party Use of Manifests
The goal of the relying party is to determine which signed objects to The goal of the relying party is to determine which signed objects to
use for routing-related tasks, (e.g. which ROAs to use in the use for routing-related tasks, (e.g., which ROAs to use in the
construction of route filters). Ultimately, this is a matter of construction of route filters). Ultimately, this is a matter of
local policy. However, in the following sections, we describe a local policy. However, in the following sections, we describe a
sequence of tests that the relying party should perform to determine sequence of tests that the relying party SHOULD perform to determine
the manifest state of the given publication point. We then discuss the manifest state of the given publication point. We then discuss
the risks associated with using signed objects in the publication the risks associated with using signed objects in the publication
point, given the manifest state; and provide suitable warning text point, given the manifest state; and provide suitable warning text
that should placed in a user-accessible log file. It is the that should placed in a user-accessible log file. It is the
responsibility of the relying party to weigh these risks against the responsibility of the relying party to weigh these risks against the
risk of routing failure that could occur if valid data is rejected, risk of routing failure that could occur if valid data is rejected,
and construct a suitable local policy. Note that if a certificate is and construct a suitable local policy. Note that if a certificate is
deemed unfit for use do to local policy, then any descendent object deemed unfit for use do to local policy, then any descendant object
that is validated using this certificate should also be deemed unfit that is validated using this certificate should also be deemed unfit
for use (regardless of the status of the manifest at its own for use (regardless of the status of the manifest at its own
publication point). publication point).
8.1. Tests for Determining Manifest State 8.1. Tests for Determining Manifest State
For a given publication point, the relying party should perform the For a given publication point, the relying party should perform the
following tests to determine the manifest state of the publication following tests to determine the manifest state of the publication
point: point:
1. Select the manifest having highest manifestNumber among all valid 1. For each entity using this publication point, select the entity's
manifests (where manifest validity is defined in Section manifest having highest manifestNumber among all valid manifests
Section 7). (where manifest validity is defined in Section Section 7).
* If the publication point does not contain a valid manifest, * If the publication point does not contain a valid manifest,
see Section Section 8.2. Lacking a valid manifest, the see Section Section 8.2. Lacking a valid manifest, the
following tests cannot be performed. following tests cannot be performed.
2. Check that the current time is between thisUpdate and nextUpdate. 2. Check that the current time is between thisUpdate and nextUpdate.
* If the current time does not lie in this interval then see * If the current time does not lie within this interval then see
Section Section 8.4, but still continue with the following Section 8.4, but still continue with the following tests.
tests.
3. Check that every file at the publication point appears on the 3. Check that every file at the publication point appears in one and
manifest, and that every file on the manifest appears at the only one manifest, and that every file listed in each manifest
publication point. appears at the publication point.
* If there exists files at the publication point that do not * If there exists files at the publication point that do not
appear on the manifest, or files on the manifest that do not appear on any manifest, or files listed in a manifest that do
appear at the publication point then see Section Section 8.5 not appear at the publication point then see Section 8.5 but
but still continue with the following test. still continue with the following test.
4. Check that the hash of every file listed on the manifest matches 4. Check that listed hash value of every file listed in each
the value obtained by hashing the file in at the publication manifest matches the value obtained by hashing the file at the
point. publication point.
* If there exist files at the publication point whose hash does * If there exist files at the publication point whose hash does
not match the hash value listed in the manifest, then see not match the hash value listed in the manifest, then see
Section Section 8.6. Section 8.6.
For a particular signed object, if all of the following conditions For a particular signed object, if all of the following conditions
hold: hold:
o the manifest for its publication passes all of the above checks; * the manifest for its publication, and the associated
o the signed object is valid; and publication point, pass all of the above checks;
o the manifests for every certificate on the certificate path used * the signed object is valid; and
to validate the signed object pass all of the above checks; * the manifests for every certificate on the certificate path
used to validate the signed object, and the associated
publication points, pass all of the above checks;
then the relying party can conclude that no attack against the then the relying party can conclude that no attack against the
repository system has compromised the given signed object, and the repository system has compromised the given signed object, and the
signed object MUST be treated as valid. signed object MUST be treated as valid.
8.2. Missing Manifests 8.2. Missing Manifests
The absence of a valid manifest at a publication could occur due to The absence of a valid manifest at a publication point could occur
an error by the publisher or due to (malicious or accidental) due to an error by the publisher or due to (malicious or accidental)
deletion or corruption of all valid manifests. deletion or corruption of all valid manifests.
When no valid manifest is available, there is no protection against When no valid manifest is available, there is no protection against
attacks that delete signed objects or replay old versions of signed attacks that delete signed objects or replay old versions of signed
objects. All signed objects at the publication point, and all objects. All signed objects at the publication point, and all
descendent objects that are validated using a certificate at this descendant objects that are validated using a certificate at this
publication point should be viewed as somewhat suspect, but may be publication point should be viewed as somewhat suspect, but may be
used by the relying party as per local policy. used by the relying party, as per local policy.
The primary risk in using signed objects at this publication point is The primary risk in using signed objects at this publication point is
that a deleted CRL causes the relying party to improperly treat a that a deleted CRL causes the relying party to improperly treat a
revoked certificate as valid. This risk is somewhat mitigated if the revoked certificate as valid (and thus rely upon signed objects that
CRL for this publication point has a short time between thisUpdate are validated using that certificate). This risk is somewhat
and nextUpdate (and the current time is within this interval). The mitigated if the CRL for this publication point has a short time
risk in discarding signed objects at this publication point is that between thisUpdate and nextUpdate (and the current time is within
the relying party may incorrectly discard a large number of valid this interval). The risk in discarding signed objects at this
objects. This gives significant power to an adversary that is able publication point is that the relying party may incorrectly discard a
to corrupt all manifests at the publication point. large number of valid objects. This gives significant power to an
adversary that is able to delete all manifests at the publication
point.
Regardless of whether signed objects from this publication are deemed Regardless of whether signed objects from this publication are deemed
fit for use by the relying party, this situation should result in a fit for use by the relying party, this situation should result in a
warning to the effect that: "No manifest is available for <pub point warning to the effect that: "No manifest is available for <pub point
name>, and thus there may have been undetected deletions or replay name>, and thus there may have been undetected deletions or replay
substitutions from the publication point." substitutions from the publication point."
In the case where the relying party has access to a local cache of
previously issued manifests that are valid, the relying party MAY use
the most recently previously issued valid manifests for this RPKI
repository publication collection in this case for each entity that
publishes at his publication point.
8.3. Invalid Manifests 8.3. Invalid Manifests
The presence of invalid manifests at a publication point could occur The presence of invalid manifests at a publication point could occur
due to an error by the publisher or due to (malicious or accidental) due to an error by the publisher or due to (malicious or accidental)
corruption of a valid manifest. An invalid manifest MUST never be corruption of a valid manifest. An invalid manifest MUST never be
used even if the manifestNumber is greater than that on valid used even if the manifestNumber is greater than that on valid
manifests. manifests.
There are no risks associated with using signed objects at a There are no risks associated with using signed objects at a
publication point containing an invalid manifest, provided that a publication point containing an invalid manifest, provided that valid
valid manifest covering the signed objects is also present. manifests the collectively cover all the signed objects are also
present.
If an invalid manifest is present at a publication point that also If an invalid manifest is present at a publication point that also
contains one or more valid manifests, this situation should result in contains one or more valid manifests, this situation should result in
a warning to the effect that: "An invalid manifest was found at <pub a warning to the effect that: "An invalid manifest was found at <pub
point name>, this indicates an attack against the publication point point name>, this indicates an attack against the publication point
or an error by the publisher. Processing for this publication point or an error by the publisher. Processing for this publication point
will continue using the most recent valid manifest." will continue using the most recent valid manifest."
In the case where the relying party has access to a local cache of
previously issued manifests that are valid, the relying party MAY use
the locally cached most recently previously issued valid manifest
issued by the entity that issued the invalid manifest in this case.
8.4. Stale Manifests 8.4. Stale Manifests
A manifest is considered stale if the current time is after the A manifest is considered stale if the current time is after the
nextUpdate time for the manifest. This could be due to publisher nextUpdate time for the manifest. This could be due to publisher
failure to promptly publish a new manifest, or due to (malicious or failure to promptly publish a new manifest, or due to (malicious or
accidental) corruption of a more recent manifest. accidental) corruption of a more recent manifest.
All signed objects at the publication point, and all descendent All signed objects at the publication point, and all descendant
objects that are validated using a certificate at this publication objects that are validated using a certificate at this publication
point should be viewed as somewhat suspect, but may be used by the point should be viewed as somewhat suspect, but may be used by the
relying party as per local policy. relying party as per local policy.
The primary risk in using signed objects at this publication point is The primary risk in using signed objects at this publication point is
that a newer manifest exists that, if present, would indicate that that a newer manifest exists that, if present, would indicate that
certain objects are have been removed or replaced. (E.g. the new certain objects are have been removed or replaced. (e.g., the new
manifest if present might show the existence of a newer CRL and the manifest if present might show the existence of a newer CRL and the
removal of several revoked certificates). Thus use of objects on a removal of several revoked certificates). Thus use of objects on a
stale manifest may cause the relying party to incorrectly treat stale manifest may cause the relying party to incorrectly treat
several invalid objects as valid. The risk is that a stale CRL several invalid objects as valid. The risk is that a stale CRL
causes the relying party to improperly treat a revoked certificate as causes the relying party to improperly treat a revoked certificate as
valid. This risk is somewhat mitigated if the time between the valid. This risk is somewhat mitigated if the time between the
nextUpdate field of the manifest and the current time is short. The nextUpdate field of the manifest and the current time is short. The
risk in discarding signed objects at this publication point is that risk in discarding signed objects at this publication point is that
the relying party may incorrectly discard a large number of valid the relying party may incorrectly discard a large number of valid
objects. This gives significant power to an adversary that is able objects. This gives significant power to an adversary that is able
skipping to change at page 21, line 8 skipping to change at page 21, line 43
before the thisUpdate time for the manifest. This case could be due before the thisUpdate time for the manifest. This case could be due
to publisher error, or a local clock error, and in such a case this to publisher error, or a local clock error, and in such a case this
situation should result in a warning to the effect that: "The situation should result in a warning to the effect that: "The
manifest found at <pub point name> has an incorrect thisUpdate field. manifest found at <pub point name> has an incorrect thisUpdate field.
This could be due to publisher error, or a local clock error, and This could be due to publisher error, or a local clock error, and
processing for this publication point will continue using this processing for this publication point will continue using this
otherwise valid manifest." otherwise valid manifest."
8.5. Mismatch between Manifest and Publication Point 8.5. Mismatch between Manifest and Publication Point
If there exist otherwise valid signed objects that do not appear on If there exist otherwise valid signed objects that do not appear in
any manifest, then provided the manifest is not stale (see Section any manifest, then provided the manifest is not stale (see Section
Section 8.4) it is likely that their omission is an error by the Section 8.4) it is likely that their omission is an error by the
publisher. (If the objects were intended to be invalid, then they publisher. It is also possible that this state could be the result
should have been revoked using whatever revocation mechanism is of a (malicious or accidental) replacement of a current manifest with
appropriate for the signed object in question.) Therefore, there is an older, but still valid manifest. However, regarding the
little risk in using such signed objects. If the manifest in appropriate interpretation such objects, it remains the case that if
question is stale, then there is a greater risk that the objects in the objects were intended to be invalid, then they should have been
question were revoked with a missing CRL (whose absence is revoked using whatever revocation mechanism is appropriate for the
undetectable since the manifest is stale). In any case, the use of signed object in question.) Therefore, there is little risk in using
signed objects not present on a manifest (or descendent objects that such signed objects. If the manifest in question is stale, then
are validated using such signed objects) is a matter of local policy. there is a greater risk that the objects in question were revoked
with a missing CRL, whose absence 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.
Regardless of whether objects not appearing on a manifest are deemed Regardless of whether objects not appearing on a manifest are deemed
fit for use by the relying party, this situation should result in a fit for use by the relying party, this situation should result in a
warning to the effect that: "The following files are present in the warning to the effect that: "The following files are present in the
repository at <pub point name>, but are not on the manifest <file repository at <pub point name>, but are not on the manifest <file
list>." list>."
If there exist files listed on the manifest that do not appear in the If there exist files listed on the manifest that do not appear in the
repository, then these objects are likely to have been improperly repository, then these objects are likely to have been improperly
(via malice or accident) deleted from the manifest. A primary (via malice or accident) deleted from the manifest. A primary
skipping to change at page 21, line 45 skipping to change at page 22, line 35
by the publisher." by the publisher."
8.6. Hash Values Not Matching Manifests 8.6. Hash Values Not Matching Manifests
A file appearing on a manifest with an incorrect hash value could A file appearing on a manifest with an incorrect hash value could
occur because of publisher error, but it is likely to indicate that a occur because of publisher error, but it is likely to indicate that a
serious error has occurred. serious error has occurred.
If an object appeared on a previous valid manifest with a correct If an object appeared on a previous valid manifest with a correct
hash value and now appears with an invalid hash value, then it is hash value and now appears with an invalid hash value, then it is
likely that the object has been superceded by a new (unavailable) 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 version of the object. If the object is used there is a risk that
the relying party will be treating a stale object as valid. This the relying party will be treating a stale object as valid. This
risk is more significant if the object in question is a CRL. risk is more significant if the object in question is a CRL.
Assuming that the object is validated in the RPKI, the use of these Assuming that the object is validated in the RPKI, the use of these
objects is a matter of local policy. objects is a matter of local policy.
If an object appears on a manifest with an invalid hash and has never 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 previously appeared on a manifest, then it is unclear whether the
available version of the object is more or less recent than the available version of the object is more or less recent than the
version whose hash appears in the manifest. If the manifest is stale version whose hash appears in the manifest. If the manifest is stale
(see Section Section 8.4) then it becomes more likely that the (see Section 8.4) then it becomes more likely that the available
available version is more recent that the version indicated on the version is more recent that the version indicated on the manifest,
manifest, but this is never certain. Whether to use such objects is but this is never certain. Whether to use such objects is a matter
a matter of local policy. However, in general, it is better to use a of local policy. However, in general, it is better to use a possibly
possibly outdated version of the object than to discard the object outdated version of the object than to discard the object completely.
completely.
While it is a matter of local policy, in the case of CRLs a relying While it is a matter of local policy, in the case of CRLs a relying
party should endeavour to use the most recently issued valid CRL even party should endeavor to use the most recently issued valid CRL even
where the hash value in the manifest matches an older CRL, or does where the hash value in the manifest matches an older CRL, or does
not match any CRL hand. The ThisUpdate field of the CRL can be used not match any CRL hand. The thisUpdate field of the CRL can be used
to establish the most recent CRL in the case where a relying party to establish the most recent CRL in the case where a relying party
has more than one valid CRL at hand. has more than one valid CRL at hand.
Regardless of whether objects with incorrect hashes are deemed fit Regardless of whether objects with incorrect hashes are deemed fit
for use by the relying party, this situation should result in a for use by the relying party, this situation should result in a
warning to the effect that: "The following files at the repository warning to the effect that: "The following files at the repository
<pub point name> appear on a manifest with incorrect hash values <pub point name> appear on a manifest with incorrect hash values
<file list>. It is possible that these objects have been superseded <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 by a more recent version. It is very likely that this problem is due
to an attack on the publication point, although it could also be due to an attack on the publication point, although it could also be due
to a publisher error." to a publisher error."
9. Publication Repositories 9. Publication Repositories
The RPKI publication system model requires that every publication The RPKI publication system model requires that every publication
point be associated with a CA or an EE, and be non-empty. Upon point be associated with one or more CAs or one or more EEs, and be
creation of the publication point associated with a CA, the CA MUST non-empty. Upon creation of the publication point associated with a
create and publish a manifest as well as a CRL. The manifest will CA, the CA MUST create and publish a manifest as well as a CRL. The
contain at least one entry, the CRL issued by the CA upon repository manifest will contain at least one entry, the CRL issued by the CA
creation. Upon the creation of the publication point associated with upon repository creation. Upon the creation of the publication point
an EE, the EE MUST create and publish a manifest. The manifest in an associated with an EE, the EE MUST create and publish a manifest.
otherwise empty repository publication point associated with an EE The manifest in an otherwise empty repository publication point
will contain no entries in the manifest's fileList sequence (i.e. a associated with an EE will contain no entries in the manifest's
sequence of length zero). [ID.SIDR-REPOSITORY] fileList sequence (i.e., the ASN.1 SEQUENCE will have a length of
zero). [ID.sidr-repos-struct]
For signed objects EE certificate used in the verification of such For each signed object, the EE certificate used to verify the object
objects is either a single-use certificate, used to verify a single is either a single-use certificate, used to verify a single signed
signed object, or a multiple-use certificate. In the case of a object, or a multiple-use certificate. In the case of a single-use
single-use EE certificate, the signed object is published in the EE certificate, the signed object is published in the repository
repository publication point of the CA that issued the single use EE publication point of the CA that issued the single use EE
certificate, and is listed in the manifest associated with that CA certificate, and is listed in the manifest associated with that CA
certificate. In the case where the EE certificate is used to verify certificate. In the case where an EE certificate is used to verify
multiple objects, signed object is published in the EE certificate's multiple objects, each signed object is published in the EE
repository publication point and listed in the manifest associated certificate's repository publication point and listed in the manifest
with the EE certificate. associated with the EE certificate.
10. Security Considerations 10. Security Considerations
Manifests provide an additional level of protection for users of the Manifests provide an additional level of protection for relying
repository system. Manifests can assist the user to determine if parties of the repository system. Manifests can assist a relying
repository objects have been occluded or other removed from view, and party to determine if repository objects have been occluded or other
to determine if an older version of an object has been substituted removed from view, and to determine if an older version of an object
for the current object. has been substituted for the current object .
Manifests cannot repair the effects of such forms of attempted Manifests cannot repair the effects of such forms of attempted
corruption of repository retrieval operations, but are capable of corruption of repository retrieval operations, but are capable of
allowing the user to determine if a locally maintained copy of a allowing a relying party to determine if a locally maintained copy of
repository is a complete and up to date copy, even when the a repository is a complete and up to date copy, even when the
repository retrieval operation is conduction over an insecure repository retrieval operation is conduction over an insecure
channel. In those cases where the manifest and the retrieved channel. In those cases where the manifest and the retrieved
repository contents differ, the manifest can assist in determining repository contents differ, the manifest can assist in determining
which repository objects form the difference set in terms of missing, which repository objects form the difference set in terms of missing,
extraneous or older objects. extraneous or older objects .
The signing structure of a manifest and the use of next update times The signing structure of a manifest and the use of the nextUpdate
allows the user to determine if the manifest itself is the subject of value allows the relying party to determine if the manifest itself is
attempted alteration. The requirement for all repositories to the subject of attempted alteration. The requirement for every
contain manifests allows the user to determine is the manifest itself repository publication point to contain at least one manifest allows
has been occluded from view. Such attacks against the manifest are a relying party to determine is the manifest itself has been occluded
detectable within the timeframe of the regular schedule of manifest from view. Such attacks against the manifest are detectable within
updates. Forms of replay attack within finer-grained timeframes are the time frame of the regular schedule of manifest updates. Forms of
not necessarily detectable by the manifest structure. replay attack within finer-grained time frames are not necessarily
detectable by the manifest structure .
11. IANA Considerations 11. IANA Considerations
[Note to IANA, to be removed prior to publication: there are no IANA [Note to IANA, to be removed prior to publication: there are no IANA
considerations stated in this version of the document.] considerations stated in this version of the document.]
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the contributions from George The authors would like to acknowledge the contributions from George
Michaelson and Randy Bush in the preparation of the manifest Michelson and Randy Bush in the preparation of the manifest
specification. Additionally, the authors would like to thank Mark specification. Additionally, the authors would like to thank Mark
Reynolds and Christopher Small for assistance in clarifying manifest Reynolds and Christopher Small for assistance in clarifying manifest
validation and relying party behavior. validation and relying party behavior.
13. Normative References 13. Normative References
[ID.SIDR-ARCH] [ID.sidr-arch]
Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure Lepinski, M., Kent, S., and R. Barnes, "An Infrastructure
to Support Secure Internet Routing", Work in progress: to Support Secure Internet Routing", Work in progress:
Internet Drafts draft-ietf-sidr-arch-03.txt, Internet Drafts draft-ietf-sidr-arch-03.txt,
February 2008. February 2008.
[ID.SIDR-CERTPROFILE] [ID.sidr-repos-struct]
Huston, G., Michaleson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Work in progress:
Internet Drafts draft-ietf-sidr-res-certs-10.txt,
June 2008.
[ID.SIDR-REPOSITORY]
Huston, G., Loomans, R., and G. Michaleson, "A Profile for Huston, G., Loomans, R., and G. Michaleson, "A Profile for
Resource Certificate Repository Structure", Work in Resource Certificate Repository Structure", Work in
progress: Internet progress: Internet
Drafts draft-huston-sidr-repos-struct-02.txt, June 2008. Drafts draft-huston-sidr-repos-struct-02.txt, June 2008.
[ID.sidr-res-certs]
Huston, G., Michaleson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", Work in progress:
Internet Drafts draft-ietf-sidr-res-certs-10.txt,
June 2008.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP [RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
Addresses and AS Identifiers", RFC 3779, June 2004. Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, July 2004. RFC 3852, July 2004.
[RFC4049] Housley, R., "BinaryTime: An Alternate Format for [RFC4049] Housley, R., "BinaryTime: An Alternate Format for
Representing Date and Time in ASN.1", RFC 4049, Representing Date and Time in ASN.1", RFC 4049,
April 2005. April 2005.
skipping to change at page 25, line 14 skipping to change at page 26, line 4
Authors' Addresses Authors' Addresses
Rob Austein Rob Austein
Internet Systems Consortium Internet Systems Consortium
950 Charter St. 950 Charter St.
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
Email: sra@isc.org Email: sra@isc.org
Geoff Huston Geoff Huston
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
33 park Rd. 33 Park Rd.
Milton, QLD 4064 Milton, QLD 4064
Australia Australia
Email: gih@apnic.net Email: gih@apnic.net
URI: http://www.apnic.net URI: http://www.apnic.net
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton St. 10 Moulton St.
Cambridge, MA 02138 Cambridge, MA 02138
 End of changes. 73 change blocks. 
185 lines changed or deleted 224 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/