< draft-ietf-sidr-algorithm-agility-05.txt		draft-ietf-sidr-algorithm-agility-06.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 20, 2012 BBN Technologies		Expires: December 28, 2012 BBN Technologies
	S. Turner		S. Turner
	IECA, Inc.		IECA, Inc.
	January 17, 2012		June 26, 2012
	Algorithm Agility Procedure for RPKI.		Algorithm Agility Procedure for RPKI.
	draft-ietf-sidr-algorithm-agility-05		draft-ietf-sidr-algorithm-agility-06
	Abstract		Abstract
	This document specifies the process that Certification Authorities		This document specifies the process that Certification Authorities
	(CAs) and Relying Parties (RP) 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
	(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
	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 20, 2012.		This Internet-Draft will expire on December 28, 2012.
	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 2, line 28 ¶		skipping to change at page 2, line 28 ¶
	4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 7		4.2. Process overview . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.3. Phase 0 . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 10		4.3.1. Milestone 1 . . . . . . . . . . . . . . . . . . . . . 10
	4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 11		4.4. Phase 1 . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12		4.5. Phase 2 . . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.6. Phase 3 . . . . . . . . . . . . . . . . . . . . . . . . . 13
	4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14		4.7. Phase 4 . . . . . . . . . . . . . . . . . . . . . . . . . 14
	4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 15		4.8. Return to Phase 0 . . . . . . . . . . . . . . . . . . . . 15
	5. Multi Algorithm support in the RPKI provisioning protocol . . 16		5. Multi Algorithm support in the RPKI provisioning protocol . . 16
	6. Validation of multiple instance of signed products . . . . . . 17		6. Validation of multiple instance of signed products . . . . . . 17
	7. Revocations . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 19		8. Key rollover . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9. Repository structure . . . . . . . . . . . . . . . . . . . . . 20		9. Repository structure . . . . . . . . . . . . . . . . . . . . . 20
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		10. Deprecating an Algorithm Suite . . . . . . . . . . . . . . . . 21
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 22		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23		12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 24		14. Normative References . . . . . . . . . . . . . . . . . . . . . 26
	13.2. Informative References . . . . . . . . . . . . . . . . . . 25		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 26		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
	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", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		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
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 19 ¶
	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
	be necessitated by suspected private key compromise, one can never		be necessitated by suspected private key compromise, one can never
	assume coordination of these events among all of the CAs in the RPKI.		assume coordination of these events among all of the CAs in the RPKI.
	In an emergency key rollover, the old certificate is revoked and a		In an emergency key rollover, the old certificate is revoked and a
	new certificate with a new key is issued. The mechanisms to perform		new certificate with a new key is issued. The mechanisms to perform
	a key rollover in RPKI (either planned or in an emergency), while		a key rollover in RPKI (either planned or in an emergency), while
	maintaining the same algorithm suite, are covered in		maintaining the same algorithm suite, are covered in [RFC6489].
	[I-D.ietf-sidr-keyroll].
	This document describes the mechanism to perform a key rollover in		This document describes the mechanism to perform a key rollover in
	RPKI due to the migration to a new signature algorithm suite. A		RPKI due to the migration to a new signature algorithm suite. A
	signature algorithm suite encompasses both a signature algorithm		signature algorithm suite encompasses both a signature algorithm
	(with a specified key size range) and a one-way hash algorithm. It		(with a specified key size range) and a one-way hash algorithm. It
	is anticipated that the RPKI will require the adoption of updated key		is anticipated that the RPKI will require the adoption of updated key
	sizes and/or different algorithm suites over time. This document		sizes and/or different algorithm suites over time. This document
	treats the adoption of a new hash algorithm while retaining the		treats the adoption of a new hash algorithm while retaining the
	current signature algorithm as equivalent to an algorithm migration,		current signature algorithm as equivalent to an algorithm migration,
	and requires the CA to change its key. Migration to a new algorithm		and requires the CA to change its key. Migration to a new algorithm
	suite will be required in order to maintain an acceptable level of		suite will be required in order to maintain an acceptable level of
	cryptographic security and protect the integrity of certificates,		cryptographic security and protect the integrity of certificates,
	CRLs and signed objects in the RPKI. All of the data structures in		CRLs and signed objects in the RPKI. All of the data structures in
	the RPKI explicitly identify the signature and hash algorithms being		the RPKI explicitly identify the signature and hash algorithms being
	used. However, experience has demonstrated that the ability to		used. However, experience has demonstrated that the ability to
	represent algorithm IDs is not sufficient to enable migration to new		represent algorithm IDs is not sufficient to enable migration to new
	algorithm suites (algorithm agility). One also must ensure that		algorithm suites (algorithm agility). One also must ensure that
	protocols, infrastructure elements, and operational procedures also		protocols, infrastructure elements, and operational procedures also
	accommodate migration from one algorithm suite to another. Algorithm		accommodate the migration from one algorithm suite to another.
	migration is expected to be very infrequent, but it also will require		Algorithm migration is expected to be very infrequent and it will
	support of a "current" and "next" suite for a prolonged interval,		require support of a "current" and "next" suite for a prolonged
	probably several years.		interval, probably several years.
	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) [I-D.ietf-sidr-cp] mandates the use of the		Certificate Policy (CP) [RFC6484] mandates the use of the algorithms
	algorithms defined in [I-D.ietf-sidr-rpki-algs] by CAs and RPs. When		defined in [RFC6485] by CAs and RPs. When an algorithm transition is
	an algorithm transition is initiated, [I-D.ietf-sidr-rpki-algs] will		initiated, [RFC6485] will be updated (as defined in Section 4.1 of
	be updated (as defined in Section 4.1 of this document) redefining		this document) redefining the required algorithm(s) for compliant
	the required algorithm(s) for compliant RPKI CAs and RPs under the		RPKI CAs and RPs under the CP. The CP will not change as a side
	CP. The CP will not change as a side effect of algorithm transition		effect of algorithm transition (and thus the policy OID in RPKI
	(and thus the policy OID in RPKI certificates will not change.)		certificates will not change.)
	An additional document, the algorithm transition timetable, will be		An additional document, the algorithm transition timetable, will be
	published (as a BCP) to define the dates for each milestone defined		published (as an IETF BCP) to define the dates for each milestone
	in this document. It will define dates for the phase transitions,		defined in this document. It will define dates for the phase
	consistent with the descriptions provided in Section 4. It also will		transitions, consistent with the descriptions provided in Section 4.
	describe how the RPKI community will measure the readiness of CAs and		It also will describe how the RPKI community will measure the
	RPs to transition to each phase. CAs publish certificates, CRLs, and		readiness of CAs and RPs to transition to each phase. CAs publish
	other signed objects under the new algorithm suite as the transition		certificates, CRLs, and other signed objects under the new algorithm
	progresses. This provides visibility into the deployment of the new		suite as the transition progresses. This provides visibility into
	algorithm suite, enabling the community to evaluate deployment		the deployment of the new algorithm suite, enabling the community to
	progress. The transition procedure allows CAs to remove old		evaluate deployment progress. The transition procedure allows CAs to
	certificates, CRLs, and signed products, after the twilight date.		remove old certificates, CRLs, and signed products, after the
	This provides an ability to observe and measure the withdrawal of the		twilight date. This provides an ability to observe and measure the
	old algorithm suite. Thus the phases defined in this document enable		withdrawal of the old algorithm suite. Thus the phases defined in
	the community to evaluate the progress of the transition. The		this document enable the community to evaluate the progress of the
	timetable document will also describe procedures to amend the		transition. The timetable document will also describe procedures to
	timetable if problems arise in implementing later phases of the		amend the timetable if problems arise in implementing later phases of
	transition. It is RECOMMENDED that the timetable document be		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"		"A Profile for Resource Certificate Repository Structure" [RFC6481].
	[I-D.ietf-sidr-repos-struct]. Additional terms and conventions used		Additional terms and conventions used in examples are provided below.
	in examples are provided below.
	Algorithm migration A planned transition from one signature and hash		Algorithm migration: A planned transition from one signature and
	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 and		Algorithm Suite A: The "current" algorithm suite used for hashing
	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		Algorithm Suite C: The "old" algorithm suite used for hashing and
	signing, used in examples in this document		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-leaf		Non-Leaf CA: A CA that issues certificates to other CAs is a non-
	CA.		leaf CA.
	Leaf CA A leaf CA is a CA that issues only EE certs.		Leaf CA: A leaf CA is a CA that issues only EE certs.
	PoP (proof of possession) Execution of a protocol that demonstrates		PoP (proof of possession): Execution of a protocol that demonstrates
	to an issuer that a subject requesting a certificate		to an issuer that a subject requesting a certificate
	possesses the private key corresponding to the public key		possesses the private key corresponding to the public key
	in the certificate 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
	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 [I-D.ietf-sidr-rpki-algs]. When a		CP document, by reference to [RFC6485]. When a migration of the RPKI
	migration of the RPKI algorithm suite is needed, the first step MUST		algorithm suite is needed, the first step MUST be an update of
	be an update of the [I-D.ietf-sidr-rpki-algs] document to define the		[RFC6485] to define the new algorithm suite. The algorithm
	new algorithm suite. The algorithm transition timeline document MUST		transition timeline document MUST also be published (as a BCP), to
	also be published (as a BCP), to inform the community of the dates		inform the community of the dates selected for milestones in the
	selected for milestones in the transition process, as described in		transition process, as described in Section 4.1.
	Section 4.1.
	4.1. Milestones definition		4.1. Milestones definition
	CA Ready Algorithm B Date - After this date, all (non-leaf) CAs MUST		CA Ready Algorithm B Date: After this date, all (non-leaf) CAs MUST
	be ready to process a request from a child CA to issue a		be ready to process a request from a child CA to issue a
	certificate under the Algorithm B suite.		certificate under the Algorithm Suite B. All CAs
			publishing an [RFC6490] Trust Anchor Locator (TAL) for
			Algorithm Suite A, MUST also publish the correspondent
			TAL for Algorithm Suite B.
	CA Go Algorithm B Date - After this date, all (non-leaf) CAs MUST		CA Go Algorithm B Date: After this date, all CAs MUST have reissued
	have reissued all of their signed product sets under the		all of their signed product sets under the Algorithm
	Algorithm B suite.		Suite B.
	RP Ready Algorithm B Date - After this date, all RPs MUST be		RP Ready Algorithm B Date: After this date, all RPs MUST be prepared
	prepared to process signed material issued under the		to process signed material issued under the Algorithm
	Algorithm B suite.		Suite B.
	Twilight Algorithm B - After this date, a CA MAY cease issuing		Twilight Date: After this date, a CA MAY cease issuing signed
	signed products under the Algorithm A suite. Also, after		products under the Algorithm Suite A. Also, after this
	this date, a RP MAY cease to validate signed materials		date, a RP MAY cease to validate signed materials issued
	issued under the Algorithm A suite.		under the Algorithm Suite A.
	End Of Life (EOL) Algorithm A - After this date every CA MUST NOT		End Of Life (EOL) Date: After this date, the Algorithm Suite C is
	generate certificates, CRLs, or other RPKI signed objects		MUST be deprecated using the process in Section 10 and
	under the Algorithm A suite. Also, after this date, no		all Algorithm Suite C TALs MUST be removed from their
	RP SHOULD accept as valid any certificate, CRL or signed		publication points.
	object using the Algorithm A suite.
	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 Algorithm A" date. Due to the decentralized nature		time is the EOL Date. Due to the decentralized nature of the RPKI
	of the RPKI infrastructure, it is expected that an algorithm		infrastructure, it is expected that an algorithm transition will span
	transition will span several years.		several years.
	In order to facilitate the transition, CAs will start issuing		In order to facilitate the transition, CAs will start issuing
	certificates using the Algorithm B in a hierarchical top-down		certificates using the Algorithm B in a hierarchical top-down
	fashion. In our example, CA Y will issue certificates using the		fashion. In our example, CA Y will issue certificates using the
	Algorithm B suite only after CA X has started to do so (CA Y Ready		Algorithm Suite B only after CA X has started to do so (CA Y Ready
	Algorithm B Date > CA X Ready Algorithm B Date). This ordered		Algorithm B Date > CA X Ready Algorithm B Date). This ordered
	transition avoids issuance of "mixed" suite certificates, e.g., a CA		transition avoids issuance of "mixed" suite CA certificates, e.g., a
	certificate signed using Suite A, containing a key from Suite B. In		CA certificate signed using Suite A, containing a key from Suite B.
	the RPKI, a CA MUST NOT sign a CA certificate carrying a subject key		In the RPKI, a CA MUST NOT sign a CA certificate carrying a subject
	that corresponds to an algorithm suite that differs from the one used		key that corresponds to an algorithm suite that differs from the one
	to sign the certificate (X.509 accommodates such mixed algorithm		used to sign the certificate. (X.509 accommodates such mixed
	certificates, but this process avoids using that capability.) A not		algorithm certificates, but this process avoids using that
	top-down transition approach would require use of such mixed mode		capability.) A not top-down transition approach would require use of
	certificates, but this would lead to exponential growth of the RPKI		such mixed mode certificates, and would lead to exponential growth of
	repository. Also, because the RPKI CP mandates "proof of possession"		the RPKI repository. Also, because the RPKI CP mandates Proof of
	for certificate requests, it is not possible for a CA to request a		Possession (PoP) for certificate requests, it is not possible for a
	certificate for Algorithm Suite B, until its parent CA supports that		CA to request a certificate for Algorithm Suite B, until its parent
	Suite. (See Section 5 for more details.)		CA supports that Suite. (See Section 5 for more details.)
	The algorithm agility model described here does not prohibit a CA		The algorithm agility model described here does not prohibit a CA
	from issuing an EE certificate with a subject public key from a		from issuing an EE certificate with a subject public key from a
	different algorithm suite, if that certificate is not used to verify		different algorithm suite, if that certificate is not used to verify
	repository objects. This exception to the mixed algorithm suite		repository objects. This exception to the mixed algorithm suite
	certificate rule is allowed because an EE certificate that is not		certificate rule is allowed because an EE certificate that is not
	used to verify repository objects does not interfere with the ability		used to verify repository objects does not interfere with the ability
	of RPs to download and verify repository content. As noted above,		of RPs to download and verify repository content. As noted above,
	every CA in the RPKI is required to perform a Proof of Possession		every CA in the RPKI is required to perform a PoP check for the
	(PoP) check for the subject public key when issuing a certificate.		subject public key when issuing a certificate. In general a subject
	In general a subject cannot assume that a CA is capable of supporting		cannot assume that a CA is capable of supporting a different
	a different algorithm. However, if the subject is closely affiliated		algorithm. However, if the subject is closely affiliated with the
	with the CA, it is reasonable to assume that there are ways for the		CA, it is reasonable to assume that there are ways for the subject to
	subject to know whether the CA can support a request to issue an EE		know whether the CA can support a request to issue an EE certificate
	certificate containing a specific, different public key algorithm.		containing a specific, different public key algorithm. This document
	This document does not specify how a subject can determine whether a		does not specify how a subject can determine whether a CA is capable
	CA is capable of issuing a mixed suite EE certificate, because it		of issuing a mixed suite EE certificate, because it anticipates that
	anticipates that such certificates will be issued only in contexts		such certificates will be issued only in contexts where the subject
	where the subject and CA are sufficiently closely affiliated (for		and CA are sufficiently closely affiliated (for example, an ISP
	example, an ISP issuing certificates to devices that it manages).		issuing certificates to devices that it manages).
	The following figure gives an overview of the process:		The following figure gives an overview of the process:
	Process for RPKI CAs:		Process for RPKI CAs:
	Phase 0 Phase 1 Phase 2 Phase 4 Phase 0		Phase 0 Phase 1 Phase 2 Phase 4 Phase 0
	-----------x---------x-------------------x--------x-----------		-----------x---------x-------------------x--------x-----------
	^ ^ ^ ^ ^		^ ^ ^ ^ ^
	| | | | |		| | | | |
	(1) (2) (3) (5) (6)		(1) (2) (3) (5) (6)
	skipping to change at page 9, line 28 ¶		skipping to change at page 9, line 28 ¶
	| | | |		| | | |
	(1) (4) (5) (6)		(1) (4) (5) (6)
	(1) RPKI algorithm document is updated and the algorithm transition timeline document is issued		(1) RPKI algorithm document is updated and the algorithm transition timeline document is issued
	(2) CA Ready Algorithm B Date		(2) CA Ready Algorithm B Date
	(3) CA Go Algorithm B Date		(3) CA Go Algorithm B Date
	(4) RP Ready Algorithm B Date		(4) RP Ready Algorithm B Date
	(5) Twilight Date		(5) Twilight Date
	(6) End Of Live (EOL) Date		(6) End Of Live (EOL) Date
	Each of these milestones is discussed in the next section as part of		Each of these milestones is discussed in the next section when
	describing each phase of the transition process.		describing each phase of the transition process.
	Two situations have been identified that motivate pausing or rolling		Two situations have been identified that motivate pausing or rolling
	back the transition process. The first situation arises if the RPKI		back the transition process. The first situation arises if the RPKI
	community is not ready to make the transition. For example, many CAs		community is not ready to make the transition. For example, many CAs
	might not be prepared to issue signed products under Suite B, or many		might not be prepared to issue signed products under Suite B, or many
	RPs might not be ready to process Suite B product sets. Under these		RPs might not be ready to process Suite B products. Under these
	circumstances, the timetable MUST be reissued, postponing the date		circumstances, the timetable MUST be reissued, postponing the date
	for the phase in question, and pushing back the dates for later		for the phase in question, and pushing back the dates for later
	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.
	skipping to change at page 10, line 28 ¶		skipping to change at page 10, line 28 ¶
	|-> 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
	using the algorithm suite A.		using the algorithm suite A.
	4.3.1. Milestone 1		4.3.1. Milestone 1
	The first milestone initiates the migration process. It updates the		The first milestone initiates the migration process. It updates
	[I-D.ietf-sidr-rpki-algs] document with the following definitions for		[RFC6485] with the following definitions for the RPKI:
	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 will 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
	o EOL Date		o EOL Date
	o Readiness metrics for CAs and RPs in each phase		o Readiness metrics for CAs and RPs in each phase
	All Dates MUST be represented using the local UTC date-time format		Each date specified here is assumed at one minute after midnight,
	specified in [RFC3339].		UTC. No finer granularity time specification is required or
			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 B suite. 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 will 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, CAs MUST cease accepting requests for certificates under		replaced, the Algorithm Suite B MUST be deprecated using the process
	Suite B, and Suite B certificates that have been issued MUST be		described in Section 10.
	revoked.
	As the transition will happen using a (hierarchic) top-down model, a		As the transition will happen using a (hierarchic) top-down model, a
	child CA will be able to issue certificates using the Algorithm B		child CA will be able to issue certificates using the Algorithm Suite
	suite only after its parent CA has issued its own. The RPKI		B only after its parent CA has issued its own. The RPKI provisioning
	provisioning protocol can identify if a parent CA is capable of		protocol can identify if a parent CA is capable of issuing
	issuing certificates using the Algorithm Suite B, and can identify		certificates using the Algorithm Suite B, and can identify the
	the corresponding algorithm suite in each Certificate Signing Request		corresponding algorithm suite in each Certificate Signing Request
	(see Section 5).		(see Section 5). During much of this phase the Suite B product tree
			will be incomplete, i.e., not all CAs will have issued products under
			Suite B. Thus for production purposes, RPs MUST fetch and validate
			only Suite A products. Suite B products should be fetched and
			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 B suite.		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)
	skipping to change at page 12, line 41 ¶		skipping to change at page 12, line 41 ¶
	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 will 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. If the Suite B algorithm is		there is no adverse impact on RPs that are not prepared to process
	deemed unsuitable, the algorithm transition timeline and the		suite B products. If the Suite B algorithm is deemed unsuitable, the
	algorithm specification documents MUST be replaced. CAs MUST cease		algorithm transition timeline and the algorithm specification
	accepting requests for certificates under Suite B, and Suite B		documents MUST be replaced and the Algorithm Suite B MUST be
	certificates that have been issued MUST be revoked.		deprecated using the process described in Section 10.
			It is RECOMMENDED that RPs that can process Algorithm Suite B fetch
			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
			RP that elects to validate signed product sets using both Algorithm
			Suite A or Algorithm Suite B should expect the same results. If
			there are discrepancies when evaluating corresponding signed product
			sets, successful validation of either product set is acceptable. A
			detailed analysis of the validation of multiple instances of signed
			objects is included in Section 6.
	An RP that validates all signed product sets using both Algorithm
	Suite A or Algorithm Suite B SHOULD expect the same results.
	However, an object that validates using either Algorithm Suite A or
	Algorithm Suite B MUST be considered valid. A detailed analysis on
	the validation of multiple instances of signed 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
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 38 ¶
	|-> 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
	Phase 3 starts at the RP Ready Algorithm B Date. During this phase,		Phase 3 starts at the RP Ready Algorithm B Date. During this phase,
	all signed product sets are available using both algorithm suites and		all signed product sets are available using both algorithm suites and
	all RPs MUST be able to validate them using either suite. An object		all RPs MUST be able to validate them. It is RECOMMENDED that, in
	that validates using either Algorithm Suite A or Algorithm Suite B		preparation for Phase 4, RPs retrieve and process Suite B product
	MUST be considered valid. It is RECOMMENDED that, in preparation for		sets first, and treat them as the preferred product sets for
	Phase 4, RPs utilize Suite B as the first and preferred option for		validation throughout this phase. Thus an RP SHOULD try to validate
	validation throughout this phase. Thus, for example, an RP SHOULD		the sets of signed products retrieved from the Algorithm Suite B
	try to validate the sets of signed products retrieved from the		repository first.
	Algorithm Suite B repository first. If this effort fails (relative
	to the local validation policy), the RP SHOULD revert to using the
	Algorithm Suite A repository.
	If a substantial number of RPs are unable to process product sets		If a substantial number of RPs are unable to process product sets
	signed with Suite B, the algorithm transition timeline document MUST		signed with Suite B, the algorithm transition timeline document MUST
	be reissued, pushing back the date for this and later milestones, as		be reissued, pushing back the date for this and later milestones, as
	discussed in Section 4.2. Since the Suite B products SHOULD be		discussed in Section 4.2. Since the Suite B products SHOULD be
	published at distinct publication points, RPs that cannot process		published at distinct publication points, RPs that cannot process
	Suite B products can be expected to revert to the Suite A products		Suite B products can be expected to revert to the Suite A products
	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. CAs MUST cease accepting requests for		documents MUST be replaced and the Algorithm Suite B MUST be
	certificates under Suite B, and Suite B certificates that have been		deprecated using the process described in Section 10.
	issued MUST be revoked.
	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 Algorithm A Twilight Date. At that date, the		Phase 4 starts at the Twilight Date. At that date, the Algorithm A
	Algorithm A is labeled as "old" and the Algorithm B is labeled as		is labeled as "old" and the Algorithm B is labeled as "current":
	"current":
	Before Twilight --> After Twilight		Before Twilight --> After Twilight
	Algorithm Suite A ("current") --> Algorithm Suite C ("old")		Algorithm Suite A ("current") --> Algorithm Suite C ("old")
	Algorithm Suite B ("new") --> Algorithm Suite A ("current")		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 A (formerly B) and MAY be issued using Algorithm
	Suite C (formerly A). All signed products sets issued using Suite A		Suite C (formerly A). All signed products sets issued using Suite A
	MUST be published at their corresponding publication points, but		MUST be published at their corresponding publication points. Signed
	signed products sets issued using Suite C MAY NOT be published at		products sets issued using Suite C might not be available at their
	their corresponding publication points. Also, every RP MUST		corresponding publication points. Every RP MUST validate signed
	validate signed product sets using Suite A but also MAY validate		product sets using Suite A. RPs MAY validate signed product sets
	signed product sets using Suite C. However, RPs SHOULD NOT assume the		using Suite C. However, RPs SHOULD NOT assume that the collection of
	Suite C repository is complete.		Suite C product sets is complete. Thus RPs SHOULD make use of only
			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 requires 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 Suite B algorithm is deemed		this phase is delayed. If the Algorithm Suite A (former Algorithm
	unsuitable, the algorithm transition timeline and the algorithm		Suite B) is deemed unsuitable, the algorithm transition timeline and
	specification documents MUST be replaced. CAs MUST cease accepting		the algorithm specification documents MUST be replaced and the
	requests for certificates under Suite A (formal Suite A), and Suite A		Algorithm Suite A MUST be deprecated using the process described in
	certificates that have been issued MUST be revoked. At this stage,		Section 10. At this stage, RPs are still capable of processing Suite
	RPs are still capable of processing Suite C signed products.		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. In this case, CA Z no longer issues signed		of the example CAs.
	products using the Algorithm Suite C.
	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)
	|-> CA-X-Signed-Objects-Algorithm-Suite-C		|-> CA-X-Signed-Objects-Algorithm-Suite-C
	CA X-Certificate-Algorithm-Suite-A (Cert-XA)		CA X-Certificate-Algorithm-Suite-A (Cert-XA)
	skipping to change at page 15, line 26 ¶		skipping to change at page 15, line 26 ¶
	|-> 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
	4.8. Return to Phase 0		4.8. Return to Phase 0
	The EOL Algorithm Date triggers a return to Phase 0 (steady state).		The EOL Date triggers the return to Phase 0 (steady state). At this
	At this phase, ALL signed product sets using Algorithm Suite C MUST		point, the Algorithm Suite C MUST be deprecated using the process
	be considered invalid. CAs MUST neither issue nor publish signed		described in Section 10.
	products using Algorithm Suite C.
	This phase closes the loop as Algorithm Suite A is the only required		This phase closes the loop as Algorithm Suite A is the only required
	algorithm suite in RPKI.		algorithm suite in RPKI.
	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. CAs MUST NOT		be reissued pushing back the date for this milestone.
	remove Suite C product sets if this phase is delayed.
	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:
	o A child CA needs to identify which algorithm suites are supported		o A child CA needs to identify which algorithm suites are supported
	by its parent CA		by its parent CA
	o A child CA needs to identify which algorithm suite should be used		o A child CA needs to signal which algorithm suite should be used by
	to sign a Certificate Signing Request (CSR)		its parent CA to sign a Certificate Signing Request (CSR)
	The RPKI provisioning protocol [I-D.ietf-sidr-rescerts-provisioning]		The RPKI provisioning protocol [RFC6492] supports multiple algorithms
	supports multiple algorithms suites by implementing different		suites by implementing different resource classes for each suite.
	resource classes for each suite. Several different resource classes		Several different resource classes also may use the same algorithm
	also may use the same algorithm suite for different resource sets.		suite for different resource sets.
	A child CA that wants to identify which algorithm suites are		A child CA that wants to identify which algorithm suites are
	supported by its parent CA MUST perform the following tasks:		supported by its parent CA MUST perform the following tasks:
	1. Establish a provisioning protocol session with its parent CA		1. Establish a provisioning protocol session with its parent CA
	2. Perform a "list" command as described in Section 3.3.1 of		2. Perform a "list" command as described in Section 3.3.1 of
	[I-D.ietf-sidr-rescerts-provisioning]		[RFC6492]
	3. From the Payload in the "list response" resource class, extract		3. From the Payload in the "list response" resource class, extract
	the "issuer's certificate" for each class. The Algorithm Suite		the "issuer's certificate" for each class. The Algorithm Suite
	for each class will match the Algorithm Suite used to issue the		for each class will match the Algorithm Suite used to issue the
	corresponding "issuer's certificate".		corresponding "issuer's certificate" (as specified in the
			SubjectPublicKeyInfo field of that certificate)
	A child CA that wants to specify an Algorithm Suite to its parent CA		A child CA that wants to specify an Algorithm Suite to its parent CA
	(e.g., in a certificate request) MUST perform the following tasks:		(e.g., in a certificate request) MUST perform the following tasks:
	1. Perform the tasks to identify the resource class for each		1. Perform the tasks described above to identify the algorithm
	Algorithm Suite supported by its parent CA (as above).		suites supported by its parent CA, and the resource class
			corresponding to each suite
	2. Identify the corresponding resource class in the appropriate		2. Identify the corresponding resource class in the appropriate
	provisioning protocol command (e.g. "issue" or "revoke")		provisioning protocol command (e.g. "issue" or "revoke")
	Upon receipt of a certificate request from a child CA, a parent CA		Upon receipt of a certificate request from a child CA, a parent CA
	will verify the PoP of the private key. If a child CA requests		will verify the PoP of the private key. If a child CA requests
	issuing a certificate using an algorithm suite that does not match a		issuing a certificate using an algorithm suite that does not match a
	resource class, the PoP validation will fail and the request will not		resource class, the PoP validation will fail and the request will not
	be performed.		be performed.
	6. Validation of multiple instance of signed products		6. Validation of multiple instance of signed products
	During Phases 1,2,3 and 4, two algorithm suites will be valid		During Phases 1,2,3 and 4, two algorithm suites will be valid
	simultaneously in RPKI. In this section, we describe the RP behavior		simultaneously in RPKI. In this section, we describe the RP behavior
	when validating instances of the same signed product but signed with		when validating corresponding instances of the same signed product
	different algorithm suites. As a general rule, the validation of		signed with different algorithm suites.
	signed products using different algorithm suites are independent and
	the RP MUST NOT keep any relationship between the different
	hierarchies.
	During Phase 1 two (corresponding) instances MAY be available for		During Phase 1 two (corresponding) instances MAY be available for
	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. When an RP validates these signed products, if		Algorithm Suite B. As noted in Section 4.4, in this phase there is a
	either instance of an object validates, the product is accepted. A		preference for Suite A product sets. All products are available
	failure to validate one instance of a product, under either algorithm		under Suite A, while only some products may be available under Suite
	Suite MUST NOT cause the RP to reject the other instance of the		B. For production purposes an RP MAY fetch and validate only Suite A
	product. Because both instances of such products MUST contain the		products. Suite B products SHOULD be fetched and validated only for
	same resources, relying on either instance will yield the same		test purposes. When product sets exist under both Suites, they
	outcome.		should yield equivalent results, which facilitates testing. (It is
			not possible to directly compare Suite A and Suite B product sets, as
			certs, CRLs, and manifests will appear syntactically different.
			However, the output of the process, i.e., the ROA payloads (ASN and
			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 in Phase 1, when		of all signed products MUST be available to RPs. As noted in Section
	an RP validates these signed products, if either instance validates,		4.5, it is RECOMMENDED that Suite B capable RPs fetch and validate
	the product is accepted. A failure to validate one instance of a		Suite B products sets, during Phase 2. If an RP encounters
	product, under either algorithm Suite MUST NOT cause the RP to reject		validation problems with the Suite B products, it SHOULD revert to
	the other instance of the product. Also, as above, if only one		using Suite A products. RPs that are Suite B capable MAY fetch both
	instance of a signed product can be validated, subordinate products		product sets and compare the results (e.g., ROA outputs) for testing.
	issued under the other (non-validated) algorithm suite cannot be
	used, and thus SHOULD NOT be processed (or even retrieved).
	During Phase 4 two (corresponding) files for an object MAY be		In Phase 3 all RPs MUST be Suite B capable, and MUST fetch Suite B
	available for each signed product, one signed under Algorithm Suite A		product sets. If an RP encounters problems with Suite B product
	and one under Algorithm Suite C. When an RP validates these signed		sets, it can revert to Suite A products. RPs encountering such
	products, if either instance of an object validates, the product is		problems SHOULD contact the relevant repository maintainers (e.g.,
	accepted. A failure to validate one instance of a product, under		using the mechanism defined in [RFC6493] to report problems.)
	either algorithm Suite MUST NOT cause the RP to reject the other
	instance of the product. Because both instances of such products
	MUST contain the same resources, relying on either instance will
	yield the same outcome.
	7. Revocations		During Phase 4 only Suite A (previously Suite B) product sets are
			required to be present for all RPKI entities, as per Section 4.7.
			Thus RPs SHOULD retrieve and validate only these product sets.
			Retrieval of Suite C (old Suite A) products sets may yield an
			incomplete set of signed products and is NOT RECOMMENDED.
	As the algorithm migration process mandates the maintenance of two		7. Revocation
	parallel certificate hierarchies, revocations requests for each
	algorithm suite MUST be handled independently. A Child CA MUST
	request revocation of a certificate relative to a specific algorithm
	suite.
	During phase 2 and phase 3, the two parallel certificate hierarchies		The algorithm migration process mandates the maintenance of two
	are designed to carry identical information. When not performing a		parallel but equivalent certification hierarchies during Phases 2 and
	key rollover operation (which process is described in Section 8), a		3 of the process. During these phases, a CA MUST revoke certificates
	child CA requesting the revocation of a certificate during these two		consistently under both algorithm Suites. When not performing a key
	phases MUST perform that request for both algorithm suites (A and B).		rollover operation (as described in Section 8), a CA requesting the
	A non-leaf CA is NOT required to verify that its child CAs comply		revocation of its certificate during these two phases MUST perform
	with this requirement.		that request for both algorithm suites (A and 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 certificate relative to
			a specific algorithm suite using the mechanism described in Section 5
			During Phase 1, a CA that revokes a certificate under Suite A SHOULD
			revoke the corresponding certificate under Suite B, if that
			certificate exists. During Phase 4, a CA that revokes a certificate
			under Suite A SHOULD revoke the corresponding certificate under Suite
			C, if that certificate exists.
			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
			purposes. During Phase 4 a CA may revoke certificates issued under
			Suite C without revoking them under Suite A, since Suite C products
			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
	[I-D.ietf-sidr-keyroll].		[RFC6489].
	9. Repository structure		9. Repository structure
	The two parallel hierarchies that will exist during the transition		The two parallel hierarchies that will exist during the transition
	process SHOULD have independent publications points. The repository		process SHOULD have independent publications points. The repository
	structures for each algorithm suite are described in		structures for each algorithm suite are described in [RFC6481].
	[I-D.ietf-sidr-repos-struct].
	10. IANA Considerations		10. Deprecating an Algorithm Suite
			To deprecate an algorithm suite, the following process MUST be
			executed by every CA in the RPKI:
			1. Each CA MUST cease issuing certificates under the suite. This
			means that any request for a (CA) certificate from a child will
			be rejected, e.g., sending an error_response message with error
			code:"request - no such resource class" as defined in [RFC6492].
			2. Each CA MUST cease generating signed products, except the CRL and
			Manifest, under the deprecated Algorithm Suite.
			3. Each CA MUST revoke the EE certificates for all signed products
			that it has issued under the deprecated Algorithm Suite. The CA
			SHOULD delete these products from its publication point, to avoid
			burdening RPs with downloading and processing these products.
			4. Each CA MUST revoke all CA certificates that it has issued under
			the deprecated Algorithm Suite.
			5. Each CA SHOULD remove all CA certificates that it has issued
			under the deprecated Algorithm Suite.
			6. Each CA that publishes a TAL under the deprecated Algorithm Suite
			MUST removed it from the TAL's publication point.
			7. Each CA SHOULD continue to maintain the publication point for the
			deprecated Algorithm Suite, maintained at least until the CRL
			nextUpdate. This publication point MUST contain only he CRL and
			a Manifest for that publication point. This behavior provides a
			window in which RPs may be able to become aware of the revoked
			status of the signed products that have been deleted.
			8. Each RP MUST remove any TALs that is has published under the
			deprecated Algorithm Suite.
			CAs in the RPKI hierarchy may become aware of the deprecation of the
			algorithm suite at different times, and may execute the procedure
			above in an asynchronous fashion relative to one another. Thus, for
			example, a CA may request revocation of its CA certificate only to
			learn that the certificate has already been revoked by the issuing
			CA. The revocation of a CA certificate makes the CRL and manifest
			issued under it incapable of validation. The asynchronous execution
			of this procedure likely will result in transient "inconsistencies"
			among the publication points associated with the deprecated algorithm
			suite. However, these inconsistencies should yield "fail safe"
			results, i.e., the objects signed under the deprecated suite should
			be rejected by RPs.
			11. IANA Considerations
	No IANA requirements		No IANA requirements
	11. Security Considerations		12. Security Considerations
	An algorithm transition in RPKI should be a very infrequent event and		An algorithm transition in RPKI should be a very infrequent event and
	it requires wide community consensus. The events that may lead to an		it requires wide community consensus. The events that may lead to an
	algorithm transition may be related to a weakness of the		algorithm transition may be related to a weakness of the
	cryptographic strength of the algorithm suite in use by RPKI, which		cryptographic strength of the algorithm suite in use by RPKI, which
	is normal to happen over time. The procedure described in this		is normal to happen over time. The procedure described in this
	document will take years to complete an algorithm transition. During		document will take years to complete an algorithm transition. During
	that time, the RPKI system will be vulnerable to any cryptographic		that time, the RPKI system will be vulnerable to any cryptographic
	weakness that may have triggered this procedure (i.e. downgrade		weakness that may have triggered this procedure (i.e. downgrade
	attack).		attack).
	skipping to change at page 23, line 5 ¶		skipping to change at page 25, line 5 ¶
	described in this document (after the EOL of the "old" algorithm		described in this document (after the EOL of the "old" algorithm
	suite), its signed product set will no longer be valid.		suite), its signed product set will no longer be valid.
	Consequently, the RPKI may, at the end of Phase 4, have a smaller		Consequently, the RPKI may, at the end of Phase 4, have a smaller
	number of valid signed products than before starting the process.		number of valid signed products than before starting the process.
	Conversely, a RP that does not follow this process will lose the		Conversely, a RP that does not follow this process will lose the
	ability to validate signed products issued under the new algorithm		ability to validate signed products issued under the new algorithm
	suite. The resulting incomplete view of routing info from the RPKI		suite. The resulting incomplete view of routing info from the RPKI
	(as a result of a failure by CAs or RPs to complete the transition)		(as a result of a failure by CAs or RPs to complete the transition)
	could degrade routing in the public Internet.		could degrade routing in the public Internet.
	12. Acknowledgements		13. Acknowledgements
	The authors would like to acknowledge the work of the SIDR working		The authors would like to acknowledge the work of the SIDR working
	group co-chairs (Sandra Murphy and Chris Morrow) as well as the		group co-chairs (Sandra Murphy and Chris Morrow) as well as the
	contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry		contributions given by Geoff Huston, Arturo Servin, Brian Weis, Terry
	Manderson, Brian Dickson and Danny McPherson.		Manderson, Brian Dickson and Danny McPherson.
	13. References		14. Normative References
	13.1. Normative References
	[I-D.ietf-sidr-cp]
	Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
	Policy (CP) for the Resource PKI (RPKI",
	draft-ietf-sidr-cp-17 (work in progress), April 2011.
	[I-D.ietf-sidr-keyroll]
	Huston, G., Michaelson, G., and S. Kent, "CA Key Rollover
	in the RPKI", draft-ietf-sidr-keyroll-05 (work in
	progress), December 2010.
	[I-D.ietf-sidr-repos-struct]
	Huston, G., Loomans, R., and G. Michaelson, "A Profile for
	Resource Certificate Repository Structure",
	draft-ietf-sidr-repos-struct-06 (work in progress),
	November 2010.
	[I-D.ietf-sidr-res-certs]
	Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates",
	draft-ietf-sidr-res-certs-21 (work in progress),
	December 2010.
	[I-D.ietf-sidr-rescerts-provisioning]
	Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
	Protocol for Provisioning Resource Certificates",
	draft-ietf-sidr-rescerts-provisioning-10 (work in
	progress), June 2011.
	[I-D.ietf-sidr-rpki-algs]
	Huston, G., "A Profile for Algorithms and Key Sizes for
	use in the Resource Public Key Infrastructure",
	draft-ietf-sidr-rpki-algs-04 (work in progress),
	November 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
	Adams, "X.509 Internet Public Key Infrastructure Online
	Certificate Status Protocol - OCSP", RFC 2560, June 1999.
	[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
	Internet: Timestamps", RFC 3339, July 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.
	[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
	Addresses", RFC 4193, October 2005.
	[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.
	13.2. Informative References		[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
			Resource Certificate Repository Structure", RFC 6481,
			February 2012.
	[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI		[RFC6484] Kent, S., Kong, D., Seo, K., and R. Watro, "Certificate
	Scheme", RFC 5781, February 2010.		Policy (CP) for the Resource Public Key Infrastructure
			(RPKI)", BCP 173, RFC 6484, February 2012.
			[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
			Use in the Resource Public Key Infrastructure (RPKI)",
			RFC 6485, February 2012.
			[RFC6489] Huston, G., Michaelson, G., and S. Kent, "Certification
			Authority (CA) Key Rollover in the Resource Public Key
			Infrastructure (RPKI)", BCP 174, RFC 6489, February 2012.
			[RFC6490] "".
			[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
			Protocol for Provisioning Resource Certificates",
			RFC 6492, 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 05 to 06:
			1. Added reference to published RFCs
			2. Removed requirement on dates format
			3. Changed revocation section to emphasize the differences between
			phase 1,2,3 and 4.
			4. Added Section 10: Deprecating an Algorithm Suite
			5. Typos and editoral changes
	From 04 to 05:		From 04 to 05:
	1. WGLC nits		1. WGLC nits
	From 03 to 04:		From 03 to 04:
	1. Added text for "roll-over" capability in each phase		1. Added text for "roll-over" capability in each phase
	2. Added the requirement for splitting the milestone 1 in two		2. Added the requirement for splitting the milestone 1 in two
	documents: the update of the alg document and a new document		documents: the update of the alg document and a new document
	skipping to change at page 26, line 34 ¶		skipping to change at page 27, line 47 ¶
	From 02 to 03:		From 02 to 03:
	1. Explicitely named than "mixed" certificates are not allowed for		1. Explicitely named than "mixed" certificates are not allowed for
	CA certs but may be possible for EE certs that are not used to		CA certs but may be possible for EE certs that are not used to
	validate repository objects.		validate repository objects.
	From 01 to 02:		From 01 to 02:
	1. Add reference to Multi-Objects validation		1. Add reference to Multi-Objects validation
	2. EOL Data is the only milestone that RP and CA take actions "at		2. EOL Date is the only milestone that RP and CA take actions "at
	the same time".		the same time".
	3. Updated references		3. Updated references
	4. Editorial		4. Editorial
	From 00 to 01:		From 00 to 01:
	1. Include text to clarify former Suites		1. Include text to clarify former Suites
	2. Include text that documents that an RP that validates an object		2. Include text that documents that an RP that validates an object
	signed with either suites in Phase 2 MUST consider it as valid		signed with either suites in Phase 2 MUST consider it as valid
	From individual submission to WG item:		From individual submission to WG item:
End of changes. 78 change blocks.
	288 lines changed or deleted		330 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/