< draft-turner-ct-keypackage-receipt-n-error-algs-01.txt		draft-turner-ct-keypackage-receipt-n-error-algs-02.txt >
	Network Working Group Sean Turner		Network Working Group Sean Turner
	Internet Draft IECA		Internet Draft IECA
	Intended Status: Standards Track May 9, 2013		Intended Status: Standards Track May 9, 2013
	Expires: November 10, 2013		Expires: November 10, 2013
	Algorithms for Cryptographic Message Syntax (CMS)		Algorithms for Cryptographic Message Syntax (CMS)
	Key Package Receipt and Error Content Types		Key Package Receipt and Error Content Types
	draft-turner-ct-keypackage-receipt-n-error-algs-01.txt		draft-turner-ct-keypackage-receipt-n-error-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 Cryptographic Message Syntax (CMS)		cryptographic algorithms with the Cryptographic Message Syntax (CMS)
	key package receipt and error content types. Specifically, it		key package receipt and error content types. Specifically, it
	includes conventions necessary to implement SignedData,		includes conventions necessary to implement SignedData,
	EnvelopedData, EncryptedData, and AuthEnvelopedData.		EnvelopedData, EncryptedData, and AuthEnvelopedData.
	Status of this Memo		Status of this Memo
	skipping to change at page 3, line 13 ¶		skipping to change at page 3, line 13 ¶
	3. EnvelopedData		3. EnvelopedData
	If an implementation supports EnvelopedData, then it MUST implement		If an implementation supports EnvelopedData, then it MUST implement
	key transport, and it MAY implement key agreement.		key transport, and it MAY implement key agreement.
	When key transport is used, RSA encryption [RFC3370] MUST be		When key transport is used, RSA encryption [RFC3370] MUST be
	supported, and RSA Encryption Scheme - Optimal Asymmetric Encryption		supported, and RSA Encryption Scheme - Optimal Asymmetric Encryption
	Padding (RSAES-OAEP) [RFC3560] SHOULD be supported.		Padding (RSAES-OAEP) [RFC3560] SHOULD be supported.
	When key agreement is used, Diffie-Hellman (DH) ephemeral-static		When key agreement is used, Diffie-Hellman (DH) ephemeral-static
	[RFC3370] MUST be supported. When key agreement is used, Elliptic		[RFC3370] MUST be supported. When key agreement is used, Elliptic
	Curve Diffie-Hellman (ECDH) [RFC6090][RFC5753] MAY be supported.		Curve Diffie-Hellman (ECDH) [RFC5753][RFC6090] MAY be supported.
	Regardless of the key management technique choice, implementations		Regardless of the key management technique choice, implementations
	MUST support AES-128 in CBC mode [AES] as the content-encryption		MUST support AES-128 in CBC mode [AES] as the content-encryption
	algorithm. Implementations SHOULD support AES-256 in CBC mode [AES]		algorithm. Implementations SHOULD support AES-256 in CBC mode [AES]
	as the content-encryption algorithm.		as the content-encryption algorithm.
	When key agreement is used, the same key-wrap algorithm MUST be used		When key agreement is used, the same key-wrap algorithm MUST be used
	for both key and content encryption. If the content-encryption		for both key and content encryption. If the content-encryption
	algorithm is AES-128 in CBC mode, then the key-wrap algorithm MUST be		algorithm is AES-128 in CBC mode, then the key-wrap algorithm MUST be
	AES-128 Key Wrap [RFC3394]. If the content-encryption algorithm is		AES-128 Key Wrap [RFC3394]. If the content-encryption algorithm is
	AES-256 in CBC mode, then the key-wrap algorithm MUST be AES-256 Key		AES-256 in CBC mode, then the key-wrap algorithm MUST be AES-256 Key
	Wrap [RFC3394].		Wrap [RFC3394].
	3. EncryptedData		4. EncryptedData
	If an implementation supports EncryptedData, then it MUST implement		If an implementation supports EncryptedData, then it MUST implement
	AES-128 in CBC mode [AES] and SHOULD implement AES-256 in CBC mode		AES-128 in CBC mode [AES] and SHOULD implement AES-256 in CBC mode
	[AES].		[AES].
	NOTE: EncryptedData requires that keys be managed by other means;		NOTE: EncryptedData requires that keys be managed by other means;
	therefore, the only algorithm specified is the content-encryption		therefore, the only algorithm specified is the content-encryption
	algorithm.		algorithm.
	4. AuthEnvelopedData		5. AuthEnvelopedData
	If an implementation supports AuthEnvelopedData, then it MUST		If an implementation supports AuthEnvelopedData, then it MUST
	implement the EnvelopedData recommendations except for the content-		implement the EnvelopedData recommendations except for the content-
	encryption algorithm, which, in this case, MUST be AES-GCM [RFC5084];		encryption algorithm, which, in this case, MUST be AES-GCM [RFC5084];
	the 128-bit version MUST be implemented, and the 256-bit version		the 128-bit version MUST be implemented, and the 256-bit version
	SHOULD be implemented. Implementations MAY also support AES-CCM		SHOULD be implemented. Implementations MAY also support AES-CCM
	[RFC5084].		[RFC5084].
	5. Public Key Sizes		6. Public Key Sizes
	The easiest way to implement SignedData, EnvelopedData, and		The easiest way to implement SignedData, EnvelopedData, and
	AuthEnvelopedData is with public key certificates [RFC5280]. If an		AuthEnvelopedData is with public key certificates [RFC5280]. If an
	implementation supports RSA, RSASSA-PSS, DSA, RSAES-OAEP, or Diffie-		implementation supports RSA, RSASSA-PSS, DSA, RSAES-OAEP, or Diffie-
	Hellman, then it MUST support key lengths from 1024-bit to 2048-bit,		Hellman, then it MUST support key lengths from 1024-bit to 2048-bit,
	inclusive. If an implementation supports ECDSA or ECDH, then it MUST		inclusive. If an implementation supports ECDSA or ECDH, then it MUST
	support keys on P-256 [RFC6090].		support keys on P-256 [RFC6090].
	6. IANA Considerations		7. IANA Considerations
	None.		None.
	7. Security Considerations		8. Security Considerations
	The security considerations from [RFC3370], [RFC3394], [RFC3560],		The security considerations from [RFC3370], [RFC3394], [RFC3560],
	[RFC4056], [RFC5083], [RFC5084], [RFC5652], [RFC5753], and [RFC5754]		[RFC4056], [RFC5084], [RFC5652], [RFC5753], and [RFC5754] apply.
	apply.
	[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.
	8. Acknowledgements		9. Acknowledgements
	I'd like to thank Russ Housley for his early feedback on this		I'd like to thank Russ Housley for his early feedback on this
	document.		document.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[AES] National Institute of Standards and Technology, FIPS Pub		[AES] National Institute of Standards and Technology, FIPS Pub
	197: Advanced Encryption Standard (AES), 26 November 2001.		197: Advanced Encryption Standard (AES), 26 November 2001.
	[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.
	skipping to change at page 5, line 37 ¶		skipping to change at page 5, line 36 ¶
	Transmission Protocol (SCTP)", RFC 6083, January 2011.		Transmission Protocol (SCTP)", RFC 6083, January 2011.
	[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic		[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
	Curve Cryptography Algorithms", RFC 6090, February 2011.		Curve Cryptography Algorithms", RFC 6090, February 2011.
	[ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic		[ID.housley-keypackage-receipt-n-error] Housley, R., "Cryptographic
	Message Syntax (CMS) Key Package Receipt and Error Content		Message Syntax (CMS) Key Package Receipt and Error Content
	Types", draft-housley-ct-keypackage-receipt-n-error, May		Types", draft-housley-ct-keypackage-receipt-n-error, May
	2013.		2013.
	9.2. Informative References		10.2. Informative References
	[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content		[RFC5959] Turner, S., "Algorithms for Asymmetric Key Package Content
	Type", RFC 5959, August 2010.		Type", RFC 5959, August 2010.
	[RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax		[RFC6033] Turner, S., "Algorithms for Cryptographic Message Syntax
	(CMS) Encrypted Key Package Content Type", RFC 6033,		(CMS) Encrypted Key Package Content Type", RFC 6033,
	December 2010.		December 2010.
	[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax		[RFC6160] Turner, S., "Algorithms for Cryptographic Message Syntax
	(CMS) Protection of Symmetric Key Package Content Types",		(CMS) Protection of Symmetric Key Package Content Types",
End of changes. 12 change blocks.
	13 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/