[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 5480

PKIX WG                                               Sean Turner, IECA
Internet Draft                                   Daniel Brown, Certicom
Intended Status: Standard Track                   Kelvin Yiu, Microsoft
Updates: 3279 (once approved)              Russ Housley, Vigil Security
Expires: January 11, 2009                                Tim Polk, NIST
                                                          July 11, 2008


        Elliptic Curve Cryptography Subject Public Key Information
                 draft-ietf-pkix-ecc-subpubkeyinfo-06.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 January 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 RFC 3279.





Turner, et al          Expires January 11, 2009                [Page 1]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 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..............5
            2.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......................................13
         2.1.2. Restricted Algorithm Identifiers and Parameters.....15
      2.2. Subject Public Key.......................................16
   3. Key Usage Bits................................................16
   4. Security Considerations.......................................17
   5. IANA Considerations...........................................19
   6. Acknowledgements..............................................19
   7. References....................................................19
      7.1. Normative References.....................................19
      7.2. Informative References...................................20
   Appendix A. ASN.1 Modules........................................21
      Appendix A.1. 1988 ASN.1 Module...............................21
      Appendix A.2. 2004 ASN.1 Module...............................29
   Appendix B. Random Base Generation Routine.......................40
      Appendix B.1. Generation of Random Candidate Point............40
      Appendix B.2. Generation of Random Base.......................41

1. Introduction

   This document specifies the format of the subjectPublicKeyInfo field
   in X.509 certificates [RFC5280] that use Elliptic Curve Cryptography
   (ECC).  It updates [RFC3279]. 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 Menezes-Qu-Vanstone (ECMQV) family schemes.




Turner, et al          Expires January 11, 2009                [Page 2]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   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 to
   implement.

   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 to implement.

   Specification of all EC parameters is complicated with many options.
   To promote interoperability, this document indicates which options
   are required to implement.

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}},
       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.









Turner, et al          Expires January 11, 2009                [Page 3]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   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
   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 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 Cryptography Public Key Algorithm Identifiers

   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
   PKAlgorithms parameterized type, which uses the following ASN.1
   structure:

     PKAlgorithms ALGORITHM ::= {
       pk-ec |
       pk-ecDH |
       pk-ecMQV,
       ... -- Extensible
     }




Turner, et al          Expires January 11, 2009                [Page 4]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   The algorithms defined are as follows:

      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
      CHOICE MUST be supported.  See paragraph 2.1.1. This value is
      also used when a key is used with ECDSA.

      pk-ecDH and pk-ecMQV MAY be supported.  See paragraph 2.1.2.

2.1.1. Unrestricted Identifiers and Parameters

   The "unrestricted" algorithm is defined as follows:

    pk-ec 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 and they MUST always
   be present:

     ECParameters ::= CHOICE {
       namedCurve      CURVE.&id({NamedCurve}),
       specifiedCurve  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


Turner, et al          Expires January 11, 2009                [Page 5]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


      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 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 recommended curves:

   -- Note in [ANSIX9.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] the secp192r1 curve was referred to as
   -- prime192v1 and the secp256v1 curve was referred to as secp256r1.

   -- Note that [DSS] refers to secp192r1 as P-192, secp224r1 as P-224,
   -- secp384r1 as P-384, 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 }


Turner, et al          Expires January 11, 2009                [Page 6]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   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 }

   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 }
















Turner, et al          Expires January 11, 2009                [Page 7]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


2.1.1.2. Specified Curve

   The specifiedCurve field in ECParameters is of 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 G
       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 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) the parameters.

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.  The OID varies based on the algorithm but the PARMS are
   always ECParameters and they MUST always be present (see paragraph
   2.1.1).

   The ECDH is defined as follows:

     pk-ecDH ALGORITHM ::= {
       OID id-ecDH PARMS ECParameters }

   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-ecMQV ALGORITHM ::= {
       OID id-ecMQV PARMS ECParameters }



