view Side-By-Side changes
Internet Draft Daniel Brown, Certicom Intended Status: Standard Track Kelvin Yiu, Microsoft Updates: 3279 (once approved) Russ Housley, Vigil Security Expires:JanuaryMarch 11, 2009 Tim Polk, NISTJulySeptember 11, 2008 Elliptic Curve Cryptography Subject Public Key Informationdraft-ietf-pkix-ecc-subpubkeyinfo-06.txtdraft-ietf-pkix-ecc-subpubkeyinfo-07.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 onJanuaryMarch 11, 2009. 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 Sections 2.3.5, 3, and 5 of RFC 3279. Turner, et al ExpiresJanuaryMarch 11, 2009 [Page 1] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008 Table of Contents 1. Introduction...................................................2 1.1. Terminology...............................................3 2. Subject Public Key Information Fields..........................3 2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers...............................................4 2.1.1. Unrestricted Identifiers and Parameters..............52.1.1.1. Named Curve.....................................6 2.1.1.2. Specified Curve.................................8 2.1.1.2.1. Specified Curve Version....................9 2.1.1.2.2. Field Identifiers..........................9 2.1.1.2.2.1. Prime-p..............................10 2.1.1.2.2.2. Characteristic-two...................10 2.1.1.2.3. Curve.....................................12 2.1.1.2.4. Base......................................13 2.1.1.2.5. Hash......................................132.1.2. Restricted Algorithm Identifiers andParameters.....15Parameters......7 2.2. Subject PublicKey.......................................16Key........................................8 3. Key UsageBits................................................16Bits.................................................9 4. SecurityConsiderations.......................................17Considerations.......................................10 5.IANA Considerations...........................................19ASN.1 Considerations..........................................12 6.Acknowledgements..............................................19IANA Considerations...........................................12 7.References....................................................19 7.1.Acknowledgements..............................................13 8. References....................................................13 8.1. NormativeReferences.....................................19 7.2.References.....................................13 8.2. InformativeReferences...................................20References...................................14 Appendix A. ASN.1Modules........................................21 AppendixModules........................................15 A.1. 1988 ASN.1Module...............................21 AppendixModule........................................15 A.2. 2004 ASN.1Module...............................29 Appendix B. Random Base Generation Routine.......................40 Appendix B.1. Generation of Random Candidate Point............40 Appendix B.2. Generation of Random Base.......................41Module........................................22 1. Introduction This document specifies the format of the subjectPublicKeyInfo field in X.509 certificates[RFC5280][PKI] that use Elliptic Curve Cryptography (ECC). It updates[RFC3279].[PKI-ALG]. This document specifies the encoding formats for public keys used with the following ECC algorithms: o Elliptic Curve Digital Signature Algorithm (ECDSA); o Elliptic Curve Diffie-Hellman (ECDH) family schemes; and, o Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes.Turner, et al Expires January 11, 2009 [Page 2] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008Two 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 to implement.ThreeTwo methods for specifying the algorithm's parameters are also defined. One allows forcomplete specification of the Elliptic Curve (EC), one allows forthe EC to be identified by an objectidentifier,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 to implement.Specification of all EC parameters is complicated with many options. To promote interoperability, this document indicates which options are required to implement.Turner, et al Expires March 11, 2009 [Page 2] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 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 subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier{{PKAlgorithms}},{{ PKIXAlgs-PublicKeys }}, subjectPublicKey BIT STRING } The fields in SubjectPublicKeyInfo have the following meanings: o algorithm is the algorithm identifier and algorithm parameters for the ECC public key. SeeparagraphSection 2.1. o subjectPublicKey is the ECC public key. SeeparagraphSection 2.2.Turner, et al Expires January 11, 2009 [Page 3] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008The classALGORITHMPUBLIC-KEY parameterizes the AlgorithmIdentifier type with sets of legalvalues (this classvalues, which isused in many placesdefined inthis document): ALGORITHM[PKI-ASN]: PUBLIC-KEY ::= CLASS { &id OBJECTIDENTIFIER UNIQUE, &TypeIDENTIFIER, &Params OPTIONAL, ¶mPresence ParamOptions DEFAULT required, &KeyValue, &PrivateKey OPTIONAL } WITH SYNTAX {OIDIDENTIFIER &id[PARMS &Type]KEY &KeyValue [PARAMS TYPE [&Params] ARE ¶mPresence] [PRIVATE KEY &PrivateKey] } Turner, et al Expires March 11, 2009 [Page 3] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 ParamOptions ::= ENUMERATED { required, -- Parameters MUST be encoded in structure preferedPresent, -- Parameters SHOULD be encoded in structure preferedAbsent, -- Parameters SHOULD NOT be encoded in structure absent, -- Parameters MUST NOT be encoded in structure notPresent, inheritable -- Parameters are inherited if not present } 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 defined in this document: PKAlgorithms (see paragraph 2.1) and CurveHashFunctions (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 identifiesWhen defining acryptographic algorithm. The OBJECT IDENTIFIER component identifies the algorithm. The contents ofPUBLIC-KEY type: o &id is theoptional parameters field will vary accordingobject identifier assigned to thealgorithm identified. parameters,public-key type. o &Params, which isOPTIONAL, varies based onoptional, is thealgorithm identified.parameters for the public- key type. o ¶mPresence parameter presence requirement o &KeyValue contains the type for the public key value o &PrivateKey is the associated private key format. 2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers The algorithm field in the SubjectPublicKeyInfo structure indicates the algorithms and any associated parameters for the ECC public key (seeparagraphSection 2.2). The algorithms are restricted to thePKAlgorithmsPKIXAlgs-PublicKeys parameterized type, which uses the following ASN.1 structure:PKAlgorithms ALGORITHMPKIXAlgs-PublicKeys PUBLIC-KEY ::= { pk-ec | pk-ecDH | pk-ecMQV, ... -- Extensible }Turner, et al Expires January 11, 2009 [Page 4] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008The algorithms defined are as follows: o pk-ec 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 pk-ec Turner, et al Expires March 11, 2009 [Page 4] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 CHOICE MUST be supported. SeeparagraphSection 2.1.1. This value is also used when a key is used with ECDSA. o pk-ecDH and pk-ecMQV MAY be supported. SeeparagraphSection 2.1.2. 2.1.1. Unrestricted Identifiers and Parameters The "unrestricted" algorithm is defined as follows: pk-ecALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-ecPublicKeyPARMSKEY ECPoint PARAMS TYPE ECParameters ARE required } The algorithm identifier is: id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } The public key syntax is described in Section 2.2. The parameters for id-ecPublicKey are as follows and they MUST always be present: ECParameters ::= CHOICE { namedCurve CURVE.&id({NamedCurve}),specifiedCurve SpecifiedCurve,implicitCurve NULL -- specifiedCurve SpecifiedCurve -- specifiedCurve MUST NOT be used in PKIX -- Details for specifiedCurve can be found in [X9.62] -- Any future additions to this CHOICE should be coordinated -- with ASNI X.9. } The fields in ECParameters have the following meanings: o 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. SeeparagraphSection 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.o implicitCurve allows the elliptic curve parameters to beinherited from the issuer's certificate.inherited. 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. Turner, et al ExpiresJanuaryMarch 11, 2009 [Page 5] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008MUST use the namedCurve option.That is, implicitCurve is only supported if the superior doesn't use the namedCurve option. o specifedCuve, which is defined in [X9.62], allows all of the curve parameters to be explicitly specified. This choice MUST NOT be used. See the ASN.1 Considerations section. The addition of any new choices in ECParameters ought to be coordinated with ANSI X9. 2.1.1.1. Named Curve The namedCurve field in ECParameters 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 } 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 recommendedcurves:curves [FIPS186-3]: -- Note in[ANSIX9.62][X9.62] the curves are referred to as 'ansiX9' as -- opposed to 'sec'. For example secp192r1 is the same curve as -- ansix9p192r1. -- Note that in[RFC3279][PKI-ALG] the secp192r1 curve was referred to as -- prime192v1 and the secp256v1 curve was referred to as secp256r1. -- Note that[DSS][FIPS186-3] refers to secp192r1 as P-192, secp224r1 asP-224,-- P-224, secp384r1 as P-384, and secp521r1 as P-521. secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3) prime(1) 1 } Turner, et al Expires March 11, 2009 [Page 6] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 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 }Turner, et al Expires January 11, 2009 [Page 6] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008sect233k1 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 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 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 } 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.2. Restricted Algorithm Identifiers and Parameters Algorithms used with elliptic curve cryptography fall in to different categories: signature and key agreement algorithms. ECDSA uses the Turner, et al ExpiresJanuaryMarch 11, 2009 [Page 7] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 20082.1.1.2. Specified Curve The specifiedCurve fieldpk-ec described inECParameters is2.1.1. Two sets ofSpecifiedCurve type. SpecifiedCurve useskey agreement algorithms are identified herein: thefollowing ASN.1 structure: SpecifiedCurve ::= SEQUENCE { version SpecifiedCurveVersion ( ecpVer1 | ecpVer2 | ecpVer3, ... ), fieldID FieldID {{FieldTypes}}, curve Curve, --Elliptic CurveE base ECPoint, -- Base point G order INTEGER, -- Order n ofDiffie-Hellman (ECDH) key agreement scheme and thebase point cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n hash HashAlgorithm OPTIONAL, ... -- Extensible } The fields in SpecifiedCurveElliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. All algorithms are identified by an object identifier and havethe 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 G on 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 G, specified in base. 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 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 G, specified in the base field, verifiably pseudorandom. If the hash field is omitted, then the hash algorithm SHALL be SHA1. See paragraph 2.1.1.2.5. Turner, et al Expires January 11, 2009 [Page 8] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 SpecifiedCurve is extensible. Extending SpecifiedCurve with new fields or defining a new version number MUST be coordinated with the ANSI X9.62 WG. 2.1.1.2.1. Specified Curve Version The version field in SpecifiedCurve is of SpecifiedCurveVersion type. SpecifiedCurveVersion uses the following ASN.1: SpecifiedCurveVersion ::= INTEGER { ecpVer1(1), ecpVer2(2), ecpVer3(3) } SpecfifiedCurveVersion is ecpVer1, ecpVer2, or ecpVer3. If version is ecpVer1, then the elliptic curve may or may not be verifiably pseudorandom 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 pseudorandom. If version is ecpVer2, then the curve and the base point G shall be generated verifiably pseudorandom, and curve.seed SHALL be present. If version is ecpVer3, then the curve is not generated verifiably pseudorandom but the base point G SHALL be generated verifiably pseudorandom from curve.seed, which SHALL be present. Implementations of this document MUST support ecpVer1. 2.1.1.2.2. Field Identifiers The fieldID field in SpecifiedCurve is of 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}) } Turner, et al Expires January 11, 2009 [Page 9] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 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 are 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. This definition has been made extensible to leave the formal description of the single remaining case, GF(p**n) with p>2 and m>1, for future standardization coordinated with other relevant standards defining organizations. 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. 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 } Turner, et al Expires January 11, 2009 [Page 10] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 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 dimension of the field (over GF(2)). basis is the type of basis used to express elements of the field. parameters represent 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. 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) basisType(3) 1 } A normal base has NULL parameters. Turner, et al Expires January 11, 2009 [Page 11] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 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) basisType(3) 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 pentanomial 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) basisType(3) 3 } A pentanomial base has the following parameters: Pentanomial ::= SEQUENCE { k1 INTEGER, -- 0 < k1 k2 INTEGER, -- k1 < k2 k3 INTEGER -- k2 < k3 < m } 2.1.1.2.3. Curve The curve field in SpecifiedCurve is of Curve type. Curve uses the following ASN.1 structure: Curve ::= SEQUENCE { a FieldElement, b FieldElement, seed BIT STRING OPTIONAL -- seed MUST be present if version is either -- ecpVer2 or ecpVer3, and it MAY be present for ecpVer1 } 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, is represented as a Turner, et al Expires January 11, 2009 [Page 12] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 value of type FieldElement. Conversion routines for field element to octet string are found in [SEC1]. seed is an optional parameter that is used to derive the coefficients of a randomly generated elliptic curve. seed MUST be present if version is either ecpVer2 or ecpVer3, and it MAY be present for ecpVer1. The curve generation routine is found in [X9.62]. 2.1.1.2.4. Base The base field in SpecifiedCurve is of 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]. Note that these octet strings MAY represent an elliptic curve point in compressed or uncompressed form. Implementations that support elliptic curve cryptography according to this document MUST support the uncompressed form and MAY support the compressed form. The routine for generating the random base when SpecifiedECDomain is either ecdpVer2 or ecdpVer3 is found in Appendix B. 2.1.1.2.5. Hash The hash field in SpecifiedCurve is of HashAlgorithm type. HashAlgorithm uses the following ASN.1 syntax: HashAlgorithm ::= AlgorithmIdentifier {{CurveHashFunctions}} CurveHashAlgorithm is restricted to the CurveHashFunctions parameterized type, which uses the following ASN.1 structure: CurveHashFunctions ALGORITHM ::= { ow-sha1 | ow-sha224 | ow-sha256 | ow-sha384 | ow-sha512, ... -- Extensible } Turner, et al Expires January 11, 2009 [Page 13] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 SHA1 [SHS] is defined as follows: ow-sha1 ALGORITHM ::= { OID id-sha1 PARMS NULL } It has the following object identifier: id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } SHA224 [SHS] is defined as follows: ow-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 } SHA256 [SHS] is defined as follows: ow-sha256 ALGORITHM ::= { OID id-sha256 PARMS NULL } It has the following object identifier: id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 } SHA384 [SHS] is defined as follows: ow-sha384 ALGORITHM ::= { OID id-sha384 PARMS NULL } It has the following object identifier: id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 } Turner, et al Expires January 11, 2009 [Page 14] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 SHA512 [SHS] is defined as follows: ow-sha512 ALGORITHM ::= { OID id-sha512 PARMS NULL } It has the following object identifier: 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 CurveHashFunctions might include information objects whose parameters field is more meaningful.) An implementation of this document SHOULD omit (leave absent) theparameters.2.1.2. Restricted Algorithm Identifiers and Parameters Algorithms used with elliptic curve cryptography fall in to different categories: signature and key agreement algorithms. ECDSA uses the pk-ec described in 2.1.1. Two sets of key agreement algorithms are identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. All algorithms are identified by an OID and have PARMS.TheOIDobject identifier varies based on the algorithm but thePARMSparameters are always ECParameters and they MUST always be present (seeparagraphSection 2.1.1). The ECDH is defined as follows: pk-ecDHALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-ecDHPARMSKEY ECPoint PARAMS TYPE ECParameters ARE required } The algorithm identifier is: id-ecDH OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) ecdh(12) } The ECMQV is defined as follows: pk-ecMQVALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-ecMQVPARMSKEY ECPoint PARAMS TYPE ECParameters ARE required }Turner, et al Expires January 11, 2009 [Page 15] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008The algorithm identifier is: id-ecMQV OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) ecmqv(13) } 2.2. Subject Public Key The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax: ECPoint ::= OCTET STRING Turner, et al Expires March 11, 2009 [Page 8] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 Implementations of elliptic curve cryptography according to this document MUST support the uncompressed form and MAY support the compressed form of the ECC public key. As specified in [SEC1]: o 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. Conversion routines are found in Sections 2.3.1 and 2.3.2 of [SEC1]. o The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 and the compressed form is indicated by either 0x02 or 0x03 (see 2.3.3 in [SEC1]). 3. Key Usage 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 specification RECOMMENDS that if keyCertSign or cRLSign is present, keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.Turner, et al Expires January 11, 2009 [Page 16] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008If 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. Turner, et al Expires March 11, 2009 [Page 9] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 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][PKI-ALG] apply. When implementing ECC in X.509 Certificates, there are three algorithm related choices that need to be made: 1) What is the public key size? 2) What is the hashalgorithm?algorithm [SHS]? 3) What is the curve? Consideration must be given to the strength of the security provided by each of these choices. Security is measured in bits, where a strong symmetric cipher with a key of X bits is said to provide X bits of security. It is recommended that the bits of security provided by each choice are roughly equivalent. The following table provides comparable minimum bits of security [SP800-57] for the ECDSA key sizes and message digest algorithms. It also lists curves (seeparagraphSection 2.1.1.1) for the key sizes.Using a larger hash value and then truncating it, consumes more processing power than is necessary. This is more important on constrained devices. Since the signer does not know the environment that the recipient will use to validate the signature, it is better to use a hash function that provides the desired have value output size, and no more.Turner, et al ExpiresJanuaryMarch 11, 2009 [Page17]10] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008 Minimum | ECDSA | Message | Curves Bits of | Key Size | Digest | Security | | Algorithms | ---------+----------+------------+----------- 80 | 160-223 | SHA1 | sect163k1 | | SHA224 | secp163r2 | | SHA256 | secp192r1 | | SHA384 | | | SHA512 | ---------+----------+------------+----------- 112 | 224-255 | SHA224 | secp224r1 | | SHA256 | sect233k1 | | SHA384 | sect233r1 | | SHA512 | ---------+----------+------------+----------- 128 | 256-383 | SHA256 | secp256r1 | | SHA384 | sect283k1 | | SHA512 | sect283r1 ---------+----------+------------+----------- 192 | 384-511 | SHA384 | secp384r1 | | SHA512 | sect409k1 | | | sect409r1 ---------+----------+------------+----------- 256 | 512+ | SHA512 | secp521r1 | | | sect571k1 | | | sect571r1 ---------+----------+------------+----------- To promote interoperability, the following choices are RECOMMENDED: Minimum | ECDSA | Message | Curves Bits of | Key Size | Digest | Security | | Algorithms | ---------+----------+------------+----------- 80 | 192 | SHA256 | secp192r1 ---------+----------+------------+----------- 112 | 224 | SHA256 | secp224r1 ---------+----------+------------+----------- 128 | 256 | SHA256 | secp256r1 ---------+----------+------------+----------- 192 | 384 | SHA384 | secp384r1 ---------+----------+------------+----------- 256 | 512 | SHA512 | secp521r1 ---------+----------+------------+----------- Using a larger hash value and then truncating it, consumes more processing power than is necessary. This is more important on Turner, et al ExpiresJanuaryMarch 11, 2009 [Page18]11] Internet-Draft ECCSubjectPublicKeyInfo Format July 2008SubjectPublicKeyInfo Format September 2008 constrained devices. Since the signer does not know the environment that the recipient will use to validate the signature, it is better to use a hash function that provides the desired have value output size, and no more. There are security risks with using keys not associated with well known and widely reviewed curves. For example, the curve may not satisfy the MOV condition or the curve may be vulnerable to the Anomalous attack [X9.62]. Additionally, either a) all of the arithmetic properties of a candidate ECC public key must be validated to ensure that it has the unique correct representation in the correct (additive) subgroup (and therefore is also in the correct EC group) specified by the associated ECC domain parameters or b) some of the of the arithmetic properties of a candidate ECC public key must be validated to ensure that it is in the correct group (but not necessarily the correct subgroup) specified by the associated ECC domain parameters [SP800-56A]. 5. ASN.1 Considerations [X9.62] defines additional options for ECParameters and ECDSA-Sig- Value. If an implementation needs to use these options, then use the [X9.62] ASN.1 module. This RFC contains a conformant subset of the ASN.1 module defined in [X9.62]. If an implementations generates a PER [X.691] encoding using the ASN.1 module found in this specification it might not achieve the same encoded output as one that uses the [X9.62] module. PER is not required by either the PKIX or S/MIME environments. If an implementation environment requires PER, then implementation concerns are less likely with the use of the [X9.62] module. 6. IANA Considerations This document makes extensive use of object identifiers to register public key types, elliptic curves, field types, andhashalgorithms. Most are registered in the ANSI X9.62 arc with exception of the hash algorithms, which are in NIST's arc, and many of the curves, which are in the Certicom Inc. arc (these curves have adopted by ANSI and NIST). Additionally, object identifiers are used to identify the ASN.1 modules found in Appendix A. These are defined in an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates.6.Turner, et al Expires March 11, 2009 [Page 12] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 7. Acknowledgements The authors wish to thank AlfredHinesHoenes, Johannes Merkle, and Jim Schaad for their valued input.7.8. References7.1.8.1. Normative References[DSS] Federal Information Processing[FIPS186-3] National Institute of Standards and Technology (NIST), FIPS Publication(FIPS PUB) 186-2,186-3: Digital Signature Standard,January 2000.(draft) March 2006. [PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [PKI-ASN] Hoffman, P., and J. Schaad, "New ASN.1 Modules for PKIX", draft-ietf-pkix-new-asn1, work-in-progress. [PKI-ADALG] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", draft-ietf-pkix-sha2-dsa-ecdsa, work-in-progress. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC5280] D., Copper, et al., "Internet[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate andCertificationCertificate Revocation List (CRL) Profile", RFC5280, May 2008. [SHS] National Institute of Standards and Technology (NIST), FIPS Publication 180-2: Secure Hash Standard, August 2002.4055, June 2005. [SEC1] Standards for Efficient Cryptography, "SEC 1: Elliptic Curve Cryptography", Version 1.0, September 2000. [SHS] National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, (draft) June 2007. [X9.62] American National Standards Institute (ANSI), ANS X9.62- 2005: The Elliptic Curve Digital Signature Algorithm (ECDSA), 2005. Turner, et al Expires March 11, 2009 [Page 13] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 [X.208] ITU-T Recommendation X.208 (1988) | ISO/IEC 8824-1:1988. Specification of Abstract Syntax Notation One (ASN.1).Turner, et al Expires January 11, 2009 [Page 19] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. Information Technology - Abstract Syntax Notation One. [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. Information Technology - Abstract Syntax Notation One: Information Object Specification. [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. Information Technology - Abstract Syntax Notation One: Constraint Specification. [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications.7.2.8.2. Informative References[RFC3279][PKI-ALG] Polk, W., Housley, R. and L. Bassham, "Algorithm Identifiers for the Internet X.509 Public Key Infrastructure", RFC 3279, April 2002. [SP800-56A] National Institute of Standards and Technology (NIST), Special Publication 800-56A: Recommendation Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised), March 2007. [SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management, August 2005. [X.691] ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002. Information Technology - ASN.1 Encoding Rules: Specification of Packed Encoding Rules. Turner, et al ExpiresJanuaryMarch 11, 2009 [Page20]14] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008 Appendix A. ASN.1 Modules Appendix A.1 provides the normative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.208]. Appendix A.2 provides an informative ASN.1 definitions for the structures described in this specification using ASN.1 as defined in [X.680], [X.681], [X.682], and [X.683]. This appendix contains the same information as Appendix A.1 in a more recent (and precise) ASN.1 notation, however Appendix A.1 takes precedence in case of conflict. These modules include more than the ASN.1 updates described in the text of this document. They also include additional ASN.1 from[RFC3279][PKI- ALG] because this document updates the entire ASN.1 module.AppendixAdditionally, it includes ASN.1 for DSA with SHA-224 and SHA-256 [PKI-ADALG]. A.1. 1988 ASN.1 Module PKIXAlgs-1988 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBD } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL IMPORTSAlgorithmIdentifier-- From [RSAOAEP] id-sha224, id-sha256, id-sha384, id-sha512 FROMPKIX1Explicit88PKIX1-PSS-OAEP-Algorithms { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)mod(0) pkix1-explicit(18)id-mod(0) id-mod-pkix1-rsa-pkalgs(33) } ; Turner, et al Expires March 11, 2009 [Page 15] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- -- Public Key (pk) Algorithms -- -- RSA PK Algorithm, Parameters, and Keys rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }Turner, et al Expires January 11, 2009 [Page 21] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER -- e } -- DSA PK Algorithm and Parameters id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } DSAPublicKey ::= INTEGER -- public key, y DSS-Parms ::= SEQUENCE { p INTEGER, q INTEGER, g INTEGER } -- Diffie-Hellman PK Algorithm, Keys, and Parameters dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } DHPublicKey ::= INTEGER -- public key, y = g^x mod p DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } Turner, et al Expires March 11, 2009 [Page 16] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- KEA PK Algorithm and Parameters id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { 2 16 840 1 101 2 1 1 22 } KEA-Parms-Id ::= OCTET STRING -- Sec 2.1.1 UnrestrictedAlgorithmsAlgorithm IDs, Parameters, andParameters (including ECDSA)Keys -- (ECDSA keys use id-ecPublicKey) id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }Turner, et al Expires January 11, 2009 [Page 22] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008ECPoint ::= OCTET STRING -- Sec 2.1.2 RestrictedAlgorithmsAlgorithm IDs, Parameters, andParametersKeys id-ecDH OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) ecdh(12) } -- ECPoint ::= OCTET STRING -- Sec 2.1.2 RestrictedAlgorithmsAlgorithm IDs, Parameters, andParametersKeys id-ecMQV OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) ecmqv(13) } -- ECPoint ::= OCTET STRING -- Parameters for both Restricted and Unrestricted ECParameters ::= CHOICE { namedCurve OBJECT IDENTIFIER,specifiedCurve SpecifiedCurve,implicitCurve NULL -- specifiedCurve SpecifiedCurve -- specifiedCurve MUST NOT be used in PKIX -- Details for specifiedCurve can be found in [X9.62] -- Any future additions to this CHOICE should be coordinated -- with ANSI X.9. } Turner, et al Expires March 11, 2009 [Page 17] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- Sec 2.1.1.1 Named Curves -- Note in [X9.62] the curves are referred to as 'ansiX9' as -- opposed to 'sec'. For example secp192r1 is the same curve as -- ansix9p192r1. -- Note that in[RFC3279][PKI-ALG] the secp192r1 curve was referred to as -- prime192v1 and the secp256v1 curve was referred to as secp256r1. -- Note that[DSS][FIPS186-3] refers to secp192r1 as P-192, secp224r1 asP-224,-- P-224, secp384r1 as P-384, and secp521r1 as P-521. secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 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 }Turner, et al Expires January 11, 2009 [Page 23] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008sect233r1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) 27 } secp256r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 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 March 11, 2009 [Page 18] Internet-Draft ECC SubjectPublicKeyInfo Format September 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 } --Sec 2.1.1.2 Specified Curve SpecifiedCurve ::= SEQUENCE { version SpecifiedCurveVersion, fieldID FieldID, curve Curve,--Curve E base ECPoint, -- Base point G order INTEGER,Signature Algorithms (sa) --Order n of the base point cofactor INTEGER OPTIONAL,--The integer h = #E(Fq)/n hash HashAlgorithm OPTIONAL } Turner, et al Expires January 11, 2009 [Page 24] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 SpecifiedCurveVersion ::= INTEGER { ecpVer1(1), ecpVer2(2), ecpVer3(3) } FieldIDRSA with MD-2 -- Parameters are NULL md2WithRSAEncryption OBJECT IDENTIFIER ::=SEQUENCE{fieldType OBJECT IDENTIFIER, parameters ANY DEFINED BY fieldTypeiso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 } --where fieldType is prime-field, the parameters are of type Prime-p prime-fieldRSA with MD-5 -- Parameters are NULL md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) fieldType(1) 1rsadsi(113549) pkcs(1) pkcs-1(1) 4 }Prime-p ::= INTEGER--where fieldType is characteristic-two-field, the parameters areRSA with SHA-1 --of type Characteristic-two characteristic-two-fieldParameters are NULL sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) fieldType(1) 2 } Characteristic-two ::= SEQUENCE { m INTEGER, -- Field size 2^m basis OBJECT IDENTIFIER, parameters ANY DEFINED BY basisrsadsi(113549) pkcs(1) pkcs-1(1) 5 } --The object identifiers gnBasis, tpBasis and ppBasis name -- three kinds of basis for characteristic-two finite fields -- normal basis is identified by OID gnBasis and indicatesDSA with SHA-1 --parametersParameters areNULL gnBasisABSENT dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) basisType(3) 1x9-57(10040) x9algorithm(4) 3 } --trinomial basis is identified by OID tpBasis and indicatesDSA with SHA-224 --parameters of type Pentanomial tpBasisParameters are ABSENT dsa-with-sha224 OBJECT IDENTIFIER ::= {iso(1) member-body(2)joint-iso-ccitt(2) country(16) us(840)ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) basisType(3) 2organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1 } Turner, et al ExpiresJanuaryMarch 11, 2009 [Page25]19] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008Trinomial ::= INTEGER -- Trinomial basis representation of F2^m -- Integer k for reduction polynomial x**m + x**k + 1--pentanomial basis is identified by OID ppBasis and indicatesDSA with SHA-256 --parameters of type Pentanomial ppBasisParameters are ABSENT dsa-with-sha256 OBJECT IDENTIFIER ::= {iso(1) member-body(2)joint-iso-ccitt(2) country(16) us(840)ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) basisType(3) 3 } -- Pentanomial basis representation of F2^m -- reduction polynomial integers k1, k2, k3 -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1 Pentanomial ::= SEQUENCE { k1 INTEGER, -- 0 < k1 k2 INTEGER, -- k1 < k2 k3 INTEGER -- k2 < k3 < m } Curve ::= SEQUENCE { a FieldElement, -- Elliptic curve coefficient a b FieldElement, -- Elliptic curve coefficient b seed BIT STRING OPTIONAL -- seed MUST be present if version is either -- ecpVer2 or ecpVer3, and it MAY be present for ecpVer1organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 2 }FieldElement ::= OCTET STRING ECPoint ::= OCTET STRING HashAlgorithm ::= AlgorithmIdentifier---- Signature Algorithms (sa) -- -- RSAECDSA withMD-2 md2WithRSAEncryptionSHA-1 -- Parameters are ABSENT ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)rsadsi(113549) pkcs(1) pkcs-1(1) 2ansi-X9-62(10045) signatures(4) 1 }Turner, et al Expires January 11, 2009 [Page 26] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008--RSAECDSA withMD-5 md5WithRSAEncryptionSHA-224 -- Parameters are ABSENT ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)rsadsi(113549) pkcs(1) pkcs-1(1) 4ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } --RSAECDSA withSHA-1 sha1WithRSAEncryptionSHA-256 -- Parameters are ABSENT ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)rsadsi(113549) pkcs(1) pkcs-1(1) 5ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } --DSAECDSA withSHA-1 dsa-with-sha1SHA-384 -- Parameters are ABSENT ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)x9-57(10040) x9algorithm(4)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } -- ECDSA withSHA-1 ecdsa-with-SHA1SHA-512 -- Parameters are ABSENT ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)1ecdsa-with-SHA2(3) 4 } Turner, et al Expires March 11, 2009 [Page 20] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- -- Signature Values -- -- DSA DSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } -- ECDSA ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } -- -- One-way (ow) Hash Algorithms -- -- MD-2 -- Parameters are NULL id-md2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }Turner, et al Expires January 11, 2009 [Page 27] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008-- MD-5 -- Parameters are NULL id-md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 } -- SHA-1 -- Parameters are preferred ABSENT id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } -- SHA-224id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 } -- SHA-256 id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 }--SHA-384 id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 }Parameters are preferred ABSENT --SHA-512 id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 } ENDid-sha224 Turner, et al ExpiresJanuaryMarch 11, 2009 [Page28]21] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008Appendix-- SHA-256 -- Parameters are preferred ABSENT -- id-sha256 -- SHA-384 -- Parameters are preferred ABSENT -- id-sha384 -- SHA-512 -- Parameters are preferred ABSENT -- id-sha512 END A.2. 2004 ASN.1 Module PKIXAlgs-2008 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBD } DEFINITIONS EXPLICIT TAGS ::= BEGIN -- EXPORTS ALL--IMPORTSNONE ALGORITHM ::= CLASS { &id OBJECT IDENTIFIER UNIQUE, &Type OPTIONAL } WITH SYNTAX-- FROM [PKI-ASN] PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM FROM AlgorithmInformation {OID &id [PARMS &Type]iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithInformation(TBD) }AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE-- From [PKI-ASN] mda-sha224, mda-sha256, mda-sha384, mda-sha512 FROM PKIX1-PSS-OAEP-Algorithms {algorithm ALGORITHM.&id({IOSet}), parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONALiso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBD } ; Turner, et al Expires March 11, 2009 [Page 22] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- -- Public Key(pk)(pk-) Algorithms --PKAlgorithms ALGORITHMPKIXAlgs-PublicKeys PUBLIC-KEY ::= { pk-rsa | pk-dsa | pk-dh | pk-kea | pk-ec | pk-ecDH | pk-ecMQV, ... -- Extensible } -- RSA PK Algorithm, Parameters, and Keys pk-rsaALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER rsaEncryptionPARMSKEY RSAPublicKey PARAMS TYPE NULL ARE absent -- Private key format not in this document -- } rsaEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }Turner, et al Expires January 11, 2009 [Page 29] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008RSAPublicKey ::= SEQUENCE { modulus INTEGER, -- n publicExponent INTEGER -- e } -- DSA PK Algorithm, Parameters, and Keys pk-dsaALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-dsaPARMSKEY DSAPublicKey PARAMS TYPE DSS-Parms ARE inheritable -- Private key format not in this document -- } id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } Turner, et al Expires March 11, 2009 [Page 23] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 DSS-Parms ::= SEQUENCE { p INTEGER, q INTEGER, g INTEGER } DSAPublicKey ::= INTEGER -- public key, y -- Diffie-Hellman PK Algorithm, Parameters, and Keys pk-dhALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER dhpublicnumberPARMSKEY DHPublicKey PARAMS TYPE DomainParameters ARE inheritable -- Private key format not in this document -- } dhpublicnumber OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 } DomainParameters ::= SEQUENCE { p INTEGER, -- odd prime, p=jq +1 g INTEGER, -- generator, g q INTEGER, -- factor of p-1 j INTEGER OPTIONAL, -- subgroup factor, j>= 2 validationParms ValidationParms OPTIONAL } ValidationParms ::= SEQUENCE { seed BIT STRING, pgenCounter INTEGER } DHPublicKey ::= INTEGER -- public key, y = g^x mod p -- KEA PK Algorithm and Parameters pk-keaALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-keyExchangeAlgorithmPARMS-- key is not encoded -- PARAMS TYPE KEA-Parms-Id ARE required -- Private key format not in this document -- }Turner, et al Expires January 11, 2009 [Page 30] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= { 2 16 840 1 101 2 1 1 22 } Turner, et al Expires March 11, 2009 [Page 24] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 KEA-Parms-Id ::= OCTET STRING -- Sec 2.1.1 Unrestricted Algorithms IDs, Parameters, andParameters (including ECDSA)Keys -- (ECDSA uses pk-ec) pk-ecALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-ecPublicKeyPARMSKEY ECPoint PARAMS TYPE ECParameters ARE required -- Private key format not in this document -- } id-ecPublicKey OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 } ECPoint ::= OCTET STRING -- Sec 2.1.2 RestrictedAlgorithmsAlgorithm IDs, Parameters, andParametersKeys pk-ecDHALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-ecDHPARMSKEY ECPoint PARAMS TYPE ECParameters ARE required -- Private key format not in this document -- } id-ecDH OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) ecdh(12) } -- Sec 2.1.2 RestrictedAlgorithmsAlgorithm IDs, Parameters, andParametersKeys pk-ecMQVALGORITHMPUBLIC-KEY ::= {OIDIDENTIFIER id-ecMQVPARMSKEY ECPoint PARAMS TYPE ECParameters ARE required -- Private key format not in this document -- } id-ecMQV OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) schemes(1) ecmqv(13) } Turner, et al Expires March 11, 2009 [Page 25] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- Parameters for both Restricted and Unrestricted ECParameters ::= CHOICE { namedCurve CURVE.&id({NamedCurve}),specifiedCurve SpecifiedCurve,implicitCurveNULLNULL, -- specifiedCurve SpecifiedCurve -- specifiedCurve MUST NOT be used in PKIX -- Details for specifiedCurve can be found in [X9.62] -- Any future additions to this CHOICE should be coordinated -- with ANSI X.9. } -- Sec 2.1.1.1 Named Curve CURVE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX { ID &id }Turner, et al Expires January 11, 2009 [Page 31] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008NamedCurve 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 } -- Note in [X9.62] the curves are referred to as 'ansiX9' as -- opposed to 'sec'. For example secp192r1 is the same curve as -- ansix9p192r1. -- Note that in[RFC3279][PKI-ALG] the secp192r1 curve was referred to as -- prime192v1 and the secp256v1 curve was referred to as secp256r1. -- Note that[DSS][FIPS186-3] refers to secp192r1 as P-192, secp224r1 asP-224,-- P-224, secp384r1 as P-384, and secp521r1 as P-521. secp192r1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 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 } Turner, et al Expires March 11, 2009 [Page 26] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 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 ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) 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 }Turner, et al Expires January 11, 2009 [Page 32] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008secp384r1 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 } 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 } -- Sec 2.1.1.2 Specified Curve SpecifiedCurve ::= SEQUENCE { version SpecifiedCurveVersion ( ecpVer1 | ecpVer2 | ecpVer3, ... ), fieldID FieldID {{FieldTypes}}, curve Curve, -- Curve E base ECPoint, -- Base point G order INTEGER, -- Order n of the base point cofactor INTEGER OPTIONAL, -- The integer h = #E(Fq)/n hash HashAlgorithm OPTIONAL, ... -- Extensible::= { iso(1) identified-organization(3) certicom(132) curve(0) 37 }SpecifiedCurveVersionsecp521r1 OBJECT IDENTIFIER ::=INTEGER{ecpVer1(1), ecpVer2(2), ecpVer3(3)iso(1) identified-organization(3) certicom(132) curve(0) 35 }FIELD-IDsect571k1 OBJECT IDENTIFIER ::=TYPE-IDENTIFIER FieldID{FIELD-ID:IOSetiso(1) identified-organization(3) certicom(132) curve(0) 38 } sect571r1 OBJECT IDENTIFIER ::=SEQUENCE{fieldType FIELD-ID.&id({IOSet}), parameters FIELD-ID.&Type({IOSet}{@fieldType})iso(1) identified-organization(3) certicom(132) curve(0) 39 } Turner, et al ExpiresJanuaryMarch 11, 2009 [Page33]27] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008FieldTypes FIELD-ID-- -- Signature Algorithms (sa-) -- PKIXAlgs-Signature SIGNATURE-ALGORITHM ::= {{ Prime-p IDENTIFIED BY prime-field }sa-rsaWithMD2 |{ Characteristic-two IDENTIFIED BY characteristic-two-field },sa-rsaWithMD5 | sa-rsaWithSHA1 | sa-dsawithSHA1 | sa-dsawithSHA224 | sa-dsawithSHA256 | sa-ecdsaWithSHA1 | sa-ecdsaWithSHA224 | sa-ecdsaWithSHA256 | sa-ecdsaWithSHA384 | sa-ecdsaWithSHA512, ... -- Extensible } --where fieldType is prime-field, the parameters are of type Prime-p prime-field OBJECT IDENTIFIERRSA with MD-2 sa-rsaWithMD2 SIGNATURE-ALGORITHM ::= {iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1IDENTIFIER md2WithRSAEncryption PARAMS TYPE NULL ARE present USES { mda-md2 }Prime-p ::= INTEGER -- where fieldType is characteristic-two-field, the parameters are -- of type Characteristic-two characteristic-two-fieldPUBKEYS { pk-rsa } } md2WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) fieldType(1)rsadsi(113549) pkcs(1) pkcs-1(1) 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 -- The object identifiers gnBasis, tpBasis and ppBasis name--three kinds of basis for characteristic-two finite fields BasisTypes CHARACTERISTIC-TWORSA with MD-5 sa-rsaWithMD5 SIGNATURE-ALGORITHM ::= {{IDENTIFIER md5WithRSAEncryption PARAMS TYPE NULLIDENTIFIED BY gnBasis } |ARE present USES {Trinomial IDENTIFIED BY tpBasismda-md5 }|PUBKEYS {Pentanomial IDENTIFIED BY ppBasis }, ... -- Extensiblepk-rsa }-- normal basis is identified by OID gnBasis and indicates -- parameters are NULL gnBasis} md5WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) basisType(3) 1rsadsi(113549) pkcs(1) pkcs-1(1) 4 } Turner, et al ExpiresJanuaryMarch 11, 2009 [Page34]28] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008 --trinomial basis is identified by OID tpBasis and indicates -- parameters of type Trinomial tpBasisRSA with SHA-1 sa-rsaWithSHA1 SIGNATURE-ALGORITHM ::= { IDENTIFIER sha1WithRSAEncryption PARAMS TYPE NULL ARE present USES { mda-sha1 } PUBKEYS { pk-rsa } } sha1WithRSAEncryption OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) basisType(3) 2rsadsi(113549) pkcs(1) pkcs-1(1) 5 }Trinomial ::= INTEGER -- Trinomial basis representation of F2^m -- Integer k for reduction polynomial x**m + x**k + 1 -- pentanomial basis is identified by OID ppBasis and indicates--parameters of type Pentanomial ppBasisDSA with SHA-1 sa-dsaWithSHA1 SIGNATURE-ALGORITHM ::= { IDENTIFIER dsa-with-sha1 VALUE DSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha1 } PUBKEYS { pk-dsa } } dsa-with-sha1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)ansi-X9-62(10045) fieldType(2) characteristic-two-basis(2) basisType(3)x9-57(10040) x9algorithm(4) 3 } --Pentanomial basis representation of F2^m -- reduction polynomial integers k1, k2, k3 -- f(x) = x**m + x**k3 + x**k2 + x**k1 + 1 PentanomialDSA with SHA-224 sa-dsaWithSHA224 SIGNATURE-ALGORITHM ::=SEQUENCE{k1 INTEGER, -- 0 > k1 k2 INTEGER, -- k1 < k2 k3 INTEGER -- k2 < k3 < mIDENTIFIER dsa-with-sha224 VALUE DSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha224 } PUBKEYS { pk-dsa }Curve} dsa-with-sha224 OBJECT IDENTIFIER ::=SEQUENCE{a FieldElement, b FieldElement, seed BIT STRING OPTIONAL -- seed MUST be present if version is either -- ecpVer2 or ecpVer3, and it MAY be present for ecpVer1joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 1 }FieldElement ::= OCTET STRING ECPoint ::= OCTET STRING HashAlgorithm ::= AlgorithmIdentifier {{CurveHashFunctions}}Turner, et al ExpiresJanuaryMarch 11, 2009 [Page35]29] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008CurveHashFunctions ALGORITHM ::= { ow-sha1 | ow-sha224 | ow-sha256 | ow-sha384 | ow-sha512, ... -- Extensible } -- -- Signature Algorithms (sa) -- SignatureAlgorithms ALGORITHM ::= { sa-rsaWithMD2 | sa-rsaWithMD5 | sa-rsaWithSHA1 | sa-dsawithSHA1 | sa-ecdsaWithSHA1, ... -- Extensible }--RSADSA withMD-2 sa-rsaWithMD2 ALGORITHMSHA-256 sa-dsaWithSHA256 SIGNATURE-ALGORITHM ::= {OID md2WithRSAEncryption PARMSIDENTIFIER dsa-with-sha256 VALUE DSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha256 }md2WithRSAEncryptionPUBKEYS { pk-dsa } } dsa-with-sha256 OBJECT IDENTIFIER ::= {iso(1) member-body(2)joint-iso-ccitt(2) country(16) us(840)rsadsi(113549) pkcs(1) pkcs-1(1)organization(1) gov(101) csor(3) algorithms(4) id-dsa-with-sha2(3) 2 } --RSAECDSA withMD-5 sa-rsaWithMD5 ALGORITHMSHA-1 sa-ecdsaWithSHA1 SIGNATURE-ALGORITHM ::= {OID md5WithRSAEncryption PARMSIDENTIFIER ecdsa-with-SHA1 VALUE ECDSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha1 }md5WithRSAEncryptionPUBKEYS { pk-ec } } ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)rsadsi(113549) pkcs(1) pkcs-1(1) 4ansi-X9-62(10045) signatures(4) 1 } --RSAECDSA withSHA-1 sa-rsaWithSHA1 ALGORITHMSHA-224 sa-ecdsaWithSHA224 SIGNATURE-ALGORITHM ::= {OID sha1WithRSAEncryption PARMSIDENTIFIER ecdsa-with-SHA224 VALUE ECDSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha224 }sha1WithRSAEncryptionPUBKEYS { pk-ec } } ecdsa-with-SHA224 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)rsadsi(113549) pkcs(1) pkcs-1(1) 5ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 1 } Turner, et al ExpiresJanuaryMarch 11, 2009 [Page36]30] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008 --DSAECDSA withSHA-1 sa-dsaWithSHA1 ALGORITHMSHA-256 sa-ecdsaWithSHA256 SIGNATURE-ALGORITHM ::= {OID dsa-with-sha1 PARMSIDENTIFIER ecdsa-with-SHA256 VALUE ECDSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha256 }dsa-with-sha1PUBKEYS { pk-ec } } ecdsa-with-SHA256 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)x9-57(10040) x9algorithm(4)ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 2 } -- ECDSA with SHA-384 sa-ecdsaWithSHA384 SIGNATURE-ALGORITHM ::= { IDENTIFIER ecdsa-with-SHA384 VALUE ECDSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha384 } PUBKEYS { pk-ec } } ecdsa-with-SHA384 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 3 } -- ECDSA withSHA-1 sa-ecdsaWithSHA1 ALGORITHMSHA-512 sa-ecdsaWithSHA512 SIGNATURE-ALGORITHM ::= {OID ecdsa-with-sha1 PARMSIDENTIFIER ecdsa-with-SHA512 VALUE ECDSA-Sig-Value PARAMS TYPE NULL ARE absent USES { mda-sha512 }ecdsa-with-SHA1PUBKEYS { pk-ec } } ecdsa-with-SHA512 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)1ecdsa-with-SHA2(3) 4 } Turner, et al Expires March 11, 2009 [Page 31] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- -- Signature Values -- -- DSA DSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } -- ECDSA ECDSA-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER }Turner, et al Expires January 11, 2009 [Page 37] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008-- --One-way (ow) Hash AlgorithmsMessage Digest Algorthms (mda-) -- HashAlgorithmsALGORITHMDIGEST-ALGORITHM ::= {ow-md2mda-md2 |ow-md5mda-md5 |ow-sha1mda-sha1 |ow-sha224mda-sha224 |ow-sha256mda-sha256 |ow-sha384mda-sha384 |ow-sha512,mda-sha512, ... -- Extensible } -- MD-2ow-md2 ALGORITHMmda-md2 DIGEST-ALGORITHM ::= {OIDIDENTIFIER id-md2PARMSPARAMS TYPE NULL ARE preferredAbsent } id-md2 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 } Turner, et al Expires March 11, 2009 [Page 32] Internet-Draft ECC SubjectPublicKeyInfo Format September 2008 -- MD-5ow-md5 ALGORITHMmda-md5 DIGEST-ALGORITHM ::= {OIDIDENTIFIER id-md5PARMSPARAMS TYPE NULL ARE preferredAbsent } id-md5 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 } -- SHA-1ow-sha1 ALGORITHMmda-sha1 DIGEST-ALGORITHM ::= {OIDIDENTIFIER id-sha1PARMSPARAMS TYPE NULL ARE preferredAbsent } id-sha1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26 } -- SHA-224ow-sha224 ALGORITHM ::= { OID id-sha224 PARMS NULL } Turner, et al Expires January 11, 2009 [Page 38] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 4 }-- Parameters are preferred ABSENT -- mda-sha224 -- SHA-256ow-sha256 ALGORITHM ::= { OID id-sha256 PARMS NULL } id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 1 }-- Parameters are preferred ABSENT -- mda-sha256 -- SHA-384ow-sha384 ALGORITHM ::= { OID id-sha384 PARMS NULL } id-sha384 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 2 }-- Parameters are preferred ABSENT -- mda-sha384 -- Parameters are preferred ABSENT -- SHA-512ow-sha512 ALGORITHM ::= { OID id-sha512 PARMS NULL } id-sha512 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistalgorithm(4) hashalgs(2) 3 }-- Parameters are preferred ABSENT -- mda-sha512 END Turner, et al ExpiresJanuary 11, 2009 [Page 39] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 Appendix B. Random Base Generation Routine This Appendix is normative. Appendix B.1. Generation of Random Candidate Point Inputs: Bit string SEED, integer counter basecount, selected hash function with output length hashlen bits, field size q, cofactor h. (See [X9.62] for descriptions of these quantities.) Actions: The following or its equivalent: a) Set element = 1. b) Convert basecount and element to octet strings BaseCount and Element of minimal length, respectively. c) Compute H = Hash ("Base point" || BaseCount || Element || SEED). d) Convert H to an integer e, using A.5 of [X9.62]. e) Let t = e mod 2q, so that t is an integer in the interval [0, 2q - 1]. f) Let x = t mod q and z = Floor[t / q]. g) Convert x to field element in Fq using A.5 of [X9.62]. h) Recover the field element y from (x, z) using the appropriate method from A.3.1.3 of [X9.62]. i) If the result is an error, then increment element and go back to Step b). Output: A random candidate point (x, y). Turner, et al Expires January 11, 2009 [Page 40] Internet-Draft ECC SubjectPublicKeyInfo Format July 2008 Appendix B.2. Generation of Random Base Input: Elliptic curve E = (Fq, a, b), cofactor h, prime n, and bit string SEED. (See [X9.62] for descriptions of these quantities.) Actions: The following or its equivalent: a) Set basecount = 1. b) Generate a random candidate point R = (x, y) using Annex B.1 with the current value of basecount. c) Let G = hR. d) If g = 0 or nG not = 0, then increment basecount and go back to Step b), unless base > 10h^2, in which case, output "Failure". Output: A random base G, or "Failure". Turner, et al Expires JanuaryMarch 11, 2009 [Page41]33] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 2008 Authors' 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 ExpiresJanuaryMarch 11, 2009 [Page42]34] Internet-Draft ECC SubjectPublicKeyInfo FormatJulySeptember 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 ExpiresJanuaryMarch 11, 2009 [Page43]35] ----