< draft-ietf-sidr-rpki-algs-01.txt		draft-ietf-sidr-rpki-algs-02.txt >
	SIDR G. Huston		SIDR G. Huston
	Internet-Draft APNIC		Internet-Draft APNIC
	Intended status: Informational May 16, 2010		Intended status: Standards Track October 8, 2010
	Expires: November 17, 2010		Expires: April 11, 2011
	A Profile for Algorithms and Key Sizes for use in the Resource Public		A Profile for Algorithms and Key Sizes for use in the Resource Public
	Key Infrastructure		Key Infrastructure
	draft-ietf-sidr-rpki-algs-01.txt		draft-ietf-sidr-rpki-algs-02.txt
	Abstract		Abstract
	This document defines a profile for the algorithm and key size to be		This document defines a profile for the algorithm and key size to be
	used for signatures applied to certificates, Certificate Revocation		used for signatures applied to certificates, Certificate Revocation
	Lists, and signed objects in the context of the Resource Public Key		Lists, and signed objects in the context of the Resource Public Key
	Infrastructure.		Infrastructure.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 November 17, 2010.		This Internet-Draft will expire on April 11, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 19 ¶		skipping to change at page 2, line 19 ¶
	Lists (CRLs), and signed objects in the context of the Resource		Lists (CRLs), and signed objects in the context of the Resource
	Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch].		Public Key Infrastructure (RPKI) [I-D.ietf-sidr-arch].
	This section of the profile is specified in a distinct profile		This section of the profile is specified in a distinct profile
	document, referenced by the RPKI Certificate Policy (CP)		document, referenced by the RPKI Certificate Policy (CP)
	[I-D.ietf-sidr-cp] and the RPKI Certificate Profile		[I-D.ietf-sidr-cp] and the RPKI Certificate Profile
	[I-D.ietf-sidr-res-certs], in order to allow for a degree of		[I-D.ietf-sidr-res-certs], in order to allow for a degree of
	algorithm and key agility in the RPKI, while permitting some longer		algorithm and key agility in the RPKI, while permitting some longer
	term stability in the CP and Certificate Profile specifications.		term stability in the CP and Certificate Profile specifications.
			1.1. Terminology
	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 RFC 2119.		document are to be interpreted as described in RFC 2119.
	2. Algorithm and Key Size		2. Algorithm and Key Size
	This profile specifies the use of RSASSA-PKCS1-v1_5 [RFC3447] with		This profile specifies the use of RSASSA-PKCS1-v1_5 [RFC3447] with
	the SHA-256 hash algorithm to compute the signature of certificates,		the SHA-256 hash algorithm to compute the signature of certificates,
	CRLs, and signed objects in the context of the RPKI. Accordingly,		CRLs, and signed objects in the context of the RPKI. Accordingly,
	the OID value in the RPKI for such signatures MUST be		the OID value in the RPKI for such signatures MUST be
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 50 ¶
	3. Future Upates		3. Future Upates
	It is anticipated that the RPKI will require the adoption of updated		It is anticipated that the RPKI will require the adoption of updated
	key sizes and a different set of signature and hash algorithms over		key sizes and a different set of signature and hash algorithms over
	time, in order to maintain an acceptable level of cryptographic		time, in order to maintain an acceptable level of cryptographic
	security to protect the integrity of signed products in the RPKI.		security to protect the integrity of signed products in the RPKI.
	This profile should be updated to specify such future requirements,		This profile should be updated to specify such future requirements,
	as and when appropriate.		as and when appropriate.
	CAs and RPs should be capable of supporting a transition to allow for		CAs and RPs SHOULD be capable of supporting a transition to allow for
	the phased introduction of additional encryption algorithms and key		the phased introduction of additional encryption algorithms and key
	specifications, and also accomodate the orderly deprecation of		specifications, and also accomodate the orderly deprecation of
	previously specified algorithms and keys. Accordingly, CAs and RPs		previously specified algorithms and keys. Accordingly, CAs and RPs
	SHOULD be capable of supporting multiple RPKI algorithm and key		SHOULD be capable of supporting multiple RPKI algorithm and key
	profiles simultaneously within the scope of such anticipated		profiles simultaneously within the scope of such anticipated
	transitions.		transitions. The recommended procedures to implement such a
			transition of key sizes and algorithms is not specified in this
	Note: This document specifies the current algorithm requirements for		document.
	the RPKI. The document acknowledges a requirement for algorithm
	agility, both in terms of larger key sizes in conjunction with the
	current algorithms, and transition to other algorithms. It is noted
	that the SIDR architecture is one where each CA is required to
	generate signed material that may be validated by the entire
	collection of Relying Parties. This architectural requirement
	precludes the use of any negotiation between a CA and a RP as to the
	algorithm to use for signed products in the RPKI. This constraint
	implies that any transition of key size or algorithm will require a
	phased approach with the concurrent support of both old and new
	algorithms until such time as it is deemed that all RPs can support
	the new algorithm. Given that there is no accommodation for multiple
	signature algorithms in the current collection of RPKI
	specifications, either the colelction of RPKI specifications will
	require subsequent revision to support the use of multiple signature
	algorithms within the specifications of signed objects in the RPKI,
	which itself poses a transition issue, or all such form of algorithm
	transition will require the construction and operation of a parallel
	RPKI structure that is entirely distinct from the "current" RPKI
	structure by virtue of its exclusive use of a "new" algorithm for
	signature generation. The latter option, that of the concurrent
	operation of parallel RPKI structures, poses some complex issues in
	terms of synchronisation of actions across the set of RPKI CAs, as
	well as issues of consistency and coherency in the operation of
	multiple parallel RPKI frameworks, as well as the uncertainties
	associated with a global determination of when any such transition
	can be considered "complete". The alternate approach, of allowing
	multiple signature algorithms in the RPKI certificate profile, and in
	the specification of CMS signatures as used in manifests, ROAS, other
	signed objects, and in the provisioning protocol, allows for
	algorithm transition to occur within a single RPKI framework, and
	allows for individual CAs to commence use of multiple algorithms in a
	piecemeal fashion without reliance on the algorithm transition of the
	immediate superior CA and without a forced synchronisation of
	algorithm transition with subordinate CAs. In the light of this
	consideration, this document recommends the comprehensive revision of
	the existing RPKI specification and architecture documents to include
	provision for multiple signatures with multiple algorithms in order
	to support an orderly transition to longer key sizes and to other
	signature algorithms in the RPKI.
	4. Security Considerations		4. Security Considerations
	The Security Considerations of [RFC3779], [RFC5280], and [RFC4055]		The Security Considerations of [RFC3779], [RFC5280], and [RFC4055]
	apply to signatures as defined by this profile, and their use.		apply to signatures as defined by this profile, and their use.
	Algorithm transition poses some particular security issues, relating
	to potential vulnerabilities in the parallel operation of an RPKI
	framework where a potentially compromised algorithm remains in use
	beyond a reasonable time for retirement. These issues should be
	considered in detail in a future version of this document.
	5. IANA Considerations		5. IANA Considerations
	[There are no IANA considerations in this document.]		[There are no IANA considerations in this document.]
	6. Acknowledgments		6. Acknowledgments
	The author acknowledges the re-use in this draft of material		The author acknowledges the re-use in this draft of material
	originally contained in working drafts the RPKI Certificate Policy		originally contained in working drafts the RPKI Certificate Policy
	and Resource Certificate profile documents. The co-authors of these		and Resource Certificate profile documents. The co-authors of these
	two documents, namely Stephen Kent, Derrick Kong, Karen Seo, Ronald		two documents, namely Stephen Kent, Derrick Kong, Karen Seo, Ronald
	Watro, George Michaelson and Robert Loomans, are acknowledged with		Watro, George Michaelson and Robert Loomans, are acknowledged, with
	thanks. The constraint on key size noted in this profile is the		thanks. The constraint on key size noted in this profile is the
	outcome of comments from Stephen Kent and review comments from David		outcome of comments from Stephen Kent and review comments from David
	Cooper.		Cooper.
	7. Normative References		7. Normative References
	[I-D.ietf-sidr-arch]		[I-D.ietf-sidr-arch]
	Lepinski, M. and S. Kent, "An Infrastructure to Support		Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", draft-ietf-sidr-arch (work in		Secure Internet Routing", draft-ietf-sidr-arch (work in
	progress), July 2009.		progress), July 2009.
	skipping to change at page 5, line 24 ¶		skipping to change at page 4, line 28 ¶
	June 2005.		June 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.
	Author's Address		Author's Address
	Geoff Huston		Geoff Huston
	Asia Pacific Network Information Centre		APNIC
	Email: gih@apnic.net		Email: gih@apnic.net
End of changes. 9 change blocks.
	56 lines changed or deleted		12 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/