< draft-turner-ecprivatekey-02.txt		draft-turner-ecprivatekey-03.txt >
	Network Working Group Sean Turner, IECA		Network Working Group Sean Turner, IECA
	Internet Draft Dan Brown, Certicom		Internet Draft Dan Brown, Certicom
	Intended Status: Informational December 4, 2009		Intended Status: Informational February 2, 2010
	Expires: June 4, 2010		Expires: August 2, 2010
	Elliptic Curve Private Key Structure		Elliptic Curve Private Key Structure
	draft-turner-ecprivatekey-02.txt		draft-turner-ecprivatekey-03.txt
			Abstract
			This document specifies the syntax and semantics for conveying
			Elliptic Curve (EC) private key information. This syntax and
			semantics defined herein are based on a similar syntax and semantics
			defined in Standards for Efficient Cryptography Group (SECG).
	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 31 ¶		skipping to change at page 1, line 38 ¶
	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 June 4, 2010.		This Internet-Draft will expire on August 2, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	This document specifies the syntax and semantics for conveying		described in the Simplified BSD License.
	Elliptic Curve (EC) private key information. This syntax and
	semantics defined herein are based on a similar syntax and semantics
	defined in Standards for Efficient Cryptography Group (SECG).
	1. Introduction		1. Introduction
	This document specifies a syntax and semantics for Elliptic Curve		This document specifies a syntax and semantics for Elliptic Curve
	(EC) private key information. EC private key information includes a		(EC) private key information. EC private key information includes a
	private key and optionally parameters. Additionally, it may include		private key and parameters. Additionally, it may include the
	the corresponding public key. The syntax and semantics defined		corresponding public key. The syntax and semantics defined herein
	herein are based on a similar syntax and semantics defined in		are based on a similar syntax and semantics defined in Standards for
	Standards for Efficient Cryptography Group (SECG) [SECG1].		Efficient Cryptography Group (SECG) [SECG1].
	Most Public Key Infrastructures (PKIs) mandate local key generation;		Most Public Key Infrastructures (PKIs) mandate local key generation;
	however, there are some PKIs that also support centralized key		however, there are some PKIs that also support centralized key
	generation (e.g., the public-private key pair is generated by a CA).		generation (e.g., the public-private key pair is generated by a CA).
	The structure defined in this document allows the entity that		The structure defined in this document allows the entity that
	generates the private and public keys to distribute the key pair and		generates the private and public keys to distribute the key pair and
	optionally the associated domain parameters.		the associated domain parameters.
	A scenario in which this syntax is useful distributes EC private keys		A scenario in which this syntax is useful distributes EC private keys
	using PrivateKeyInfo, as defined in PKCS #8 [RFC5208]. Distributing		using PrivateKeyInfo, as defined in PKCS #8 [RFC5208]. Distributing
	an EC private key with PKCS#8 [RFC5208] involves including:		an EC private key with PKCS#8 [RFC5208] involves including:
	a) id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]) with the		a) id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]) with the
	namedCurve as the parameters in the privateKeyAlgorithm field		namedCurve as the parameters in the privateKeyAlgorithm field
	b) ECPrivateKey in the PrivateKey field, which is an OCTET STRING.		b) ECPrivateKey in the PrivateKey field, which is an OCTET STRING.
	When the public key is included, it is present in the ECPrivateKey		There are two possible locations to carry a public key. When one is
	publicKey field not in the PKCS#8 publicKey field.		included, the publicKey field in the ECPrivateKey is used. The
			publicKey field in PKCS#8 is not used.
	2. Terminology		2. 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].
	3. Elliptic Curve Private Key Format		3. Elliptic Curve Private Key Format
	This section gives the syntax for an EC private key. Computationally		This section gives the syntax for an EC private key. Computationally
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	is one (1).		is one (1).
	o privateKey is the private key. It is an octet string of length		o privateKey is the private key. It is an octet string of length
	ceiling (log2(n/8)) (where n is the order of the curve) obtained		ceiling (log2(n/8)) (where n is the order of the curve) obtained
	from the unsigned integer via the Integer-to-Octet-String-		from the unsigned integer via the Integer-to-Octet-String-
	Primitive (I2OSP) defined in [RFC3447].		Primitive (I2OSP) defined in [RFC3447].
	o parameters specifies the elliptic curve domain parameters		o parameters specifies the elliptic curve domain parameters
	associated to the private key. The type ECParameters are discussed		associated to the private key. The type ECParameters are discussed
	in [RFC5480]. As specified in [RFC5480], only the namedCurve		in [RFC5480]. As specified in [RFC5480], only the namedCurve
	CHOICE, which is an object identifier that fully identifies the		CHOICE is permitted. namedCurve is an object identifier that fully
	required values for a particular set of elliptic curve domain		identifies the required values for a particular set of elliptic
	parameters, is permitted. Though the ASN.1 indicates parameters is		curve domain parameters. Though the ASN.1 indicates that the
	OPTIONAL, implementations that conform to this document MUST		parameters field is OPTIONAL, implementations that conform to this
	always include the parameters field.		document MUST always include the parameters field.
	o publicKey contains the elliptic curve public key associated with		o publicKey contains the elliptic curve public key associated with
	the private key in question. The format of the public key is		the private key in question. The format of the public key is
	specified in Section 2.2 of [RFC5480]. Though the ASN.1 indicates		specified in Section 2.2 of [RFC5480]. Though the ASN.1 indicates
	publicKey is OPTIONAL, implementations that conform to this		publicKey is OPTIONAL, implementations that conform to this
	document SHOULD always include the publicKey field. The publicKey		document SHOULD always include the publicKey field. The publicKey
	field can be omitted when the public key has been distributed via		field can be omitted when the public key has been distributed via
	another mechanism, which is beyond the scope of this document.		another mechanism, which is beyond the scope of this document.
	Given the private key and the parameters the public key can always		Given the private key and the parameters the public key can always
	be recomputed, this field exists as a convenience to the consumer.		be recomputed; this field exists as a convenience to the consumer.
	4. Other Considerations		4. Other Considerations
	When generating a transfer encoding, generators SHOULD use DER		When generating a transfer encoding, generators SHOULD use DER
	[X.690] and receivers SHOULD be prepared to handle BER [X.690] and		[X.690] and receivers SHOULD be prepared to handle BER [X.690] and
	DER [X.690].		DER [X.690].
			Section 1 described a format for transporting EC private keys (i.e.,
			converting ECPrivateKey to PrivateKeyInfo [PKCS#8]); however, this
			format can also be used for local storage.
	Local storage of an unencrypted ECPrivateKey object is out of scope		Local storage of an unencrypted ECPrivateKey object is out of scope
	of this document. However, one popular format uses the .pem file		of this document. However, one popular format uses the .pem file
	extension. It is a PEM encoding, which is the Base64 encoding		extension. It is a PEM encoding, which is the Base64 encoding
	[RFC4648], of the DER encoded ECPrivateKey object sandwiched between:		[RFC4648], of the DER encoded ECPrivateKey object sandwiched between:
	-----BEGIN EC PRIVATE KEY-----		-----BEGIN EC PRIVATE KEY-----
	-----END EC PRIVATE KEY-----		-----END EC PRIVATE KEY-----
	Another local storage format uses the .der file extension. In this		Another local storage format uses the .der file extension. In this
	case, it is a DER [X.609] encoding of the ECPrivateKey object.		case, it is a DER [X.690] encoding of the ECPrivateKey object.
	Local storage of an encrypted ECPrivateKey object is out of scope of		Local storage of an encrypted ECPrivateKey object is out of scope of
	this document. However, ECPrivateKey should be the format for the		this document. However, ECPrivateKey should be the format for the
	plaintext key being encrypted, and DER encoding it will promote		plaintext key being encrypted. DER [X.690] encoding ECPrivateKey
	interoperability if the key is encrypted for transport to another		will promote interoperability if the key is encrypted for transport
	party. See [RFC5208].		to another party. PEM encoding the DER encoded ECPrivateKey is
			common; "Proc-Type:" and "DEK-INFO:" fields [RFC1421] followed by the
			DER Encoded ECPrivateKey are sandwiched between:
			-----BEGIN EC PRIVATE KEY-----
			-----END EC PRIVATE KEY-----
	5. Security Considerations		5. Security Considerations
	This structure does not protect the EC private key information in any		This structure does not protect the EC private key information in any
	way. This structure should be combined with a security protocol to		way. This structure should be combined with a security protocol to
	protect it.		protect it.
	Protection of the private-key information is vital to public-key		Protection of the private-key information is vital to public-key
	cryptography. Disclosure of the private-key material to another		cryptography. The consequences of disclosure depends on the purpose
	entity can lead to masquerades. The encryption algorithm used in the		of the private key. If a private key is used for signature, then the
			disclosure allows unauthorized signing. If a private key is used for
			key management, then disclosure allows unauthorized parties to access
			the managed keying material. The encryption algorithm used in the
	encryption process must be as 'strong' as the key it is protecting.		encryption process must be as 'strong' as the key it is protecting.
	6. IANA Considerations		6. 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.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
			[RFC1421] J. Linn, "Privacy Enhancement for Internet Electronic
			Mail: Part I: Message Encryption and Authentication
			Procedures," RFC 1421, February 1993.
	[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.
	[RFC3447] Kaliski, B., and J. Jonsson, "Public-Key Cryptography		[RFC3447] Kaliski, B., and J. Jonsson, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, February 2003.		Version 2.1", RFC 3447, February 2003.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	skipping to change at page 5, line 35 ¶		skipping to change at page 6, line 5 ¶
	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.
	Information Technology - Abstract Syntax Notation One:		Information Technology - Abstract Syntax Notation One:
	Constraint Specification.		Constraint Specification.
	[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002.		[X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002.
	Information Technology - Abstract Syntax Notation One:		Information Technology - Abstract Syntax Notation One:
	Parameterization of ASN.1 Specifications, 2002.		Parameterization of ASN.1 Specifications, 2002.
			[X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002.
			Information Technology - ASN.1 encoding rules:
			Specification of Basic Encoding Rules (BER), Canonical
			Encoding Rules (CER) and Distinguished Encoding Rules
			(DER).
	7.2. Informative References		7.2. Informative References
	[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS)		[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS)
	#8: Private-Key Information Syntax Specification Version		#8: Private-Key Information Syntax Specification Version
	1.2, RFC 5208, May 2008.		1.2, RFC 5208, May 2008.
	Appendix A ASN.1 Module		Appendix A ASN.1 Module
	This appendix provides informative ASN.1 definitions for the		This appendix provides ASN.1 definitions for the structures described
	structures described in this specification using ASN.1 as defined in		in this specification using ASN.1 as defined in [X.680], [X.681],
	[X.680], [X.681], [X.682], and [X.683] for compilers that support the		[X.682], and [X.683] for compilers that support the 2002 ASN.1.
	2002 ASN.1.
	ECPrivateKey-2009-02 { id-tbd }		ECPrivateKey { iso(1) identified-organization(3) dod(6)
			internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-ecprivateKey(65) }
	DEFINITIONS EXPLICIT TAGS ::=		DEFINITIONS EXPLICIT TAGS ::=
	BEGIN		BEGIN
	-- EXPORTS ALL;		-- EXPORTS ALL;
	IMPORTS		IMPORTS
	-- FROM [RFCXXXX]		-- FROM New PKIX ASN.1 [RFCXXXX]
	ECParameters, NamedCurve		ECParameters, NamedCurve
	FROM PKIXAlgs-2009		FROM PKIXAlgs-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-pkix1-algorithms2008-02(56) }		id-mod-pkix1-algorithms2008-02(56) }
	;		;
	ECPrivateKey ::= SEQUENCE {		ECPrivateKey ::= SEQUENCE {
	version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),		version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
	privateKey OCTET STRING,		privateKey OCTET STRING,
	parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,		parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
	publicKey [1] BIT STRING OPTIONAL		publicKey [1] BIT STRING OPTIONAL
	}		}
	END		END
			Appendix B Differences with SECG1
			This appendix lists the differences between this document and
			[SECG1]:
			1. This document uses the I2OSP routine defined in [RFC3447] while
			SECG1 defines its own routine. The two routines result in the same
			output.
			2. SECG1 constrains its parameters (i.e., the curves) to
			SECGCurveNames. This document constrains the parameters to
			NamedCurve from [RFC5480].
			3. This document requires parameters be present while SECG1 does not.
			4. This document specifies requirements for encoding rules while
			SECG1 did not.
	Acknowledgements		Acknowledgements
	The authors would like to thank Simon Blake-Wilson and John O. Goyo		The authors would like to thank Simon Blake-Wilson and John O. Goyo
	for their work on defining the structure in [SECG1]. The authors		for their work on defining the structure in [SECG1]. The authors
	would also like to thank Pasi Eronen, Alfred Hoenes, Russ Housley,		would also like to thank Pasi Eronen, Alfred Hoenes, Joel Jaegglie,
	and Jim Schaad for their comments.		Avshalom Houri, Russ Housley, Jim Schaad, and Carl Wallace for their
			comments.
	Authors' Addresses		Authors' Addresses
	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
End of changes. 21 change blocks.
	43 lines changed or deleted		89 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/