PKIX Working Group Daniel R. L. Brown, INTERNET-DRAFT Certicom Corp. Expires November 2004 July 2004 Additional Algorithms and Identifiers for use of Elliptic Curve Cryptography with PKIX Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts may be found at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories may be found at http://www.ietf.org/shadow.html. Abstract This document gives additional algorithms and associated ASN.1 identifiers for elliptic curve cryptography (ECC) used with the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (PKIX). The algorithms and identifiers here are consistent with both ANSI X9.62-1998 and X9.63-2001, and shall be consistent with the forthcoming revisions of these documents. Consistency shall also be maintained with SEC1 and SEC2, and any revisions or successors of such documents. Brown [Page 1] INTERNET-DRAFT Additional ECC for PKIX July 2004 Table of Contents 1 Introduction ............................................... 3 1.1 Terminology ........................................... 3 1.2 Ellipitic Curve Cryptography .......................... 3 1.3 Algorithm Identifiers ................................. 4 2 Auxiliary Functions ........................................ 4 2.1 Hash Functions ........................................ 5 2.2 Key Derivation Functions .............................. 6 2.3 Key Wrap Functions .................................... 7 2.4 Message Authentication Codes .......................... 7 2.5 Key Confirmation Methods ... .......................... 7 3 Elliptic Curve Domain Parameters ........................... 8 4 ECC Algorithms ............................................ 10 4.1 Signature Schemes .................................... 11 4.1.1 ECDSA ........................................... 11 4.2 Key Agreement Schemes ................................ 13 4.2.1 1-Pass ECDH ..................................... 13 4.2.2 Full and 1-Pass ECMQV ........................... 14 4.3 ECC Algorithm Set .................................... 15 5 ECC Keys .................................................. 16 5.1 Public Keys .......................................... 16 5.2 Private Keys ......................................... 17 6 ASN.1 Module .............................................. 18 7 References ................................................ 20 8 Security Considerations ................................... 20 9 Intellectual Property Rights .............................. 21 10 Acknowledgments ........................................... 21 11 Authors' Addresses ........................................ 21 12 Full Copyright Statement .................................. 22 Brown [Page 2] INTERNET-DRAFT Additional ECC for PKIX July 2004 1 Introduction This document supplements [RFC 3279], "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile " This document specifies supplementary algorithm identifiers and ASN.1 [X.680] encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKIX). The supplementary formats specified are used to indicate the auxiliary functions, such as the new hash functions specified in [FIPS 180-2] including SHA-256, that are to be used with elliptic curve public keys. Furthermore, this document specifies formats to indicate that an elliptic curve public key is to be restricted for use with a an indicated set of elliptic curve cryptography algorithms. Note: Previous standards [X9.62], [X9.63] and [SEC1] suggested that the extended key usage field could be used for purposes above. Because such a practice was regarded as improper, a new means to accomplish the objectives is being introduced both in this document and revisions of the standards above. 1.1 Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 1.2 Ellipitic Curve Cryptography Elliptic Curve Cryptography (ECC) is a family of cryptographic algorithms. Several algorithms, such as Diffie-Hellman (DH) key agreement and the Digital Signature Algorithm (DSA), have analogues in ECC. The analogy is that the cryptographic group is an elliptic curve group over a finite field rather the multiplicative group of (invertible) integers modulo a large prime. Because an ECC groups and its elements are different from DH and DSA groups and elements, ECC requires a slightly different syntax from DSA and DH. Because a single ECC public key in a certificated might potentially be used for multiple different ECC algorithms, a mechanism for indicating algorithm usage is important. Brown [Page 3] INTERNET-DRAFT Additional ECC for PKIX July 2004 1.3 Algorithm Identifiers The parameters field of the ASN.1 type AlgorithmIdentifier is optional when using ECC. When the parameters field is not used meaningfully, it SHOULD be absent, but MAY be NULL if it is necessary to interoperate with legacy implementaitons that do not support an optional parameters field. Absent and NULL parameters SHOULD both be accepted as valid and MUST then be considered to have the same meaning. The following ASN.1 information object class helps to parameterize the AlgorithmIdentifier type with sets of legal values. ALGORITHM ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } WITH SYNTAX { OID &id [PARMS &Type] } The type AlgorithmIdentifier is parameterized to allow legal sets of values to be specified by constraining the type with an information object set. AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE { algorithm ALGORITHM.&id({IOSet}), parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL } In practice, AlgorithmIdentifier is a sequence of an OID and an optional second field with syntax depending on the OID. In this document, the use of AlgorithmIdentifier will be constrained form. For example, when a hash function needs to be identified, a constrained form of AlgorithmIdentifier is used that only permits the OIDs for hash functions. The constraints also dictate the syntax for the the parameters field for a given OID. Note: Older syntax for AlgorithmIdentifier had a mandatory parameters field, which was customarily set to NULL when parameters field had nothing to convey. However, in the new syntax, in such situations the abset parameters are preferred to NULL parameters when the paremeters field does not carry any meaning. This document specifies exactly what is permitted in the parameters field. Brown [Page 4] INTERNET-DRAFT Additional ECC for PKIX July 2004 2 Auxiliary Functions A number of different auxiliary functions are used in ECC. When two entities use an ECC algorithm in their communications with each other, they need to use matching auxiliary functions in order to successfully interoperate. Standards for ECC generally recommend or require certain choices of auxiliary functions, usually according to the elliptic curve key size in use. The following syntax helps to indicate, if needed, which auxiliary functions are to be used. 2.1 Hash Functions Most notable among the auxiliary functions are hash functions, which are used in several different ways: message digesting for signatures, verifiably random domain parameter generation, building key derivation functions, building message authentication codes, as well as building random number generators. The hash functions that can be used with ECC are SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512. They are specified in FIPS 180-2, Change Notice. Hash functions are identified with the following object identifiers. sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) sha1(26) } id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } Brown [Page 5] INTERNET-DRAFT Additional ECC for PKIX July 2004 The following information object set is used to constrain the AlgorithmIdentifer type for hash functions. 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 hashes may be added } The constrained AlgorithmIdentifier syntax to identify a hash function is: HashAlgorithm ::= AlgorithmIdentifer {{HashFunctions}} The parameters SHOULD be absent but MAY be NULL. 2.2 Key Derivation Functions <<< Rough version, only. Anticipate using a more flexible syntax in next update of this draft ... >>> Crucial to key establishment, a Key Derivation Function (KDF) takes input of a raw elliptic curve point and other information such as identifiers, and then derives a key. A KDF helps to eliminate any structure from the key. (Elliptic curve points generally have some structure and cannot be regarded as pseudorandom.) The KDF to use with ECC is specified in X9.63, except that the hash function SHA-1 can be replaced by one of SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512. In particular, the KDF is determined entirely by the hash function it is built from, so the following syntax is adopted. KeyDerivationFunction ::= HashAlgorithm That certain protocols might use a different KDF, such as KDF1 in IEEE 1363-2000, only means that the specifications here are overridden in these protocols. Such KDFs ought to be deprecated. No ASN.1 syntax is given here to support such KDFs, making protocols that use such KDFs provide their own mechanisms to indicate use of them. Brown [Page 6] INTERNET-DRAFT Additional ECC for PKIX July 2004 2.3 Key Wrap Functions <<< To be added.>>> Key wrap functions can be used to transform a key agreement scheme into a key transport scheme. 2.4 Message Authentication Codes Some ECC algorithms use a Message Authentication Code (MAC), for example, as part of key confirmation. <<< Surely these exist somewhere >>> 2.5 Key Confirmation Methods <<< To be added. Unilateral, bilateral, etc.>>> Brown [Page 7] INTERNET-DRAFT Additional ECC for PKIX July 2004 3 Elliptic Curve Domain Parameters Elliptic curve domain parameters include the elliptic curve group used, as well as a particular element of this group, called base point or generator, and further includes the way the finite field elements in the elliptic curve poins are represented. Elliptic domain parameters usually include further information such as order of the base point, a number called the cofactor, a value called seed which is used to select the curve, and possibly the base point, verifiably at random. Verifiably random domain parameters require an auxiliary hash function. A few changes to elliptic curve domain parameters as originally specified in ANSI X9.62-1998 and ANSI X9.63-2001 mean that the corresponding ASN.1 syntax needs the following revisions. The ASN.1 syntax to represent finite field elements and elliptic curve points remains unchanged. The following new ASN.1 type provides the version numbers for explicitly specifying elliptic curve (EC) domain parameters. SpecifiedECDomainVersion ::= INTEGER { ecdpVer1(1), ecdpVer2(2), ecdpVer3(3) } The ASN.1 type for identifying an elliptic curve remains the same except the presence of its optional field is governed by the version number above. Curve ::= SEQUENCE { a FieldElement, b FieldElement, seed BIT STRING OPTIONAL } The ASN.1 type for specifying EC domain paramters has been revised to include a field to identify the hash function used to generate the elliptic domain paramters verifiably at random, as follows. SpecifiedECDomain ::= SEQUENCE { version SpecifiedECDomainVersion ( ecdpVer1 | ecdpVer2 | ecdpVer3 ), fieldID FieldID {{FieldTypes}}, curve Curve, base ECPoint, order INTEGER, cofactor INTEGER OPTIONAL, hash HashAlgorithm OPTIONAL -- New field } Brown [Page 8] INTERNET-DRAFT Additional ECC for PKIX July 2004 A version value of ecdpVer1 is used when either the domain parameters are not verifiably random or when the curve (not the base point) is verfiably random (from curve.seed). A version value of ecdpVer2 is used wehn the curve and the base point are both verifiably random (derived from curve.seed). A version value of ecdpVer3 is used when the base point, but not the curve, is verifiably random (derived from curve.seed). If the hash is omitted then, the hash algorithm to be used is SHA-1. The object identifiers for NIST recommended curves extend the object identifiers primeCurve and secgCurve whose values are primeCurve OBJECT IDENTIFER ::= { iso(1) member-body(2) us(840) 10045 curves(3) prime(1) } secgCurve OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) } The values of the object identifiers for the fifteen NIST recommended curves are ansip192r1 OBJECT IDENTIFIER ::= { primeCurve 1 } ansit163k1 OBJECT IDENTIFIER ::= { secgCurve 1 } ansit163r2 OBJECT IDENTIFIER ::= { secgCurve 15 } ansip224r1 OBJECT IDENTIFIER ::= { secgCurve 33 } ansit233k1 OBJECT IDENTIFIER ::= { secgCurve 26 } ansit233r1 OBJECT IDENTIFIER ::= { secgCurve 27 } ansip256r1 OBJECT IDENTIFIER ::= { primeCurve 7 } ansit283k1 OBJECT IDENTIFIER ::= { secgCurve 16 } ansit283r1 OBJECT IDENTIFIER ::= { secgCurve 17 } ansip384r1 OBJECT IDENTIFIER ::= { secgCurve 34 } ansit409k1 OBJECT IDENTIFIER ::= { secgCurve 36 } ansit409r1 OBJECT IDENTIFIER ::= { secgCurve 37 } ansip521r1 OBJECT IDENTIFIER ::= { secgCurve 35 } ansit571k1 OBJECT IDENTIFIER ::= { secgCurve 38 } ansit571r1 OBJECT IDENTIFIER ::= { secgCurve 39 } Brown [Page 9] INTERNET-DRAFT Additional ECC for PKIX July 2004 The following information object class helps to constrain an field below to identify only a certain EC domain parameters. ECDOMAIN ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { ID &id } The following information object set is used to constrain an AlgorithmIdentifer for identifying EC domain parameters. ANSINamedECDomains ECDOMAIN ::= { { ID ansip192r1 } | { ID ansit163k1 } | { ID ansit163r2 } | { ID ansip224r1 } | { ID ansit233k1 } | { ID ansit233r1 } | { ID ansip256r1 } | { ID ansit283k1 } | { ID ansit283r1 } | { ID ansip384r1 } | { ID ansit409k1 } | { ID ansit409r1 } | { ID ansip521r1 } | { ID ansit571k1 } | { ID ansit571r1 } , ... -- Additional EC domain parameters may be added } The ASN.1 type for specifying elliptic curve domain parameters, whether explicitly, by name, or implicitly, is slightly revised as follows. ECDomainParmaters ::= CHOICE { specified SpecifiedECDomain, named ECDOMAIN.&id({ANSINamedECDomains}), implcitCA NULL } Brown [Page 10] INTERNET-DRAFT Additional ECC for PKIX July 2004 4 ECC Algorithms ECC algorithms can be identified using algorithm identifiers, in places such as PKIX certificates (and also in CMS). In the new syntax here, the parameters field of these algorithm identifiers sometimes identifies the auxiliary functions. 4.1 Signature Schemes 4.1.1 ECDSA To identify use of ECDSA with ASN.1, the auxiliary hash function for computing the message digest is necessary, which shall be implicit from the object identifeir for ECDSA, and possibly as well as the corresponding public key, or shall be explicitly given in the parameters field, as detailed below. The following object identifier serves as the root for further object identifier in this section. id-ecSigType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 signatures(4) } The following object identifier identifies SHA1 to be used for message digesting: ecdsa-with-Sha1 OBJECT IDENTIFIER ::= { id-ecSigType sha1(1) } The following new object identifier identifies the hash function to be used for message digesting is the one recommended for the public key size: ecdsa-with-Recommended OBJECT IDENTIFIER ::= { id-ecSigType recommended(2) } The recommended hash functions are given in the draft revision of X9.62, and is determined as follows. Among the hash functions SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, the recommended one has the largest bit size that does not require bit truncation during the signing process. Bit truncation occurs the hash output bit length is greater than the bit length of n, the order of the base point G. (Note: even if bit trunctation does not occur, modular reduction can occur.) Brown [Page 11] INTERNET-DRAFT Additional ECC for PKIX July 2004 The following new object identifier identifies the hash function to be used for message digesting is the one specified in the parameters field of the algorithm identifier: ecdsa-with-Specified OBJECT IDENTIFIER ::= { id-ecSigType specified(3) } The following information object set helps specify the legal set of algorithm identifiers for ECDSA. 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} , ... -- Future combinations may be added } The following type is the constrained AlgorithmIdentifier {} that identifies ECDSA: ECDSAAlgorithm ::= AlgorithmIdentifer {{ECDSAAlgorithmSet}} Brown [Page 12] INTERNET-DRAFT Additional ECC for PKIX July 2004 4.2 Key Agreement Schemes The standard [X9.63] and draft standard [SP 800-56] specify some ECC key agreement schemes. The standard [X9.63] also specifies some ASN.1 syntax, but this will be revised, as indicated below, in to accommodate the new hash functions. 4.2.1 1-Pass ECDH <<< In progress ... >>> In the 1-Pass Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme, the initiator sends an ephemeral EC public key to the responder who has a static EC public key, typcially in a certificate. The following object identifiers from ANSI X9.63 identify the use of 1-Pass ECDH: dhSinglePass-stdDH-sha1kdf OBJECT IDENTIFIER ::= {} dhSinglePass-stdDH-sha1kdf OBJECT IDENTIFIER ::= {} dhSinglePass-cofactorDH-sha1kdf OBJECT IDENTIFIER ::= {} dhSinglePass-cofactorDH-sha1kdf OBJECT IDENTIFIER ::= {} dhSinglePass-cofactorDH-recommendedKDF OBJECT IDENTIFIER ::= {} dhSinglePass-cofactorDH-specifiedKDF OBJECT IDENTIFIER ::= {} The following information object set helps specify the legal set of algorithm identifiers for ECDH. 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 } The following type is the constrained AlgorithmIdentifier {} that legally identifies 1-Pass ECDH: ECDHAlgorithm ::= AlgorithmIdentifer {{ECDHAlgorithmSet}} Brown [Page 13] INTERNET-DRAFT Additional ECC for PKIX July 2004 4.2.2 Full and 1-Pass ECMQV <<< In progress.>>> In the Full and 1-Pass Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement schemes, both the initiator and responder have static EC public keys, typically in certificates, and the initiator sends an ephemeral EC public key to the responder. In Full ECMQV, the responder sends the intiator an ephemeral EC publicc key, but in 1-Pass ECQMV the sender does not. The following object identifiers from ANSI X9.63 identify the mqvSinglePass-sha1kdf OBJECT IDENTIFIER ::= {} mqvSinglePass-recommendedKDF OBJECT IDENTIFIER ::= {} mqvSinglePass-specifiedKDF OBJECT IDENTIFIER ::= {} mqvFull-sha1kdf OBJECT IDENTIFIER ::= {} mqvFull-recommendedKDF OBJECT IDENTIFIER ::= {} mqvFull-specifiedKDF OBJECT IDENTIFIER ::= {} The following information object set helps specify the legal set of algorithm identifiers for ECMQV. 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 } The following type is the constrained AlgorithmIdentifier {} that legally identifies 1-Pass and Full ECMQV: ECMQVAlgorithm ::= AlgorithmIdentifer {{ECMQVAlgorithmSet}} Brown [Page 14] INTERNET-DRAFT Additional ECC for PKIX July 2004 4.3 ECC Algorithm Set The following information object set helps specify a legal set of ECC algorithms. ECCAlgorithmSet ALGORITHM ::= { ECDSAAlgorithmSet | ECDHAlgorithmSet | ECMQVAlgorithmSet , ... -- Future combinations may be added } The following type is the constrained AlgorithmIdentifier {} that legally identifies an ECC algorithm: ECCAlgorithm ::= AlgorithmIdentifer {{ECCAlgorithmSet}} The following type permits a sequence of ECC algorithm identifier to given. ECCAlgorithms ::= SEQUENCE OF ECCAlgorithm The order of the sequence SHOULD indicate an order of preference for which algorithm to used, where appropriate. Brown [Page 15] INTERNET-DRAFT Additional ECC for PKIX July 2004 5 ECC Keys Keys in ECC generally need to be associated with additional information such as domain parameters as well as, possibly, restrictions or preferrences on algorithms that key can be used with. 5.1 Public Keys Public keys are generally contained in certificates or stored in trusted memory, often in self-signed certificated format. Certificates are conveyed between parties or accessed from directories. For certificates containing elliptic curve subject public keys, or certificates signed with elliptic curve issuer public keys using ECDSA, it is often necessary to identify the particular ECC algorithms and elliptic curve domain parameters that are used. Certificates with ECC subject public keys can either restrict or not restrict the set of ECC algorithms with which they are used. Unrestricted public keys are identified by the following OID: id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 keyType(2) unrestricted(1) } This OID is used in an algorithm identifer as follows: ecPublicKeyType ALGORITHM ::= { OID id-ecPublicKey PARMS ECDomainParameters } The following new syntax identifies ECC subject keys restricted to a certain subset of ECC algorithms. Firstly, the following OID is used: id-ecPublicKeyRestricted OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 keyType(2) restricted(2) } The following new syntax permits both elliptic curve domain parameters and a sequence of algorithm restrictions to be associated with an ECC public key: ECPKRestrictions ::= SEQUENCE { ecDomain ECDomainParameters, eccAlgorithms ECCAlgorithms } Brown [Page 16] INTERNET-DRAFT Additional ECC for PKIX July 2004 The new OID and new type are used in an algorithm identifier as follows: ecPublicKeyTypeRestricted ALGORITHM ::= { OID id-ecPublicKeyRestricted PARMS ECPKRestrictions } The following information object set ECPKAlgorithmSet specifies the legal set of algorithm identifiers to identify an ECC public key: ECPKAlgorithmSet ::= { ecPublicKeyType | ecPublicKeyTypeRestricted , ... -- Further ECC public key types might be added } The following type uses the set above to constrain a algorithm identifer accordingly: ECPKAlgorithm ::= AlgorithmIdentifer {ECPKAlgorithmSet} In a PKIX certificate with an ECC subject public key, the SubjectPublicKeyInfo type shall use the following syntax: SubjectPublicKeyInfo ::= SEQUENCE { algorithm ECPKAlgorithm, subjectPublicKey BIT STRING } The elliptic curve public key (a value of type ECPoint which is an OCTET STRING) is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most signficant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. 5.2 Private Keys <<< To be added. Perhaps unnecessary for PKIX. >>> Brown [Page 17] INTERNET-DRAFT Additional ECC for PKIX July 2004 6 ASN.1 Module(s) <<< To be added. >>> Brown [Page 18] INTERNET-DRAFT Additional ECC for PKIX July 2004 <<< Temporary blank page >>> Brown [Page 19] INTERNET-DRAFT Additional ECC for PKIX July 2004 7 References [FIPS 180-2] U.S. Department of Commerce/National Institute of Standards and Technology. Secure Hash Standard (SHS), FIPS PUB 180-2, [? ? ? Auguest 2001 ? ? ?]. (http://csrc.nist.gov/fips/fips180-2.pdf) [FIPS 186-2] U.S. Department of Commerce/National Institute of Standards and Technology. Digital Signature Standard (DSS), FIPS PUB 186-2, January 2000. (http://csrc.nist.gov/fips/fips186-2.pdf) [RFC 3279] W. Polk, R. Housley and L. Bassham. Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. [RFC 3278] S. Blake-Wilson, D. Brown and P. Lambert. Use of ECC Algorithms in CMS, April 2002. [SEC2] Standards for Efficient Cryptography Group. SEC 2 - Recommended Elliptic Curve Domain Parameters. Working Draft Ver. 0.6., 1999. (http://www.secg.org) [SP 800-56] NIST. Special Publication 800-56, Key Establishment Schemes, 2003. [X9.62] American National Standard for Financial Services. ANSI X9.62-1998, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm. 1998. [X9.63] American National Standard for Financial Services. ANSI X9.63-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography. November 2001. 8 Security Considerations <<< To be added later. >>> Brown [Page 20] INTERNET-DRAFT Additional ECC for PKIX July 2004 9 Intellectual Property Rights The IETF has been notified of intellectual property rights claimed in regard to the specification contained in this document. For more information, consult the online list of claimed rights (http://www.ietf.org/ipr.html). The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. 10 Acknowledgments To be added later. 11 Authors' Addresses Authors: Daniel R. L. Brown Certicom Corp. dbrown@certicom.com Brown [Page 21] INTERNET-DRAFT Additional ECC for PKIX July 2004 12 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. In addition, the ASN.1 module presented in Section 6 may be used in whole or in part without inclusion of the copyright notice. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process shall be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Brown [Page 22]