< draft-ietf-sidr-algorithm-agility-09.txt		draft-ietf-sidr-algorithm-agility-10.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: June 20, 2013 BBN Technologies		Expires: July 11, 2013 BBN Technologies
	S. Turner		S. Turner
	IECA, Inc.		IECA, Inc.
	December 17, 2012		January 7, 2013
	Algorithm Agility Procedure for RPKI.		Algorithm Agility Procedure for RPKI.
	draft-ietf-sidr-algorithm-agility-09		draft-ietf-sidr-algorithm-agility-10
	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 several 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
	(parent migrates before children).		(parent migrates before children).
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 June 20, 2013.		This Internet-Draft will expire on July 11, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 37 ¶		skipping to change at page 2, line 37 ¶
	6. Validation of multiple instance of signed products . . . . . . 18		6. Validation of multiple instance of signed products . . . . . . 18
	7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 19		7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 20		8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 20
	9. Repository structure . . . . . . . . . . . . . . . . . . . . . 21		9. Repository structure . . . . . . . . . . . . . . . . . . . . . 21
	10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 22		10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 22
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 25		12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
	13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
	14. Normative References . . . . . . . . . . . . . . . . . . . . . 27		14. Normative References . . . . . . . . . . . . . . . . . . . . . 27
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Requirements notation		1. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "NOT RECOMMENDED" and
	document are to be interpreted as described in [RFC2119].		"OPTIONAL" in this document are to be interpreted as described in
			[RFC2119].
	2. Introduction		2. Introduction
	The RPKI must accommodate transitions between the public keys used by		The RPKI must accommodate transitions between the public keys used by
	CAs. Transitions of this sort are usually termed "key rollover".		CAs. Transitions of this sort are usually termed "key rollover".
	Planned key rollover will occur at regular intervals throughout the		Planned key rollover will occur at regular intervals throughout the
	life of the RPKI, as each CA changes its public keys, in a non-		life of the RPKI, as each CA changes its public keys, in a non-
	coordinated fashion. (By non-coordinated we mean that the time at		coordinated fashion. (By non-coordinated we mean that the time at
	which each CA elects to change its keys is locally determined, not		which each CA elects to change its keys is locally determined, not
	coordinated across the RPKI.) Moreover, because a key change might		coordinated across the RPKI.) Moreover, because a key change might
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 4 ¶
	This document defines how entities in the RPKI execute (planned) CA		This document defines how entities in the RPKI execute (planned) CA
	key rollover when the algorithm suite changes. The description		key rollover when the algorithm suite changes. The description
	covers actions by CAs, repository operators, and RPs. It describes		covers actions by CAs, repository operators, and RPs. It describes
	the behavior required of both CAs and RPs to make such key changes		the behavior required of both CAs and RPs to make such key changes
	work in the RPKI context, including how the RPKI repository system is		work in the RPKI context, including how the RPKI repository system is
	used to support key rollover.		used to support key rollover.
	This document does not specify any algorithm suite per se. The RPKI		This document does not specify any algorithm suite per se. The RPKI
	Certificate Policy (CP) [RFC6484] mandates the use of the algorithms		Certificate Policy (CP) [RFC6484] mandates the use of the algorithms
	defined in [RFC6485] by CAs and RPs. When an algorithm transition is		defined in [RFC6485] by CAs and RPs. When an algorithm transition is
	initiated, [RFC6485] will be updated (as defined in Section 4.1 of		initiated, [RFC6485] MUST be updated (as defined in Section 4.1 of
	this document) redefining the required algorithm(s) for compliant		this document) redefining the required algorithm(s) for compliant
	RPKI CAs and RPs under the CP. The CP will not change as a side		RPKI CAs and RPs under the CP. The CP will not change as a side
	effect of algorithm transition (and thus the policy OID in RPKI		effect of algorithm transition (and thus the policy OID in RPKI
	certificates will not change.)		certificates will not change.)
	An additional document, the algorithm transition timetable, will be		For each algorithm transition, an additional document (the algorithm
	published (as an IETF BCP) to define the dates for each milestone		transition timetable) MUST be published (as an IETF BCP) to define
	defined in this document. It will define dates for the phase		the dates for each milestone defined in this document. It will
	transitions, consistent with the descriptions provided in Section 4.		define dates for the phase transitions, consistent with the
	It also will describe how the RPKI community will measure the		descriptions provided in Section 4. It also will describe how the
	readiness of CAs and RPs to transition to each phase. CAs publish		RPKI community will measure the readiness of CAs and RPs to
	certificates, CRLs, and other signed objects under the new algorithm		transition to each phase. CAs publish certificates, CRLs, and other
	suite as the transition progresses. This provides visibility into		signed objects under the new algorithm suite as the transition
	the deployment of the new algorithm suite, enabling the community to		progresses. This provides visibility into the deployment of the new
	evaluate deployment progress. The transition procedure allows CAs to		algorithm suite, enabling the community to evaluate deployment
	remove old certificates, CRLs, and signed products, after the		progress. The transition procedure allows CAs to remove old
	twilight date. This provides an ability to observe and measure the		certificates, CRLs, and signed products, after the twilight date.
	withdrawal of the old algorithm suite. Thus the phases defined in		This provides an ability to observe and measure the withdrawal of the
	this document enable the community to evaluate the progress of the		old algorithm suite. Thus the phases defined in this document enable
	transition. The timetable document will also describe procedures to		the community to evaluate the progress of the transition. The
	amend the timetable if problems arise in implementing later phases of		timetable document will also describe procedures to amend the
	the transition. It is RECOMMENDED that the timetable document be		timetable if problems arise in implementing later phases of the
			transition. It is RECOMMENDED that the timetable document be
	developed by representatives of the RPKI community, e.g., IANA,		developed by representatives of the RPKI community, e.g., IANA,
	Internet Registries, and network operators.		Internet Registries, and network operators.
	3. Terminology		3. Terminology
	This document assumes that the reader is familiar with the terms and		This document assumes that the reader is familiar with the terms and
	concepts described in "Internet X.509 Public Key Infrastructure		concepts described in "Internet X.509 Public Key Infrastructure
	Certificate and Certificate Revocation List (CRL) Profile" [RFC5280],		Certificate and Certificate Revocation List (CRL) Profile" [RFC5280],
	"X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and		"X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], and
	"A Profile for Resource Certificate Repository Structure" [RFC6481].		"A Profile for Resource Certificate Repository Structure" [RFC6481].
	skipping to change at page 6, line 23 ¶		skipping to change at page 6, line 23 ¶
	Algorithm migration: A planned transition from one signature and		Algorithm migration: A planned transition from one signature and
	hash algorithm to a new signature and hash algorithm.		hash algorithm to a new signature and hash algorithm.
	Algorithm Suite A: The "current" algorithm suite used for hashing		Algorithm Suite A: The "current" algorithm suite used for hashing
	and signing, in examples in this document		and signing, in examples in this document
	Algorithm Suite B: The "next" algorithm suite used for hashing and		Algorithm Suite B: The "next" algorithm suite used for hashing and
	signing, used in examples in this document		signing, used in examples in this document
	Algorithm Suite C: The "old" algorithm suite used for hashing and
	signing, used in examples in this document
	CA X: The CA that issued CA Y's certificate (i.e., CA Y's		CA X: The CA that issued CA Y's certificate (i.e., CA Y's
	parent), used in examples in this document.		parent), used in examples in this document.
	CA Y: The non-leaf CA used in examples this document		CA Y: The non-leaf CA used in examples this document
	CA Z: A CA that is a "child" of CA Y, used in examples this		CA Z: A CA that is a "child" of CA Y, used in examples this
	document		document
	Non-Leaf CA: A CA that issues certificates to other CAs is a non-		Non-Leaf CA: A CA that issues certificates to other CAs is a non-
	leaf CA.		leaf CA.
	skipping to change at page 8, line 5 ¶		skipping to change at page 7, line 11 ¶
	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.)
			ROA: Route Origination Autorization, as defined in [RFC6482].
	4. Key Rollover steps for algorithm migration		4. Key Rollover steps for algorithm migration
	The "current" RPKI algorithm suite (Suite A) is defined in the RPKI		The "current" RPKI algorithm suite (Suite A) is defined in the RPKI
	CP document, by reference to [RFC6485]. When a migration of the RPKI		CP document, by reference to [RFC6485]. When a migration of the RPKI
	algorithm suite is needed, the first step MUST be an update of		algorithm suite is needed, the first step MUST be an update of
	[RFC6485] to define the new algorithm suite. The algorithm		[RFC6485] to define the new algorithm suite. The algorithm
	transition timeline document MUST also be published (as a BCP), to		transition timeline document MUST also be published (as a BCP), to
	inform the community of the dates selected for milestones in the		inform the community of the dates selected for milestones in the
	transition process, as described in Section 4.1.		transition process, as described in Section 4.1.
	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 MUST		End Of Life (EOL) Date: After this date, the Algorithm Suite A MUST
	be deprecated using the process in Section 10 and all		be deprecated using the process in Section 10 and all
	Algorithm Suite C TALs MUST be removed from their		Algorithm Suite A 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 10, line 48 ¶		skipping to change at page 10, line 48 ¶
	phases. The other situation arises if, during the transition,		phases. The other situation arises if, during the transition,
	serious concerns arise about the security of the Suite B algorithms.		serious concerns arise about the security of the Suite B algorithms.
	Such concerns would motivate terminating the transition and rolling		Such concerns would motivate terminating the transition and rolling
	back signed products, i.e., reverting to Suite A. In this case the		back signed products, i.e., reverting to Suite A. In this case the
	timetable MUST be republished, and the RPKI algorithm document MUST		timetable MUST be republished, and the RPKI algorithm document MUST
	be superseded. The phase descriptions below allude to these two		be superseded. The phase descriptions below allude to these two
	situations, as appropriate.		situations, as appropriate.
	4.3. Phase 0		4.3. Phase 0
	Phase 0 is the initial phase of the process, throughout this phase		Phase 0 is the steady state phase of the process; throughout this
	the algorithm suite A is the only supported algorithm suite in RPKI.		phase, Algorithm Suite A is the only supported algorithm suite in
	This is also the steady state for the RPKI.		RPKI. This is also the steady state for the RPKI.
	The following figure illustrates the format used to describe signed		The following figure illustrates the format used to describe signed
	objects in the repository. It reflects the algorithm suites in use,		objects in the repository. It reflects the algorithm suites in use,
	and shows the relationship between three CAs (X, Y, and Z) that form		and shows the relationship between three CAs (X, Y, and Z) that form
	a chain.		a chain.
	During Phase 0, CAs X, Y and Z are required to generate signed		During Phase 0, CAs X, Y and Z are required to generate signed
	product sets using only the Algorithm Suite A. Also, RPs are required		product sets using only the Algorithm Suite A. Also, RPs are required
	to validate signed product sets issued using only Algorithm Suite A.		to validate signed product sets issued using only Algorithm Suite A.
	skipping to change at page 11, line 35 ¶		skipping to change at page 11, line 35 ¶
	4.3.1. Milestone 1		4.3.1. Milestone 1
	The first milestone initiates the migration process. It updates		The first milestone initiates the migration process. It updates
	[RFC6485] with the following definitions for the RPKI:		[RFC6485] with the following definitions for the RPKI:
	o Algorithm Suite A		o Algorithm Suite A
	o Algorithm Suite B		o Algorithm Suite B
	Additionally, the new algorithm transition timeline document will be		Additionally, the new algorithm transition timeline document MUST be
	published with the following information:		published with the following information:
	o CA Ready Algorithm B Date		o CA Ready Algorithm B Date
	o CA Go Algorithm B Date		o CA Go Algorithm B Date
	o RP Ready Algorithm B Date		o RP Ready Algorithm B Date
	o Twilight Date		o Twilight Date
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 12 ¶
	Each date specified here is assumed at one minute after midnight,		Each date specified here is assumed at one minute after midnight,
	UTC. No finer granularity time specification is required or		UTC. No finer granularity time specification is required or
	supported.		supported.
	4.4. Phase 1		4.4. Phase 1
	Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all		Phase 1 starts at the CA Ready Algorithm B Date. During Phase 1, all
	(non-leaf) CAs MUST be ready to process a request from a child CA to		(non-leaf) CAs MUST be ready to process a request from a child CA to
	issue or revoke a certificate using the Algorithm Suite B. If it is		issue or revoke a certificate using the Algorithm Suite B. If it is
	determined that a substantial number of CAs are not ready, the		determined that a substantial number of CAs are not ready, the
	algorithm transition timeline document will be reissued, as noted in		algorithm transition timeline document MUST be reissued, as noted in
	Section 4.2. However, CAs that are capable of issuing Suite B		Section 4.2. However, CAs that are capable of issuing Suite B
	certificates may continue to do so, if requested by their child CAs.		certificates may continue to do so, if requested by their child CAs.
	Since this phase does not require any RPs to process signed objects		Since this phase does not require any RPs to process signed objects
	under Suite B, and since Suite B product sets SHOULD be stored at		under Suite B, and since Suite B product sets SHOULD be stored at
	independent publication points, there is no adverse impact on RPs.		independent publication points, there is no adverse impact on RPs.
	If the Suite B algorithm is deemed unsuitable, the algorithm		If the Suite B algorithm is deemed unsuitable, the algorithm
	transition timeline and the algorithm specification documents MUST be		transition timeline and the algorithm specification documents MUST be
	replaced, the Algorithm Suite B MUST be deprecated using the process		replaced, the Algorithm Suite B MUST be deprecated using the process
	described in Section 10.		described in Section 10.
	skipping to change at page 13, line 37 ¶		skipping to change at page 13, line 37 ¶
	phase, each signed product set MUST be available using both Algorithm		phase, each signed product set MUST be available using both Algorithm
	Suite A and Algorithm Suite B. Thus, prior to the start of this		Suite A and Algorithm Suite B. Thus, prior to the start of this
	phase, every CA MUST ensure that there is a Suite B product		phase, every CA MUST ensure that there is a Suite B product
	corresponding to each Suite A product that the CA has issued.		corresponding to each Suite A product that the CA has issued.
	Throughout this Phase, each CA MUST maintain this correspondence.		Throughout this Phase, each CA MUST maintain this correspondence.
	During this phase, RPs MUST be prepared to validate sets issued using		During this phase, RPs MUST be prepared to validate sets issued using
	Algorithm Suite A and MAY be prepared to validate sets issued using		Algorithm Suite A and MAY be prepared to validate sets issued using
	the Algorithm Suite B.		the Algorithm Suite B.
	If it is determined that a substantial number of CAs are not ready,		If it is determined that a substantial number of CAs are not ready,
	the algorithm transition timeline document will be reissued, as noted		the algorithm transition timeline document MUST be reissued, as noted
	in Section 4.2. (Since the processing requirement for RPs here is a		in Section 4.2. (Since the processing requirement for RPs here is a
	MAY, if RPs have problems with Suite B products this does not require		MAY, if RPs have problems with Suite B products this does not require
	pushing back the Phase 2 milestone, but it does motivate delaying the		pushing back the Phase 2 milestone, but it does motivate delaying the
	start of Phase 3.) CAs that are capable of publishing products under		start of Phase 3.) CAs that are capable of publishing products under
	Suite B MAY continue to do so. Phase 2, like Phase 1, does not		Suite B MAY continue to do so. Phase 2, like Phase 1, does not
	require any RPs to process signed objects under Suite B. Also, Suite		require any RPs to process signed objects under Suite B. Also, Suite
	B product SHOULD be stored at independent publication points, so		B product SHOULD be stored at independent publication points, so
	there is no adverse impact on RPs that are not prepared to process		there is no adverse impact on RPs that are not prepared to process
	suite B products. If the Suite B algorithm is deemed unsuitable, the		suite B products (See Section 9 for additional details.) If the
	algorithm transition timeline and the algorithm specification		Suite B algorithm is deemed unsuitable, the algorithm transition
	documents MUST be replaced and the Algorithm Suite B MUST be		timeline and the algorithm specification documents MUST be replaced
	deprecated using the process described in Section 10.		and the Algorithm Suite B MUST be deprecated using the process
			described in Section 10.
	It is RECOMMENDED that RPs that can process Algorithm Suite B fetch		It is RECOMMENDED that RPs that can process Algorithm Suite B fetch
	and validate Suite B products. RPs that are not ready to process		and validate Suite B products. RPs that are not ready to process
	Suite B products MUST continue to make use of Suite A products. An		Suite B products MUST continue to make use of Suite A products. An
	RP that elects to validate signed product sets using both Algorithm		RP that elects to validate signed product sets using both Algorithm
	Suite A or Algorithm Suite B should expect the same results. If		Suite A or Algorithm Suite B should expect the same results. If
	there are discrepancies when evaluating corresponding signed product		there are discrepancies when evaluating corresponding signed product
	sets, successful validation of either product set is acceptable. A		sets, successful validation of either product set is acceptable. A
	detailed analysis of the validation of multiple instances of signed		detailed analysis of the validation of multiple instances of signed
	objects is included in Section 6.		objects is included in Section 6.
	skipping to change at page 15, line 19 ¶		skipping to change at page 15, line 21 ¶
	that still exist. If the Suite B algorithm is deemed unsuitable, the		that still exist. If the Suite B algorithm is deemed unsuitable, the
	algorithm transition timeline and the algorithm specification		algorithm transition timeline and the algorithm specification
	documents MUST be replaced and the Algorithm Suite B MUST be		documents MUST be replaced and the Algorithm Suite B MUST be
	deprecated using the process described in Section 10.		deprecated using the process described in Section 10.
	There are no changes to the CA behavior throughout this phase.		There are no changes to the CA behavior throughout this phase.
	4.7. Phase 4		4.7. Phase 4
	Phase 4 starts at the Twilight Date. At that date, the Algorithm A		Phase 4 starts at the Twilight Date. At that date, the Algorithm A
	is labeled as "old" and the Algorithm B is labeled as "current":		is labeled as "old" and the Algorithm B is labeled as "current".
	Before Twilight --> After Twilight
	Algorithm Suite A ("current") --> Algorithm Suite C ("old")
	Algorithm Suite B ("new") --> Algorithm Suite A ("current")
	During this phase, all signed product sets MUST be issued using		During this phase, all signed product sets MUST be issued using
	Algorithm Suite A (formerly B) and MAY be issued using Algorithm		Algorithm Suite B and MAY be issued using Algorithm Suite A. All
	Suite C (formerly A). All signed products sets issued using Suite A		signed products sets issued using Suite B MUST be published at their
	MUST be published at their corresponding publication points. Signed		corresponding publication points. Signed products sets issued using
	products sets issued using Suite C might not be available at their		Suite A might not be available at their corresponding publication
	corresponding publication points. Every RP MUST validate signed		points. Every RP MUST validate signed product sets using Suite B.
	product sets using Suite A. RPs MAY validate signed product sets		RPs MAY validate signed product sets using Suite A. However, RPs
	using Suite C. However, RPs SHOULD NOT assume that the collection of		SHOULD NOT assume that the collection of Suite A product sets is
	Suite C product sets is complete. Thus RPs SHOULD make use of only		complete. Thus RPs SHOULD make use of only Suite B products sets.
	Suite A products sets. (See Section 6 for further details.)		(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 A product sets if
	this phase is delayed. If the Algorithm Suite A (former Algorithm		this phase is delayed. If the Algorithm Suite B is deemed
	Suite B) is deemed unsuitable, the algorithm transition timeline, the		unsuitable, the algorithm transition timeline, the algorithm
	algorithm specification documents MUST be replaced, the Algorithm		specification documents MUST be replaced, the Algorithm Suite B MUST
	Suite A MUST be deprecated using the process described in Section 10		be deprecated using the process described in Section 10 and CAs MUST
	and CAs MUST NOT remove Suite C product sets. At this stage, RPs are		NOT remove Suite A product sets. At this stage, RPs are still
	still capable of processing Suite C signed products, so the RPKI is		capable of processing Suite A signed products, so the RPKI is still
	still viable.		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-Y-Certificate-Algorithm-Suite-C (Cert-YC)
	|-> CA-Y-CRL-Algorithm-Suite-C (CRL-YC)
	|-> CA-Y-Signed-Objects-Algorithm-Suite-C
	|-> CA-X-CRL-Algorithm-Suite-C (CRL-XC)
	|-> CA-X-Signed-Objects-Algorithm-Suite-C
	CA X-Certificate-Algorithm-Suite-A (Cert-XA)		CA X-Certificate-Algorithm-Suite-A (Cert-XA)
	|		|
	|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)		|-> CA-Y-Certificate-Algorithm-Suite-A (Cert-YA)
	|-> CA-Z-Certificate-Algorithm-Suite-A (Cert-ZA)
	|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
	|-> CA-Z-Signed-Objects-Algorithm-Suite-A
	|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)		|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YA)
	|-> CA-Y-Signed-Objects-Algorithm-Suite-A		|-> CA-Y-Signed-Objects-Algorithm-Suite-A
	|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)		|-> CA-X-CRL-Algorithm-Suite-A (CRL-XA)
	|-> CA-X-Signed-Objects-Algorithm-Suite-A		|-> CA-X-Signed-Objects-Algorithm-Suite-A
			CA X-Certificate-Algorithm-Suite-B (Cert-XB)
			|
			|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
			|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
			|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)
			|-> CA-Z-Signed-Objects-Algorithm-Suite-B
			|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)
			|-> CA-Y-Signed-Objects-Algorithm-Suite-B
			|-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)
			|-> CA-X-Signed-Objects-Algorithm-Suite-B
	4.8. Return to Phase 0		4.8. Return to Phase 0
	The EOL Date triggers the return to Phase 0 (steady state). At this		The EOL Date triggers the return to Phase 0 (steady state). At this
	point, the Algorithm Suite C MUST be deprecated using the process		point, the old algorithm suite (Algorithm Suite A) MUST be deprecated
	described in Section 10.		using the process described in Section 10.
	This phase closes the loop as Algorithm Suite A is the only required		This phase closes the loop as the new algorithm suite (Algorithm
	algorithm suite in RPKI.		Suite B) is the only required algorithm suite in RPKI. From this
			point forward, this suite is referred to as Algorithm Suite A.
	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 milestone.		be reissued pushing back the date for this milestone.
	5. Multi Algorithm support in the RPKI provisioning protocol		5. Multi Algorithm support in the RPKI provisioning protocol
	The migration described in this document is a top-down process, where		The migration described in this document is a top-down process, where
	two synchronization issues need to be solved between child and parent		two synchronization issues need to be solved between child and parent
	CAs:		CAs:
	skipping to change at page 18, line 23 ¶		skipping to change at page 18, line 23 ¶
	each signed product, one signed under Algorithm Suite A and one under		each signed product, one signed under Algorithm Suite A and one under
	Algorithm Suite B. As noted in Section 4.4, in this phase there is a		Algorithm Suite B. As noted in Section 4.4, in this phase there is a
	preference for Suite A product sets. All products are available		preference for Suite A product sets. All products are available
	under Suite A, while only some products may be available under Suite		under Suite A, while only some products may be available under Suite
	B. For production purposes an RP MAY fetch and validate only Suite A		B. For production purposes an RP MAY fetch and validate only Suite A
	products. Suite B products SHOULD be fetched and validated only for		products. Suite B products SHOULD be fetched and validated only for
	test purposes. When product sets exist under both Suites, they		test purposes. When product sets exist under both Suites, they
	should yield equivalent results, which facilitates testing. (It is		should yield equivalent results, which facilitates testing. (It is
	not possible to directly compare Suite A and Suite B product sets, as		not possible to directly compare Suite A and Suite B product sets, as
	certs, CRLs, and manifests will appear syntactically different.		certs, CRLs, and manifests will appear syntactically different.
	However, the output of the process, i.e., the ROA payloads (ASN and		However, the output of the process, i.e., the ROA payloads
	prefix data), SHOULD match, modulo timing issues.)		(Autonomous System Number and address prefix data), SHOULD match,
			modulo timing issues.)
	During Phases 2 and 3 of this process, two (corresponding) instances		During Phases 2 and 3 of this process, two (corresponding) instances
	of all signed products MUST be available to RPs. As noted in Section		of all signed products MUST be available to RPs. As noted in Section
	4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate		4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate
	Suite B products sets, during Phase 2. If an RP encounters		Suite B products sets, during Phase 2. If an RP encounters
	validation problems with the Suite B products, it SHOULD revert to		validation problems with the Suite B products, it SHOULD revert to
	using Suite A products. RPs that are Suite B capable MAY fetch both		using Suite A products. RPs that are Suite B capable MAY fetch both
	product sets and compare the results (e.g., ROA outputs) for testing.		product sets and compare the results (e.g., ROA outputs) for testing.
	In Phase 3 all RPs MUST be Suite B capable, and MUST fetch Suite B		In Phase 3 all RPs MUST be Suite B capable, and MUST fetch Suite B
	product sets. If an RP encounters problems with Suite B product		product sets. If an RP encounters problems with Suite B product
	sets, it can revert to Suite A products. RPs encountering such		sets, it can revert to Suite A products. RPs encountering such
	problems SHOULD contact the relevant repository maintainers (e.g.,		problems SHOULD contact the relevant repository maintainers (e.g.,
	using the mechanism defined in [RFC6493] to report problems.)		using the mechanism defined in [RFC6493] to report problems.)
	During Phase 4 only Suite A (previously Suite B) product sets are		During Phase 4 only Suite B product sets are required to be present
	required to be present for all RPKI entities, as per Section 4.7.		for all RPKI entities, as per Section 4.7. Thus RPs SHOULD retrieve
	Thus RPs SHOULD retrieve and validate only these product sets.		and validate only these product sets. Retrieval of Suite A products
	Retrieval of Suite C (old Suite A) products sets may yield an		sets may yield an incomplete set of signed products and is NOT
	incomplete set of signed products and is NOT RECOMMENDED.		RECOMMENDED.
	7. Revocation		7. Revocation
	The algorithm migration process mandates the maintenance of two		The algorithm migration process mandates the maintenance of two
	parallel but equivalent certification hierarchies during Phases 2 and		parallel but equivalent certification hierarchies during Phases 2 and
	3 of the process. During these phases, a CA MUST revoke and request		3 of the process. During these phases, a CA MUST revoke and request
	revocation of certificates consistently under both algorithm Suites.		revocation of certificates consistently under both algorithm Suites.
	When not performing a key rollover operation (as described in Section		When not performing a key rollover operation (as described in Section
	8), a CA requesting the revocation of its certificate during these		8), a CA requesting the revocation of its certificate during these
	two phases MUST perform that request for both algorithm suites (A and		two phases MUST perform that request for both algorithm suites (A and
	B). A non-leaf CA SHOULD NOT verify that its child CAs comply with		B). A non-leaf CA SHOULD NOT verify that its child CAs comply with
	this requirement. Note that a CA MUST request revocation of its		this requirement. Note that a CA MUST request revocation of its
	certificate relative to a specific algorithm suite using the		certificate relative to a specific algorithm suite using the
	mechanism described in Section 5		mechanism described in Section 5
	During Phase 1, a CA that revokes a certificate under Suite A SHOULD		During Phase 1, a CA that revokes a certificate under Suite A SHOULD
	revoke the corresponding certificate under Suite B, if that		revoke the corresponding certificate under Suite B, if that
	certificate exists. During Phase 4, a CA that revokes a certificate		certificate exists. During Phase 4, a CA that revokes a certificate
	under Suite A SHOULD revoke the corresponding certificate under Suite		under Suite B SHOULD revoke the corresponding certificate under Suite
	C, if that certificate exists.		A, if that certificate exists.
	During Phase 1, a CA may revoke certificates under Suite B without		During Phase 1, a CA may revoke certificates under Suite B without
	revoking them under Suite A, since the Suite B products are for test		revoking them under Suite A, since the Suite B products are for test
	purposes. During Phase 4 a CA may revoke certificates issued under		purposes. During Phase 4 a CA may revoke certificates issued under
	Suite C without revoking them under Suite A, since Suite C products		Suite A without revoking them under Suite B, since Suite A products
	are being deprecated.		are being deprecated.
	8. Key rollover		8. Key rollover
	Key rollover (without algorithm changes) is effected independently		Key rollover (without algorithm changes) is effected independently
	for each algorithm suite and MUST follow the process described in		for each algorithm suite and MUST follow the process described in
	[RFC6489].		[RFC6489].
	9. Repository structure		9. Repository structure
	skipping to change at page 27, line 22 ¶		skipping to change at page 27, line 22 ¶
	[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, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[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,
	February 2012.		February 2012.
			[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
			Origin Authorizations (ROAs)", RFC 6482, February 2012.
	[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate		[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
	Policy (CP) for the Resource Public Key Infrastructure		Policy (CP) for the Resource Public Key Infrastructure
	(RPKI)", BCP 173, RFC 6484, February 2012.		(RPKI)", BCP 173, RFC 6484, February 2012.
	[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for		[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
	Use in the Resource Public Key Infrastructure (RPKI)",		Use in the Resource Public Key Infrastructure (RPKI)",
	RFC 6485, February 2012.		RFC 6485, February 2012.
	[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
	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 09 to 10
			1. GenArt Comments: Remove Algorithm C from process and replace a
			couple of "will" with MUST when referring to issuing a new
			document.
	From 08 to 09		From 08 to 09
	1. SecDIR comments and nits included		1. SecDIR comments and nits included
	From 07 to 08		From 07 to 08
	1. Typo in Section 10		1. Typo in Section 10
	2. Correct reference for RFC6493		2. Correct reference for RFC6493
End of changes. 33 change blocks.
	90 lines changed or deleted		98 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/