rfc9286.original   rfc9286.txt 
SIDROPS R. Austein Internet Engineering Task Force (IETF) R. Austein
Internet-Draft Arrcus, Inc. Request for Comments: 9286 Arrcus, Inc.
Obsoletes: 6486 (if approved) G. Huston Obsoletes: 6486 G. Huston
Intended status: Standards Track APNIC Category: Standards Track APNIC
Expires: 25 September 2022 S. Kent ISSN: 2070-1721 S. Kent
Independent Independent
M. Lepinski M. Lepinski
New College Florida New College Florida
24 March 2022 May 2022
Manifests for the Resource Public Key Infrastructure (RPKI) Manifests for the Resource Public Key Infrastructure (RPKI)
draft-ietf-sidrops-6486bis-11
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 (RPKI). A manifest is a signed object (file) that Infrastructure (RPKI). A manifest is a signed object (file) that
contains a listing of all the signed objects (files) in the contains a listing of all the signed objects (files) in the
repository publication point (directory) associated with an authority repository publication point (directory) associated with an authority
responsible for publishing in the repository. For each certificate, responsible for publishing in the repository. For each certificate,
Certificate Revocation List (CRL), or other type of signed objects Certificate Revocation List (CRL), or other type of signed objects
issued by the authority that are published at this repository issued by the authority that are published at this repository
skipping to change at page 1, line 36 skipping to change at line 34
containing the object and a hash of the file content. Manifests are containing the object and a hash of the file content. Manifests are
intended to enable a relying party (RP) to detect certain forms of intended to enable a relying party (RP) to detect certain forms of
attacks against a repository. Specifically, if an RP checks a attacks against a repository. Specifically, if an RP checks a
manifest's contents against the signed objects retrieved from a manifest's contents against the signed objects retrieved from a
repository publication point, then the RP can detect replay attacks, repository publication point, then the RP can detect replay attacks,
and unauthorized in-flight modification or deletion of signed and unauthorized in-flight modification or deletion of signed
objects. This document obsoletes RFC 6486. objects. This document obsoletes RFC 6486.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 25 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9286.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language
2. Manifest Scope . . . . . . . . . . . . . . . . . . . . . . . 4 2. Manifest Scope
3. Manifest Signing . . . . . . . . . . . . . . . . . . . . . . 4 3. Manifest Signing
4. Manifest Definition . . . . . . . . . . . . . . . . . . . . . 4 4. Manifest Definition
4.1. eContentType . . . . . . . . . . . . . . . . . . . . . . 4 4.1. eContentType
4.2. eContent . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. eContent
4.2.1. Manifest . . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Manifest
4.2.2. Names in FileAndHash objects . . . . . . . . . . . . 7 4.2.2. Names in FileAndHash Objects
4.3. Content-Type Attribute . . . . . . . . . . . . . . . . . 7 4.3. Content-Type Attribute
4.4. Manifest Validation . . . . . . . . . . . . . . . . . . . 7 4.4. Manifest Validation
5. Manifest Generation . . . . . . . . . . . . . . . . . . . . . 8 5. Manifest Generation
5.1. Manifest Generation Procedure . . . . . . . . . . . . . . 8 5.1. Manifest Generation Procedure
5.2. Considerations for Manifest Generation . . . . . . . . . 9 5.2. Considerations for Manifest Generation
6. Relying Party Processing of Manifests . . . . . . . . . . . . 10 6. Relying Party Processing of Manifests
6.1. Manifest Processing Overview . . . . . . . . . . . . . . 11 6.1. Manifest Processing Overview
6.2. Acquiring a Manifest for a CA . . . . . . . . . . . . . . 11 6.2. Acquiring a Manifest for a CA
6.3. Detecting Stale and or Prematurely-issued Manifests . . . 12 6.3. Detecting Stale and/or Prematurely Issued Manifests
6.4. Acquiring Files Referenced by a Manifest . . . . . . . . 12 6.4. Acquiring Files Referenced by a Manifest
6.5. Matching File Names and Hashes . . . . . . . . . . . . . 12 6.5. Matching File Names and Hashes
6.6. Failed Fetches . . . . . . . . . . . . . . . . . . . . . 12 6.6. Failed Fetches
7. Publication Repositories . . . . . . . . . . . . . . . . . . 13 7. Publication Repositories
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. References
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References
11.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. ASN.1 Module
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 15 Appendix B. Changes since RFC 6486
Appendix B. Changes since RFC 6486 . . . . . . . . . . . . . . . 16 Acknowledgements
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses
1. Introduction 1. Introduction
The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of The Resource Public Key Infrastructure (RPKI) [RFC6480] makes use of
a distributed repository system [RFC6481] to make available a variety a distributed repository system [RFC6481] to make available a variety
of objects needed by relying parties (RPs). Because all of the of objects needed by relying parties (RPs). Because all of the
objects stored in the repository system are digitally signed by the objects stored in the repository system are digitally signed by the
entities that created them, attacks that modify these published entities that created them, attacks that modify these published
objects are detectable by RPs. However, digital signatures alone objects are detectable by RPs. However, digital signatures alone
provide no protection against attacks that substitute "stale" provide no protection against attacks that substitute "stale"
skipping to change at page 3, line 41 skipping to change at line 131
repository. Manifests are intended to be used in Certification repository. Manifests are intended to be used in Certification
Authority (CA) publication points in repositories (directories Authority (CA) publication points in repositories (directories
containing files that are subordinate certificates and Certificate containing files that are subordinate certificates and Certificate
Revocation Lists (CRLs) issued by this CA and other signed objects Revocation Lists (CRLs) issued by this CA and other signed objects
that are verified by End-Entity (EE) certificates issued by this CA). that are verified by End-Entity (EE) certificates issued by this CA).
Manifests are modeled on CRLs, as the issues involved in detecting Manifests are modeled on CRLs, as the issues involved in detecting
stale manifests and potential attacks using manifest replays, etc., stale manifests and potential attacks using manifest replays, etc.,
are similar to those for CRLs. The syntax of the manifest payload are similar to those for CRLs. The syntax of the manifest payload
differs from CRLs, since RPKI repositories contain objects not differs from CRLs, since RPKI repositories contain objects not
covered by CRLs, e.g., digitally signed objects, such as Route covered by CRLs, e.g., digitally signed objects, such as Route Origin
Origination Authorizations (ROAs) [RFC6482]. Authorizations (ROAs) [RFC6482].
This document obsoletes [RFC6486]. This document obsoletes [RFC6486].
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Manifest Scope 2. Manifest Scope
A manifest associated with a CA's repository publication point A manifest associated with a CA's repository publication point
contains a list of: contains a list of:
* the set of (non-expired, non-revoked) certificates issued and * the set of (non-expired, non-revoked) certificates issued and
published by this CA, published by this CA,
skipping to change at page 4, line 36 skipping to change at line 175
repository publication point will contain multiple manifests. In repository publication point will contain multiple manifests. In
this case, each manifest describes only the collection of published this case, each manifest describes only the collection of published
products of its associated CA instance. products of its associated CA instance.
3. Manifest Signing 3. Manifest Signing
A CA's manifest is verified using an EE certificate. The A CA's manifest is verified using an EE certificate. The
SubjectInfoAccess (SIA) field of this EE certificate contains the SubjectInfoAccess (SIA) field of this EE certificate contains the
access method Object Identifier (OID) of id-ad-signedObject. access method Object Identifier (OID) of id-ad-signedObject.
The CA MUST sign only one manifest with each generated private key, The CA MUST sign only one manifest with each generated private key
and MUST generate a new key pair for each new version of the and MUST generate a new key pair for each new version of the
manifest. This form of use of the associated EE certificate is manifest. An associated EE certificate used in this fashion is
termed a "one-time-use" EE certificate [RFC6487]. termed a "one-time-use" EE certificate (see Section 3 of [RFC6487]).
4. Manifest Definition 4. Manifest Definition
A manifest is an RPKI signed object, as specified in [RFC6488]. The A manifest is an RPKI signed object, as specified in [RFC6488]. The
RPKI signed object template requires specification of the following RPKI signed object template requires specification of the following
data elements in the context of the manifest structure. data elements in the context of the manifest structure.
4.1. eContentType 4.1. eContentType
The eContentType for a manifest is defined as id-ct-rpkiManifest and The eContentType for a manifest is defined as id-ct-rpkiManifest and
has the numerical object identifier of 1.2.840.113549.1.9.16.1.26. has the numerical OID of 1.2.840.113549.1.9.16.1.26.
id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs9(9) 16 } rsadsi(113549) pkcs(1) pkcs9(9) 16 }
id-ct OBJECT IDENTIFIER ::= { id-smime 1 } id-ct OBJECT IDENTIFIER ::= { id-smime 1 }
id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 } id-ct-rpkiManifest OBJECT IDENTIFIER ::= { id-ct 26 }
4.2. eContent 4.2. eContent
skipping to change at page 6, line 4 skipping to change at line 238
that coincides with the interval from thisUpdate to nextUpdate in the that coincides with the interval from thisUpdate to nextUpdate in the
manifest, to prevent needless growth of the CA's CRL. manifest, to prevent needless growth of the CA's CRL.
The data elements of the manifest structure are defined as follows: The data elements of the manifest structure are defined as follows:
version: version:
The version number of this version of the manifest specification The version number of this version of the manifest specification
MUST be 0. MUST be 0.
manifestNumber: manifestNumber:
This field is an integer that is incremented (by 1) each time a This field is an integer that is incremented (by 1) each time a
new manifest is issued for a given publication point. This field new manifest is issued for a given publication point. This field
allows an RP to detect gaps in a sequence of published manifests. allows an RP to detect gaps in a sequence of published manifests.
As the manifest is modeled on the CRL specification, the As the manifest is modeled on the CRL specification, the
ManifestNumber is analogous to the CRLNumber, and the guidance in manifestNumber is analogous to the CRLNumber, and the guidance in
[RFC5280] for CRLNumber values is appropriate as to the range of [RFC5280] for CRLNumber values is appropriate as to the range of
number values that can be used for the manifestNumber. Manifest number values that can be used for the manifestNumber. Manifest
numbers can be expected to contain long integers. Manifest numbers can be expected to contain long integers. Manifest
verifiers MUST be able to process number values up to 20 octets. verifiers MUST be able to process number values up to 20 octets.
Conforming manifest issuers MUST NOT use number values longer than Conforming manifest issuers MUST NOT use number values longer than
20 octets. The issuer MUST increase the value of this field 20 octets. The issuer MUST increase the value of this field
monotonically for each newly-generated Manifest. Each RP MUST monotonically for each newly generated manifest. Each RP MUST
verify that a purported "new" Manifest contains a higher verify that a purported "new" manifest contains a higher
manifestNumber than previously-validated Manifests. If the manifestNumber than previously validated manifests. If the
purported "new" Manifest contains an equal or lower manifestNumber purported "new" manifest contains a manifestNumber value equal to
than previously-validated Manifests, the RP SHOULD use locally or lower than manifestNumber values of previously validated
cached versions of objects, as described in Section 6.6. manifests, the RP SHOULD use locally cached versions of objects,
as described in Section 6.6.
thisUpdate: thisUpdate:
This field contains the time when the manifest was created. This This field contains the time when the manifest was created. This
field has the same format constraints as specified in [RFC5280] field has the same format constraints as specified in [RFC5280]
for the CRL field of the same name. The issuer MUST ensure that for the CRL field of the same name. The issuer MUST ensure that
the value of this field is more recent than any previously- the value of this field is more recent than any previously
generated Manifest. Each RP MUST verify that this field value is generated manifest. Each RP MUST verify that this field value is
greater (more recent) than the most recent Manifest it has greater (more recent) than the most recent manifest it has
validated. If this field in a purported "new" Manifest is smaller validated. If this field in a purported "new" manifest is smaller
(less recent) than previously-validated Manifests, the RP SHOULD (less recent) than previously validated manifests, the RP SHOULD
use locally cached versions of objects, as described in use locally cached versions of objects, as described in
Section 6.6. Section 6.6.
nextUpdate: nextUpdate:
This field contains the time at which the next scheduled manifest This field contains the time at which the next scheduled manifest
will be issued. The value of nextUpdate MUST be later than the will be issued. The value of nextUpdate MUST be later than the
value of thisUpdate. The specification of the GeneralizedTime value of thisUpdate. The specification of the GeneralizedTime
value is the same as required for the thisUpdate field. value is the same as required for the thisUpdate field.
If the authority alters any of the items that it has published in If the authority alters any of the items that it has published in
the repository publication point, then the authority MUST issue a the repository publication point, then the authority MUST issue a
new manifest. Even if no changes are made to objects at a new manifest. Even if no changes are made to objects at a
publication point, a new manifest MUST be issued before the publication point, a new manifest MUST be issued before the
nextUpdate time. Each manifest encompasses a CRL, and the nextUpdate time. Each manifest encompasses a CRL, and the
nextUpdate field of the manifest SHOULD match that of the CRL's nextUpdate field of the manifest SHOULD match that of the CRL's
nextUpdate field, as the manifest will be re-issued when a new CRL nextUpdate field, as the manifest will be reissued when a new CRL
is published. When a new manifest is issued before the time is published. When a new manifest is issued before the time
specified in nextUpdate of the current manifest, the CA MUST also specified in nextUpdate of the current manifest, the CA MUST also
issue a new CRL that revokes the EE certificate corresponding to issue a new CRL that revokes the EE certificate corresponding to
the old manifest. the old manifest.
fileHashAlg: fileHashAlg:
This field contains the OID of the hash algorithm used to hash the This field contains the OID of the hash algorithm used to hash the
files that the authority has placed into the repository. The hash files that the authority has placed into the repository. The hash
algorithm used MUST conform to the RPKI Algorithms and Key Size algorithm used MUST conform to the RPKI Algorithms and Key Size
Profile specification [RFC7935]. Profile specification [RFC7935].
fileList: fileList:
This field is a sequence of FileAndHash objects. There is one This field is a sequence of FileAndHash objects. There is one
FileAndHash entry for each currently valid signed object that has FileAndHash entry for each currently valid signed object that has
been published by the authority (at this publication point). Each been published by the authority (at this publication point). Each
FileAndHash is an ordered pair consisting of the name of the file FileAndHash is an ordered pair consisting of the name of the file
in the repository publication point (directory) that contains the in the repository publication point (directory) that contains the
object in question and a hash of the file's contents. object in question and a hash of the file's contents.
4.2.2. Names in FileAndHash objects 4.2.2. Names in FileAndHash Objects
Names that appear in the fileList MUST consist of one or more Names that appear in the fileList MUST consist of one or more
characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _ characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or _
(UNDERSCORE), followed by a single . (DOT), followed by a three- (UNDERSCORE), followed by a single . (DOT), followed by a three-
letter extension. The extension MUST be one of those enumerated in letter extension. The extension MUST be one of those enumerated in
the "RPKI Repository Naming Scheme" registry maintained by IANA the "RPKI Repository Name Scheme" registry maintained by IANA
[IANA-NAMING]. [IANA-NAMING].
As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename. As an example, 'vixxBTS_TVXQ-2pmGOT7.cer' is a valid filename.
The example above contains a mix of uppercase and lowercase The example above contains a mix of uppercase and lowercase
characters in the filename. CAs and RPs MUST be able to perform characters in the filename. CAs and RPs MUST be able to perform
filesystem operations in a case-sensitive, case-preserving manner. filesystem operations in a case-sensitive, case-preserving manner.
4.3. Content-Type Attribute 4.3. Content-Type Attribute
skipping to change at page 8, line 5 skipping to change at line 335
To determine whether a manifest is valid, the RP MUST perform the To determine whether a manifest is valid, the RP MUST perform the
following checks in addition to those specified in [RFC6488]: following checks in addition to those specified in [RFC6488]:
1. The eContentType in the EncapsulatedContentInfo is id-ad- 1. The eContentType in the EncapsulatedContentInfo is id-ad-
rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). rpkiManifest (OID 1.2.840.113549.1.9.16.1.26).
2. The version of the rpkiManifest is 0. 2. The version of the rpkiManifest is 0.
3. In the rpkiManifest, thisUpdate precedes nextUpdate. 3. In the rpkiManifest, thisUpdate precedes nextUpdate.
Note: Although the thisUpdate and nextUpdate fields in the Manifest Note: Although the thisUpdate and nextUpdate fields in the manifest
eContent MUST match the corresponding fields in the CRL associated eContent MUST match the corresponding fields in the CRL associated
with the Manifest, RPs MUST NOT reject a manifest solely because with the manifest, RPs MUST NOT reject a manifest solely because
these fields are not identical. these fields are not identical.
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.
5. Manifest Generation 5. Manifest Generation
5.1. Manifest Generation Procedure 5.1. Manifest Generation Procedure
For a CA publication point in the RPKI repository system, a CA MUST For a CA publication point in the RPKI repository system, a CA MUST
perform the following steps to generate a manifest: perform the following steps to generate a manifest:
1. Generate a new key pair for use in a "one-time-use" EE 1. Generate a new key pair for use in a "one-time-use" EE
certificate. certificate.
2. Issue an EE certificate for this key pair. The CA MUST revoke 2. Issue an EE certificate for this key pair. The CA MUST revoke
the EE certificate used for the manifest being replaced. the EE certificate used for the manifest being replaced.
This EE certificate MUST have an SIA extension access description This EE certificate MUST have an SIA extension access description
field with an accessMethod OID value of id-ad-signedobject, where field with an accessMethod OID value of id-ad-signedObject, where
the associated accessLocation references the publication point of the associated accessLocation references the publication point of
the manifest as an object URL. (RPs are required to verify both the manifest as an object URL. (RPs are required to verify both
of these syntactic constraints.) of these syntactic constraints.)
This EE certificate MUST describe its Internet Number Resources This EE certificate MUST describe its Internet Number Resources
(INRs) using the "inherit" attribute, rather than explicit (INRs) using the "inherit" attribute, rather than an explicit
description of a resource set (see [RFC3779]). (RPs are required description of a resource set (see [RFC3779]). (RPs are required
to verify this.) to verify this.)
The validity interval of the EE certificate MUST exactly match The validity interval of the EE certificate MUST exactly match
the thisUpdate and nextUpdate times specified in the manifest's the thisUpdate and nextUpdate times specified in the manifest's
eContent. (An RP MUST NOT consider misalignment of the validity eContent. (An RP MUST NOT consider misalignment of the validity
interval misalignment in and of itself to be an error.) interval in and of itself to be an error.)
3. The EE certificate MUST NOT be published in the authority's 3. The EE certificate MUST NOT be published in the authority's
repository publication point. repository publication point.
4. Construct the manifest content. 4. Construct the manifest content.
The manifest content is described in Section 4.2.1. The The manifest content is described in Section 4.2.1. The
manifest's fileList includes the file name and hash pair for each manifest's fileList includes the file name and hash pair for each
object issued by this CA that has been published at this object issued by this CA that has been published at this
repository publication point (directory). The collection of repository publication point (directory). The collection of
objects to be included in the manifest includes all certificates objects to be included in the manifest includes all certificates
issued by this CA that are published at the CA's repository issued by this CA that are published at the CA's repository
publication point, the most recent CRL issued by the CA, and all publication point, the most recent CRL issued by the CA, and all
objects verified by EE certificates that were issued by this CA objects verified by EE certificates that were issued by this CA
that are published at this repository publication point. that are published at this repository publication point.
(Sections 6.1-5 describes the checks that an RP MUST perform in (Sections 6.1 through 6.5 describe the checks that an RP MUST
support of the manifest content noted here.) perform in support of the manifest content noted here.)
Note that the manifest does not include a self reference (i.e., Note that the manifest does not include a self reference (i.e.,
its own file name and hash), since it would be impossible to its own file name and hash), since it would be impossible to
compute the hash of the manifest itself prior to it being signed. compute the hash of the manifest itself prior to it being signed.
5. Encapsulate the manifest content using the CMS SignedData content 5. Encapsulate the manifest content using the CMS SignedData content
type (as specified Section 4), sign the manifest using the type (as specified in Section 4), sign the manifest using the
private key corresponding to the subject key contained in the EE private key corresponding to the subject key contained in the EE
certificate, and publish the manifest in the repository system certificate, and publish the manifest in the repository system
publication point that is described by the manifest. (RPs are publication point that is described by the manifest. (RPs are
required to verify the CMS signature.) required to verify the CMS signature.)
6. Because the key pair is to be used only once, the private key 6. Because the key pair is to be used only once, the private key
associated with this key pair MUST now be destroyed. associated with this key pair MUST now be destroyed.
5.2. Considerations for Manifest Generation 5.2. Considerations for Manifest Generation
skipping to change at page 10, line 34 skipping to change at line 461
As noted earlier, manifests are designed to allow an RP to detect As noted earlier, manifests are designed to allow an RP to detect
manipulation of repository data, errors by a CA or repository manipulation of repository data, errors by a CA or repository
manager, and/or active attacks on the communication channel between manager, and/or active attacks on the communication channel between
an RP and a repository. Unless all of the files enumerated in a an RP and a repository. Unless all of the files enumerated in a
manifest can be obtained by an RP during a fetch operation, the fetch manifest can be obtained by an RP during a fetch operation, the fetch
is considered to have failed and the RP MUST retry the fetch later. is considered to have failed and the RP MUST retry the fetch later.
[RFC6480] suggests (but does not mandate) that the RPKI model employ [RFC6480] suggests (but does not mandate) that the RPKI model employ
fetches that are incremental, e.g., an RP transfers files from a fetches that are incremental, e.g., an RP transfers files from a
publication point only if they are new/changed since the previous, publication point only if they are new/changed since the previous,
successful, fetch represented in the RP's local cache. This document successful fetch represented in the RP's local cache. This document
avoids language that relies on details of the underlying file avoids language that relies on details of the underlying file
transfer mechanism employed by an RP and a publication point to transfer mechanism employed by an RP and a publication point to
effect this operation. Thus the term "fetch" refers to an operation effect this operation. Thus, the term "fetch" refers to an operation
that attempts to acquire the full set of files at a publication that attempts to acquire the full set of files at a publication
point, consistent with the id-ad-rpkiManifest URI extracted from a CA point, consistent with the id-ad-rpkiManifest URI extracted from a CA
certificate's SIA (see below). certificate's SIA (see below).
If a fetch fails, it is assumed that a subsequent fetch will resolve If a fetch fails, it is assumed that a subsequent fetch will resolve
problems encountered during the fetch. Until such time as a problems encountered during the fetch. Until such time as a
successful fetch is executed, an RP SHOULD use cached data from a successful fetch is executed, an RP SHOULD use cached data from a
previous, successful fetch. This response is intended to prevent an previous, successful fetch. This response is intended to prevent an
RP from misinterpreting data associated with a publication point, and RP from misinterpreting data associated with a publication point and
thus possibly treating invalid routes as valid, or vice versa. thus possibly treating invalid routes as valid, or vice versa.
The processing described below is designed to cause all RPs with The processing described below is designed to cause all RPs with
access to the same local cache and RPKI repository data to acquire access to the same local cache and RPKI repository data to acquire
the same set of validated repository files. It does not ensure that the same set of validated repository files. It does not ensure that
the RPs will achieve the same results with regard to validation of the RPs will achieve the same results with regard to validation of
RPKI data, since that depends on how each RP resolves any conflicts RPKI data, since that depends on how each RP resolves any conflicts
that may arise in processing the retrieved files. Moreover, in that may arise in processing the retrieved files. Moreover, in
operation, different RPs will access repositories at different times, operation, different RPs will access repositories at different times,
and some RPs may experience local cache failures, so there is no and some RPs may experience local cache failures, so there is no
guarantee that all RPs will achieve the same results with regard to guarantee that all RPs will achieve the same results with regard to
acquisition or validation of RPKI data. acquisition or validation of RPKI data.
Note also that there is a "chicken and egg" relationship between the Note also that there is a "chicken and egg" relationship between the
manifest and the CRL for a given CA instance. If the EE certificate manifest and the CRL for a given CA instance. If the EE certificate
for the current manifest is revoked, i.e., it appears in the current for the current manifest is revoked, i.e., it appears in the current
CRL, then the CA or publication point manager has made a serious CRL, then the CA or publication point manager has made a serious
error. In this case the fetch has failed; proceed to Section 6.6. error. In this case, the fetch has failed; proceed to Section 6.6.
Similarly, if the CRL is not listed on a valid, current manifest, Similarly, if the CRL is not listed on a valid, current manifest,
acquired during a fetch, the fetch has failed; proceed to acquired during a fetch, the fetch has failed; proceed to
Section 6.6, because the CRL is considered missing. Section 6.6, because the CRL is considered missing.
6.1. Manifest Processing Overview 6.1. Manifest Processing Overview
For a given publication point, an RP MUST perform a series of tests For a given publication point, an RP MUST perform a series of tests
to determine which signed object files at the publication point are to determine which signed object files at the publication point are
acceptable. The tests described below (Section 6.2 to Section 6.5) acceptable. The tests described below (Sections 6.2 through 6.5) are
are to be performed using the manifest identified by the id-ad- to be performed using the manifest identified by the id-ad-
rpkiManifest URI extracted from a CA certificate's SIA. All of the rpkiManifest URI extracted from a CA certificate's SIA. All of the
files referenced by the manifest MUST be located at the publication files referenced by the manifest MUST be located at the publication
point specified by the id-ad-caRepository URI from the (same) CA point specified by the id-ad-caRepository URI from the (same) CA
certificate's SIA. The manifest and the files it references MUST certificate's SIA. The manifest and the files it references MUST
reside at the same publication point. If an RP encounters any files reside at the same publication point. If an RP encounters any files
that appear on a manifest but do not reside at the same publication that appear on a manifest but do not reside at the same publication
point as the manifest the RP MUST treat the fetch as failed, and a point as the manifest, the RP MUST treat the fetch as failed, and a
warning MUST be issued (see Section 6.6 below). warning MUST be issued (see Section 6.6 below).
Note that, during CA key rollover [RFC6489], signed objects for two Note that, during CA key rollover [RFC6489], signed objects for two
or more different CA instances will appear at the same publication or more different CA instances will appear at the same publication
point. Manifest processing is to be performed separately for each CA point. Manifest processing is to be performed separately for each CA
instance, guided by the SIA id-ad-rpkiManifest URI in each CA instance, guided by the SIA id-ad-rpkiManifest URI in each CA
certificate. certificate.
6.2. Acquiring a Manifest for a CA 6.2. Acquiring a Manifest for a CA
The RP MUST fetch the manifest identified by the SIA id-ad- The RP MUST fetch the manifest identified by the SIA id-ad-
rpkiManifest URI in the CA certificate. If an RP cannot retrieve a rpkiManifest URI in the CA certificate. If an RP cannot retrieve a
manifest using this URI, or if the manifest is not valid manifest using this URI or if the manifest is not valid
(Section 4.4), an RP MUST treat this as a failed fetch and proceed to (Section 4.4), an RP MUST treat this as a failed fetch and proceed to
Section 6.6; otherwise proceed to Section 6.3. Section 6.6; otherwise, proceed to Section 6.3.
6.3. Detecting Stale and or Prematurely-issued Manifests 6.3. Detecting Stale and/or Prematurely Issued Manifests
The RP MUST check that the current time (translated to UTC) is The RP MUST check that the current time (translated to UTC) is
between thisUpdate and nextUpdate. If the current time lies within between thisUpdate and nextUpdate. If the current time lies within
this interval, proceed to Section 6.4. If the current time is this interval, proceed to Section 6.4. If the current time is
earlier than thisUpdate, the CA may have made an error or the RP's earlier than thisUpdate, the CA may have made an error or the RP's
local notion of time may be in error; the RP MUST treat this as a local notion of time may be in error; the RP MUST treat this as a
failed fetch and proceed to Section 6.6. If the current time is failed fetch and proceed to Section 6.6. If the current time is
later than nextUpdate, then the manifest is stale; this is a failed later than nextUpdate, then the manifest is stale; this is a failed
fetch and RP MUST proceed to Section 6.6; otherwise proceed to fetch, and the RP MUST proceed to Section 6.6; otherwise, proceed to
Section 6.4. Section 6.4.
6.4. Acquiring Files Referenced by a Manifest 6.4. Acquiring Files Referenced by a Manifest
The RP MUST acquire all of the files enumerated in the manifest The RP MUST acquire all of the files enumerated in the manifest
(fileList) from the publication point. If there are files listed in (fileList) from the publication point. If there are files listed in
the manifest that cannot be retrieved from the publication point, the the manifest that cannot be retrieved from the publication point, the
fetch has failed and the RP MUST proceed to Section 6.6; otherwise, fetch has failed and the RP MUST proceed to Section 6.6; otherwise,
proceed to Section 6.5. proceed to Section 6.5.
skipping to change at page 12, line 36 skipping to change at line 556
The RP MUST verify that the hash value of each file listed in the The RP MUST verify that the hash value of each file listed in the
manifest matches the value obtained by hashing the file acquired from manifest matches the value obtained by hashing the file acquired from
the publication point. If the computed hash value of a file listed the publication point. If the computed hash value of a file listed
on the manifest does not match the hash value contained in the on the manifest does not match the hash value contained in the
manifest, then the fetch has failed and the RP MUST proceed to manifest, then the fetch has failed and the RP MUST proceed to
Section 6.6. Section 6.6.
6.6. Failed Fetches 6.6. Failed Fetches
If a fetch fails for any of the reasons cited in 6.2-6.5, the RP MUST If a fetch fails for any of the reasons cited in Sections 6.2 through
issue a warning indicating the reason(s) for termination of 6.5, the RP MUST issue a warning indicating the reason(s) for
processing with regard to this CA instance. It is RECOMMENDED that a termination of processing with regard to this CA instance. It is
human operator be notified of this warning. RECOMMENDED that a human operator be notified of this warning.
Termination of processing means that the RP SHOULD continue to use Termination of processing means that the RP SHOULD continue to use
cached versions of the objects associated with this CA instance, cached versions of the objects associated with this CA instance,
until such time as they become stale or they can be replaced by until such time as they become stale or they can be replaced by
objects from a successful fetch. This implies that the RP MUST NOT objects from a successful fetch. This implies that the RP MUST NOT
try to acquire and validate subordinate signed objects, e.g., try to acquire and validate subordinate signed objects, e.g.,
subordinate CA certificates, until the next interval when the RP is subordinate CA certificates, until the next interval when the RP is
scheduled to fetch and process data for this CA instance. scheduled to fetch and process data for this CA instance.
7. Publication Repositories 7. Publication Repositories
The RPKI publication system model requires that every publication The RPKI publication system model requires that every publication
point be associated with one or more CAs, and be non-empty. Upon point be associated with one or more CAs and be non-empty. Upon
creation of the publication point associated with a CA, the CA MUST creation of the publication point associated with a CA, the CA MUST
create and publish a manifest as well as a CRL. A CA's manifest will create and publish a manifest as well as a CRL. A CA's manifest will
always contain at least one entry, i.e., a CRL issued by the CA always contain at least one entry, i.e., a CRL issued by the CA
[RFC6481],corresponding to the scope of this manifest. [RFC6481], corresponding to the scope of this manifest.
Every published signed object in the RPKI [RFC6488] is published in Every published signed object in the RPKI [RFC6488] is published in
the repository publication point of the CA that issued the EE the repository publication point of the CA that issued the EE
certificate, and is listed in the manifest associated with that CA certificate, and is listed in the manifest associated with that CA
certificate. certificate.
8. Security Considerations 8. Security Considerations
Manifests provide an additional level of protection for RPKI RPs. Manifests provide an additional level of protection for RPKI RPs.
Manifests can assist an RP to determine if a repository object has Manifests can assist an RP in determining if a repository object has
been deleted, occluded, or otherwise removed from view, or if a been deleted, occluded, or otherwise removed from view, or if a
publication of a newer version of an object has been suppressed (and publication of a newer version of an object has been suppressed (and
an older version of the object has been substituted). an older version of the object has been substituted).
Manifests cannot repair the effects of such forms of corruption of Manifests cannot repair the effects of such forms of corruption of
repository retrieval operations. However, a manifest enables an RP repository retrieval operations. However, a manifest enables an RP
to determine if a locally maintained copy of a repository is a to determine if a locally maintained copy of a repository is a
complete and up-to-date copy, even when the repository retrieval complete and up-to-date copy, even when the repository retrieval
operation is conducted over an insecure channel. In cases where the operation is conducted over an insecure channel. In cases where the
manifest and the retrieved repository contents differ, the manifest manifest and the retrieved repository contents differ, the manifest
can assist in determining which repository objects form the can assist in determining which repository objects form the
difference set in terms of missing, extraneous, or superseded difference set in terms of missing, extraneous, or superseded
objects. objects.
The signing structure of a manifest and the use of the nextUpdate The signing structure of a manifest and the use of the nextUpdate
value allows an RP to determine if the manifest itself is the subject value allow an RP to determine if the manifest itself is the subject
of attempted alteration. The requirement for every repository of attempted alteration. The requirement for every repository
publication point to contain at least one manifest allows an RP to publication point to contain at least one manifest allows an RP to
determine if the manifest itself has been occluded from view. Such determine if the manifest itself has been occluded from view. Such
attacks against the manifest are detectable within the time frame of attacks against the manifest are detectable within the time frame of
the regular schedule of manifest updates. Forms of replay attack the regular schedule of manifest updates. Forms of replay attacks
within finer-grained time frames are not necessarily detectable by within finer-grained time frames are not necessarily detectable by
the manifest structure. the manifest structure.
9. IANA Considerations 9. IANA Considerations
As [RFC6488] created and populated the registries "RPKI Signed The "RPKI Signed Objects" registry was originally created and
Object" and three-letter filename extensions for "RPKI Repository populated by [RFC6488]. The "RPKI Repository Name Schemes" registry
Name Schemes," no new action is requested of the IANA. was created by [RFC6481] and created four of the initial three-letter
filename extensions. IANA has updated the reference for Manifest in
10. Acknowledgements the "RPKI Signed Objects" registry to point to this document. No
other actions are are required.
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 Tim
Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto
Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, Lars
Eggert, Robert Wilton, and Benjamin Kaduk for their helpful review of
this document.
11. References 10. References
11.1. Normative References 10.1. Normative References
[IANA-NAMING] [IANA-NAMING]
"RPKI Repository Name Schemes", IANA, "RPKI Repository Name Schemes",
<https://www.iana.org/assignments/rpki/rpki.xhtml#name- <https://www.iana.org/assignments/rpki/>.
schemes>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
skipping to change at page 15, line 19 skipping to change at line 668
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[X.690] "X.690", [X.690] International Telecommunication Union, "Information
<https://www.itu.int/rec/T-REC-X.690-199511-S!Cor1>. technology - ASN.1 encoding rules: Specification of Basic
Encoding Rules (BER), Canonical Encoding Rules (CER) and
Distinguished Encoding Rules (DER)", ITU-T Recommendation
X.690, February 2021,
<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
11.2. Informative References 10.2. Informative References
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<https://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[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, Addresses and AS Identifiers", RFC 3779,
DOI 10.17487/RFC3779, June 2004, DOI 10.17487/RFC3779, June 2004,
<https://www.rfc-editor.org/info/rfc3779>. <https://www.rfc-editor.org/info/rfc3779>.
skipping to change at page 16, line 47 skipping to change at line 748
FileAndHash ::= SEQUENCE { FileAndHash ::= SEQUENCE {
file IA5String, file IA5String,
hash BIT STRING hash BIT STRING
} }
END END
Appendix B. Changes since RFC 6486 Appendix B. Changes since RFC 6486
In 2019, it came to light that multiple Relying Party implementations In 2019, it came to light that multiple RP implementations were in a
were in a vulnerable position, possibly due to perceived ambiguity in vulnerable position, possibly due to perceived ambiguity in the
the original [RFC6486] specification. This document attempts to original [RFC6486] specification. This document attempts to clarify
clarify the innovative concept and application of RPKI Manifests in the innovative concept and application of RPKI manifests in light of
light of real-world deployment experience in the global Internet real-world deployment experience in the global Internet routing
routing system, to avoid future problematic cases. system, to avoid future problematic cases.
The following list summarizes the changes between RFC 6486 and this The following list summarizes the changes between RFC 6486 and this
document: document:
* Forbid "sequential-use" EE certificates, instead mandate "one- * Forbidding "sequential-use" EE certificates and instead mandating
time-use" EE certificates. "one-time-use" EE certificates.
* Clarify that Manifest EE certificates are to be issued with a * Clarifying that manifest EE certificates are to be issued with a
validity period which coincides with the interval specified in the validity period that coincides with the interval specified in the
Manifest eContent, which coincides with the CRL's thisUpdate and manifest eContent, which coincides with the CRL's thisUpdate and
nextUpdate. nextUpdate.
* Clarify the manifestNumber is monotonically incremented in steps * Clarifying that the manifestNumber is monotonically incremented in
of 1. steps of 1.
* Recommend CA issuers to coincidence the applicable CRL's * Recommending that CA issuers coincide the applicable CRL's
nextUpdate with the Manifest's nextUpdate. nextUpdate with the manifest's nextUpdate.
* The set of valid characters in FileAndHash filenames was * Constraining the set of valid characters in FileAndHash filenames.
constrained.
* Clarifications that an RP unable to obtain the full set of files * Clarifying that an RP unable to obtain the full set of files
listed on a Manifest is considered a failure state, in which case listed on a manifest is considered to be in a failure state, in
cached data from a previous attempt should be used (if available). which case cached data from a previous attempt should be used (if
available).
* Clarifications on the requirement for a current CRL to be present, * Clarifying the requirement for a current CRL to be present,
listed, and verified. listed, and verified.
* Removed the notion of 'local policy'. * Removing the notion of "local policy".
Acknowledgements
The authors would like to acknowledge the contributions from George
Michaelson 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 Tim
Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto
Wibisono, Murray Kucherawy, Francesca Palombini, Roman Danyliw, Lars
Eggert, Robert Wilton, and Benjamin Kaduk for their helpful review of
this document.
Authors' Addresses Authors' Addresses
Rob Austein Rob Austein
Arrcus, Inc. Arrcus, Inc.
Email: sra@hactrn.net Email: sra@hactrn.net
Geoff Huston Geoff Huston
APNIC APNIC
6 Cordelia St 6 Cordelia St
South Brisbane QLD 4101 South Brisbane QLD 4101
Australia Australia
Email: gih@apnic.net Email: gih@apnic.net
Stephen Kent Stephen Kent
Independent Independent
Email: kent@alum.mit.edu Email: kent@alum.mit.edu
Matt Lepinski Matt Lepinski
New College Florida New College Florida
5800 Bay Shore Rd. 5800 Bay Shore Rd.
Sarasota, FL 34243 Sarasota, FL 34243
USA United States of America
Email: mlepinski@ncf.edu Email: mlepinski@ncf.edu
 End of changes. 61 change blocks. 
156 lines changed or deleted 160 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/