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		June 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 34 ¶		skipping to change at line 173 ¶
	Where multiple CA instances share a common publication point, as can		Where multiple CA instances share a common publication point, as can
	occur when a CA performs a key-rollover operation [RFC6489], the		occur when a CA performs a key-rollover operation [RFC6489], the
	repository publication point will contain multiple manifests. In		repository publication point will contain multiple manifests. In
	this case, each manifest describes only the collection of published		this case, each manifest describes only the collection of published
	products of its associated CA instance.		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.		accessMethod 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 Schemes" 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 file name.
	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 file name. 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
	The mandatory content-type attribute MUST have its attrValues field		The mandatory content-type attribute MUST have its attrValues field
	set to the same OID as eContentType. This OID is id-ct-rpkiManifest		set to the same OID as eContentType. This OID is id-ct-rpkiManifest
	and has the numerical value of 1.2.840.113549.1.9.16.1.26.		and has the numerical value of 1.2.840.113549.1.9.16.1.26.
	4.4. Manifest Validation		4.4. Manifest Validation
	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; 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; proceed to Section 6.6. If the current time is later
	later than nextUpdate, then the manifest is stale; this is a failed		than nextUpdate, then the manifest is stale; the RP MUST treat this
	fetch and RP MUST proceed to Section 6.6; otherwise proceed to		as a failed fetch. 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,		RP MUST treat this as a failed fetch. Proceed to Section 6.6.
	proceed to Section 6.5.		Otherwise, proceed to Section 6.5.
	6.5. Matching File Names and Hashes		6.5. Matching File Names and Hashes
	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 respond
	Section 6.6.		accordingly. Proceed to 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
			file name extensions. IANA has updated the reference for the
			"Manifest" row in the "RPKI Signed Objects" registry to point to this
			document.
	10. Acknowledgements		IANA has also updated the following entries to refer to this document
			instead of RFC 6486:
	The authors would like to acknowledge the contributions from George		* id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module
	Michelson and Randy Bush in the preparation of the manifest		Identifier (1.2.840.113549.1.9.16.0)" registry
	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		* id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS
			Content Type (1.2.840.113549.1.9.16.1)" registry
	11.1. Normative References		* the "Security considerations" entry in the application media type
			registration for rpki-manifest
			No other actions are required.
			10. 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 14, line 47 ¶		skipping to change at line 663 ¶
	[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for		[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
	Resource Certificate Repository Structure", RFC 6481,		Resource Certificate Repository Structure", RFC 6481,
	DOI 10.17487/RFC6481, February 2012,		DOI 10.17487/RFC6481, February 2012,
	<https://www.rfc-editor.org/info/rfc6481>.		<https://www.rfc-editor.org/info/rfc6481>.
	[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route		[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
	Origin Authorizations (ROAs)", RFC 6482,		Origin Authorizations (ROAs)", RFC 6482,
	DOI 10.17487/RFC6482, February 2012,		DOI 10.17487/RFC6482, February 2012,
	<https://www.rfc-editor.org/info/rfc6482>.		<https://www.rfc-editor.org/info/rfc6482>.
	[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
	Algorithms and Key Sizes for Use in the Resource Public
	Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
	August 2016, <https://www.rfc-editor.org/info/rfc7935>.
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<https://www.rfc-editor.org/info/rfc6487>.		<https://www.rfc-editor.org/info/rfc6487>.
	[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>.
			[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
			Algorithms and Key Sizes for Use in the Resource Public
			Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
			August 2016, <https://www.rfc-editor.org/info/rfc7935>.
	[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
	11.2. Informative References		Distinguished Encoding Rules (DER)", ITU-T Recommendation
			X.690, February 2021,
			<https://www.itu.int/rec/T-REC-X.690-202102-I/en>.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,		10.2. Informative References
	RFC 5652, DOI 10.17487/RFC5652, September 2009,
	<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>.
			[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
			RFC 5652, DOI 10.17487/RFC5652, September 2009,
			<https://www.rfc-editor.org/info/rfc5652>.
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,		Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
	February 2012, <https://www.rfc-editor.org/info/rfc6480>.		February 2012, <https://www.rfc-editor.org/info/rfc6480>.
	[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,		[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
	"Manifests for the Resource Public Key Infrastructure		"Manifests for the Resource Public Key Infrastructure
	(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,		(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
	<https://www.rfc-editor.org/info/rfc6486>.		<https://www.rfc-editor.org/info/rfc6486>.
	[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification		[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
	Authority (CA) Key Rollover in the Resource Public Key		Authority (CA) Key Rollover in the Resource Public Key
	Infrastructure (RPKI)", BCP 174, RFC 6489,		Infrastructure (RPKI)", BCP 174, RFC 6489,
	DOI 10.17487/RFC6489, February 2012,		DOI 10.17487/RFC6489, February 2012,
	<https://www.rfc-editor.org/info/rfc6489>.		<https://www.rfc-editor.org/info/rfc6489>.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)		RPKIManifest { iso(1) member-body(2) us(840) rsadsi(113549)
	pkcs(1) pkcs9(9) smime(16) mod(0) TBD }		pkcs(1) pkcs9(9) smime(16) mod(0) 60 }
	DEFINITIONS EXPLICIT TAGS ::=		DEFINITIONS EXPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS ALL --		-- EXPORTS ALL --
	IMPORTS		IMPORTS
	CONTENT-TYPE		CONTENT-TYPE
	FROM CryptographicMessageSyntax-2010 -- in [RFC6268]		FROM CryptographicMessageSyntax-2010 -- in RFC 6268
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
	pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;		pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) } ;
	-- Manifest Content Type		-- Manifest Content Type
	ct-rpkiManifest CONTENT-TYPE ::=		ct-rpkiManifest CONTENT-TYPE ::=
	{ TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }		{ TYPE Manifest IDENTIFIED BY id-ct-rpkiManifest }
	id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)		id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }		us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
	skipping to change at page 16, line 47 ¶		skipping to change at line 762 ¶
	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 include 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 file
	constrained.		names.
	* 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. 72 change blocks.
	176 lines changed or deleted		195 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/