< draft-ietf-sidr-algorithm-agility-08.txt		draft-ietf-sidr-algorithm-agility-09.txt >
	Network Working Group R. Gagliano		Network Working Group R. Gagliano
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track S. Kent		Intended status: Standards Track S. Kent
	Expires: April 22, 2013 BBN Technologies		Expires: June 20, 2013 BBN Technologies
	S. Turner		S. Turner
	IECA, Inc.		IECA, Inc.
	October 19, 2012		December 17, 2012
	Algorithm Agility Procedure for RPKI.		Algorithm Agility Procedure for RPKI.
	draft-ietf-sidr-algorithm-agility-08		draft-ietf-sidr-algorithm-agility-09
	Abstract		Abstract
	This document specifies the process that Certification Authorities		This document specifies the process that Certification Authorities
	(CAs) and Relying Parties (RPs) participating in the Resource Public		(CAs) and Relying Parties (RPs) participating in the Resource Public
	Key Infrastructure (RPKI) will need to follow to transition to a new		Key Infrastructure (RPKI) will need to follow to transition to a new
	(and probably cryptographically stronger) algorithm set. The process		(and probably cryptographically stronger) algorithm set. The process
	is expected to be completed in a time scale of months or years.		is expected to be completed in a time scale of months or years.
	Consequently, no emergency transition is specified. The transition		Consequently, no emergency transition is specified. The transition
	procedure defined in this document supports only a top-down migration		procedure defined in this document supports only a top-down migration
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 April 22, 2013.		This Internet-Draft will expire on June 20, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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
	skipping to change at page 6, line 52 ¶		skipping to change at page 6, line 52 ¶
	in the certificate request submitted by the subject.		in the certificate request submitted by the subject.
	Signed Product Set (or Set or Product Set): A collection of		Signed Product Set (or Set or Product Set): A collection of
	certificates, signed objects, a CRL and a manifest that		certificates, signed objects, a CRL and a manifest that
	are associated by virtue of being verifiable under the		are associated by virtue of being verifiable under the
	same parent CA certificate		same parent CA certificate
	Correspond: Two certificates, issued under different Algorithm Suites		Correspond: Two certificates, issued under different Algorithm Suites
	correspond to one another if they are issued to the same		correspond to one another if they are issued to the same
	entity by the same CA and bind identical Internet Number		entity by the same CA and bind identical Internet Number
	Resoureces (INRs) to that entity. Two CRLs correspond if		Resources (INRs) to that entity. Two CRLs correspond if
	they are issued by the same CA and enumerate		they are issued by the same CA and enumerate
	corresponding certificates. Two signed objects (other		corresponding certificates. Two signed objects (other
	than manifests) correspond if they are verified using		than manifests) correspond if they are verified using
	corresponding EE certificates and they contain the same		corresponding EE certificates and they contain the same
	encapsulated Context Info field. Two manifests		encapsulated Context Info field. Two manifests
	correspond if they encompass corresponding certificates,		correspond if they encompass corresponding certificates,
	ROAs, CRLs, and (other) signed objects (the term		ROAs, CRLs, and (other) signed objects (the term
	"equivalent" is used synonymously when referring to such		"equivalent" is used synonymously when referring to such
	RPKI signed products.)		RPKI signed products.)
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	RP Ready Algorithm B Date: After this date, all RPs MUST be prepared		RP Ready Algorithm B Date: After this date, all RPs MUST be prepared
	to process signed material issued under the Algorithm		to process signed material issued under the Algorithm
	Suite B.		Suite B.
	Twilight Date: After this date, a CA MAY cease issuing signed		Twilight Date: After this date, a CA MAY cease issuing signed
	products under the Algorithm Suite A. Also, after this		products under the Algorithm Suite A. Also, after this
	date, a RP MAY cease to validate signed materials issued		date, a RP MAY cease to validate signed materials issued
	under the Algorithm Suite A.		under the Algorithm Suite A.
	End Of Life (EOL) Date: After this date, the Algorithm Suite C is		End Of Life (EOL) Date: After this date, the Algorithm Suite C MUST
	MUST be deprecated using the process in Section 10 and		be deprecated using the process in Section 10 and all
	all Algorithm Suite C TALs MUST be removed from their		Algorithm Suite C TALs MUST be removed from their
	publication points.		publication points.
	4.2. Process overview		4.2. Process overview
	The migration process described in this document involves a series of		The migration process described in this document involves a series of
	steps that MUST be executed in chronological order by CAs and RPs.		steps that MUST be executed in chronological order by CAs and RPs.
	The only milestone at which both CAs and RPs take action at the same		The only milestone at which both CAs and RPs take action at the same
	time is the EOL Date. Due to the decentralized nature of the RPKI		time is the EOL Date. Due to the decentralized nature of the RPKI
	infrastructure, it is expected that an algorithm transition will span		infrastructure, it is expected that an algorithm transition will span
	several years.		several years.
	skipping to change at page 15, line 42 ¶		skipping to change at page 15, line 42 ¶
	product sets using Suite A. RPs MAY validate signed product sets		product sets using Suite A. RPs MAY validate signed product sets
	using Suite C. However, RPs SHOULD NOT assume that the collection of		using Suite C. However, RPs SHOULD NOT assume that the collection of
	Suite C product sets is complete. Thus RPs SHOULD make use of only		Suite C product sets is complete. Thus RPs SHOULD make use of only
	Suite A products sets. (See Section 6 for further details.)		Suite A products sets. (See Section 6 for further details.)
	If it is determined that many RPs are not capable of processing the		If it is determined that many RPs are not capable of processing the
	new algorithm suite, the algorithm transition timeline document MUST		new algorithm suite, the algorithm transition timeline document MUST
	be reissued pushing back the date for this and the next milestone.		be reissued pushing back the date for this and the next milestone.
	The document MUST require CA to not remove Suite C product sets if		The document MUST require CA to not remove Suite C product sets if
	this phase is delayed. If the Algorithm Suite A (former Algorithm		this phase is delayed. If the Algorithm Suite A (former Algorithm
	Suite B) is deemed unsuitable, the algorithm transition timeline and		Suite B) is deemed unsuitable, the algorithm transition timeline, the
	the algorithm specification documents MUST be replaced and the		algorithm specification documents MUST be replaced, the Algorithm
	Algorithm Suite A MUST be deprecated using the process described in		Suite A MUST be deprecated using the process described in Section 10
	Section 10. At this stage, RPs are still capable of processing Suite		and CAs MUST NOT remove Suite C product sets. At this stage, RPs are
	C signed products, so the RPKI is still viable.		still capable of processing Suite C signed products, so the RPKI is
			still viable.
	The following figure describes a possible status for the repositories		The following figure describes a possible status for the repositories
	of the example CAs.		of the example CAs.
	CA X-Certificate-Algorithm-Suite-C (Cert-XC)		CA X-Certificate-Algorithm-Suite-C (Cert-XC)
	|		|
	|-> CA-Y-Certificate-Algorithm-Suite-C (Cert-YC)		|-> CA-Y-Certificate-Algorithm-Suite-C (Cert-YC)
	|-> CA-Y-CRL-Algorithm-Suite-C (CRL-YC)		|-> CA-Y-CRL-Algorithm-Suite-C (CRL-YC)
	|-> CA-Y-Signed-Objects-Algorithm-Suite-C		|-> CA-Y-Signed-Objects-Algorithm-Suite-C
	|-> CA-X-CRL-Algorithm-Suite-C (CRL-XC)		|-> CA-X-CRL-Algorithm-Suite-C (CRL-XC)
	skipping to change at page 28, line 10 ¶		skipping to change at page 28, line 10 ¶
	RFC 6492, February 2012.		RFC 6492, February 2012.
	[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)		[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
	Ghostbusters Record", RFC 6493, February 2012.		Ghostbusters Record", RFC 6493, February 2012.
	Appendix A. Change Log		Appendix A. Change Log
	Note to the RFC Editor: Please remove this section before		Note to the RFC Editor: Please remove this section before
	publication.		publication.
	From 07 to 06		From 08 to 09
			1. SecDIR comments and nits included
			From 07 to 08
	1. Typo in Section 10		1. Typo in Section 10
	2. Correct reference for RFC6493		2. Correct reference for RFC6493
	From 06 to 07:		From 06 to 07:
	1. Added definition for "Correspond"		1. Added definition for "Correspond"
	2. Added reference of correspondence between suites in phase 2 and 3		2. Added reference of correspondence between suites in phase 2 and 3
End of changes. 8 change blocks.
	14 lines changed or deleted		19 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/