Turner, et al          Expires January 11, 2009               [Page 15]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   The 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.
   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]:

      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.

      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 2008


   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.

   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.

   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 hash algorithm?

   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 (see
   paragraph 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          Expires January 11, 2009               [Page 17]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 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
   ---------+----------+------------+-----------





Turner, et al          Expires January 11, 2009               [Page 18]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


5. IANA Considerations

   This document makes extensive use of object identifiers to register
   public key types, elliptic curves, field types, and hash algorithms.
   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 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. Acknowledgements

   The authors wish to thank Alfred Hines and Jim Schaad for their
   valued input.

7. References

7.1. Normative References

   [DSS]       Federal Information Processing Standards Publication
               (FIPS PUB) 186-2, Digital Signature Standard, January
               2000.

   [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 X.509 Public Key
               Infrastructure Certificate and Certification Revocation
               List (CRL) Profile", RFC 5280, May 2008.

   [SHS]       National Institute of Standards and Technology (NIST),
               FIPS Publication 180-2: Secure Hash Standard, August
               2002.

   [SEC1]      Standards for Efficient Cryptography, "SEC 1: Elliptic
               Curve Cryptography", Version 1.0, September 2000.

   [X9.62]     American National Standards Institute (ANSI), ANS X9.62-
               2005: The Elliptic Curve Digital Signature Algorithm
               (ECDSA), 2005.

   [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. Informative References

   [RFC3279]   Polk, W., Housley, R. and L. Bassham, "Algorithm
               Identifiers for the Internet X.509 Public Key
               Infrastructure", RFC 3279, April 2002.

   [SP800-57]  National Institute of Standards and Technology (NIST),
               Special Publication 800-57: Recommendation for Key
               Management, August 2005.

























Turner, et al          Expires January 11, 2009               [Page 20]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 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] because this document updates the entire ASN.1 module.

Appendix 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

   IMPORTS

   AlgorithmIdentifier
     FROM PKIX1Explicit88
       { iso(1) identified-organization(3) dod(6)
         internet(1) security(5) mechanisms(5) pkix(7) mod(0)
         pkix1-explicit(18) }
   ;

   --
   -- 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 2008


   RSAPublicKey ::= 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 }

   -- 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 Unrestricted Algorithms and Parameters (including ECDSA)

   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 2008


   -- Sec 2.1.2 Restricted Algorithms and Parameters

   id-ecDH OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) certicom(132) schemes(1)
     ecdh(12) }

   -- Sec 2.1.2 Restricted Algorithms and Parameters

   id-ecMQV OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) certicom(132) schemes(1)
     ecmqv(13) }

   -- Parameters for both Restricted and Unrestricted

   ECParameters ::= CHOICE {
     namedCurve      OBJECT IDENTIFIER,
     specifiedCurve  SpecifiedCurve,
     implicitCurve   NULL
   }

   -- 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] the secp192r1 curve was referred to as
   -- prime192v1 and the secp256v1 curve was referred to as secp256r1.

   -- Note that [DSS] refers to secp192r1 as P-192, secp224r1 as P-224,
   -- secp384r1 as P-384, 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 2008


   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 }

   -- Sec 2.1.1.2 Specified Curve

   SpecifiedCurve ::= SEQUENCE {
     version  SpecifiedCurveVersion,
     fieldID  FieldID,
     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
   }







Turner, et al          Expires January 11, 2009               [Page 24]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   SpecifiedCurveVersion ::= INTEGER {
     ecpVer1(1),
     ecpVer2(2),
     ecpVer3(3)
   }

   FieldID ::= SEQUENCE {
     fieldType  OBJECT IDENTIFIER,
     parameters ANY DEFINED BY fieldType
   }

   -- where fieldType is prime-field, the parameters are of type Prime-p

   prime-field OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }

   Prime-p ::= INTEGER

   -- where fieldType is characteristic-two-field, the parameters are
   -- of type Characteristic-two

   characteristic-two-field 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 basis
   }

   -- 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 indicates
   -- parameters are NULL

   gnBasis OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
     characteristic-two-basis(2) basisType(3) 1 }

   -- trinomial basis is identified by OID tpBasis and indicates
   -- parameters of type Pentanomial

   tpBasis OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
     characteristic-two-basis(2) basisType(3) 2 }



Turner, et al          Expires January 11, 2009               [Page 25]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   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

   ppBasis OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) 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 ecpVer1
   }

   FieldElement ::= OCTET STRING

   ECPoint ::= OCTET STRING

   HashAlgorithm ::= AlgorithmIdentifier

   --
   -- Signature Algorithms (sa)
   --

   -- RSA with MD-2

   md2WithRSAEncryption OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }





