< draft-turner-encryptedkeypackagecontenttype-algs-01.txt		draft-turner-encryptedkeypackagecontenttype-algs-02.txt >
	Network Working Group Sean Turner, IECA		Network Working Group Sean Turner, IECA
	Internet Draft February 1, 2010		Internet Draft May 7, 2010
	Intended Status: Standard Track		Intended Status: Standard Track
	Expires: August 1, 2010		Expires: November 7, 2010
	Algorithms for Encrypted Key Package Content Type		Algorithms for Cryptographic Message Syntax (CMS)
	draft-turner-encryptedkeypackagecontenttype-algs-01.txt		Encrypted Key Package Content Type
			draft-turner-encryptedkeypackagecontenttype-algs-02.txt
	Abstract		Abstract
	This document describes the conventions for using several		This document describes the conventions for using several
	cryptographic algorithms with the encrypted key package content type.		cryptographic algorithms with the Cryptographic Message Syntax (CMS)
	Specifically, it includes conventions necessary to implement		encrypted key package content type. Specifically, it includes
	EnvelopedData, EncryptedData, and AuthEnvelopedData.		conventions necessary to implement EnvelopedData, EncryptedData, and
			AuthEnvelopedData.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 40 ¶
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt		http://www.ietf.org/ietf/1id-abstracts.txt
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	This Internet-Draft will expire on August 1, 2010.		This Internet-Draft will expire on November 7, 2010.
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	1. Introduction		1. Introduction
	This document describes the conventions for using several		This document describes the conventions for using several
	cryptographic algorithms with the encrypted key package content type		cryptographic algorithms with the Cryptographic Message Syntax (CMS)
	[RFCTBD]. Specifically, it includes conventions necessary to		encrypted key package content type [RFCTBD]. Specifically, it
	implement EnvelopedData [RFC5652], EncryptedData [RFC5652], and		includes conventions necessary to implement the following CMS content
			types: EnvelopedData [RFC5652], EncryptedData [RFC5652], and
	AuthEnvelopedData [RFC5083].		AuthEnvelopedData [RFC5083].
	This document does not define any new algorithms; instead it refers		This document does not define any new algorithms; instead it refers
	to previously defined algorithms.		to previously defined algorithms.
	1.1. Terminology		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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	2. EnvelopedData		2. EnvelopedData
	EnvelopedData supports a number of key management techniques.		EnvelopedData [RFC5652] supports a number of key management
	Implementations that claim conformance to this document MUST support		techniques. Implementations that claim conformance to this document
	the key transport mechanisms and SHOULD support the key agreement		MUST support the key transport mechanisms and SHOULD support the key
	mechanisms. Other techniques MAY be supported.		agreement mechanisms as defined below. Other techniques MAY be
			supported.
	When key transport is used, RSA encryption [RFC3370] MUST be		When key transport is used, RSA encryption [RFC3370] MUST be
	supported and RSA-OAEP [RFC3560] SHOULD be supported.		supported and RSA-OAEP [RFC3560] SHOULD be supported.
	When key agreement is used, Diffie-Hellman ephemeral-static [RFC3370]		When key agreement is used, Diffie-Hellman ephemeral-static [RFC3370]
	SHOULD be supported.		MUST be supported.
	Regardless of the key management technique choice, implementations		Regardless of the key management technique choice, implementations
	MUST support AES-128 Key Wrap with Padding [RFC5649].		MUST support AES-128 Key Wrap with Padding [RFC5649].
	Implementations SHOULD support AES-256 Key Wrap with Padding		Implementations SHOULD support AES-256 Key Wrap with Padding
	[RFC5649].		[RFC5649].
	When key agreement is used, a key wrap algorithm is also specified to		When key agreement is used, a key wrap algorithm is also specified to
	wrap the content encryption key. If the content encryption algorithm		wrap the content encryption key. If the content encryption algorithm
	is AES-128 Key Wrap with Padding, then the key wrap algorithm MUST be		is AES-128 Key Wrap with Padding, then the key wrap algorithm MUST be
	AES-128 Key Wrap with Padding [RFC5649]. If the content encryption		AES-128 Key Wrap with Padding [RFC5649]. If the content encryption
	algorithm is AES-256 Key Wrap with Padding, then the key wrap		algorithm is AES-256 Key Wrap with Padding, then the key wrap
	algorithm MUST be AES-256 Key Wrap with Padding [RFC5649].		algorithm MUST be AES-256 Key Wrap with Padding [RFC5649].
	3. EncryptedData		3. EncryptedData
	EncryptedData requires that keys be managed by means other than		EncryptedData [RFC5652] requires that keys be managed by other means;
	EncryptedData; therefore, the only algorithm specified is the content		therefore, the only algorithm specified is the content encryption
	encryption algorithm. Implementations MUST support AES-128 Key Wrap		algorithm. Implementations MUST support AES-128 Key Wrap with Padding
	with Padding [RFC5649]. Implementations SHOULD support AES-256 Key		[RFC5649]. Implementations SHOULD support AES-256 Key Wrap with
	Wrap with Padding [RFC5649].		Padding [RFC5649].
	4. AuthEnvelopedData		4. AuthEnvelopedData
	AuthEnvelopedData, like EnvelopedData, supports a number of key		AuthEnvelopedData [RFC5083], like EnvelopedData, supports a number of
	management techniques. The key management requirements for		key management techniques. The key management requirements for
	AuthEnvelopedData are the same as EnvelopedData. The difference is		AuthEnvelopedData are the same as for EnvelopedData. The difference
	the content encryption algorithm. Implementations MUST support 128-		is the content encryption algorithm. Implementations MUST support
	bit AES-GCM [RFC5084] and SHOULD support 256-bit AES-GCM [RFC5084].		128-bit AES-GCM [RFC5084] and SHOULD support 256-bit AES-GCM
	Implementations MAY also support for AES-CCM [RFC5084].		[RFC5084]. Implementations MAY also support AES-CCM [RFC5084].
	5. Public Key Sizes		5. Public Key Sizes
	The easiest way to implement the key transport requirement for		The easiest way to implement the key transport requirement for
	EnvelopedData and AuthenticatedData is with public key certificates		EnvelopedData and AuthEnvelopedData is with public key certificates
	[RFC5280]. If an implementation supports RSA, RSASSA-PSS, DSA, RSAES-		[RFC5280]. If an implementation supports RSA, RSAES-OAEP, or DH,
	OAEP, or DH, then it MUST support key lengths from 1024-bit to 2048-		then it MUST support key lengths from 1024-bit to 2048-bit,
	bit, inclusive.		inclusive.
	6. Security Considerations		6. Security Considerations
	The security considerations from [RFC3370], [RFC3394], [RFC3560],		The security considerations from [RFC3370], [RFC3560], [RFC5083],
	[RFC5083], [RFC5084], [RFC5649], [RFC5652], and [RFCTBD] apply.		[RFC5084], [RFC5649], [RFC5652], and [RFCTBD] apply.
	The choice of content encryption algorithms for this document was		The choice of content encryption algorithms for this document was
	based on [RFC5649]: "In the design of some high assurance		based on [RFC5649]: "In the design of some high assurance
	cryptographic modules, it is desirable to segregate cryptographic		cryptographic modules, it is desirable to segregate cryptographic
	keying material from other data. The use of a specific cryptographic		keying material from other data. The use of a specific cryptographic
	mechanism solely for the protection of cryptographic keying material		mechanism solely for the protection of cryptographic keying material
	can assist in this goal." Unfortunately, there is no AES-CCM or AES-		can assist in this goal." Unfortunately, there is no AES-GCM or AES-
	GCM mode that provides the same properties. If an AES-CCM and AES-		CCM mode that provides the same properties. If an AES-GCM and AES-
	GCM mode that provides the same properties is defined, then this		CCM mode that provides the same properties is defined, then this
	document will be updated to adopt that algorithm.		document will be updated to adopt that algorithm.
	[SP800-57] provides comparable bits of security for some algorithms		[SP800-57] provides comparable bits of security for some algorithms
	and key sizes. [SP800-57] also provides time frames during which		and key sizes. [SP800-57] also provides time frames during which
	certain numbers of bits of security are appropriate and some		certain numbers of bits of security are appropriate and some
	environments may find these time frames useful.		environments may find these time frames useful.
	7. IANA Considerations		7. IANA Considerations
	None. Please remove this section prior to publication as an RFC.		None. Please remove this section prior to publication as an RFC.
	skipping to change at page 4, line 19 ¶		skipping to change at page 4, line 24 ¶
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[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.
	[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)		[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
	Algorithms", RFC 3370, August 2002.		Algorithms", RFC 3370, August 2002.
	[RFC3394] Housley, R., and J. Schaad, "Advanced Encryption Standard
	(AES) Key Wrap Algorithm", RFC 3394, September 2002.
	[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport		[RFC3560] Housley, R., "Use of the RSAES-OAEP Key Transport
	Algorithm in the Cryptographic Message Syntax (CMS)", RFC		Algorithm in the Cryptographic Message Syntax (CMS)", RFC
	3560, July 2003.		3560, July 2003.
	[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)		[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
	Authenticated-Enveloped-Data Content Type", RFC 5083,		Authenticated-Enveloped-Data Content Type", RFC 5083,
	November 2007.		November 2007.
	[RFC5084] Housley, R., " Using AES-CCM and AES-GCM Authenticated		[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated
	Encryption in the Cryptographic Message Syntax (CMS)",		Encryption in the Cryptographic Message Syntax (CMS)",
	RFC 5084, November 2007.		RFC 5084, November 2007.
	[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		Infrastructure Certificate and Certificate Revocation
	List (CRL) Profile", RFC 5280, May 2008.		List (CRL) Profile", RFC 5280, May 2008.
	[RFC5649] Housley, R., and M. Dworkin, "Advanced Encryption		[RFC5649] Housley, R., and M. Dworkin, "Advanced Encryption
	Standard (AES) Key Wrap with Padding Algorithm", RFC		Standard (AES) Key Wrap with Padding Algorithm", RFC
	5649, September 2009.		5649, September 2009.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
	5652, September 2009.		5652, September 2009.
	[RFCTBD] Turner, S., and R. Housley, "Encrypted Key Package		[RFCTBD] Turner, S., and R. Housley, "Cryptographic Message Syntax
	Content Type", draft-turner-		(CMS) Encrypted Key Package Content Type", draft-turner-
	encryptedkeypackagecontenttype-01.txt, work-in-progress.		encryptedkeypackagecontenttype-02.txt, work-in-progress.
	/**		/**
	RFC Editor: Please replace "RFCTBD" with "RFC####" where #### is the		RFC Editor: Please replace "TBD" with the number of the published
	number of the published RFC. Please do this in both the references		RFC. Please do this in both the references and the text.
	and the text.
	**/		**/
	8.2. Informative References		8.2. Informative References
	[SP800-57] National Institute of Standards and Technology (NIST),		[SP800-57] National Institute of Standards and Technology (NIST),
	Special Publication 800-57: Recommendation for Key		Special Publication 800-57: Recommendation for Key
	Management - Part 1 (Revised), March 2007.		Management - Part 1 (Revised), March 2007.
	Authors' Addresses		Authors' Addresses
End of changes. 17 change blocks.
	46 lines changed or deleted		46 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/