< draft-turner-asymmetrickeyformat-01.txt		draft-turner-asymmetrickeyformat-02.txt >
	Network Working Group Sean Turner, IECA		Network Working Group Sean Turner, IECA
	Internet Draft 30 October 2008		Internet Draft 20 October 2009
	Intended Status: Standard Track		Intended Status: Standard Track
	Obsoletes: RFC 5208 (once approved)		Updates: RFC 5208 (once approved)
	Expires: 30 April 2009		Expires: 20 April 2010
	Asymmetric Key Packages		Asymmetric Key Packages
	draft-turner-asymmetrickeyformat-01.txt		draft-turner-asymmetrickeyformat-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79. This document may contain material
	have been or will be disclosed, and any of which he or she becomes		from IETF Documents or IETF Contributions published or made publicly
	aware will be disclosed, in accordance with Section 6 of BCP 79.		available before November 10, 2008. The person(s) controlling the
			copyright in some of this material may not have granted the IETF
			Trust the right to allow modifications of such material outside the
			IETF Standards Process. Without obtaining an adequate license from
			the person(s) controlling the copyright in such materials, this
			document may not be modified outside the IETF Standards Process, and
			derivative works of it may not be created outside the IETF Standards
			Process, except to format it for publication as an RFC or to
			translate it into languages other than English.
	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.
	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."
	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 30 April 2009.		This Internet-Draft will expire on 20 April 2010.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2008).		Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	This document defines the syntax for private key information and a		This document defines the syntax for private key information and a
	content type for it. Private-key information includes a private key		content type for it. Private-key information includes a private key
	for some public-key algorithm and a set of attributes. The document		for a specified public-key algorithm and a set of attributes. The
	also describes a syntax for encrypted private keys. The		Cryptographic Message Syntax (CMS), as defined in RFC 3852, can be
	Cryptographic Message Syntax, as defined in RFC 3852, can be used to		used to digitally sign, digest, authenticate, or encrypt the
	digitally sign, digest, authenticate, or encrypt the asymmetric key		asymmetric key format content type. This document updates RFC 5208.
	format content type. This document obsoletes RFC 5208.
	Table of Contents
	1. Introduction...................................................2
	1.1. Requirements Terminology..................................2
	1.2. ASN.1 Syntax Notation.....................................2
	1.3. Changes since RFC 5208....................................2
	2. Asymmetric Key Package Content Type............................3
	3. Encrypted Private Key Info.....................................5
	4. Protecting the AsymmetricKeyPackage............................5
	5. Other Considerations...........................................6
	6. Security Considerations........................................6
	7. IANA Considerations............................................7
	8. References.....................................................7
	8.1. Normative References......................................7
	8.2. Non-Normative References..................................7
	APPENDIX A: ASN.1 Module..........................................9
	1. Introduction		1. Introduction
	This document defines the syntax for private key information and a		This document defines the syntax for private key information and a
	content type for it. Private-key information includes a private key		Cryptographic Message Syntax (CMS) [RFC5652] content type for it.
	for some public-key algorithm and a set of attributes. The document		Private-key information includes a private key for a specified
	also describes a syntax for encrypted private keys. The		public-key algorithm and a set of attributes. The CMS can be used to
	Cryptographic Message Syntax [RFC3852] can be used to digitally sign,		digitally sign, digest, authenticate, or encrypt the asymmetric key
	digest, authenticate, or encrypt the asymmetric key format content		format content type. This document updates PKCS#8 v1.2 [RFC5208]
	type. This document obsoletes PKCS#8 v1.2 [RFC5208].		sections 5 and 7, and it adds two new sections; the first covers
			protecting the Asymmetric Key Content Type, and the second discusses
			compatibility with other private-key formats.
	1.1. Requirements Terminology		1.1. Requirements 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 ASN.1 [X.680], [X.681], [X.682], and		The key package is defined using ASN.1 [X.680], [X.681], [X.682], and
	[X.683].		[X.683].
	1.3. Changes since RFC 5208		1.3. Summary of Updates to RFC 5208
	The following are the changes since [RFC5208]:		The following summarizes the updates to [RFC5208]:
			- Changed the name "PrivateKeyInfo" to "OneAsymmetricKey". This
			reflects the addition of the public key field to allow both parts
			of the asymmetric key to be conveyed separately. Not all
			algorithms will use both fields; however, the publicKey field was
			added for completeness.
	- Defined Asymmetric Key Package CMS content type.		- Defined Asymmetric Key Package CMS content type.
	- Removed IMPLICIT from aKeyAttrs to align text with module.		- Removed redundant IMPLICIT from attributes.
	- Added public key to OneAsymmetricKey and added new version number.		- Added publicKey to OneAsymmetricKey and updated the version number.
	- Added that PKCS#9 attributes MAY be supported.		- Added that PKCS#9 attributes may be supported.
	- Added Other Considerations section.		- Added discussion of compatibility with other private-key formats.
			- Added requirements for encoding rule set.
			- Changed imports from PKCS#5 to [RFCTBD3].
	2. Asymmetric Key Package CMS Content Type		2. Asymmetric Key Package CMS Content Type
			This section updates section 5 of [RFC5208].
	The asymmetric key package CMS content type is used to transfer one		The asymmetric key package CMS content type is used to transfer one
	or more plaintext asymmetric keys from one party to another. An		or more plaintext asymmetric keys from one party to another. An
	asymmetric key package MAY be encapsulated in one or more CMS		asymmetric key package MAY be encapsulated in one or more CMS
	protecting content types (see Section 4). This content type MUST be		protecting content types (see Section 4). Earlier versions of this
	DER encoded [X.690].		specification [RFC5208] did not specify a particular encoding rule
			set, but generators SHOULD use DER [X.690] and receivers SHOULD be
			prepared to handle BER [X.690] and DER [X.690].
	The asymmetric key package content type has the following syntax:		The asymmetric key package content type has the following syntax:
	PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER		PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER
	asymmetric-key-package PKCS7-CONTENT-TYPE ::=		asymmetric-key-package PKCS7-CONTENT-TYPE ::=
	{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }		{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }
	id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::= |		id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
	{ TBD }		{ TBD }
	AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey		AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
	OneAsymmetricKey ::= SEQUENCE {		OneAsymmetricKey ::= SEQUENCE {
	version Version,		version Version,
	privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,		privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
	privateKey PrivateKey, -- DER encoded		privateKey PrivateKey,
	attributes [0] Attributes OPTIONAL,		attributes [0] Attributes OPTIONAL,
	publicKey [1] PublicKey OPTIONAL }		publicKey [1] PublicKey OPTIONAL
			}
	PrivateKeyInfo ::= OneAsymmetricKey -- Used in [P12]		PrivateKeyInfo ::= OneAsymmetricKey
			-- PrivateKeyInfo is used by [P12]. If version is set to 1,
			-- publicKey MUST be absent. When v1, PrivateKeyInfo is the same
			-- as it was in [RFC5208].
	Version ::= INTEGER { v1(0), v2(1) } (v1, v2,...)		Version ::= INTEGER { v1(0), v2(1) } (v1, v2,...)
	PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier		PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
	{ { PrivateKeyAlgorithms } }		{ { PrivateKeyAlgorithms } }
	PrivateKey ::= OCTET STRING		PrivateKey ::= OCTET STRING
	-- Content varies based on type of key. The		-- Content varies based on type of key. The
	-- algorithm identifier dictates the format of		-- algorithm identifier dictates the format of
	-- the key. DSA's is an INTEGER ECDSA's is an		-- the key.
	-- INTEGER, and RSA is as per [RFC3447].
	PublicKey ::= OCTET STRING		PublicKey ::= BIT STRING
	-- Content varies based on type of key. The		-- Content varies based on type of key. The
	-- algorithm identifier dictates the format of		-- algorithm identifier dictates the format of
	-- the key. DSA is an INTEGER, ECDSA is an OCTET		-- the key.
	-- STRING, and RSA is a sequence of two INTEGERs
	-- [PKI-ALG].
	Attributes ::= Set of Attribute		Attributes ::= Set of Attribute
	The AsymmetricKeyPackage contains one or more OneAsymmetricKey		The AsymmetricKeyPackage contains one or more OneAsymmetricKey
	elements. The syntax of OneAsymmetricKey accommodates a version		elements.
	number, an indication of the algorithm to be used with the private
	key, a private key, and optionally keying material attributes (e.g.,
	certificates) and a public key. In general, either the public key or
	the certificate will be present. In very rare cases will both the
	public key and the certificate be present as this includes two copies
	of the public key. The fields in OneAsymmetricKey are used as
	follows:
	- version identifies version of the asymmetric key package content		The syntax of OneAsymmetricKey accommodates a version number, an
	structure. For this version of the specification, version MUST be		indication of the asymmetric algorithm to be used with the private
	v1 if the publicKey field is absent and it MUST be set to v2 if the		key, a private key, optional keying material attributes (e.g.,
	publicKey field is present.		userCertificate from [X.520]), and an optional public key. In
			general, either the public key or the certificate will be present.
			In very rare cases will both the public key and the certificate be
			present as this includes two copies of the public key.
			OneAsymmetricKey is a renamed extension of the PrivateKeyInfo syntax
			defined in [RFC5208]. The new name better reflects the ability to
			carry both private and public key components. Backwards
			compatibility with the original PrivateKeyInfo is preserved via
			version number. The fields in OneAsymmetricKey are used as follows:
	- privateKeyAlgorithm identifies the private key algorithm and		- version identifies the version of OneAsymmetricKey. If publicKey
			is present, then version is set 2 else version is set to 1.
			- privateKeyAlgorithm identifies the private-key algorithm and
	optionally contains parameters associated with the asymmetric key.		optionally contains parameters associated with the asymmetric key.
	The algorithm is identified by an OID and the parameters format		The algorithm is identified by an object identifier (OID) and the
	depends on the OID. The value placed in		format of the parameters depends on the OID. The value placed in
	privateKeyAlgorithmIdentifier is the value an originator would		privateKeyAlgorithmIdentifier is the value an originator would
	apply to indicate which algorithm was used.		apply to indicate which algorithm is to be used with the private
			key.
	- privateKey is an OCTET STRING whose contents is the DER encoded		- privateKey is an OCTET STRING whose contents are the value of the
	private key. The interpretation of the contents is defined in the		private key. The interpretation of the contents is defined in the
	registration of the private-key algorithm.		registration of the private-key algorithm. For example, a DSA key
			is an INTEGER, an RSA key is represented as RSAPrivateKey as
			defined in [RFC3447], and an ECC key is represented as ECPrivateKey
			as defined in [RFCTBD2].
	- attributes is optional. It contains information corresponding to		- attributes is optional. It contains information corresponding to
	the public key (e.g., certificates). The attributes field uses the		the public key (e.g., certificates). The attributes field uses the
	class ATTRIBUTE which is restricted by the SupportedAttributes		class ATTRIBUTE which is restricted by the SupportedAttributes
	parameterized type. SupportedAttributes is an open ended set in		parameterized type. SupportedAttributes is an open ended set in
	this document. Others documents can constrain these values.		this document. Others documents can constrain these values.
	Attributes from [RFC2985] MAY be supported.		Attributes from [RFC2985] MAY be supported.
	- publicKey is optional. When present, it contains the public key		- publicKey is optional. When present, it contains the public key
	encoded as an OCTET STRING. The structure within the octet string,		encoded as an OCTET STRING. The structure within the octet string,
	if any, depends on the privateKeyAlgorithm.		if any, depends on the privateKeyAlgorithm. For example, a DSA key
			is an INTEGER. Other documents may define additional private key
	3. Encrypted Private Key Info		formats. Note that RSA public keys are included in RSAPrivateKey
			(i.e., n and e are present), as per [RFC3447], and ECC public keys
	This section gives the syntax for encrypted private-key information,		are included in ECPrivateKey (i.e., in the publicKey field), as per
	which is used with [P12].		[RFCTBD2].
	Encrypted private-key information shall have ASN.1 type
	EncryptedPrivateKeyInfo:
	EncryptedPrivateKeyInfo ::= SEQUENCE {
	encryptionAlgorithm EncryptionAlgorithmIdentifier,
	encryptedData EncryptedData }
	EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
	{ { KeyEncryptionAlgorithms } }
	EncryptedData ::= OCTET STRING
	The EncAsymmetricKeyPackage contains one or more
	EncryptedPrivateKeyInfo elements. The fields in
	EncryptedPrivateKeyInfo are used as follows:
	- encryptionAlgorithm identifies the algorithm under which the
	private-key information is encrypted. Implementations MUST support
	the TBD algorithm.
	- encryptedData is the result of encrypting the private-key
	information (i.e., the PrivateKeyInfo).
	The encryption process involves the following two steps:
	1. The private-key information is BER encoded, yielding an octet
	string.
	2. The result of step 1 is encrypted with the secret key to give an
	octet string, the result of the encryption process.
	4. Protecting the AsymmetricKeyPackage		3. Protecting the AsymmetricKeyPackage
	CMS [RFC3852] and [RFC5083] protecting content types can be used to		CMS protecting content types, [RFC5652] and [RFC5083], can be used to
	provide security to the AsymmetricKeyPackage:		provide security to the AsymmetricKeyPackage:
	- SignedData can be used to apply a digital signature to the		- SignedData can be used to apply a digital signature to the
	AsymmetricKeyPackage.		AsymmetricKeyPackage.
	- EncryptedData can be used to encrypt the AsymmetricKeyPackage to		- EncryptedData can be used to encrypt the AsymmetricKeyPackage to
	provide confidentiality but does not distribute the content		provide confidentiality but does not distribute the content
	encryption keys.		encryption keys.
	- EnvelopedData can be used to encrypt the AsymmetricKeyPackage with		- EnvelopedData can be used to encrypt the AsymmetricKeyPackage with
	simple symmetric encryption, where the sender and the receiver		simple symmetric encryption, where the sender and the receiver
	already share the necessary encryption key.		already share the necessary encryption key.
	- AuthenticatedData can be used to protect the AsymmetricKeyPackage		- AuthenticatedData can be used to protect the AsymmetricKeyPackage
	with message authentication codes, where key management information		with message authentication codes, where key management information
	is handled in a manner similar to EnvelopedData.		is handled in a manner similar to EnvelopedData.
	- AuthEnvelopedData can be used to protect the AsymmetricKeypackage		- AuthEnvelopedData can be used to protect the AsymmetricKeyPackage
	with algorithms that support authenticated encryption, where key		with algorithms that support authenticated encryption, where key
	management information is handled in a manner similar to		management information is handled in a manner similar to
	EnvelopedData.		EnvelopedData.
	5. Other Considerations		4. Other Private-Key Format Considerations
	This document defines the syntax and the semantics for content types		This document defines the syntax and the semantics for a content type
	that exchange asymmetric keys. There are two other standards for		that exchanges asymmetric private keys. There are two other formats
	transporting asymmetric private keys:		that have been used for the transport of asymmetric private keys:
	- Personal Information Exchange (PFX) or more commonly referred to as		- Personal Information Exchange (PFX) Syntax Standard [P12], which is
	P12 [P12], is a transfer syntax for personal identity information,		more commonly referred to as PKCS #12 or simply P12, is a transfer
	including private keys, certificates, miscellaneous secrets, and		syntax for personal identity information, including private keys,
	extensions. Both PrivateKeyInfo and EncryptedPrivateKeyInfo can be		certificates, miscellaneous secrets, and extensions.
	carried in a P12 message.		OneAsymmetricKey, PrivateKeyInfo, and EncryptedPrivateKeyInfo
			[RFC5208] can be carried in a P12 message. The private key
			information, OneAsymmetricKey and PrivateKeyInfo, are carried in
			the P12 keyBag BAG-TYPE. EncryptedPrivateKeyInfo is carried in the
			P12 pkcs8ShroudedKeyBag BAG-TYPE. In current implementations, the
			file extensions .pfx and .p12 can be used interchangeably.
	- Microsoft's Exchange Security format, which is a proprietary		- Microsoft's private key proprietary transfer syntax. The .pvk file
	format.		extension is used for local storage.
	When locally storing private keys, the file format is either a DER		The .pvk and .p12/.pfx formats are not interchangeable; however,
	encoded file with the file extension .p12 or a PEM encoded file with		conversion tools exist to convert from one format to another.
	the file extension .pem.
	When the private key is a character string, the OCTET STRING contains		[RFCTBD3] defines the appication/pkcs8 media type and .p8 file
	an embedded UTF8String.		extension.
	6. Security Considerations		To extract the private key information from the AsymmetricKeyPackage,
			the encapsulating layers need to be removed. At a minimum, the outer
			ContentInfo [RFC5652] layer needs to be removed. If the
			AsymmetricKeyPackage is encapsulated in a SignedData [RFC5652], then
			the SignedData and EncapsulatedContentInfo layers [RFC5652] also need
			to be removed. The same is true for EnvelopedData, EncryptedData, and
			AuthenticatedData all from [RFC5652] as well as AuthEnvelopedData
			from [RFC5083]. Once all the outer layers are removed, there are as
			many sets of private key information as there are OneAsymmetricKey
			structures. OneAsymmetricKey and PrivateKeyInfo are the same
			structure; therefore, either can be saved as a .p8 file or copied in
			to the P12 KeyBack BAG-TYPE. Removing encapsulating security layers
			will invalidate any signature and may expose the key to unauthorized
			disclosure.
	Protection of the private-key information is vital to public-key		.p8 files are sometimes PEM encoded. When .p8 files are PEM encoded
	cryptography. Disclosure of the private-key material to another		they use the .pem file extension. PEM encoding is the Base64
	entity can lead to masquerades. The encryption algorithm used in the		encoding [RFC2045] of either the DER encoded EncryptedPrivateKeyInfo
	encryption process must be as 'strong' as the key it is protecting.		sandwiched between:
			-----BEGIN ENCRYPTED PRIVATE KEY-----
			-----END ENCRYPTED PRIVATE KEY-----
			or the PrivateKeyInfo or the OneAsymmetricKey sandwiched between:
			-----BEGIN PRIVATE KEY-----
			-----END PRIVATE KEY-----
			5. Security Considerations
			The security considerations in [RFC5208] also apply to this document.
	The asymmetric key package contents are not protected. This content		The asymmetric key package contents are not protected. This content
	type can be combined with a security protocol to protect the contents		type can be combined with a security protocol to protect the contents
	of the package.		of the package.
	The encrypted asymmetric key package contents are protected; as noted		6. IANA Considerations
	above the encryption algorithm must be as 'strong' as the key it is
	protecting.
	7. IANA Considerations
	None: All identifiers are already registered. Please remove this		None: All identifiers are already registered. Please remove this
	section prior to publication as an RFC.		section prior to publication as an RFC.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2045] Freed, .N, and N. Borenstein, "Multipurpose Internet Mail
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Extensions (MIME) Part One: Format of Internet Message
			Bodies", RFC 2045, November 1996.
	[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC3852,		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	July 2004.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
	Information Technology - Abstract Syntax Notation One.		5652, September 2009.
	[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.		[RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax
	Information Technology - Abstract Syntax Notation One: Information		Standard Version 1.2", RFC 5208, May 2008.
	Object Specification.
	[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.		[RFCTBD1] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX",
	Information Technology - Abstract Syntax Notation One: Constraint		draft-ietf-pkix-new-asn1-07.txt, work-in-progress.
	Specification.
	[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002.		[RFCTBD3] Jennings C., and J. Fischl "Certificate Management
	Information Technology - Abstract Syntax Notation One:		Service for The Session Initiation Protocol (SIP)",
	Parameterization of ASN.1 Specifications.		draft-ietf-sip-certs-09.txt, work-in-progress.
	[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002.		[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.
	Information Technology - ASN.1 encoding rules: Specification of Basic		Information Technology - Abstract Syntax Notation One.
	Encoding Rules (BER), Canonical Encoding Rules (CER) and
	Distinguished Encoding Rules (DER).
	8.2. Non-Normative References		[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002.
			Information Technology - Abstract Syntax Notation One:
			Information Object Specification.
	[P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information Exchange		[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002.
	Syntax", June 1999.		Information Technology - Abstract Syntax Notation One:
			Constraint Specification.
	[RFC2985] Nystrom, M., and B. Kaliski, "PKCS #9: Selected Object		[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002.
	Classes and Attribute Types Version 2.0", RFC 2985, November 2000.		Information Technology - Abstract Syntax Notation One:
			Parameterization of ASN.1 Specifications.
	[RFC3447] Jonsson, J., and B. Kaliski, " Public-Key Cryptography		[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002.
	Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1",		Information Technology - ASN.1 encoding rules:
	RFC 3447, February 2003.		Specification of Basic Encoding Rules (BER), Canonical
			Encoding Rules (CER) and Distinguished Encoding Rules
			(DER).
	[RFC5208] Kaliski, B., "PKCS #8: Private Key Information Syntax		7.2. Non-Normative References
	Standard Version 1.2", RFC 5208, May 2008.
	[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)		[P12] RSA Laboratories, "PKCS #12 v1.0: Personal Information
	Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.		Exchange Syntax", June 1999.
	[PKI-ALG] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,		[RFC2985] Nystrom, M., and B. Kaliski, "PKCS #9: Selected Object
	"Elliptic Curve Cryptography Subject Public Key Information", draft-		Classes and Attribute Types Version 2.0", RFC 2985,
	ietf-pkix-ecc-subpubkeyinfo, work-in-progress.		November 2000.
			[RFC3447] Jonsson, J., and B. Kaliski, "Public-Key Cryptography
			Standards (PKCS) #1: RSA Cryptography Specifications
			Version 2.1", RFC 3447, February 2003.
			[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS)
			Authenticated-Enveloped-Data Content Type", RFC 5083,
			November 2007.
			[X.520] ITU-T Recommendation X.520 (2005) | ISO/IEC 9594-6:2005,
			Information technology - Open Systems Interconnection -
			The Directory: Selected attribute types.
			[RFCTBD2] Turner, S., and D. Brown, "EC Private Key Info
			Structure", draft-turner-ecprivatekey-00.txt, work-in-
			progress.
	APPENDIX A: ASN.1 Module		APPENDIX A: ASN.1 Module
	This annex provides the normative ASN.1 definitions for the		This annex provides the normative ASN.1 definitions for the
	structures described in this specification using ASN.1 as defined in		structures described in this specification using ASN.1 as defined in
	[X.680] through [X.683].		[X.680] through [X.683].
	AsymmetricKeyPackageModulev1 { tbd }		AsymmetricKeyPackageModulev1 { tbd }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 4 ¶
	structures described in this specification using ASN.1 as defined in		structures described in this specification using ASN.1 as defined in
	[X.680] through [X.683].		[X.680] through [X.683].
	AsymmetricKeyPackageModulev1 { tbd }		AsymmetricKeyPackageModulev1 { tbd }
	DEFINITIONS IMPLICIT TAGS ::=		DEFINITIONS IMPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS ALL		-- EXPORTS ALL
	IMPORTS NOTHING		IMPORTS NOTHING
	Attribute{}, ATTRIBUTE, AlgorithmIdentifier{}		Attribute{}, ATTRIBUTE
	FROM PKIX-CommonTypes		FROM PKIX-CommonTypes-2009 -- FROM [RFCTBD1]
	{ 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(43) }		id-mod-pkixCommon-02(57) }
	id-aes128-wrap, id-aes192-wrap, id-aes1256-wrap		AlgorithmIdentifier{}
	FROM CMSAesRsaesOaep		FROM AlgorithmInformation-2009 -- FROM [RFCTBD1]
	{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)		{ iso(1) identified-organization(3) dod(6) internet(1)
	pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) }		security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-algorithmInformation-02(58) }
	;		;
	PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER		PKCS7-CONTENT-TYPE ::= TYPE-IDENTIFIER
	KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= {		KeyPackageContentTypes PKCS7-CONTENT-TYPE ::= {
	asymmetric-key-package |		asymmetric-key-package,
	... -- Expect additional content types --		... -- Expect additional content types --
	}		}
	asymmetric-key-package PKCS7-CONTENT-TYPE ::=		asymmetric-key-package PKCS7-CONTENT-TYPE ::=
	{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }		{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }
	id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=		id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
	{ TBD }		{ TBD }
	AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey		AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
	skipping to change at page 10, line 4 ¶		skipping to change at page 9, line 34 ¶
	... -- Expect additional content types --		... -- Expect additional content types --
	}		}
	asymmetric-key-package PKCS7-CONTENT-TYPE ::=		asymmetric-key-package PKCS7-CONTENT-TYPE ::=
	{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }		{ AsymmetricKeyPackage IDENTIFIED BY id-ct-KP-aKeyPackage }
	id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=		id-ct-KP-aKeyPackage OBJECT IDENTIFIER ::=
	{ TBD }		{ TBD }
	AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey		AsymmetricKeyPackage ::= SEQUENCE SIZE (1..MAX) OF OneAsymmetricKey
	OneAsymmetricKey ::= SEQUENCE {		OneAsymmetricKey ::= SEQUENCE {
	version Version,		version Version,
	privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,		privateKeyAlgorithm PrivateKeyAlgorithmIdentifier,
	privateKey PrivateKey, -- DER encoded		privateKey PrivateKey,
	attributes [0] Attributes OPTIONAL,		attributes [0] Attributes OPTIONAL,
	publicKey [1] PublicKey OPTIONAL }		publicKey [1] PublicKey OPTIONAL
			}
	PrivateKeyInfo ::= OneAsymmetricKey		PrivateKeyInfo ::= OneAsymmetricKey
			-- PrivateKeyInfo is used by [P12]. If version is set to 1,
			-- publicKey MUST be absent. When v1, PrivateKeyInfo is the same
			-- as it was in [RFC5208].
	Version ::= INTEGER {v1(0), v2(1)} (v1, v2,...)		Version ::= INTEGER {v1(0), v2(1)} (v1, v2,...)
	PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier		PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier
	{ { PrivateKeyAlgorithms } }		{ { PrivateKeyAlgorithms } }
			PrivateKey ::= OCTET STRING
			-- Content varies based on type of key. The
			-- algorithm identifier dictates the format of
			-- the key.
	PrivateKey ::= OCTET STRING -- Content varies based on type of key		PublicKey ::= BIT STRING
	-- DSA is INTEGER, ECDSA is ECPublicKey		-- Content varies based on type of key. The
			-- algorithm identifier dictates the format of
	PublicKey ::= OCTET STRING		-- the key.
	Attributes ::= Set of Attribute { { SupportAttributes } }		Attributes ::= Set of Attribute { { SupportedAttributes } }
	SupportedAttributes ATTRIBUTE :: {		SupportedAttributes ATTRIBUTE :: {
	... -- For local profiles		... -- For local profiles
	}		}
	EncryptedPrivateKeyInfo ::= SEQUENCE {		EncryptedPrivateKeyInfo ::= SEQUENCE {
	encryptionAlgorithm EncryptionAlgorithmIdentifier,		encryptionAlgorithm EncryptionAlgorithmIdentifier,
	encryptedData EncryptedData }		encryptedData EncryptedData }
	EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier		EncryptionAlgorithmIdentifier ::= AlgorithmIdentifier
	{ { KeyEncryptionAlgorithms } }		{ { KeyEncryptionAlgorithms } }
	EncryptedData ::= OCTET STRING -- Encrypted PrivateKeyInfo		EncryptedData ::= OCTET STRING -- Encrypted PrivateKeyInfo
	PrivateKeyAlgorithms ALGORITHM-IDENTIFIER ::= {		PrivateKeyAlgorithms ALGORITHM-IDENTIFIER ::= {
	... -- Extensible		... -- Extensible
	}		}
	KeyEncryptionAlgorithms ALGORITHM-IDENTIFIER ::= {		KeyEncryptionAlgorithms ALGORITHM-IDENTIFIER ::= {
	id-aes128-wrap |
	id-aes192-wrap |
	id-aes256-wrap,
	... -- Extensible		... -- Extensible
	}		}
	END		END
	Acknowledgements		Acknowledgements
	Many thanks go out to the Burt Kaliski and Jim Randall at RSA.		Many thanks go out to the Burt Kaliski and Jim Randall at RSA.
	Without the prior version of the document, this one wouldn't exist.		Without the prior version of the document, this one wouldn't exist.
	We'd also like to thank Pasi Eronen and Russ Housley.		We'd also like to thank Pasi Eronen, Russ Housley, and Carl Wallace.
	Author's Address		Author's Address
	Sean Turner		Sean Turner
	IECA, Inc.		IECA, Inc.
	3057 Nutley Street, Suite 106		3057 Nutley Street, Suite 106
	Fairfax, VA 22031		Fairfax, VA 22031
	USA		USA
	Email: turners@ieca.com		Email: turners@ieca.com
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at ietf-
	ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 75 change blocks.
	197 lines changed or deleted		238 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/