Turner, et al          Expires January 11, 2009               [Page 26]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   -- RSA with MD-5

   md5WithRSAEncryption OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

   -- RSA with SHA-1

   sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }

   -- DSA with SHA-1

   dsa-with-sha1 OBJECT IDENTIFIER ::=  {
     iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }

   -- ECDSA with SHA-1

   ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }

   --
   -- 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

   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

   id-md5  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 }

   -- SHA-1

   id-sha1 OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) oiw(14) secsig(3)
     algorithm(2) 26 }

   -- SHA-224

   id-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 }

   -- 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 }

   END













Turner, et al          Expires January 11, 2009               [Page 28]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


Appendix 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

   -- IMPORTS NONE

   ALGORITHM ::= CLASS {
     &id     OBJECT IDENTIFIER UNIQUE,
     &Type   OPTIONAL
   }
   WITH SYNTAX { OID &id [PARMS &Type] }

   AlgorithmIdentifier {ALGORITHM:IOSet} ::= SEQUENCE {
     algorithm   ALGORITHM.&id({IOSet}),
     parameters  ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL
   }

   --
   -- Public Key (pk) Algorithms
   --

   PKAlgorithms ALGORITHM ::= {
     pk-rsa |
     pk-dsa |
     pk-dh  |
     pk-kea |
     pk-ec |
     pk-ecDH |
     pk-ecMQV,
     ... -- Extensible
   }

   -- RSA PK Algorithm, Parameters, and Keys

   pk-rsa ALGORITHM ::= {
     OID rsaEncryption PARMS NULL }

   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 2008


   RSAPublicKey ::= SEQUENCE {
     modulus         INTEGER, -- n
     publicExponent  INTEGER  -- e
   }

   -- DSA PK Algorithm, Parameters, and Keys

   pk-dsa ALGORITHM ::= {
     OID id-dsa PARMS DSS-Parms }

   id-dsa OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }

   DSS-Parms ::= SEQUENCE {
     p  INTEGER,
     q  INTEGER,
     g  INTEGER
   }

   DSAPublicKey ::= INTEGER --  public key, y

   -- Diffie-Hellman PK Algorithm, Parameters, and Keys

   pk-dh ALGORITHM ::= {
     OID dhpublicnumber PARMS DomainParameters }

   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-kea ALGORITHM ::= {
     OID id-keyExchangeAlgorithm PARMS KEA-Parms-Id }



Turner, et al          Expires January 11, 2009               [Page 30]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {
     2 16 840 1 101 2 1 1 22 }

   KEA-Parms-Id ::= OCTET STRING

   -- Sec 2.1.1 Unrestricted Algorithms and Parameters (including ECDSA)

   pk-ec ALGORITHM ::= {
     OID id-ecPublicKey PARMS ECParameters }

   id-ecPublicKey OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }

   -- Sec 2.1.2 Restricted Algorithms and Parameters

   pk-ecDH ALGORITHM ::= {
     OID id-ecDH PARMS ECParameters }

   id-ecDH OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) certicom(132) schemes(1)
     ecdh(12) }

   -- Sec 2.1.2 Restricted Algorithms and Parameters

   pk-ecMQV ALGORITHM ::= {
     OID id-ecMQV PARMS ECParameters }

   id-ecMQV OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) certicom(132) schemes(1)
     ecmqv(13) }

   -- Parameters for both Restricted and Unrestricted

   ECParameters ::= CHOICE {
     namedCurve      CURVE.&id({NamedCurve}),
     specifiedCurve  SpecifiedCurve,
     implicitCurve   NULL
   }

   -- 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 2008


   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
   }

   -- 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] the secp192r1 curve was referred to as
   -- prime192v1 and the secp256v1 curve was referred to as secp256r1.

   -- Note that [DSS] refers to secp192r1 as P-192, secp224r1 as P-224,
   -- secp384r1 as P-384, 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 }

   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 2008


   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 }

   -- 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
   }

   SpecifiedCurveVersion ::= INTEGER {
     ecpVer1(1),
     ecpVer2(2),
     ecpVer3(3)
   }

   FIELD-ID ::= TYPE-IDENTIFIER

   FieldID { FIELD-ID:IOSet } ::= SEQUENCE {
     fieldType  FIELD-ID.&id({IOSet}),
     parameters FIELD-ID.&Type({IOSet}{@fieldType})
   }





