< draft-turner-ct-keypackage-receipt-n-error-algs-00.txt		draft-turner-ct-keypackage-receipt-n-error-algs-01.txt >
	Network Working Group Sean Turner		Network Working Group Sean Turner
	Internet Draft IECA		Internet Draft IECA
	Intended Status: Standards Track April 18, 2013		Intended Status: Standards Track May 9, 2013
	Expires: October 20, 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-00.txt		draft-turner-ct-keypackage-receipt-n-error-algs-01.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 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	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 Cryptographic Message Syntax (CMS)		cryptographic algorithms with the Cryptographic Message Syntax (CMS)
	key package receipt and error content types [ID.housley-keypackage-		key package receipt and error content types [ID.housley-keypackage-
	receipt-n-error]. Specifically, it includes conventions necessary to		receipt-n-error]. Specifically, it includes conventions necessary to
	implement SignedData [RFC5652], EnvelopedData [RFC5652],		implement SignedData [RFC5652], EnvelopedData [RFC5652],
	EncryptedData [RFC5652], and AuthEnvelopedData [RFC6083].		EncryptedData [RFC5652], and 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. In fact, the algorithm		to previously defined algorithms. In fact, the algorithm
	requirements in this document are the same as those in		requirements in this document are the same as those in [RFC5959],
	[RFC5959][RFC6162], [RFC6033][RFC6161], and [RFC6160] with the		[RFC6033], [RFC6160], [RFC6161], and [RFC6162] with the following
	following exceptions: the content-encryption algorithm is AES in CBC		exceptions: the content-encryption algorithm is AES in CBC mode as
	mode as opposed to AES Key Wrap with MLI and the key-wrap algorithm		opposed to AES Key Wrap with Message Length Indicator (MLI) and the
	is AES Key Wrap as opposed to AES Key Wrap with Message Length		key-wrap algorithm is AES Key Wrap as opposed to AES Key Wrap with
	Indicator (MLI). The rationale for the difference is that the receipt		MLI. The rationale for the difference is that the receipt and error
	and error content types are not keys therefore AES Key Wrap with MLI		content types are not keys therefore AES Key Wrap with MLI is not
	is not appropriate for the content-encryption algorithm and if an		appropriate for the content-encryption algorithm and if an
	implementation isn't using AES Key Wrap with MLI as the content-		implementation is not using AES Key Wrap with MLI as the content-
	encryption algorithm then there's no need to keep the key-wrap		encryption algorithm then there's no need to keep the key-wrap
	algorithm the same as he content encryption algorithm.		algorithm the same as the content encryption algorithm.
	NOTE: [ID.housley-keypackage-receipt-n-error] only requires that the		NOTE: [ID.housley-keypackage-receipt-n-error] only requires that the
	key package receipt be signed.		key package receipt be signed.
	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", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	skipping to change at page 2, line 49 ¶		skipping to change at page 2, line 49 ¶
	2. SignedData		2. SignedData
	If an implementation supports SignedData, then it MUST support the		If an implementation supports SignedData, then it MUST support the
	signature scheme RSA [RFC3370] and SHOULD support the signature		signature scheme RSA [RFC3370] and SHOULD support the signature
	schemes RSA Probabilistic Signature Scheme (RSASSA-PSS) [RFC4056] and		schemes RSA Probabilistic Signature Scheme (RSASSA-PSS) [RFC4056] and
	Digital Signature Algorithm (DSA) [RFC3370]. Additionally,		Digital Signature Algorithm (DSA) [RFC3370]. Additionally,
	implementations MUST support the hash function SHA-256 [RFC5754] in		implementations MUST support the hash function SHA-256 [RFC5754] in
	concert with these signature schemes, and they SHOULD support the		concert with these signature schemes, and they SHOULD support the
	hash function SHA-1 [RFC3370]. If an implementation supports		hash function SHA-1 [RFC3370]. If an implementation supports
	SignedData, then it MAY support Elliptic Curve Digital Signature		SignedData, then it MAY support Elliptic Curve Digital Signature
	Algorithm (ECDSA) [RFC6090][RFC5753].		Algorithm (ECDSA) [RFC5753] and [RFC6090].
	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
	skipping to change at page 3, line 23 ¶		skipping to change at page 3, line 23 ¶
	Curve Diffie-Hellman (ECDH) [RFC6090][RFC5753] MAY be supported.		Curve Diffie-Hellman (ECDH) [RFC6090][RFC5753] 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 with Padding [RFC3394]. If the content-encryption		AES-128 Key Wrap [RFC3394]. If the content-encryption algorithm is
	algorithm is AES-256 in CBC mode, then the key-wrap algorithm MUST be		AES-256 in CBC mode, then the key-wrap algorithm MUST be AES-256 Key
	AES-256 Key Wrap [RFC3394].		Wrap [RFC3394].
	3. EncryptedData		3. 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.
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 17 ¶
	6. IANA Considerations		6. IANA Considerations
	None.		None.
	7. Security Considerations		7. Security Considerations
	The security considerations from [RFC3370], [RFC3394], [RFC3560],		The security considerations from [RFC3370], [RFC3394], [RFC3560],
	[RFC4056], [RFC5083], [RFC5084], [RFC5652], [RFC5753], and [RFC5754]		[RFC4056], [RFC5083], [RFC5084], [RFC5652], [RFC5753], and [RFC5754]
	apply.		apply.
	Unfortunately, there is no AES-GCM or AES-CCM mode that provides the
	same properties. If an AES-GCM and AES-CCM mode that provides the
	same properties is defined, then this 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.
	8. Acknowledgements		8. Acknowledgements
	I'd like to that 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		9. References
	9.1. Normative References		9.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
	skipping to change at page 5, line 40 ¶		skipping to change at page 5, line 34 ¶
	[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram		[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
	Transport Layer Security (DTLS) for Stream Control		Transport Layer Security (DTLS) for Stream Control
	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, April		Types", draft-housley-ct-keypackage-receipt-n-error, May
	2013.		2013.
	9.2. Informative References		9.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.
End of changes. 10 change blocks.
	25 lines changed or deleted		20 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/