PKIX Working Group Sean Turner, IECA Internet Draft Daniel Brown, Certicom Intended Status: Standard Track Kelvin Yiu, Microsoft Expires: July 2, 2008 Russ Housley, Vigil Security Tim Polk, NIST 22 January, 2008 Elliptic Curve Cryptography Subject Public Key Information draft-ietf-pkix-ecc-subpubkeyinfo-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 obsoleted 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 can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on July 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates [RFC3279]. Turner, et al. Expires July 22, 2008 [Page 1] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 Table of Contents 1. Introduction......................................... 2 1.1. Terminology..................................... 3 2. Subject Public Key Information Fields.................... 3 2.1. Elliptic Curve Public Key Algorithm Identifier......... 4 2.1.1. Unrestricted Identifiers and Parameters.......... 5 2.1.1.1. Named Curve............................. 5 2.1.1.2. Specified Curve.......................... 7 2.1.1.2.1. Specified Curve Version............... 8 2.1.1.2.2. Field Identifiers.................... 9 2.1.1.2.2.1. Prime-p........................ 9 2.1.1.2.2.2. Characteristic-two.............. 10 2.1.1.2.3. Curve............................. 12 2.1.1.2.4. Base.............................. 12 2.1.1.2.5. Hash.............................. 12 2.1.2. Restricted Algorithm Identifiers and Parameters... 14 2.2. Subject Public Key............................... 15 3. KeyUsage Bits....................................... 15 4. Security Considerations............................... 16 5. IANA Considerations.................................. 16 6. References......................................... 16 6.1. Normative References............................. 16 6.2. Informative References........................... 17 Appendix A. ASN.1 Module................................ 17 1. Introduction This document specifies the format of the subjectPublicKeyInfo field in X.509 certificates [RFC3280] that use Elliptic Curve Cryptography (ECC). This document specifies the encoding formats for public keys used with the following ECC algorithms: Elliptic Curve Digital Signature Algorithm (ECDSA); Elliptic Curve Diffie-Hellman (ECDH) family schemes; and, Elliptic Curve Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes. Two methods for specifying the algorithms that can be used with the subjectPublicKey are defined. One method does not restrict the algorithms the key can be used with while the other method does restrict the algorithms the key can be used with. To promote interoperability, this document indicates which is required. Turner, et al. Expires July 22, 2008 [Page 2] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 Three methods for specifying the algorithm's parameters are also defined. One allows for complete specification of the Elliptic Curve (EC), one allows for the EC to be identified by an object identifier, and one allows for the EC to be inherited from the issuer's certificate. To promote interoperability, this document indicates which options are required. Specification of all EC parameters is complicated with many options. To promote interoperability, this document indicates which options are required. 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 [RFC2119]. 2. Subject Public Key Information Fields In the X.509 certificate, the subjectPublilcKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier {{ECPKAlgorithms}}, subjectPublicKey BIT STRING } The fields in SubjectPublicKeyInfo have the following meanings: algorithm is the algorithm identifier and algorithm parameters for the ECC public key. See paragraph 2.1. subjectPublicKey is the ECC public key. See paragraph 2.2. The class ALGORITHM parameterizes the AlgorithmIdentifier type with sets of legal values (this class is used in many places in this document): 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. There are two parameterized types for AlgorithmIdentifier Turner, et al. Expires July 22, 2008 [Page 3] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 are defined in this document: ECPKAlgorithms (see paragraph 2.1) and HashFunctions (see paragraph 2.1.1.2.5). AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE { algorithm ALGORITHM.&id({IOSet}), parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL } The fields in AlgorithmIdentifier have the following meaning: algorithm identifies a cryptographic algorithm. The OBJECT IDENTIFIER component identifies the algorithm. The contents of the optional parameters field will vary according to the algorithm identified. parameters, which is optional, varies based on the algorithm identified. 2.1. Elliptic Curve Public Key Algorithm Identifier The algorithm field in the SubjectPublicKeyInfo structure indicates the algorithms and any associated parameters for the ECC public key (see paragraph 2.2). The algorithms are restricted to the ECPKCAlgorithms parameterized type, which uses the following ASN.1 structure: ECPKAlgorithms ALGORITHM ::= { ecPublicKeyType | ecDH | ecMQV } The algorithms defined are as follows: ecPublicKeyType indicates that the algorithms that can be used with the subject public key are not restricted (i.e., they are unrestricted). The key is only restricted by the values indicated in the key usage certificate extension. The ecPublicKeyType MUST be supported. See paragraph 2.1.1. This value is also used when a key is used with ECDSA. ecDH and ecMQV MAY be supported. See paragraph 2.1.2. Turner, et al. Expires July 22, 2008 [Page 4] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 2.1.1. Unrestricted Identifiers and Parameters The "unrestricted" algorithm is defined as follows: ecPublicKeyType ALGORITHM ::= { OID id-ecPublicKey PARMS ECParameters } The algorithm identifier is: id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } The parameters for id-ecPublicKey are as follows: ECParameters ::= CHOICE { namedCurve CURVE.&id({NamedCurve}), specifiedCuve SpecifiedCurve, implicitCurve NULL } The fields in ECParameters have the following meanings: namedCurve allows all the required values for a particular set of elliptic curve domain parameters to be represented by an object identifier. This choice MUST be supported. See paragraph 2.1.1.1. specifiedCurve allows all of the required values to be explicitly specified. This choice MAY be supported, and if it is implicitCurve MUST also be supported. See paragraph 2.1.1.2. implicitCurve allows the elliptic curve parameters to be inherited from the issuer's certificate. This choice MAY be supported, but if subordinate certificates use the same namedCurve as their superior, then the subordinate certificate MUST use the namedCurve option. That is implicitCurve is only supported if the superior doesn't use the namedCurve option. 2.1.1.1. Named Curve The namedCurve field in ECParamaters uses the class CURVE to constrain the set of legal values from NamedCurve, which are object identifiers: CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { ID &id } Turner, et al. Expires July 22, 2008 [Page 5] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 The NamedCurve parameterized type is defined as follows: NamedCurve CURVE ::= { { ID secp192r1 } | { ID sect163k1 } | { ID sect163r2 } | { ID secp224r1 } | { ID sect233k1 } | { ID sect233r1 } | { ID secp256r1 } | { ID sect283k1 } | { ID sect283r1 } | { ID secp384r1 } | { ID sect409k1 } | { ID sect409r1 } | { ID secp521r1 } | { ID sect571k1 } | { ID sect571r1 } | ... -- Extensible } The curve identifiers are the fifteen NIST recommended curves: secp192r1 OBJECT IDENTIFIER ::= { ansi-x9-62 curves(3) prime(1) 1 } sect163k1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 1 } sect163r2 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 15 } secp224r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 33 } sect233k1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 26 } sect233r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 27 } secp256r1 OBJECT IDENTIFIER ::= { ansi-x9-62 curves(3) prime(1) 7 } sect283k1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 16 } sect283r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 17 } secp384r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 34 } sect409k1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 36 } Turner, et al. Expires July 22, 2008 [Page 6] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 sect409r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 37 } secp521r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 35 } sect571k1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 38 } sect571r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 39 } 2.1.1.2. Specified Curve The specified field in ECParameters is the SpecifiedCurve type. SpecifiedCurve uses the following ASN.1 structure: SpecifiedCurve ::= SEQUENCE { version SpecifiedCurveVersion ( ecpVer1 | ecpVer2 | ecpVer3 ), fieldID FieldID {{FieldTypes}}, curve Curve, -- Curve E base ECPoint, -- Base point P order INTEGER, -- Order n of the base point cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n hash HashAlgorithm OPTIONAL, ... -- Extensible } The fields in SpecifiedCurve have the following meaning: version specifies the version number of the elliptic curve parameters. See paragraph 2.1.1.2.1. fieldID identifies the finite field over which the elliptic curve, specified in the curve field, is defined. See paragraph 2.1.1.2.2. curve specifies the elliptic curve E. See paragraph 2.1.1.2.3. base specifies the base point P of the elliptic curve E, specified in the curve field. See paragraph 2.1.1.2.4. order specifies the order n of the base point P, specified in base. Turner, et al. Expires July 22, 2008 [Page 7] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 cofactor is the order of the curve, specified in the curve field, divided by the order, specified in the order field, of the base point, specified in the base field (i.e., h = #E(Fq)/n). Inclusion of the cofactor is optional; however, it is strongly RECOMMENDED that that the cofactor be included in order to facilitate interoperability between implementations. hash is the hash algorithm used to generate the elliptic curve E, specified in the curve field, and/or base point P, specified in the base field, verifiably psuedorandomly. If the hash field is omitted, then the hash algorithm shall be SHA1. See paragraph 2.1.1.2.5. SpecifiedCurve is extensible and other documents may specify additional fields for this ASN.1 structure. 2.1.1.2.1. Specified Curve Version The version field in SpecifiedCurve is the SpecifiedCurveVersion type. SpecifiedCurveVersion uses the following ASN.1 structure: SpecifiedCurveVersion ::= INTEGER { ecpVer1(1), ecpVer2(2), ecpVer3(3), ... -- Extensible } SpecfifiedCurveVersion is ecdpVer1, ecdpVer2, or ecdpVer3. If version is ecdpVer1, then the elliptic curve may or may not be verifiably psuedorandomly according to whether curve.seed (see paragraph 2.1.1.2.3) is present, and the base point G (see paragraph 2.1.1.2.4) is not generated verifiably psuedorandomly. If version is ecdpVer2, then the curve and the base point G shall be generated verifiably psuedorandomly, and curve.seed shall be present. If version is ecdpVer3, then the curve is not generated verifiably psuedorandomly but the base point G shall be generated verifiably psuedorandomly from curve.seed, which shall be present. SpecifiedCurveVersion is extensible and other documents can specify additional values for SpecifiedCurveVersion. Implementations of this document MUST support ecpVer1. Turner, et al. Expires July 22, 2008 [Page 8] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 2.1.1.2.2. Field Identifiers The fieldID field in SpecifiedCurve is the FieldID type. Finite fields are represented by values of the parameterized type FieldID, constrained to the values of the objects defined in the information object set FieldTypes. The type FIELD-ID is defined by the following: FIELD-ID ::= TYPE-IDENTIFIER The FieldID parameterized type is defined as follows: FieldID { FIELD-ID:IOSet } ::= SEQUENCE { fieldType FIELD-ID.&id({IOSet}), parameters FIELD-ID.&Type({IOSet}{@fieldType}) } Field types are given in the following information object set: FieldTypes FIELD-ID ::= { { Prime-p IDENTIFIED BY prime-field } | { Characteristic-two IDENTIFIED BY characteristic-two-field } | ... -- Extensible } Two FieldTypes defined herein: prime-p (see paragraph 2.1.1.2.2.1) and characteristic-two (see paragraph 2.1.1.2.2.2). Implementations claiming conformance to this specification MUST support the prime-p field type and MAY support the characteristic-two field type. FieldTypes is extensible and other documents can specify additional values for FieldTypes. 2.1.1.2.2.1. Prime-p A prime finite field is specified in FieldID.fieldType by the following object identifier: prime-field OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 } The prime finite field parameters specified in FIELD-ID parameters has the following ASN.1 structure: Prime-p ::= INTEGER Prime-p is an integer which is the size of the field. Turner, et al. Expires July 22, 2008 [Page 9] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 2.1.1.2.2.2. Characteristic-two A characteristic-two finite field is specified in FieldID.fieldType by the following object identifier: characteristic-two-field OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 2 } The characteristic-two finite field parameters specified in FieldID.parameters have the following ASN.1 structure: Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m basis CHARACTERISTIC-TWO.&id({BasisTypes}), parameters CHARACTERISTIC-TWO.&Type({BasisTypes}{@basis}) } The fields in Characteristic-two have the following meanings: m is the size of the field. basis is the type of basis used to express elements of the field. parameters is the polynomial used to generate the field. The parameters vary based on the basis. The type CHARACTERISTIC-TWO is defined by the following: CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER The characteristic-two field basis types are given in the following information object set: BasisTypes CHARACTERISTIC-TWO ::= { { NULL IDENTIFIED BY gnBasis } | { Trinomial IDENTIFIED BY tpBasis } | { Pentanomial IDENTIFIED BY ppBasis } | ... -- Extensible } Three basis types are defined herein: normal bases, trinomial bases, and pentanomial bases. Implementation claiming conformance to this document MUST support normal basis and MAY support trimonial and pentanomial bases. BasisTypes is extensible and other documents can specify additional values for BasisTypes. Turner, et al. Expires July 22, 2008 [Page 10] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 Normal bases are specified in the basis field by the object identifier: gnBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 1 } A normal base has NULL parameters. A trinomial base specifies the degree of the middle term in the defining trinomial. A trinomial base is identified in the basis field by the object identifier: tpBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 2 } A trinomial base has the following parameters: Trinomial ::= INTEGER A pentanomial base specifies the degrees of the three middle terms in the defining pentanomial. A pentaomial base is identified in the basis field by the object identifier: ppBasis OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) 3 } A pentanomial base has the following parameters: Pentanomial ::= SEQUENCE { k1 INTEGER, -- k1 > 0 k2 INTEGER, -- k2 > k1 k3 INTEGER -- k3 > k2 } Turner, et al. Expires July 22, 2008 [Page 11] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 2.1.1.2.3. Curve The curve field in SpecifiedCurve is the Curve type. Curve uses the following ASN.1 structure: Curve ::= SEQUENCE { a FieldElement, b FieldElement, seed BIT STRING OPTIONAL -- Shall be present if used in SpecifiedCurve -- with version of ecdpVer2 or ecdpVer3 } FieldElement ::= OCTET STRING The fields in Curve have the following meanings: a and b are the coefficients a and b, respectively, of the elliptic curve E. Each coefficient, a and b, shall be represented as a value of type FieldElement. Conversion routines for field element to octet string are found in [SEC1]. Note that these octet strings may represent an elliptic curve point in compressed or uncompressed form. Implementations that support elliptic curve according to this document MUST support the uncompressed form and MAY support the compressed form. seed is an optional parameter that is used to derive the coefficients of a randomly generated elliptic curve. seed MUST be present if SpecifiedECDomain is either ecdpVer2 or ecdpVer3. 2.1.1.2.4. Base The base field in SpecifiedCurve is the ECPoint type. ECPoint uses the following ASN.1 syntax: ECPoint ::= OCTET STRING The contents of ECPoint is the octet string representation of an elliptic curve point. Conversion routines for point to octet string are found in [SEC1]. 2.1.1.2.5. Hash The hash field in SpecifiedCurve is the HashAlgorithm type. HashAlgorithm use the following ASN.1 syntax: HashAlgorithm ::= AlgorithmIdentifier {{HashFunctions}} Turner, et al. Expires July 22, 2008 [Page 12] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 HashAlgorithm is restricted to the HashFunctions parameterized type, which uses the following ASN.1 structure: HashFunctions ALGORITHM ::= { sha1 | sha224 | sha256 | sha384 | sha512 | ... -- Extensible } The SHA1 [SHA2] algorithm is defined as follows: sha1 ALGORITHM ::= { OID id-sha1 PARMS NULL } The algorithm identifier is: id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } The SHA224 [SHA2] algorithm is defined as follows: sha224 ALGORITHM ::= { OID id-sha224 PARMS NULL } It has the following object identifier: id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } The SHA256 [SHA2] algorithm is defined as follows: sha256 ALGORITHM ::= { OID id-sha256 PARMS NULL } The algorithm identifier is: id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } Turner, et al. Expires July 22, 2008 [Page 13] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 The SHA384 [SHA2] algorithm is defined as follows: sha384 ALGORITHM ::= { OID id-sha384 PARMS NULL } The algorithm identifier is: id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } The SHA512 [SHA2] algorithm is defined as follows: sha512 ALGORITHM ::= { OID id-sha512 PARMS NULL } The algorithm identifier is: id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } An implementation of this document SHOULD accept values of the parameterized type HashAlgorithm that have no parameters (also called absent) and values that have NULL parameters. These values SHALL be treated equally. (Of course, future extensions to the type parameter HashFunctions might include information objects whose parameters field is more meaningful.) An implementation of this document SHOULD omit (leave absent) the parameters unless the recipient implementation is unable to process absent parameters correctly. 2.1.2. Restricted Algorithm Identifiers and Parameters Algorithms used with EC fall in to different categories: signature and key agreement algorithms. ECDSA uses the ecPublicKey described in 2.1.1. Two sets of key agreement algorithms are identified herein: Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. All algorithms are identified by an OID and have PARMS. The OID varies based on the algorithm but the PARMS are always ECParameters (see paragraph 2.1.1). The ECDH is defined as follows: ecDH ALGORITHM ::= { OID TBD PARMS ECParameters } Turner, et al. Expires July 22, 2008 [Page 14] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 The algorithm identifier is: TBD OBJECT IDENTIFIER ::= { TBD } The ECMQV is defined as follows: ecMQV ALGORITHM ::= { OID TBD PARMS ECParameters } The algorithm identifier is: TBD OBJECT IDENTIFIER ::= { TBD } 2.2. Subject Public Key The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. Implementations that support elliptic curve according to this document MUST support the uncompressed form and MAY support the compressed form of the ECC public key. As specified in [SEC1]: The first two bytes of the key indicate whether the key is compressed or uncompressed. 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 significant 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. 3. KeyUsage Bits If the keyUsage extension is present in a CA certificate that indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of the following values MAY be present: digitalSignature; nonRepudiation; keyAgreement; keyCertSign; and cRLSign. If the CA certificate keyUsage extension asserts keyAgreement then it MAY assert either encipherOnly or decipherOnly. However, this Turner, et al. Expires July 22, 2008 [Page 15] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 specification RECOMMENDS that if keyCertSign or cRLSign is present, keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. If the keyUsage extension is present in an EE certificate that indicates id-ecPublicKey in subjectPublicKeyInfo, any combination of the following values MAY be present: digitalSignature; nonRepudiation; and keyAgreement. If the EE certificate keyUsage extension asserts keyAgreement then it MAY assert either encipherOnly or decipherOnly. However, this specification RECOMMENDS that if cRLSign is present, then keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present. If the keyUsage extension is present in a certificate that indicates ecDH or ecMQV in subjectPublicKeyInfo, keyAgreement MUST be present and digitalSignature, nonRepudiation, keyTransport, keyCertSign, and cRLSign MUST NOT be present. If this certificate keyUsage extension asserts keyAgreement then it MAY assert either encipherOnly or decipherOnly. 4. Security Considerations The security considerations in [RFC3279] apply. No new security considerations are introduced by this document. 5. IANA Considerations None. Please remove this section prior to publication as an RFC. 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certification Revocation List (CRL) Profile", RFC 3280, April 2002. [SHA2] National Institute of Standards and Technology (NIST), FIPS Publication 180-2: Secure Hash Standard, 1 August 2002. Turner, et al. Expires July 22, 2008 [Page 16] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 [SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic Curve Cryptography", Version 1.0, September 2000. [X.680] ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One, 1997. [X.681] ITU-T Recommendation X.680: Information Technology - Abstract Syntax Notation One: Information Object Spcification, 1997. 6.2. Informative References [RFC3279] Polk, W., Housley, R. and L. Bassham, "Algorithm Identifiers for the Internet X.509 Public Key Infrastructure", RFC 3279, April 2002. Appendix A. ASN.1 Module Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680,X.681]. To Be Supplied Later Turner, et al. Expires July 22, 2008 [Page 17] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 Author's Addresses Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA EMail: turners@ieca.com Kelvin Yiu Microsoft One Microsoft Way Redmond, WA 98052-6399 USA Email: kelviny@microsoft.com Daniel R. L. Brown Certicom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1 CANADA EMail: dbrown@certicom.com Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA EMail: housley@vigilsec.com Tim Polk NIST Building 820, Room 426 Gaithersburg, MD 20899 USA EMail: wpolk@nist.gov Turner, et al. Expires July 22, 2008 [Page 18] Internet-Draft ECC SubjectPublicKeyInfo Format January 2008 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). Turner, et al. Expires July 22, 2008 [Page 19]