Turner, et al          Expires January 11, 2009               [Page 33]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   FieldTypes FIELD-ID ::= {
     { Prime-p            IDENTIFIED BY prime-field } |
     { Characteristic-two IDENTIFIED BY characteristic-two-field },
     ... -- Extensible
   }

   -- where fieldType is prime-field, the parameters are of type Prime-p

   prime-field OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(1) 1 }

   Prime-p ::= INTEGER

   -- where fieldType is characteristic-two-field, the parameters are
   -- of type Characteristic-two

   characteristic-two-field 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       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-TWO ::= {
     { NULL        IDENTIFIED BY gnBasis } |
     { Trinomial   IDENTIFIED BY tpBasis } |
     { Pentanomial IDENTIFIED BY ppBasis },
     ...  -- Extensible
   }

   -- normal basis is identified by OID gnBasis and indicates
   -- parameters are NULL

   gnBasis OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
     characteristic-two-basis(2) basisType(3) 1 }






Turner, et al          Expires January 11, 2009               [Page 34]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   -- trinomial basis is identified by OID tpBasis and indicates
   -- parameters of type Trinomial

   tpBasis OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) fieldType(2)
     characteristic-two-basis(2) basisType(3) 2 }

   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

   ppBasis OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) 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,
     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

   ECPoint ::= OCTET STRING

   HashAlgorithm ::= AlgorithmIdentifier {{CurveHashFunctions}}







Turner, et al          Expires January 11, 2009               [Page 35]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   CurveHashFunctions 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
   }

   -- RSA with MD-2

   sa-rsaWithMD2 ALGORITHM ::= {
     OID md2WithRSAEncryption PARMS NULL }

   md2WithRSAEncryption OBJECT IDENTIFIER ::= {
   iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }

   -- RSA with MD-5

   sa-rsaWithMD5 ALGORITHM ::= {
     OID md5WithRSAEncryption PARMS NULL }

   md5WithRSAEncryption OBJECT IDENTIFIER ::= {
   iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }

   -- RSA with SHA-1

   sa-rsaWithSHA1 ALGORITHM ::= {
     OID sha1WithRSAEncryption PARMS NULL }

   sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
   iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }




Turner, et al          Expires January 11, 2009               [Page 36]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 2008


   -- DSA with SHA-1

   sa-dsaWithSHA1 ALGORITHM ::= {
     OID dsa-with-sha1 PARMS NULL }

   dsa-with-sha1 OBJECT IDENTIFIER ::=  {
     iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }

   -- ECDSA with SHA-1

   sa-ecdsaWithSHA1 ALGORITHM ::= {
     OID ecdsa-with-sha1 PARMS NULL }

   ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }

   --
   -- 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 Algorithms
   --

   HashAlgorithms ALGORITHM ::= {
     ow-md2    |
     ow-md5    |
     ow-sha1   |
     ow-sha224 |
     ow-sha256 |
     ow-sha384 |
     ow-sha512,
     ... -- Extensible
   }

   -- MD-2

   ow-md2 ALGORITHM ::= {
     OID id-md2 PARMS NULL }

   id-md2  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }

   -- MD-5

   ow-md5 ALGORITHM ::= {
     OID id-md5 PARMS NULL }

   id-md5  OBJECT IDENTIFIER ::= {
     iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 }

   -- SHA-1

   ow-sha1 ALGORITHM ::= {
     OID id-sha1 PARMS NULL }

   id-sha1 OBJECT IDENTIFIER ::= {
     iso(1) identified-organization(3) oiw(14) secsig(3)
     algorithm(2) 26 }

   -- SHA-224

   ow-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 }

   -- SHA-256

   ow-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 }

   -- SHA-384

   ow-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 }

   -- SHA-512

   ow-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 }

   END

















Turner, et al          Expires January 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 January 11, 2009               [Page 41]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 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          Expires January 11, 2009               [Page 42]

Internet-Draft     ECC SubjectPublicKeyInfo Format            July 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 January 11, 2009               [Page 43]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/