< draft-turner-encryptedkeypackagecontenttype-01.txt		draft-turner-encryptedkeypackagecontenttype-02.txt >
	Network Working Group S. Turner, IECA		Network Working Group S. Turner, IECA
	Internet Draft R. Housley, Vigil Security		Internet Draft R. Housley, Vigil Security
	Intended Status: Standard Track February 1, 2010		Intended Status: Standards Track May 7, 2010
	Expires: August 1, 2010		Expires: November 7, 2010
			Cryptographic Message Syntax (CMS)
	Encrypted Key Package Content Type		Encrypted Key Package Content Type
	draft-turner-encryptedkeypackagecontenttype-01.txt		draft-turner-encryptedkeypackagecontenttype-02.txt
	Abstract		Abstract
	This document defines the encrypted key package content type, which		This document defines the Cryptographic Message Syntax (CMS)
	can be used to encrypt a content that includes a key package, such as		encrypted key package content type, which can be used to encrypt a
	a symmetric key package or an asymmetric key package. It is		content that includes a key package, such as a symmetric key package
	transport independent. The Cryptographic Message Syntax (CMS) can be		or an asymmetric key package. It is transport independent. CMS can
	used to digitally sign, digest, authenticate, or further encrypt this		be used to digitally sign, digest, authenticate, or further encrypt
	content type. It is designed to be used with the CMS Content		this content type. It is designed to be used with the CMS Content
	Constraints extension, which does not constrain the EncryptedData,		Constraints (CCC) extension, which does not constrain the
	EnvelopedData, and AuthEnvelopedData.		EncryptedData, EnvelopedData, 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 42 ¶		skipping to change at page 1, line 43 ¶
	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
	The Cryptographic Message Syntax (CMS) specification [RFC5652]		The Cryptographic Message Syntax (CMS) specification [RFC5652]
	defines means to digitally sign, digest, authenticate or encrypt		defines mechanisms to digitally sign, digest, authenticate or encrypt
	arbitrary message content. Many specifications define content types		arbitrary message content. Many specifications define content types
	intended for use with CMS. [RFCTBD1] and [RFCTBD2] define symmetric		intended for use with CMS. [RFCTBD1] and [RFCTBD2] define symmetric
	key package and asymmetric key package content types that can be		key package and asymmetric key package content types that can be
	signed or encrypted using CMS. CMS allows composition of complex		signed or encrypted using CMS. CMS allows composition of complex
	messages with an arbitrary number of layers. CMS has been augmented		messages with an arbitrary number of layers. CMS has been augmented
	by several specifications ([RFC3274], [RFC4073] and [RFC5083]) that		by several specifications ([RFC3274], [RFC4073] and [RFC5083]) that
	define additional mechanisms to enable creation of messages of		define additional mechanisms to enable creation of messages of
	arbitrary depth and breadth using a variety of authentication,		arbitrary depth and breadth using a variety of authentication,
	encryption and compression techniques.		encryption and compression techniques.
	The CMS Content Constraints (CCC) certificate extension [CCC] defines		The CMS Content Constraints (CCC) certificate extension [CCC] defines
	an authorization mechanism that allows recipients to determine		an authorization mechanism that allows recipients to determine
	skipping to change at page 3, line 43 ¶		skipping to change at page 3, line 43 ¶
	o Verify the signature on the outer SignedData layer per [RFC5652].		o Verify the signature on the outer SignedData layer per [RFC5652].
	o Build and validate a certification path of the outer signer and		o Build and validate a certification path of the outer signer and
	confirm the outer signer is authorized to produce the encrypted		confirm the outer signer is authorized to produce the encrypted
	key package per [RFC5280] and [CCC].		key package per [RFC5280] and [CCC].
	o Decrypt the encrypted key package		o Decrypt the encrypted key package
	o Verify the signature on the inner SignedData layer per [RFC5652].		o Verify the signature on the inner SignedData layer per [RFC5652].
	o Build and validate a certification path to the signer the		o Build and validate a certification path to the signer of the
	inner SignedData and confirm the inner signer is authorized to		inner SignedData and confirm the inner signer is authorized to
	produce the symmetric key package per [RFC5280] and [CCC].		produce the symmetric key package per [RFC5280] and [CCC].
	As specified in [CCC], the validator may use the attributes and		As specified in [CCC], the validator may use the attributes and
	public keys returned from the second step as inputs for this CMS		public keys returned from the second step as inputs for this CMS
	content constraints processing.		content constraints processing.
	o Use the symmetric key material.		o Use the symmetric key material.
	+--------------------------------------+		+--------------------------------------+
	| ContentInfo |		| ContentInfo |
	skipping to change at page 4, line 32 ¶		skipping to change at page 4, line 32 ¶
	| | +------------------------------+ | |		| | +------------------------------+ | |
	| +----------------------------------+ |		| +----------------------------------+ |
	+--------------------------------------+		+--------------------------------------+
	In the example, authorization of the SymmetricKeyPackage originator		In the example, authorization of the SymmetricKeyPackage originator
	need not require an intermediate SignedData layer. For example, if		need not require an intermediate SignedData layer. For example, if
	the AuthEnvelopedData option within an EncryptedKeyPackage were used,		the AuthEnvelopedData option within an EncryptedKeyPackage were used,
	the second authorization check would be performed beginning with the		the second authorization check would be performed beginning with the
	authEnveloped field.		authEnveloped field.
	This document also defines an unprotected attribute for use with one		This document also defines an unprotected attribute, Content
	of the key management options supported by the encrypted key package		Decryption Key Identifier, for use with EncryptedData.
	content type.
	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].
	1.2. ASN.1 Syntax Notation		1.2. ASN.1 Syntax Notation
	The key package is defined using the ASN.1 [X.680].		The key package is defined using the ASN.1 [X.680], [X.681], [X.682],
			and [X.683].
	2. Encrypted Key Package		2. Encrypted Key Package
	The encrypted key package content type is used to encrypt a content		The encrypted key package content type is used to encrypt a content
	that includes a key package. This content type is usually used to		that includes a key package. This content type is usually used to
	provide encryption of a key package or a signed key package. This		provide encryption of a key package or a signed key package. This
	content type makes use of the CMS EncryptedData content type		content type makes use of the CMS EncryptedData content type
	[RFC5652], the CMS EnvelopedData content type [RFC5652], or the CMS		[RFC5652], the CMS EnvelopedData content type [RFC5652], or the CMS
	AuthEnvelopedData content type [RFC5083] depending on the fields that		AuthEnvelopedData content type [RFC5083] depending on the fields that
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 31 ¶
	Due to multiple layers of encryption, the content-decryption-key-		Due to multiple layers of encryption, the content-decryption-key-
	identifier attribute can appear in more than one location in the		identifier attribute can appear in more than one location in the
	overall key package. When there are multiple occurrences of the		overall key package. When there are multiple occurrences of the
	content-decryption-key-identifier attribute, each occurrence is		content-decryption-key-identifier attribute, each occurrence is
	evaluated independently. Each one is used to identify the needed		evaluated independently. Each one is used to identify the needed
	keying material for that layer of encryption.		keying material for that layer of encryption.
	4. Security Considerations		4. Security Considerations
	The security considerations from [RFC3274], [RFC4073], [RFC5083],		Implementers of this protocol are strongly encouraged to consider
	[RFC5652] [RFCTBD1], [RFCTBD2], [RFCTBD3], [RFCTBD4], and [CCC]		generally accepted principles of secure key management when
	apply.		integrating this capability within an overall security architecture.
			The security considerations from [RFC5083], [RFC5652], [RFCTBD1],
			[RFCTBD2], [RFCTBD3], and [RFCTBD4] apply. If the CCC extension is
			used as an authorization mechanism, then the security considerations
			from [CCC] also apply.
	The encrypted key package content type might not provide proof of		The encrypted key package content type might not provide proof of
	origin if the content encryption algorithm does not support		origin if the content encryption algorithm does not support
	authenticated key exchange. To provide proof of origin for this		authenticated key exchange. To provide proof of origin for this
	content, another security protocol needs to be used. This is the		content, another security protocol needs to be used. This is the
	reason that support for encapsulating the SymmetricKeyPackage and		reason that support for encapsulating the SymmetricKeyPackage and
	AsymmetricKeypackage with a SignedData content type from [RFC5652] is		AsymmetricKeypackage with a SignedData content type from [RFC5652] is
	required for the EnvelopedData and EncryptedData choices.		required for the EnvelopedData and EncryptedData choices.
	When this content type is used the CMS SignedData [RFC5652]		When this content type is used the CMS SignedData [RFC5652]
	validation rules MUST be used. The PKCS #7 [RFC2315] validation		validation rules MUST be used. The PKCS #7 [RFC2315] validation
	rules MUST NOT be used.		rules MUST NOT be used.
	5. IANA Considerations		5. IANA Considerations
	None. Please remove this section prior to publication as an RFC.		This document makes use of object identifiers to identify a CMS
			content type, a CMS attribute, and the ASN.1 module; all found in
			Appendix A. All OIDs are registered in an arc delegated by IANA to
			the SMIME Working Group. No further action by IANA is necessary for
			this document or any anticipated updates.
	6. References		6. References
	6.1. Normative References		6.1. Normative References
			[CCC] Wallace, C., and R. Housley, "Cryptographic Message
			Syntax (CMS) Content Constraints X.509 Certificate
			Extension", draft-housley-cms-content-constraints-extn-
			05.txt, work-in-progress.
			/**
			RFC Editor: Please replace [CCC] with [RFCXXXX] where XXXX is the
			number of the published RFC. Please do this in both the references
			and the text.
			**/
	[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.
	[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.
	[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.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
	5652, September 2009.		5652, September 2009.
	[RFCTBD1] Housley, R. and S. Turner, "Symmetric Key package Content		[RFCTBD1] Housley, R. and S. Turner, "Symmetric Key package Content
	Type", draft-ietf-keyprov-symmetrickeyformat-07.txt,		Type", draft-ietf-keyprov-symmetrickeyformat-08.txt,
	work-in-progress.		work-in-progress.
	/**		/**
	RFC Editor: Please replace "RFCTBD1" with "RFC####" where #### is the		RFC Editor: Please replace "TBD1" 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.
	**/		**/
	[RFCTBD2] Turner, S., "Asymmetric Key Packages", draft-turner-		[RFCTBD2] Turner, S., "Asymmetric Key Packages", draft-turner-
	asymmetrickeyformat-03.txt, work-in-progress.		asymmetrickeyformat-05.txt, work-in-progress.
	/**		/**
	RFC Editor: Please replace "RFCTB2" with "RFC####" where #### is the		RFC Editor: Please replace "TB2" 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.
	**/		**/
	[RFCTBD3] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX",		[RFCTBD3] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX",
	draft-ietf-pkix-new-asn1-07.txt, work-in-progress.		draft-ietf-pkix-new-asn1-08.txt, work-in-progress.
	/**		/**
	RFC Editor: Please replace "RFCTBD3" with "RFC####" where #### is the		RFC Editor: Please replace "TBD3" 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.
	**/		**/
	[RFCTBD4] Schaad, J., and P. Hoffman, "New ASN.1 Modules for		[RFCTBD4] Schaad, J., and P. Hoffman, "New ASN.1 Modules for
	SMIME", draft-ietf-smime-new-asn1-07.txt, work-in-		SMIME", draft-ietf-smime-new-asn1-07.txt, work-in-
	progress.		progress.
	/**		/**
	RFC Editor: Please replace "RFCTBD4" with "RFC####" where #### is the		RFC Editor: Please replace "TBD4" 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.
	**/		**/
	[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.		[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
	Information Technology - Abstract Syntax Notation One.		Information Technology - Abstract Syntax Notation One.
	[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.		[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.
	Information Technology - Abstract Syntax Notation One:		Information Technology - Abstract Syntax Notation One:
	Information Object Specification.		Information Object Specification.
	[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.		[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.
	skipping to change at page 9, line 47 ¶		skipping to change at page 10, line 16 ¶
	[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax		[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
	Version 1.5", RFC 2315, March 1998.		Version 1.5", RFC 2315, March 1998.
	[RFC3274] Gutmann, P., "Compressed Data Content Type for		[RFC3274] Gutmann, P., "Compressed Data Content Type for
	Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.		Cryptographic Message Syntax (CMS)", RFC 3274, June 2002.
	[RFC4073] Housley, R., "Protecting Multiple Contents with the		[RFC4073] Housley, R., "Protecting Multiple Contents with the
	Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.		Cryptographic Message Syntax (CMS)", RFC 4073, May 2005.
	[CCC] Wallace, C., and R. Housley, "Cryptographic Message
	Syntax (CMS) Content Constraints X.509 Certificate
	Extension", draft-housley-cms-content-constraints-extn-
	02.txt, work-in-progress.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	This appendix provides the normative ASN.1 [X.680] definitions for		This appendix provides the normative ASN.1 [X.680] definitions for
	the structures described in this specification using ASN.1 as defined		the structures described in this specification using ASN.1 as defined
	in [X.680] through [X.683].		in [X.680] through [X.683].
	EncryptedKeyPackageModuleV1		EncryptedKeyPackageModuleV1
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)		{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
	smime(16) modules(0) id-mod-encryptedKeyPkgV1(51) }		smime(16) modules(0) id-mod-encryptedKeyPkgV1(51) }
	skipping to change at page 10, line 47 ¶		skipping to change at page 11, line 15 ¶
	-- From New PKIX ASN.1 [RFCTBD3]		-- From New PKIX ASN.1 [RFCTBD3]
	ATTRIBUTE		ATTRIBUTE
	FROM PKIX-CommonTypes-2009		FROM PKIX-CommonTypes-2009
	{ iso(1) identified-organization(3) dod(6) internet(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkixCommon-02(57) }		id-mod-pkixCommon-02(57) }
	;		;
	KeyPackageContentTypes CONTENT-TYPE ::= {		ContentSet CONTENT-TYPE ::= {
	ct-encrypted-key-package,		ct-encrypted-key-package,
	... -- Expect additional content types --		... -- Expect additional content types --
	}		}
	ct-encrypted-key-package CONTENT-TYPE ::=		ct-encrypted-key-package CONTENT-TYPE ::=
	{ EncryptedKeyPackage IDENTIFIED BY id-ct-KP-encryptedKeyPkg }		{ EncryptedKeyPackage IDENTIFIED BY id-ct-KP-encryptedKeyPkg }
	id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::=		id-ct-KP-encryptedKeyPkg OBJECT IDENTIFIER ::=
	{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)		{ joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
	dod(2) infosec(1) formats(2) key-package-content-types(78) 2 }		dod(2) infosec(1) formats(2) key-package-content-types(78) 2 }
	EncryptedKeyPackage ::= CHOICE {		EncryptedKeyPackage ::= CHOICE {
	encrypted EncryptedData,		encrypted EncryptedData,
	enveloped [0] EnvelopedData,		enveloped [0] EnvelopedData,
End of changes. 23 change blocks.
	44 lines changed or deleted		57 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/