< draft-ietf-sidr-rpki-manifests-10.txt		draft-ietf-sidr-rpki-manifests-11.txt >
	Secure Inter-Domain Routing R. Austein		Secure Inter-Domain Routing R. Austein
	Internet-Draft ISC		Internet-Draft ISC
	Intended status: Standards Track G. Huston		Intended status: Standards Track G. Huston
	Expires: October 15, 2011 APNIC		Expires: November 6, 2011 APNIC
	S. Kent		S. Kent
	M. Lepinski		M. Lepinski
	BBN		BBN
	April 13, 2011		May 5, 2011
	Manifests for the Resource Public Key Infrastructure		Manifests for the Resource Public Key Infrastructure
	draft-ietf-sidr-rpki-manifests-10.txt		draft-ietf-sidr-rpki-manifests-11.txt
	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 47 ¶		skipping to change at page 1, line 47 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on October 15, 2011.		This Internet-Draft will expire on November 6, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	skipping to change at page 2, line 42 ¶		skipping to change at page 2, line 42 ¶
	6. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 9		6. Relying Party Use of Manifests . . . . . . . . . . . . . . . . 9
	6.1. Tests for Determining Manifest State . . . . . . . . . . . 10		6.1. Tests for Determining Manifest State . . . . . . . . . . . 10
	6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 11		6.2. Missing Manifests . . . . . . . . . . . . . . . . . . . . 11
	6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 12		6.3. Invalid Manifests . . . . . . . . . . . . . . . . . . . . 12
	6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 12		6.4. Stale Manifests . . . . . . . . . . . . . . . . . . . . . 12
	6.5. Mismatch between Manifest and Publication Point . . . . . 13		6.5. Mismatch between Manifest and Publication Point . . . . . 13
	6.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 14		6.6. Hash Values Not Matching Manifests . . . . . . . . . . . . 14
	7. Publication Repositories . . . . . . . . . . . . . . . . . . . 15		7. Publication Repositories . . . . . . . . . . . . . . . . . . . 15
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 16		11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	11.2. Informative References . . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The Resource Public Key Infrastructure (RPKI) [ID.ietf-sidr-arch]		The Resource Public Key Infrastructure (RPKI) [ID.ietf-sidr-arch]
	makes use of a distributed repository system		makes use of a distributed repository system
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	present in the repository. To assist in the detection of such		present in the repository. To assist in the detection of such
	attacks, the RPKI repository system can make use of a signed object		attacks, the RPKI repository system can make use of a signed object
	called a "manifest".		called a "manifest".
	A manifest is a signed object that enumerates all the signed objects		A manifest is a signed object that enumerates all the signed objects
	(files) in the repository publication point (directory) that are		(files) in the repository publication point (directory) that are
	associated with an authority responsible for publishing at that		associated with an authority responsible for publishing at that
	publication point. Each manifest contains both the name of the file		publication point. Each manifest contains both the name of the file
	containing the object, and a hash of the file content, for every		containing the object, and a hash of the file content, for every
	signed object issued by an authority that is published at the		signed object issued by an authority that is published at the
	authority's repository publication point. A manifest allows an RP to		authority's repository publication point. A manifest is intended to
	detect unauthorized object removal, or the substitution of "stale"		allow an RP to detect unauthorized object removal, or the
	versions of objects at a publication point. A manifest also intended		substitution of "stale" versions of objects at a publication point.
	to allow an RP to detect similar outcomes that may result from a man-		A manifest also intended to allow an RP to detect similar outcomes
	in-the middle attack on the retrieval of objects from the repository.		that may result from a man-in-the-middle attack on the retrieval of
	Manifests are intended to be used in Certification Authority (CA)		objects from the repository. Manifests are intended to be used in
	publication points in repositories (directories containing files that		Certification Authority (CA) publication points in repositories
	are subordinate certificates and Certificate Revocation Lists (CRLs)		(directories containing files that are subordinate certificates and
	issued by this CA and other signed objects that are verified by End		Certificate Revocation Lists (CRLs) issued by this CA and other
	Entity (EE) certificates issued by this CA).		signed objects 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 detection of potential attacks using manifest		stale manifests, and detection of potential attacks using manifest
	replays, etc are similar to those for CRLs. The syntax of the		replays, etc are similar to those for CRLs. The syntax of the
	manifest payload differs from CRLs, since RPKI repositories contain		manifest payload differs from CRLs, since RPKI repositories contain
	objects not covered by CRLs,e.g., digitally signed objects, such as		objects not covered by CRLs,e.g., digitally signed objects, such as
	Route Origination Authorizations (ROAs).		Route Origination Authorizations (ROAs).
	1.1. Terminology		1.1. Terminology
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	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,
	* the most recent CRL issued by this CA, and		* the most recent CRL issued by this CA, and
	* all published signed objects that are verifiable using EE		* all published signed objects that are verifiable using EE
	certificates [I-D.sidr-res-certs], issued by this CA.		certificates [I-D.sidr-res-certs], issued by this CA.
	Where an EE certificate is placed in the Cryptographic Message Syntax		Every RPKI signed object includes, in the Cryptographic Message
	(CMS) wrapper of a published RPKI signed object		Syntax (CMS) [RFC3370] wrapper of the object, the EE certificate used
	[ID.sidr-signed-object] there is no requirement to separately publish		to verify it [ID.sidr-signed-object]. Thus there is no requirement
	the EE certificate in the CA's repository publication point.		to separately publish that EE certificate at the CA's repository
			publication point.
	Where multiple CA instances share a common publication point, as can		Where multiple CA instances share a common publication point, as can
	occur when an entity performs a key-rollover operation		occur when an entity performs a key-rollover operation
	[ID.sidr-keyroll], the repository publication point will contain		[ID.sidr-keyroll], the repository publication point will contain
	multiple manifests. In this case, each manifest describes only the		multiple manifests. In this case, each manifest describes only the
	collection of published products of its associated CA instance.		collection of published 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 OID of id-ad-signedObject.		access method OID of id-ad-signedObject.
	The CA MAY chose to sign only one manifest with each generated		The CA MAY choose to sign only one manifest with each generated
	private key, and generate a new key pair for each new version of the		private key, and generate a new key pair for each new version of the
	manifest. This form of use of the associated EE certificate is		manifest. This form of use of the associated EE certificate is
	termed a "one-time-use" EE certificate.		termed a "one-time-use" EE certificate.
	Alternatively, the CA MAY elect to use the same private key to sign a		Alternatively, the CA MAY elect to use the same private key to sign a
	sequence of manifests. Because only a single manifest (issued under		sequence of manifests. Because only a single manifest (issued under
	a single CA instance) is current at any point in time, the associated		a single CA instance) is current at any point in time, the associated
	EE certificate is used to verify only a single object at a time. As		EE certificate is used to verify only a single object at a time. As
	long as the sequence of objects verified by this EE certificate are		long as the sequence of objects verified by this EE certificate are
	published using the same file name, then this sequential, multiple		published using the same file name, then this sequential, multiple
	skipping to change at page 9, line 8 ¶		skipping to change at page 9, line 8 ¶
	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 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 repository system		certificate, and publish the manifest in repository system
	publication point that is described by the manifest.		publication point that is described by the manifest.
	6. In the case of a key pair that is to be used only once, in		6. In the case of a key pair that is to be used only once, in
	conjunction with a "one-time-use" EE certificate, the private key		conjunction with a "one-time-use" EE certificate, the private key
	associated with this key pair SHOULD now be destroyed.		associated with this key pair MUST now be destroyed.
	5.2. Considerations for Manifest Generation		5.2. Considerations for Manifest Generation
	A new manifest MUST be issued on or before the nextUpdate time.		A new manifest MUST be issued and published on or before the
			nextUpdate time.
	An authority MUST issue a new manifest in conjunction with the		An authority MUST issue a new manifest in conjunction with the
	finalization of changes made to objects in the publication point. An		finalization of changes made to objects in the publication point. An
	authority MAY perform a number of object operations on a publication		authority MAY perform a number of object operations on a publication
	repository within the scope of a repository change before issuing a		repository within the scope of a repository change before issuing a
	single manifest that covers all the operations within the scope of		single manifest that covers all the operations within the scope of
	this change. Repository operators SHOULD implement some form of		this change. Repository operators SHOULD implement some form of
	repository update procedure that mitigates, to the extent possible,		repository update procedure that mitigates, to the extent possible,
	the risk that RPs performing retrieval operations on the repository		the risk that RPs that are performing retrieval operations on the
	are exposed to inconsistent transient intermediate states during		repository are exposed to inconsistent transient intermediate states
	updates to the repository publication point (directory) and the		during updates to the repository publication point (directory) and
	associated manifest.		the associated manifest.
	Since the manifest object URL is included in the SIA of issued		Since the manifest object URL is included in the SIA of issued
	Certificates, a new manifest MUST NOT invalidate the manifest object		Certificates, a new manifest MUST NOT invalidate the manifest object
	URL of previously issued certificates. This implies that the		URL of previously issued certificates. This implies that the
	manifest's publication name in the repository, in the form of an		manifest's publication name in the repository, in the form of an
	object URL, is unchanged across manifest generation cycles.		object URL, is unchanged across manifest generation cycles.
	When a CA entity is performing a key rollover, the entity MAY chose		When a CA entity is performing a key rollover, the entity MAY choose
	to have two CAs instances simultaneously publishing into the same		to have two CA instances simultaneously publishing into the same
	repository publication point. In this case there will be one		repository publication point. In this case there will be one
	manifest associated with each active CA instance that is publishing		manifest associated with each active CA instance that is publishing
	into the common repository publication point (directory).		into the common repository publication point (directory).
	6. Relying Party Use of Manifests		6. Relying Party Use of Manifests
	The goal of an RP is to determine which signed objects to use for		The goal of an RP is to determine which signed objects to use for
	validating assertions about INRs and their use (e.g., which ROAs to		validating assertions about INRs and their use (e.g., which ROAs to
	use in the construction of route filters). Ultimately, this		use in the construction of route filters). Ultimately, this
	selection is a matter of local policy. However, in the following		selection is a matter of local policy. However, in the following
	skipping to change at page 11, line 5 ¶		skipping to change at page 11, line 9 ¶
	publication point.		publication point.
	If the computed hash value of a file listed on the manifest does		If the computed hash value of a file listed on the manifest does
	not match the hash value contained in the manifest, then see		not match the hash value contained in the manifest, then see
	Section 6.6.		Section 6.6.
	5. An RP MAY check that the contents of each current manifest		5. An RP MAY check that the contents of each current manifest
	conforms to the manifest's scope constraints, as specified in		conforms to the manifest's scope constraints, as specified in
	Section 2.		Section 2.
	If a current manifest contains entries for objects that are not		6. If a current manifest contains entries for objects that are not
	within the scope of the manifest, then the out-of-scope entries		within the scope of the manifest, then the out-of-scope entries
	SHOULD be disregarded in the context of this manifest. If there		SHOULD be disregarded in the context of this manifest. If there
	is no other current manifest that describes these objects within		is no other current manifest that describes these objects within
	that other manifest's scope, then see Section 6.2.		that other manifest's scope, then see Section 6.2.
	For each signed object, if all of the following conditions hold:		For each signed object, if all of the following conditions hold:
	* the manifest for its publication, and the associated		* the manifest for its publication, and the associated
	publication point, pass all of the above checks;		publication point, pass all of the above checks;
	* the signed object is valid; and		* the signed object is valid; and
	* the manifests for every certificate on the certification path		* the manifests for every certificate on the certification path
	used to validate the signed object, and the associated		used to validate the signed object, and the associated
	publication points, pass all of the above checks;		publication points, pass all of the above checks;
	then the RP can conclude that no attack against the repository system		then the RP can conclude that no attack against the repository system
	has compromised the given signed object, and the signed object MUST		has compromised the given signed object, and the signed object MUST
	be treated as valid.		be treated as valid (relative to manifest checking).
	6.2. Missing Manifests		6.2. Missing Manifests
	The absence of a current manifest at a publication point could occur		The absence of a current manifest at a publication point could occur
	due to an error by the publisher or due to (malicious or accidental)		due to an error by the publisher or due to (malicious or accidental)
	deletion or corruption of all valid manifests.		deletion or corruption of all valid manifests.
	When no valid manifest is available, there is no protection against		When no valid manifest is available, there is no protection against
	attacks that delete signed objects or replay old versions of signed		attacks that delete signed objects or replay old versions of signed
	objects. All signed objects at the publication point, and all		objects. All signed objects at the publication point, and all
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 16 ¶
	Regardless of whether signed objects from this publication are deemed		Regardless of whether signed objects from this publication are deemed
	fit for use by an RP, this situation SHOULD result in a warning to		fit for use by an RP, this situation SHOULD result in a warning to
	the effect that: "No manifest is available for <pub point name>, and		the effect that: "No manifest is available for <pub point name>, and
	thus there may have been undetected deletions or replay substitutions		thus there may have been undetected deletions or replay substitutions
	from the publication point."		from the publication point."
	In the case where an RP has access to a local cache of previously		In the case where an RP has access to a local cache of previously
	issued manifests that are valid, the RP MAY use the most recently		issued manifests that are valid, the RP MAY use the most recently
	previously issued valid manifests for this RPKI repository		previously issued valid manifests for this RPKI repository
	publication collection in this case for each entity that publishes at		publication collection in this case for each entity that publishes at
	his publication point.		this publication point.
	6.3. Invalid Manifests		6.3. Invalid Manifests
	The presence of an invalid manifest at a publication point could		The presence of an invalid manifest at a publication point could
	occur due to an error by the publisher or due to (malicious or		occur due to an error by the publisher or due to (malicious or
	accidental) corruption of a valid manifest. An invalid manifest MUST		accidental) corruption of a valid manifest. An invalid manifest MUST
	never be used.		never be used, even if th manifestNumber of the invalid manifest is
			greater that that of other (valid) manifests.
	There are no risks associated with using signed objects at a		There are no risks associated with using signed objects at a
	publication point containing an invalid manifest, provided that valid		publication point containing an invalid manifest, provided that valid
	manifests that collectively cover all the signed objects are also		manifests that collectively cover all the signed objects are also
	present.		present.
	If an invalid manifest is present at a publication point that also		If an invalid manifest is present at a publication point that also
	contains one or more valid manifests, this situation SHOULD result in		contains one or more valid manifests, this situation SHOULD result in
	a warning to the effect that: "An invalid manifest was found at <pub		a warning to the effect that: "An invalid manifest was found at <pub
	point name>, this indicates an attack against the publication point		point name>, this indicates an attack against the publication point
	skipping to change at page 16, line 16 ¶		skipping to change at page 16, line 22 ¶
	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 attack
	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
	[Note to IANA, to be removed prior to publication: there are no IANA		[Note to IANA, to be removed prior to publication: there are no IANA
	considerations stated in this version of the document.]		considerations stated in this version of the document.]
	10. Acknowledgments		10. Acknowledgements
	The authors would like to acknowledge the contributions from George		The authors would like to acknowledge the contributions from George
	Michelson and Randy Bush in the preparation of the manifest		Michelson and Randy Bush in the preparation of the manifest
	specification. Additionally, the authors would like to thank Mark		specification. Additionally, the authors would like to thank Mark
	Reynolds and Christopher Small for assistance in clarifying manifest		Reynolds and Christopher Small for assistance in clarifying manifest
	validation and RP behavior. The authors also wish to thank Sean		validation and RP behavior. The authors also wish to thank Sean
	Turner for his helpful review of this document.		Turner for his helpful review of this document.
	11. References		11. References
	skipping to change at page 17, line 25 ¶		skipping to change at page 17, line 31 ¶
	[ID.ietf-sidr-arch]		[ID.ietf-sidr-arch]
	Lepinski, M. and S. Kent, "An Infrastructure to Support		Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", draft-ietf-sidr-arch-11.txt		Secure Internet Routing", draft-ietf-sidr-arch-11.txt
	(work in progress), September 2010.		(work in progress), September 2010.
	[ID.sidr-keyroll]		[ID.sidr-keyroll]
	Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover		Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
	in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in		in the RPKI", draft-ietf-sidr-keyroll-02.txt (work in
	progress), October 2010.		progress), October 2010.
			[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
			Algorithms", RFC 3370, August 2002.
	[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP		[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
	Addresses and AS Identifiers", RFC 3779, June 2004.		Addresses and AS Identifiers", RFC 3779, June 2004.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	RPKIManifest { iso(1) identified-organization(3)		RPKIManifest { iso(1) identified-organization(3)
	dod(6) internet(1) security(5) mechanisms(5) smime(7)		dod(6) internet(1) security(5) mechanisms(5) smime(7)
	mod(0) TBD }		mod(0) TBD }
	DEFINITIONS EXPLICIT TAGS ::=		DEFINITIONS EXPLICIT TAGS ::=
End of changes. 19 change blocks.
	34 lines changed or deleted		41 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/