Diff: rfc9286v2.txt - rfc9286.txt

	rfc9286v2.txt	rfc9286.txt

	Internet Engineering Task Force (IETF) R. Austein	Internet Engineering Task Force (IETF) R. Austein
	Request for Comments: 9286 Arrcus, Inc.	Request for Comments: 9286 Arrcus, Inc.
	Obsoletes: 6486 G. Huston	Obsoletes: 6486 G. Huston
	Category: Standards Track APNIC	Category: Standards Track APNIC
	ISSN: 2070-1721 S. Kent	ISSN: 2070-1721 S. Kent
	Independent	Independent
	M. Lepinski	M. Lepinski
	New College Florida	New College Florida

	May 2022	June 2022

	Manifests for the Resource Public Key Infrastructure (RPKI)	Manifests for the Resource Public Key Infrastructure (RPKI)

	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,

	skipping to change at line 173 ¶	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. An associated EE certificate used in this fashion is	manifest. An associated EE certificate used in this fashion is
	termed a "one-time-use" EE certificate (see Section 3 of [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

	skipping to change at line 308 ¶	skipping to change at line 308 ¶
	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 Name 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


	skipping to change at line 616 ¶	skipping to change at line 616 ¶
	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 attacks	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

	The "RPKI Signed Objects" registry was originally created and	The "RPKI Signed Objects" registry was originally created and
	populated by [RFC6488]. The "RPKI Repository Name Schemes" registry	populated by [RFC6488]. The "RPKI Repository Name Schemes" registry
	was created by [RFC6481] and created four of the initial three-letter	was created by [RFC6481] and created four of the initial three-letter

	filename extensions. IANA has updated the reference for the	file name extensions. IANA has updated the reference for the
	"Manifest" row in the "RPKI Signed Objects" registry to point to this	"Manifest" row in the "RPKI Signed Objects" registry to point to this
	document.	document.

	IANA has also updated the following entries to refer to this document	IANA has also updated the following entries to refer to this document
	instead of RFC 6486:	instead of RFC 6486:

	* id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module	* id-mod-rpkiManifest (60) in the "SMI Security for S/MIME Module
	Identifier (1.2.840.113549.1.9.16.0)" registry	Identifier (1.2.840.113549.1.9.16.0)" registry

	* id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS	* id-ct-rpkiManifest (26) in the "SMI Security for S/MIME CMS

	skipping to change at line 786 ¶	skipping to change at line 786 ¶
	validity period that 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.

	* Clarifying that the manifestNumber is monotonically incremented in	* Clarifying that the manifestNumber is monotonically incremented in
	steps of 1.	steps of 1.

	* Recommending that CA issuers include 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.


	* Constraining the set of valid characters in FileAndHash filenames.	* Constraining the set of valid characters in FileAndHash file
		names.

	* Clarifying 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 to be in a failure state, in	listed on a manifest is considered to be in a failure state, in
	which case cached data from a previous attempt should be used (if	which case cached data from a previous attempt should be used (if
	available).	available).

	* Clarifying 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.

	* Removing the notion of "local policy".	* Removing the notion of "local policy".

End of changes. 7 change blocks.
	7 lines changed or deleted	8 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/