< draft-ietf-sidr-algorithm-agility-10.txt		draft-ietf-sidr-algorithm-agility-11.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: July 11, 2013 BBN Technologies		Expires: July 19, 2013 BBN Technologies
	S. Turner		S. Turner
	IECA, Inc.		IECA, Inc.
	January 7, 2013		January 15, 2013
	Algorithm Agility Procedure for RPKI.		Algorithm Agility Procedure for RPKI.
	draft-ietf-sidr-algorithm-agility-10		draft-ietf-sidr-algorithm-agility-11
	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 several 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
	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 July 11, 2013.		This Internet-Draft will expire on July 19, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 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
	skipping to change at page 7, line 11 ¶		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].		ROA: Route Origination Authorisation, 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 10, line 52 ¶		skipping to change at page 10, line 52 ¶
	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 steady state phase of the process; throughout this		Phase 0 is the steady state phase of the process; throughout this
	phase, Algorithm Suite A is the only supported algorithm suite in		phase, Algorithm Suite A is the only supported algorithm suite in
	RPKI. 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
	objects in the repository. It reflects the algorithm suites in use,
	and shows the relationship between three CAs (X, Y, and Z) that form
	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.
	CA X-Certificate-Algorithm-Suite-A (Cert-XA)		The following figure shows an example of the structure of signed
	|		objects in the repository, indicating the algorithm suites in use,
			and showing the relationships between three CAs (X, Y, and Z) that
			form a certification chain. Vertical alignment in the figure
			indicates objects signed by the same CA using the same private key.
			The differences in horizontal indentation also represent use of
			different publication points for objects signed by different CAs.
			The characters "|->" are used for visualization purposes for both the
			signing relationship and the publication point change. For example,
			the objects CA-Y-Certificate-Algorithm-Suite-A, CA-X-CRL-Algorithm-
			Suite-A and CA-X-Signed-Objects-Algorithm-Suite-A are all signed
			using the private key corresponding to CA-X-Certificate-Algorithm-
			Suite-A and published at CA X's corresponding publication point.
			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-Certificate-Algorithm-Suite-A (Cert-ZA)
	|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)		|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
	|-> CA-Z-Signed-Objects-Algorithm-Suite-A		|-> 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
	Note: Cert-XA represent the certificate for CA X, that is signed		Note: Cert-XA represent the certificate for CA X, that is signed
	skipping to change at page 13, line 5 ¶		skipping to change at page 13, line 5 ¶
	will be incomplete, i.e., not all CAs will have issued products under		will be incomplete, i.e., not all CAs will have issued products under
	Suite B. Thus for production purposes, RPs MUST fetch and validate		Suite B. Thus for production purposes, RPs MUST fetch and validate
	only Suite A products. Suite B products should be fetched and		only Suite A products. Suite B products should be fetched and
	processed only for testing purposes.		processed only for testing purposes.
	The following figure shows the status of repository entries for the		The following figure shows the status of repository entries for the
	three example CAs during this Phase. Two distinct certificate chains		three example CAs during this Phase. Two distinct certificate chains
	are maintained and CA Z has not yet requested any material using the		are maintained and CA Z has not yet requested any material using the
	Algorithm Suite B.		Algorithm Suite B.
	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-Certificate-Algorithm-Suite-A (Cert-ZA)
	|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)		|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
	|-> CA-Z-Signed-Objects-Algorithm-Suite-A		|-> 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-X-Certificate-Algorithm-Suite-B (Cert-XB)
	|
	|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)		|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
	|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)		|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
	|-> CA-Y-Signed-Objects-Algorithm-Suite-B		|-> CA-Y-Signed-Objects-Algorithm-Suite-B
	|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)		|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
	|-> CA-X-Signed-Objects-Algorithm-Suite-B		|-> CA-X-Signed-Objects-Algorithm-Suite-B
	4.5. Phase 2		4.5. Phase 2
	Phase 2 starts at the CA Go Algorithm B Date. At the start of this		Phase 2 starts at the CA Go Algorithm B Date. At the start of this
	phase, each signed product set MUST be available using both Algorithm		phase, each signed product set MUST be available using both Algorithm
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 15 ¶
	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.
	The following figure shows the status of the repository entries for		The following figure shows the status of the repository entries for
	the three example CAs throughout this phase, where all signed objects		the three example CAs throughout this phase, where all signed objects
	are available using both algorithm suites.		are available using both algorithm suites.
	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-Certificate-Algorithm-Suite-A (Cert-ZA)
	|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)		|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZA)
	|-> CA-Z-Signed-Objects-Algorithm-Suite-A		|-> 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-X-Certificate-Algorithm-Suite-B (Cert-XB)
	|
	|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)		|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
	|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)		|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
	|-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)		|-> CA-Z-CRL-Algorithm-Suite-B (CRL-ZB)
	|-> CA-Z-Signed-Objects-Algorithm-Suite-B		|-> CA-Z-Signed-Objects-Algorithm-Suite-B
	|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)		|-> CA-Y-CRL-Algorithm-Suite-B (CRL-YB)
	|-> CA-Y-Signed-Objects-Algorithm-Suite-B		|-> CA-Y-Signed-Objects-Algorithm-Suite-B
	|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)		|-> CA-X-CRL-Algorithm-Suite-B (CRL-XB)
	|-> CA-X-Signed-Objects-Algorithm-Suite-B		|-> CA-X-Signed-Objects-Algorithm-Suite-B
	4.6. Phase 3		4.6. Phase 3
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 5 ¶
	unsuitable, the algorithm transition timeline, the algorithm		unsuitable, the algorithm transition timeline, the algorithm
	specification documents MUST be replaced, the Algorithm Suite B MUST		specification documents MUST be replaced, the Algorithm Suite B MUST
	be deprecated using the process described in Section 10 and CAs MUST		be deprecated using the process described in Section 10 and CAs MUST
	NOT remove Suite A product sets. At this stage, RPs are still		NOT remove Suite A product sets. At this stage, RPs are still
	capable of processing Suite A signed products, so the RPKI is still		capable of processing Suite A signed products, so the RPKI is 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-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-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-X-Certificate-Algorithm-Suite-B (Cert-XB)
	|
	|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)		|-> CA-Y-Certificate-Algorithm-Suite-B (Cert-YB)
	|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)		|-> CA-Z-Certificate-Algorithm-Suite-B (Cert-ZB)
	|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)		|-> CA-Z-CRL-Algorithm-Suite-A (CRL-ZB)
	|-> CA-Z-Signed-Objects-Algorithm-Suite-B		|-> CA-Z-Signed-Objects-Algorithm-Suite-B
	|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)		|-> CA-Y-CRL-Algorithm-Suite-A (CRL-YB)
	|-> CA-Y-Signed-Objects-Algorithm-Suite-B		|-> CA-Y-Signed-Objects-Algorithm-Suite-B
	|-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)		|-> CA-X-CRL-Algorithm-Suite-A (CRL-XB)
	|-> CA-X-Signed-Objects-Algorithm-Suite-B		|-> CA-X-Signed-Objects-Algorithm-Suite-B
	4.8. Return to Phase 0		4.8. Return to Phase 0
	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 10 to 11
			Additional GenArt review on section 4 to improve the description of
			the figures showing the CAs chains.
	From 09 to 10		From 09 to 10
	1. GenArt Comments: Remove Algorithm C from process and replace a		1. GenArt Comments: Remove Algorithm C from process and replace a
	couple of "will" with MUST when referring to issuing a new		couple of "will" with MUST when referring to issuing a new
	document.		document.
	From 08 to 09		From 08 to 09
	1. SecDIR comments and nits included		1. SecDIR comments and nits included
End of changes. 14 change blocks.
	24 lines changed or deleted		31 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/