< draft-ietf-pkix-ecc-pkalgs-02.txt		draft-ietf-pkix-ecc-pkalgs-03.txt >
	PKIX Working Group Daniel R. L. Brown,		PKIX Working Group Daniel R. L. Brown,
	INTERNET-DRAFT Certicom Corp.		INTERNET-DRAFT Certicom Corp.
	Expires July 6, 2006 January 6, 2006		Expires April 4, 2007 October 4, 2006
	Additional Algorithms and Identifiers		Additional Algorithms and Identifiers
	for use of Elliptic Curve Cryptography with PKIX		for use of Elliptic Curve Cryptography with PKIX
	<draft-ietf-pkix-ecc-pkalgs-02.txt>		<draft-ietf-pkix-ecc-pkalgs-03.txt>
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she become
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of 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		other groups may also distribute working documents as
	Internet-Drafts.		Internet-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 July 6, 2006.		This Internet-Draft will expire on April 4, 2007.
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	This document gives additional algorithms and associated ASN.1		This document gives additional algorithms and associated ASN.1
	identifiers for elliptic curve cryptography (ECC) used with the		identifiers for elliptic curve cryptography (ECC) used with the
	Internet X.509 Public Key Infrastructure Certificate and		Internet X.509 Public Key Infrastructure Certificate and
	Certificate Revocation List (CRL) Profile (PKIX). The algorithms		Certificate Revocation List (CRL) Profile (PKIX). The algorithms
	and identifiers here are consistent with both ANSI X9.62-1998 and		and identifiers here are consistent with both ANSI X9.62-2005 and
	X9.63-2001, and shall be consistent with the forthcoming revisions		X9.63-2001, and shall be consistent with the forthcoming revisions
	of these documents. Consistency shall also be maintained with SEC1		of these documents. Consistency shall also be maintained with SEC1
	and SEC2, and any revisions or successors of such documents.		and SEC2, and any revisions or successors of such documents.
	Table of Contents		Table of Contents
	1 Introduction ............................................... 3		1 Introduction ............................................... 3
	1.1 Terminology ........................................... 3		1.1 Terminology ........................................... 3
	1.2 Elliptic Curve Cryptography ........................... 3		1.2 Elliptic Curve Cryptography ........................... 3
	1.3 Algorithm Identifiers ................................. 4		1.3 Algorithm Identifiers ................................. 4
	skipping to change at page 2, line 11 ¶		skipping to change at page 2, line 11 ¶
	X9.63-2001, and shall be consistent with the forthcoming revisions		X9.63-2001, and shall be consistent with the forthcoming revisions
	of these documents. Consistency shall also be maintained with SEC1		of these documents. Consistency shall also be maintained with SEC1
	and SEC2, and any revisions or successors of such documents.		and SEC2, and any revisions or successors of such documents.
	Table of Contents		Table of Contents
	1 Introduction ............................................... 3		1 Introduction ............................................... 3
	1.1 Terminology ........................................... 3		1.1 Terminology ........................................... 3
	1.2 Elliptic Curve Cryptography ........................... 3		1.2 Elliptic Curve Cryptography ........................... 3
	1.3 Algorithm Identifiers ................................. 4		1.3 Algorithm Identifiers ................................. 4
	2 Auxiliary Functions ........................................ 5		2 Auxiliary Functions ........................................ 5
	2.1 Hash Functions ........................................ 5		2.1 Hash Functions ........................................ 5
	2.2 Key Derivation Functions .............................. 6		2.2 Key Derivation Functions .............................. 6
	2.3 Key Wrap Functions .................................... 7		2.3 Key Wrap Functions .................................... 7
	2.4 Message Authentication Codes .......................... 7		2.4 Message Authentication Codes .......................... 8
	2.5 Key Confirmation Methods ... .......................... 7		2.5 Key Confirmation Methods ... .......................... 9
	3 Elliptic Curve Domain Parameters ........................... 8
	4 ECC Algorithms ............................................ 11		3 Elliptic Curve Domain Parameters ...........................10
	4.1 Signature Schemes .................................... 11
	4.1.1 ECDSA ........................................... 11		4 ECC Algorithms ............................................ 12
	4.2 Key Agreement Schemes ................................ 13		4.1 Signature Schemes .................................... 12
	4.2.1 1-Pass ECDH ..................................... 13		4.1.1 ECDSA ........................................... 12
	4.2.2 Full and 1-Pass ECMQV ........................... 14		4.2 Key Agreement Schemes ................................ 14
	4.3 ECC Algorithm Set .................................... 15		4.2.1 1-Pass ECDH ..................................... 14
	5 ECC Keys .................................................. 16		4.2.2 Full and 1-Pass ECMQV ........................... 15
	5.1 Public Keys .......................................... 16		4.3 ECC Algorithm Set .................................... 17
	5.2 Private Keys ......................................... 17
	6 ASN.1 Module .............................................. 18		5 ECC Keys .................................................. 17
	7 References ................................................ 24		5.1 Public Keys .......................................... 17
	8 Security Considerations ................................... 24		5.2 Private Keys ......................................... 19
	9 Acknowledgments ........................................... 25
	10 Authors' Addresses ........................................ 25		6 ASN.1 Module .............................................. 19
	11 Full Copyright Statement .................................. 25
			7 References ................................................ 20
			8 Security Considerations ................................... 21
			9 Acknowledgments ........................................... 21
			10 Authors' Addresses ........................................ 21
			11 Full Copyright Statement .................................. 21
	1 Introduction		1 Introduction
	This document supplements [RFC 3279], "Algorithms and		This document supplements [RFC 3279], "Algorithms and
	Identifiers for the Internet X.509 Public Key Infrastructure		Identifiers for the Internet X.509 Public Key Infrastructure
	Certificate and Certificate Revocation List (CRL) Profile "		Certificate and Certificate Revocation List (CRL) Profile "
	This document specifies supplementary algorithm identifiers and		This document specifies supplementary algorithm identifiers and
	ASN.1 [X.680] encoding formats for digital signatures and subject		ASN.1 encoding formats for digital signatures and subject public
	public keys used in the Internet X.509 Public Key Infrastructure		keys used in the Internet X.509 Public Key Infrastructure (PKIX).
	(PKIX).
	The supplementary formats specified are used to indicate the		The supplementary formats specified are used to indicate the
	auxiliary functions, such as the new hash functions specified in		auxiliary functions, such as the new hash functions specified in
	[FIPS 180-2] including SHA-256, that are to be used with elliptic		[FIPS 180-2] including SHA-256, that are to be used with elliptic
	curve public keys.		curve public keys.
	Furthermore, this document specifies formats to indicate that an		Furthermore, this document specifies formats to indicate that an
	elliptic curve public key is to be restricted for use with an		elliptic curve public key is to be restricted for use with an
	indicated set of elliptic curve cryptography algorithms.		indicated set of elliptic curve cryptography algorithms.
	Note: Previous standards [X9.62], [X9.63] and [SEC1] suggested that		Note: Previous standards, such as [X9.63] and [SEC1], suggested
	the extended key usage field could be used for purposes above.		that the extended key usage field could be used for purposes above.
	Because such a practice was regarded as improper, a new means to		Because such a practice was regarded as improper, a new means to
	accomplish the objectives is being introduced both in this document		accomplish the objectives is being introduced both in this document
	and revisions of the standards above.		and revisions of the standards above.
	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		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
	this document are to be interpreted as described in [RFC 2119].		this document are to be interpreted as described in [RFC 2119].
	1.2 Elliptic Curve Cryptography		1.2 Elliptic Curve Cryptography
	Elliptic Curve Cryptography (ECC) is a family of cryptographic		Elliptic Curve Cryptography (ECC) is a family of cryptographic
	algorithms. Several algorithms, such as Diffie-Hellman (DH) key		algorithms. Several algorithms, such as Diffie-Hellman (DH) key
	agreement and the Digital Signature Algorithm (DSA), have analogues		agreement and the Digital Signature Algorithm (DSA), have analogues
	in ECC. The analogy is that the cryptographic group is an elliptic		in ECC. The analogy is that the cryptographic group is an elliptic
	curve group over a finite field rather the multiplicative group of		curve group over a finite field rather the multiplicative group of
	(invertible) integers modulo a large prime.		(invertible) integers modulo a large prime.
	Because an ECC groups and its elements are different from DH and		Because an EC group and its elements are different from DH and DSA
	DSA groups and elements, ECC requires a slightly different syntax		groups and elements, ECC requires a slightly different syntax from
	from DSA and DH.		DSA and DH.
	Because a single ECC public key in a certificated might		Because a single ECC public key in a certificate might
	potentially be used for multiple different ECC algorithms, a		potentially be used for multiple different ECC algorithms, a
	mechanism for indicating algorithm usage is important.		mechanism for indicating algorithm usage is important.
	1.3 Algorithm Identifiers		1.3 Algorithm Identifiers
	The parameters field of the ASN.1 type AlgorithmIdentifier is		The parameters field of the ASN.1 type AlgorithmIdentifier is
	optional when using ECC. When the parameters field is not used		optional when using ECC. When the parameters field is not used
	meaningfully, it SHOULD be absent, but MAY be NULL if it is		meaningfully, it SHOULD be absent, but MAY be NULL if it is
	necessary to interoperate with legacy implementations that do not		necessary to interoperate with legacy implementations that do not
	support an optional parameters field. Absent and NULL parameters		support an optional parameters field. Absent and NULL parameters
	skipping to change at page 4, line 39 ¶		skipping to change at page 4, line 39 ¶
	algorithm ALGORITHM.&id({IOSet}),		algorithm ALGORITHM.&id({IOSet}),
	parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL		parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
	}		}
	In practice, AlgorithmIdentifier is a sequence of an OID and an		In practice, AlgorithmIdentifier is a sequence of an OID and an
	optional second field with syntax depending on the OID. In this		optional second field with syntax depending on the OID. In this
	document, the use of AlgorithmIdentifier will be constrained form.		document, the use of AlgorithmIdentifier will be constrained form.
	For example, when a hash function needs to be identified, a		For example, when a hash function needs to be identified, a
	constrained form of AlgorithmIdentifier is used that only permits		constrained form of AlgorithmIdentifier is used that only permits
	the OIDs for hash functions. The constraints also dictate the		the OIDs for hash functions. The constraints also dictate the
	syntax for the parameters field for a given OID.		syntax for the parameters field for a given OID. Constraints are
			useful for disallowing insertion of illegal OIDs and for more
			efficient PER encoding.
	Note: Older syntax for AlgorithmIdentifier had a mandatory		Note: Older syntax for AlgorithmIdentifier had a mandatory
	parameters field, which was customarily set to NULL when parameters		parameters field, which was customarily set to NULL when parameters
	field had nothing to convey. However, in the new syntax, in such		field had nothing to convey. However, in the new syntax, in such
	situations the absent parameters are preferred to NULL parameters		situations the absent parameters are preferred to NULL parameters
	when the parameters field does not carry any meaning. This		when the parameters field does not carry any meaning. This
	document specifies exactly what is permitted in the parameters		document specifies exactly what is permitted in the parameters
	field.		field.
	2 Auxiliary Functions		2 Auxiliary Functions
	skipping to change at page 5, line 25 ¶		skipping to change at page 5, line 25 ¶
	2.1 Hash Functions		2.1 Hash Functions
	Most notable among the auxiliary functions are hash functions,		Most notable among the auxiliary functions are hash functions,
	which are used in several different ways: message digesting for		which are used in several different ways: message digesting for
	signatures, verifiably random domain parameter generation, building		signatures, verifiably random domain parameter generation, building
	key derivation functions, building message authentication codes, as		key derivation functions, building message authentication codes, as
	well as building random number generators.		well as building random number generators.
	The hash functions SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 can		The hash functions SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 can
	be used with ECC. They are specified in FIPS 180-2, Change Notice		be used with ECC. They are specified in [FIPS 180-2].
	1.
	Hash functions are identified with the following object		Hash functions are identified with the following object
	identifiers.		identifiers.
	sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)		sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
	oiw(14) secsig(3) algorithm(2) sha1(26) }		oiw(14) secsig(3) algorithm(2) sha1(26) }
	id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)		id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
	us(840) organization(1) gov(101) csor(3) nistalgorithm(4)		us(840) organization(1) gov(101) csor(3) nistalgorithm(4)
	hashalgs(2) 4 }		hashalgs(2) 4 }
	skipping to change at page 6, line 35 ¶		skipping to change at page 6, line 35 ¶
	<<< Rough version, only. Anticipate using a more flexible		<<< Rough version, only. Anticipate using a more flexible
	syntax in next update of this draft ... >>>		syntax in next update of this draft ... >>>
	Crucial to key establishment, a Key Derivation Function (KDF) takes		Crucial to key establishment, a Key Derivation Function (KDF) takes
	input of a raw elliptic curve point and other information such as		input of a raw elliptic curve point and other information such as
	identifiers, and then derives a key. A KDF helps to eliminate any		identifiers, and then derives a key. A KDF helps to eliminate any
	structure from the key. (Elliptic curve points generally have some		structure from the key. (Elliptic curve points generally have some
	structure and cannot be regarded as pseudorandom.)		structure and cannot be regarded as pseudorandom.)
	The KDF to use with ECC is specified in X9.63, except that the hash		The KDFs to use with ECC are specified in [X9.63], except that the
	function SHA-1 can be replaced by one of SHA-1, SHA-224, SHA-256,		hash function SHA-1 can be replaced by one of SHA-1, SHA-224,
	SHA-384, or SHA-512. In particular, the KDF is determined entirely		SHA-256, SHA-384, or SHA-512, and in [SP 800-56]. In particular,
	by the hash function it is built from, so the following syntax is		the KDF is determined entirely by the hash function it is built
	adopted.		from, so the following syntax is adopted.
	KeyDerivationFunction ::= HashAlgorithm		KeyDerivationFunction ::= HashAlgorithm
	That certain protocols might use a different KDF, such as KDF1 in		That certain protocols might use a different KDF, such as KDF1 in
	IEEE 1363-2000, only means that the specifications here are		IEEE 1363-2000, only means that the specifications here are
	overridden in these protocols. Such KDFs ought to be deprecated.		overridden in these protocols. Such KDFs ought to be deprecated.
	No ASN.1 syntax is given here to support such KDFs, making		No ASN.1 syntax is given here to support such KDFs, making
	protocols that use such KDFs provide their own mechanisms to		protocols that use such KDFs provide their own mechanisms to
	indicate use of them.		indicate use of them.
	2.3 Key Wrap Functions		2.3 Key Wrap Functions
	<<< To be added.>>>
	Key wrap functions can be used to transform a key agreement scheme		Key wrap functions can be used to transform a key agreement scheme
	into a key transport scheme.		into a key transport scheme.
			The following constrained algorithm identifier is used to identify
			a key wrap algorithm.
			KeyWrapAlgorithm ::=
			AlgorithmIdentifier {{ KeyWrapAlgorithms }}
			The information object set used to constrain the algorithm
			identifier for key wrap algorithms is
			KeyWrapAlgorithms ::= ALGORITHM {
			{OID id-tdes-wrap } |
			{OID id-aes128-wrap } |
			{OID id-aes192-wrap } |
			{OID id-aes256-wrap } ,
			... -- More may be added
			}
			The object identifiers above are
			id-tdes-wrap OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
			rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) alg(3) 6 }
			id-ase128-wrap OBJECT IDENTIFIER ::= { nistAlgorithm aes(1)
			aes128-Wrap(5) }
			id-ase192-wrap OBJECT IDENTIFIER ::= { nistAlgorithm aes(1)
			aes128-Wrap(5) }
			id-ase256-wrap OBJECT IDENTIFIER ::= { nistAlgorithm aes(1)
			aes128-Wrap(5) }
			where the base object identifier used above is
			nistAlgorithm OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
			country(16) us(840) organization(1) gov(101) csor(3)
			nistAlgorithm(4) }
	2.4 Message Authentication Codes		2.4 Message Authentication Codes
	Some ECC algorithms use a Message Authentication Code (MAC), for		Some ECC algorithms use a Message Authentication Code (MAC), for
	example, as part of key confirmation.		example, as part of key confirmation.
	<<< Surely these exist somewhere >>>		The following constrainted algorithm identifier syntax is used to
			identify use of a MAC:
			MessageAuthenticationCode ::=
			AlgorithmIdentifier {{ MessageAuthenticationCodes }}
			The infomation object set defining the constraints is given is by
			MessageAuthenticationCodes ::= ALGORITHM {
			{OID id-hmac-sha1} |
			{OID id-hmac-sha1 PARMS INTEGER} |
			{OID id-hmac-sha224} |
			{OID id-hmac-sha224 PARMS INTEGER} |
			{OID id-hmac-sha256} |
			{OID id-hmac-sha256 PARMS INTEGER} |
			{OID id-hmac-sha384} |
			{OID id-hmac-sha384 PARMS INTEGER} |
			{OID id-hmac-sha512} |
			{OID id-hmac-sha512 PARMS INTEGER},
			... -- More MACs may be added
			}
			The optional parameter is use to indicate that the the HMAC output
			should be truncated.
			Example candidates for future expansion include GCM and UMAC.
			The following object identifiers identify a specific MAC.
			id-hmac-sha1 OBJECT IDENTIFIER ::= {
			iso(1) identified-organization(3) dod(6)
			internet(1) security(5) mechanisms(5) 8 1 2 }
			id-hmac-sha224 OBJECT IDENTIFIER ::= {id-hmac 8}
			id-hmac-sha256 OBJECT IDENTIFIER ::= {id-hmac 9}
			id-hmac-sha384 OBJECT IDENTIFIER ::= {id-hmac 10}
			id-hmac-sha512 OBJECT IDENTIFIER ::= {id-hamc 11}
			where id-hmac is to be determined.
	2.5 Key Confirmation Methods		2.5 Key Confirmation Methods
	<<< To be added. Unilateral, bilateral, etc.>>>		<<< To be added. Unilateral, bilateral, etc.>>>
	3 Elliptic Curve Domain Parameters		3 Elliptic Curve Domain Parameters
	Elliptic curve domain parameters include the elliptic curve group		Elliptic curve domain parameters include the elliptic curve group
	used, as well as a particular element of this group, called base		used, as well as a particular element of this group, called base
	point or generator, and further includes the way the finite field		point or generator, and further includes the way the finite field
	skipping to change at page 12, line 16 ¶		skipping to change at page 13, line 37 ¶
	parameters field of the algorithm identifier:		parameters field of the algorithm identifier:
	ecdsa-with-Specified OBJECT IDENTIFIER ::= {		ecdsa-with-Specified OBJECT IDENTIFIER ::= {
	id-ecSigType specified(3) }		id-ecSigType specified(3) }
	The following new object identifiers directly identify the hash		The following new object identifiers directly identify the hash
	function to be used for message digesting.		function to be used for message digesting.
	ecdsa-with-Sha224 OBJECT IDENTIFIER ::=		ecdsa-with-Sha224 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 1 }		{ id-ecSigType specified(3) 1 }
	ecdsa-with-Sha256 OBJECT IDENTIFIER ::=		ecdsa-with-Sha256 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 2 }		{ id-ecSigType specified(3) 2 }
	ecdsa-with-Sha384 OBJECT IDENTIFIER ::=		ecdsa-with-Sha384 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 3 }		{ id-ecSigType specified(3) 3 }
	ecdsa-with-Sha512 OBJECT IDENTIFIER ::=		ecdsa-with-Sha512 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 4 }		{ id-ecSigType specified(3) 4 }
	The following information object set helps specify the legal set of		The following information object set helps specify the legal set of
	algorithm identifiers for ECDSA.		algorithm identifiers for ECDSA.
	ECDSAAlgorithmSet ALGORITHM ::= {		ECDSAAlgorithmSet ALGORITHM ::= {
	{OID ecdsa-with-SHA1} |		{OID ecdsa-with-Sha1} |
	{OID ecdsa-with-SHA1 PARMS NULL} |		{OID ecdsa-with-Sha1 PARMS NULL} |
	{OID ecdsa-with-Recommended} |		{OID ecdsa-with-Recommended} |
	{OID ecdsa-with-Recommended PARMS NULL} |		{OID ecdsa-with-Recommended PARMS NULL} |
	{OID ecdsa-with-Specified PARMS HashAlgorithm } |		{OID ecdsa-with-Specified PARMS HashAlgorithm } |
	{OID ecdsa-with-Sha224} |		{OID ecdsa-with-Sha224} |
	{OID ecdsa-with-Sha256} |		{OID ecdsa-with-Sha256} |
	{OID ecdsa-with-Sha384} |		{OID ecdsa-with-Sha384} |
	{OID ecdsa-with-Sha512} ,		{OID ecdsa-with-Sha512} ,
	... -- More algorithms need to be added		... -- More algorithms need to be added
	}		}
	skipping to change at page 14, line 23 ¶		skipping to change at page 16, line 8 ¶
	In the Full and 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV)		In the Full and 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV)
	key agreement schemes, both the initiator and responder have static		key agreement schemes, both the initiator and responder have static
	EC public keys, typically in certificates, and the initiator sends		EC public keys, typically in certificates, and the initiator sends
	an ephemeral EC public key to the responder. In Full ECMQV,		an ephemeral EC public key to the responder. In Full ECMQV,
	the responder sends the initiator an ephemeral EC public key, but		the responder sends the initiator an ephemeral EC public key, but
	in 1-Pass ECMQV the sender does not.		in 1-Pass ECMQV the sender does not.
	The following object identifiers from ANSI X9.63 identify the		The following object identifiers from ANSI X9.63 identify the
	mqvSinglePass-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 16}		mqvSinglePass-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 16}
	mqvSinglePass-recommendedKDF OBJECT IDENTIFIER ::= {secg-scheme 3}		mqvSinglePass-recommendedKDF OBJECT IDENTIFIER ::= {secg-scheme 3}
	mqvSinglePass-specifiedKDF OBJECT IDENTIFIER ::= {secg-scheme 4}		mqvSinglePass-specifiedKDF OBJECT IDENTIFIER ::= {secg-scheme 4}
	mqvFull-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 17}		mqvFull-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 17}
	mqvFull-recommendedKDF OBJECT IDENTIFIER ::= {secg-scheme 5}		mqvFull-recommendedKDF OBJECT IDENTIFIER ::= {secg-scheme 5}
	mqvFull-specifiedKDF OBJECT IDENTIFIER ::= {secg-scheme 6}		mqvFull-specifiedKDF OBJECT IDENTIFIER ::= {secg-scheme 6}
	The following information object set helps specify the legal set of		The following information object set helps specify the legal set of
	algorithm identifiers for ECMQV.		algorithm identifiers for ECMQV.
	ECMQVAlgorithmSet ALGORITHM ::= {		ECMQVAlgorithmSet ALGORITHM ::= {
	{OID mqvSinglePass-sha1kdf} |		{OID mqvSinglePass-sha1kdf} |
	{OID mqvSinglePass-recommendedKDF} |		{OID mqvSinglePass-recommendedKDF} |
	{OID mqvSinglePass-specifiedKDF PARMS KeyDerivationFunction} |		{OID mqvSinglePass-specifiedKDF PARMS KeyDerivationFunction} |
	{OID mqvFull-sha1kdf} |		{OID mqvFull-sha1kdf} |
	{OID mqvFull-recommendedKDF} |		{OID mqvFull-recommendedKDF} |
	{OID mqvFull-specifiedKDF PARMS KeyDerivationFunction} ,		{OID mqvFull-specifiedKDF PARMS KeyDerivationFunction} ,
	... -- Future combinations may be added		... -- Future combinations may be added
	}		}
	The following type is the constrained AlgorithmIdentifier {} that		The following type is the constrained AlgorithmIdentifier {} that
	legally identifies 1-Pass and Full ECMQV:		legally identifies 1-Pass and Full ECMQV:
	ECMQVAlgorithm ::= AlgorithmIdentifier {{ECMQVAlgorithmSet}}		ECMQVAlgorithm ::= AlgorithmIdentifier {{ECMQVAlgorithmSet}}
			i
	4.3 ECC Algorithm Set		4.3 ECC Algorithm Set
	The following information object set helps specify a legal set of		The following information object set helps specify a legal set of
	ECC algorithms.		ECC algorithms.
	ECCAlgorithmSet ALGORITHM ::= {		ECCAlgorithmSet ALGORITHM ::= {
	ECDSAAlgorithmSet |		ECDSAAlgorithmSet |
	ECDHAlgorithmSet |		ECDHAlgorithmSet |
	ECMQVAlgorithmSet ,		ECMQVAlgorithmSet ,
	... -- Future combinations may be added		... -- Future combinations may be added
	skipping to change at page 18, line 7 ¶		skipping to change at page 19, line 30 ¶
	value becomes the most significant bit of the BIT STRING value, and		value becomes the most significant bit of the BIT STRING value, and
	so on; the least significant bit of the OCTET STRING becomes the		so on; the least significant bit of the OCTET STRING becomes the
	least significant bit of the BIT STRING.		least significant bit of the BIT STRING.
	5.2 Private Keys		5.2 Private Keys
	<<< To be added. Perhaps unnecessary for PKIX. >>>		<<< To be added. Perhaps unnecessary for PKIX. >>>
	6 ASN.1 Module(s)		6 ASN.1 Module(s)
	This module is extracted verbatim from a draft standard [DSEC1-v1.5],		<<< To be added, once ASN.1 decided. >>>
	and is subject to revision.
	DEFINITIONS EXPLICIT TAGS ::= BEGIN
	--
	-- EXPORTS ALL;
	--
	FieldID { FIELD-ID:IOSet } ::= SEQUENCE { -- Finite field
	fieldType FIELD-ID.&id({IOSet}),
	parameters FIELD-ID.&Type({IOSet}{@fieldType})
	}
	FIELD-ID ::= TYPE-IDENTIFIER
	FieldTypes FIELD-ID ::= {
	{ Prime-p IDENTIFIED BY prime-field } |
	{ Characteristic-two IDENTIFIED BY characteristic-two-field }
	}
	prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 }
	Prime-p ::= INTEGER -- Field of size p.
	id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1)}
	ansi-X9-62 OBJECT IDENTIFIER ::= {
	iso(1) member-body(2) us(840) 10045
	}
	characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }
	Characteristic-two ::= SEQUENCE {
	m INTEGER, -- Field size 2^m
	basis CHARACTERISTIC-TWO.&id({BasisTypes}),
	parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis})
	}
	CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER
	BasisTypes CHARACTERISTIC-TWO::= {
	{ NULL IDENTIFIED BY gnBasis } |
	{ Trinomial IDENTIFIED BY tpBasis } |
	{ Pentanomial IDENTIFIED BY ppBasis },
	...
	}
	gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 }
	tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 }
	ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }
	id-characteristic-two-basis OBJECT IDENTIFIER ::= {
	characteristic-two-field basisType(3)
	}
	Trinomial ::= INTEGER
	Pentanomial ::= SEQUENCE {
	k1 INTEGER, -- k1 > 0
	k2 INTEGER, -- k2 > k1
	k3 INTEGER -- k3 > k2
	}
	FieldElement ::= OCTET STRING
	ECDomainParameters{ECDOMAIN:IOSet} ::= CHOICE {
	specified SpecifiedECDomain,
	named ECDOMAIN.&id({IOSet}),
	implicitCA NULL
	}
	SpecifiedECDomain ::= SEQUENCE {
	version SpecifiedECDomainVersion(ecdpVer1 | ecdpVer2 |
	ecdpVer3, ...),
	fieldID FieldID {{FieldTypes}},
	curve Curve,
	base ECPoint,
	order INTEGER,
	cofactor INTEGER OPTIONAL,
	hash HashAlgorithm OPTIONAL,
	...
	}
	SpecifiedECDomainVersion ::= INTEGER {
	ecdpVer1(1),
	ecdpVer2(2),
	ecdpVer3(3)
	}
	Curve ::= SEQUENCE {
	a FieldElement,
	b FieldElement,
	seed BIT STRING OPTIONAL
	-- Shall be present if used in SpecifiedECDomain with
	-- version equal to ecdpVer2 or ecdpVer3
	}
	ECPoint ::= OCTET STRING
	ECDOMAIN ::= CLASS {
	&id OBJECT IDENTIFIER UNIQUE
	}
	WITH SYNTAX { ID &id }
	SECGCurveNames ECDOMAIN::= {
	... -- named curves
	}
	HashAlgorithm ::= AlgorithmIdentifier {{ HashFunctions }}
	HashFunctions ALGORITHM ::= {
	{OID sha-1} | {OID sha-1 PARMS NULL } |
	{OID id-sha224} | {OID id-sha224 PARMS NULL } |
	{OID id-sha256} | {OID id-sha256 PARMS NULL } |
	{OID id-sha384} | {OID id-sha384 PARMS NULL } |
	{OID id-sha512} | {OID id-sha512 PARMS NULL } ,
	... -- Additional hash functions may be added in the future
	}
	sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
	oiw(14) secsig(3) algorithm(2) 26}
	id-sha OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
	organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) }
	id-sha224 OBJECT IDENTIFIER ::= { id-sha 4 }
	id-sha256 OBJECT IDENTIFIER ::= { id-sha 1 }
	id-sha384 OBJECT IDENTIFIER ::= { id-sha 2 }
	id-sha512 OBJECT IDENTIFIER ::= { id-sha 3 }
	SubjectPublicKeyInfo ::= SEQUENCE {
	algorithm AlgorithmIdentifier {{ECPKAlgorithms}},
	subjectPublicKey BIT STRING
	}
	AlgorithmIdentifier{ ALGORITHM:IOSet } ::= SEQUENCE {
	algorithm ALGORITHM.&id({IOSet}),
	parameters ALGORITHM.&Type({IOSet}{@algorithm})
	}
	ALGORITHM ::= CLASS {
	&id OBJECT IDENTIFIER UNIQUE,
	&Type OPTIONAL
	}
	WITH SYNTAX { OID &id [PARMS &Type] }
	ECPKAlgorithms ALGORITHM ::= {
	ecPublicKeyType |
	ecPublicKeyTypeRestricted |
	ecPublicKeyTypeSupplemented ,
	...
	}
	ecPublicKeyType ALGORITHM ::= {
	OID id-ecPublicKey PARMS ECDomainParameters {{SECGCurveNames}}
	}
	id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }
	id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) }
	ecPublicKeyTypeRestricted ALGORITHM ::= {
	OID id-ecPublicKeyTypeRestricted PARMS ECPKRestrictions
	}
	id-ecPublicKeyTypeRestricted OBJECT IDENTIFIER ::= {
	id-publicKeyType restricted(2) }
	ECPKRestrictions ::= SEQUENCE {
	ecDomain ECDomainParameters {{ SECGCurveNames }},
	eccAlgorithms ECCAlgorithms
	}
	ECCAlgorithms ::= SEQUENCE OF ECCAlgorithm
	ECCAlgorithm ::= AlgorithmIdentifier {{ECCAlgorithmSet}}
	ecPublicKeyTypeSupplemented ALGORITHM ::= {
	OID id-ecPublicKeyTypeSupplemented PARMS ECPKSupplements
	}
	id-ecPublicKeyTypeSupplemented OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) certicom(132) schemes(1) supplementalPoints(0)}
	ECPKSupplements ::= SEQUENCE {
	ecDomain ECDomainParameters {{ SECGCurveNames }},
	eccAlgorithms ECCAlgorithms,
	eccSupplements ECCSupplements
	}
	ECCSupplements ::= CHOICE {
	namedMultiples [0] NamedMultiples,
	specifiedMultiples [1] SpecifiedMultiples
	}
	NamedMultiples ::= SEQUENCE {
	multiples OBJECT IDENTIFIER,
	points SEQUENCE OF ECPoint
	}
	SpecifiedMultiples ::= SEQUENCE OF SEQUENCE {
	multiple INTEGER,
	point ECPoint
	}
	ECPrivateKey ::= SEQUENCE {
	version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
	privateKey OCTET STRING,
	parameters [0] ECDomainParameters {{ SECGCurveNames }} OPTIONAL,
	publicKey [1] BIT STRING OPTIONAL
	}
	ecdsa-with-SHA1 OBJECT IDENTIFIER ::=
	{ id-ecSigType sha1(1)}
	ecdsa-with-Recommended OBJECT IDENTIFIER ::=
	{ id-ecSigType recommended(2) }
	ecdsa-with-Specified OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3)}
	ecdsa-with-Sha224 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 1 }
	ecdsa-with-Sha256 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 2 }
	ecdsa-with-Sha384 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 3 }
	ecdsa-with-Sha512 OBJECT IDENTIFIER ::=
	{ id-ecSigType specified(3) 4 }
	id-ecSigType OBJECT IDENTIFIER ::= { ansi-X9-62 signatures(4) }
	ECDSAAlgorithmSet ALGORITHM ::= {
	{OID ecdsa-with-SHA1} |
	{OID ecdsa-with-SHA1 PARMS NULL} |
	{OID ecdsa-with-Recommended} |
	{OID ecdsa-with-Recommended PARMS NULL} |
	{OID ecdsa-with-Specified PARMS HashAlgorithm } |
	{OID ecdsa-with-Sha224} |
	{OID ecdsa-with-Sha256} |
	{OID ecdsa-with-Sha384} |
	{OID ecdsa-with-Sha512} ,
	... -- More algorithms need to be added
	}
	ECCAlgorithmSet ALGORITHM ::= {
	ECDSAAlgorithmSet |
	ECDHAlgorithmSet |
	ECMQVAlgorithmSet |
	ECIESAlgorithmSet |
	ECWKTAlgorithmSet ,
	...
	}
	ECDHAlgorithmSet ALGORITHM ::= {
	{OID dhSinglePass-stdDH-sha1kdf} |
	{OID dhSinglePass-stdDH-sha1kdf PARMS NULL} |
	{OID dhSinglePass-cofactorDH-sha1kdf} |
	{OID dhSinglePass-cofactorDH-sha1kdf PARMS NULL} |
	{OID dhSinglePass-cofactorDH-recommendedKDF} |
	{OID dhSinglePass-cofactorDH-specifiedKDF
	PARMS KeyDerivationFunction} ,
	... -- Future combinations may be added
	}
	ECMQVAlgorithmSet ALGORITHM ::= {
	{OID mqvSinglePass-sha1kdf} |
	{OID mqvSinglePass-recommendedKDF} |
	{OID mqvSinglePass-specifiedKDF PARMS KeyDerivationFunction} |
	{OID mqvFull-sha1kdf} |
	{OID mqvFull-recommendedKDF} |
	{OID mqvFull-specifiedKDF PARMS KeyDerivationFunction} ,
	... -- Future combinations may be added
	}
	x9-63-scheme OBJECT IDENTIFIER ::= { iso(1) member-body(2)
	us(840) ansi-x9-63(63) schemes(0) }
	secg-scheme OBJECT IDENTIFIER ::= { iso(1)
	identified-organization(3) certicom(132) schemes(1) }
	dhSinglePass-stdDH-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 2}
	dhSinglePass-cofactorDH-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 3}
	mqvSinglePass-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 16}
	mqvFull-sha1kdf OBJECT IDENTIFIER ::= {x9-63-scheme 17}
	dhSinglePass-cofactorDH-recommendedKDF OBJECT IDENTIFIER ::=
	{secg-scheme 1}
	dhSinglePass-cofactorDH-specifiedKDF OBJECT IDENTIFIER ::=
	{secg-scheme 2}
	mqvSinglePass-recommendedKDF OBJECT IDENTIFIER ::= {secg-scheme 3}
	mqvSinglePass-specifiedKDF OBJECT IDENTIFIER ::= {secg-scheme 4}
	mqvFull-recommendedKDF OBJECT IDENTIFIER ::= {secg-scheme 5}
	mqvFull-specifiedKDF OBJECT IDENTIFIER ::= {secg-scheme 6}
	KeyDerivationFunction ::= HashAlgorithm
	ECDSA-Sig-Value ::= SEQUENCE {
	r INTEGER,
	s INTEGER
	}
	END
	7 References		7 References
	[FIPS 180-2] U.S. Department of Commerce/National Institute of		[FIPS 180-2] U.S. Department of Commerce/National Institute of
	Standards and Technology. Secure Hash Standard (SHS), FIPS		Standards and Technology. Secure Hash Standard (SHS), FIPS
	PUB 180-2, (http://csrc.nist.gov/fips/fips180-2.pdf)		PUB 180-2, Change Notice 1,
			http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
	[FIPS 186-2] U.S. Department of Commerce/National Institute of		[FIPS 186-2] U.S. Department of Commerce/National Institute of
	Standards and Technology. Digital Signature Standard (DSS), FIPS		Standards and Technology. Digital Signature Standard (DSS), FIPS
	PUB 186-2, January 2000.		PUB 186-2, January 2000.
	(http://csrc.nist.gov/fips/fips186-2.pdf)		http://csrc.nist.gov/publications/fips/fips186-2/fips186-2-change1.pdf
	[RFC 3279] W. Polk, R. Housley and L. Bassham. Algorithms and		[RFC 3279] W. Polk, R. Housley and L. Bassham. Algorithms and
	Identifiers for the Internet X.509 Public Key Infrastructure		Identifiers for the Internet X.509 Public Key Infrastructure
	Certificate and Certificate Revocation List (CRL) Profile, April		Certificate and Certificate Revocation List (CRL) Profile, April
	2002.		2002.
	[RFC 3278] S. Blake-Wilson, D. Brown and P. Lambert. Use of ECC		[RFC 3278] S. Blake-Wilson, D. Brown, and P. Lambert. Use of ECC
	Algorithms in CMS, April 2002.		Algorithms in CMS, April 2002.
	[SEC1v1] Standards for Efficient Cryptography Group. SEC 1 - Elliptic		[SEC1v1] Standards for Efficient Cryptography Group. SEC 1 - Elliptic
	Curve Cryptography, Version 1.0. September,		Curve Cryptography, Version 1.0. September,
	2000. (http://www.secg.org)		2000. (http://www.secg.org)
	[DSEC1-v1.5] Standards for Efficient Cryptography Group. SEC 1 -		[DSEC1-v1.5] Standards for Efficient Cryptography Group. SEC 1 -
	Elliptic Curve Cryptography, Draft Version 1.5. February,		Elliptic Curve Cryptography, Draft Version 1.5. February,
	2005. (http://www.secg.org)		2005. (http://www.secg.org)
	[SEC2] Standards for Efficient Cryptography Group. SEC 2 -		[SEC2] Standards for Efficient Cryptography Group. SEC 2 -
	Recommended Elliptic Curve Domain Parameters, Version		Recommended Elliptic Curve Domain Parameters, Version
	1.0. September, 2000. (http://www.secg.org)		1.0. September, 2000. (http://www.secg.org)
	[SP 800-56] NIST. Special Publication 800-56, Key Establishment		[SP 800-56] E. Barker, D. Johnson, and M. SmidNIST Special
	Schemes, 2003.		Publication 800-56A, Recommendation for Pair-Wise Key
			Establishment Schemes Using Discrete Logarithm
			Cryptography. March, 2006.
	[X9.62] American National Standard for Financial Services. ANSI		[X9.62] American National Standard for Financial Services. ANSI
	X9.62-2005, Public Key Cryptography for the Financial Services		X9.62-2005, Public Key Cryptography for the Financial Services
	Industry: The Elliptic Curve Digital Signature Algorithm. 1998.		Industry: The Elliptic Curve Digital Signature Algorithm.
			November, 2005.
	[X9.63] American National Standard for Financial Services. ANSI		[X9.63] American National Standard for Financial Services. ANSI
	X9.63-2001, Public Key Cryptography for the Financial Services		X9.63-2001, Public Key Cryptography for the Financial Services
	Industry: Key Agreement and Key Transport using Elliptic Curve		Industry: Key Agreement and Key Transport using Elliptic Curve
	Cryptography. November 2001.		Cryptography. November, 2001.
	8 Security Considerations		8 Security Considerations
	<<< To be added later. >>>		<<< To be added later. >>>
	9 Acknowledgments		9 Acknowledgments
	To be added later.		To be added later.
	10 Authors' Addresses		10 Authors' Addresses
End of changes. 36 change blocks.
	293 lines changed or deleted		150 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/