IETF 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: May 21, 2009                                    Tim Polk, NIST
                                                      November 21, 2008


        Elliptic Curve Cryptography Subject Public Key Information
                 draft-ietf-pkix-ecc-subpubkeyinfo-10.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 May 21, 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, 5, and the
   ASN.1 module of RFC 3279.




Turner, et al            Expires May 21, 2009                  [Page 1]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 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............................................. 3
         2.1.1. Unrestricted Algorithm Identifier and Parameters... 4
            2.1.1.1. Named Curve................................... 5
         2.1.2. Restricted Algorithm Identifiers and Parameters.... 6
      2.2. Subject Public Key...................................... 7
   3. Key Usage Bits............................................... 7
   4. Security Considerations...................................... 8
   5. ASN.1 Considerations........................................ 10
   6. IANA Considerations......................................... 11
   7. Acknowledgements............................................ 11
   8. References.................................................. 11
      8.1. Normative References................................... 11
      8.2. Informative References................................. 12
   Appendix A. ASN.1 Module....................................... 13

1. Introduction

   This document specifies the format of the subjectPublicKeyInfo field
   in X.509 certificates [PKI] that use Elliptic Curve Cryptography
   (ECC).  It updates [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.

   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.

   This ASN.1 module in this document includes ASN.1 for ECC algorithms.
   It also included ASN.1 for non-ECC algorithms defined in [PKI-ALG]
   and [PKI-ADALG] even though the associated text is unaffected.  By
   updating all of the ASN.1 from [PKI-ALG] in this document,
   implementers only need to use the module found in this document.



Turner, et al            Expires May 21, 2009                  [Page 2]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 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 [MUSTSHOULD].

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,
       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.  See Section 2.1.

      o subjectPublicKey is the ECC public key.  See Section 2.2.

   The AlgorithmIdentifier type, which is included for convenience
   [PKI], is defined as follows:

      AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm   OBJECT IDENTIFIER,
        parameters  ANY DEFINED BY algorithm OPTIONAL
      }

   The fields in AlgorithmIdentifer have the following meanings:

      o algorithm identifies the cryptographic algorithm with an object
        identifier.  See Section 2.1.

      o parameters, which are optional, are the associated parameters
        for the algorithm identifier in the algorithm field.  See
        Section 2.1.1.

2.1. Elliptic Curve Cryptography Public Key Algorithm Identifiers

   The algorithm field in the SubjectPublicKeyInfo structure [PKI]
   indicates the algorithm and any associated parameters for the ECC
   public key (see Section 2.2).  Three algorithm identifiers are
   defined in this document:



Turner, et al            Expires May 21, 2009                  [Page 3]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


      o id-ecPublicKey indicates that the algorithms that can be used
        with the subject public key is unrestricted.   The key is only
        restricted by the values indicated in the key usage certificate
        extension.  id-ecPublicKey MUST be supported.  See Section
        2.1.1. This value is also used when a key is used with ECDSA.

      o id-ecDH indicates that the algorithm that can be used with the
        subject public key is restricted to the Elliptic Curve Diffie-
        Hellman algorithm.  See Section 2.1.2.  id-ecDH MAY be
        supported.

      o id-ecMQV indicates that the algorithm that can be used with the
        subject public key is restricted to the Elliptic Curve Menezes-
        Qu-Vanstone key agreement algorithm.  See Section 2.1.2.    id-
        ecMQV MAY be supported.

2.1.1. Unrestricted Algorithm Identifier and Parameters

   The "unrestricted" algorithm identifier is:

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

   The parameter for id-ecPublicKey is as follows and MUST always be
   present:

     ECParameters ::= CHOICE {
       namedCurve         OBJECT IDENTIFIER
       -- implicitCurve   NULL
       -- specifiedCurve  SpecifiedECDomain
     }
       -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
       -- Details for SpecifiedECDomain can be found in [X9.62].
       -- Any future additions to this CHOICE should be coordinated
       -- with ANSI X.9.

   The fields in ECParameters have the following meanings:

      o namedCurve identifies 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 Section
        2.1.1.1.

      o implicitCurve allows the elliptic curve parameters to be
        inherited.  This choice MUST NOT be used.




Turner, et al            Expires May 21, 2009                  [Page 4]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


      o specifiedCurve, which is SpecifiedECDomain type 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 needs to be
   coordinated with ANSI X9.

   The AlgorithmIdentifier within subjectPublicKeyInfo is the only place
   within a certificate where the domain parameters may be used.  If the
   parameters are not present, then clients MUST reject the certificate.

2.1.1.1. Named Curve

   The namedCurve field in ECParameters uses object identifiers to name
   well known curves.  This document publishes curve identifiers for the
   fifteen NIST recommended curves [FIPS186-3].  Other document can
   publish other name curve identifiers.  The NIST named cures are:

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

     -- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
     -- P-224, secp256r1 as P-256, 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 May 21, 2009                  [Page 5]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 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 }

2.1.2. Restricted Algorithm Identifiers and Parameters

   Two "restricted" algorithms are defined for key agreement algorithms:
   the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and the
   Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. Both
   algorithms are identified by an object identifier and have
   parameters.  The object identifier varies based on the algorithm but
   the parameters are always ECParameters and they MUST always be
   present (see Section 2.1.1).

   The ECDH algorithm uses the following object identifier:

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



Turner, et al            Expires May 21, 2009                  [Page 6]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   The ECMQV algorithm uses the following object identifier:

     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

   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.  The hybrid form from [X9.62]
   MUST NOT be used.  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]).  The public MUST be
        rejected if any other value is included in the first octet.

3. Key Usage Bits

   If the keyUsage extension is present in a CA certificate that
   indicates id-ecPublicKey in subjectPublicKeyInfo, then any
   combination of the following values MAY be present:

     digitalSignature;
     nonRepudiation;
     keyAgreement;
     keyCertSign; and
     cRLSign.

   If the CA certificate keyUsage extension asserts keyAgreement, then
   it MAY assert either encipherOnly or decipherOnly.  However, this


Turner, et al            Expires May 21, 2009                  [Page 7]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   specification RECOMMENDS that if keyCertSign or cRLSign is present,
   then keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be
   present.

   If the keyUsage extension is present in an EE certificate that
   indicates id-ecPublicKey in subjectPublicKeyInfo, then 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
   id-ecDH or id-ecMQV in subjectPublicKeyInfo, then the following MUST
   be present:

     keyAgreement;

   the following MUST NOT be present:

     digitalSignature;
     nonRepudiation;
     keyTransport;
     keyCertSign; and,
     cRLSign;

   the following MAY be present:

     encipherOnly; or,
     decipherOnly.

4. Security Considerations

   The security considerations in [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 hash algorithm [FIPS180-3]?

   3) What is the curve?



Turner, et al            Expires May 21, 2009                  [Page 8]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   Consideration must be given by the CA 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 Section 2.1.1.1) for the key sizes.

   Minimum  | ECDSA    | Message    | Curves
   Bits of  | Key Size | Digest     |
   Security |          | Algorithms |
   ---------+----------+------------+-----------
   80       | 160-223  | SHA-1      | sect163k1
            |          | SHA-224    | secp163r2
            |          | SHA-256    | secp192r1
            |          | SHA-384    |
            |          | SHA-512    |
   ---------+----------+------------+-----------
   112      | 224-255  | SHA-224    | secp224r1
            |          | SHA-256    | sect233k1
            |          | SHA-384    | sect233r1
            |          | SHA-512    |
   ---------+----------+------------+-----------
   128      | 256-383  | SHA-256    | secp256r1
            |          | SHA-384    | sect283k1
            |          | SHA-512    | sect283r1
   ---------+----------+------------+-----------
   192      | 384-511  | SHA-384    | secp384r1
            |          | SHA-512    | sect409k1
            |          |            | sect409r1
   ---------+----------+------------+-----------
   256      | 512+     | SHA-512    | secp521r1
            |          |            | sect571k1
            |          |            | sect571r1
   ---------+----------+------------+-----------













Turner, et al            Expires May 21, 2009                  [Page 9]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   To promote interoperability, the following choices are RECOMMENDED:

   Minimum  | ECDSA    | Message    | Curves
   Bits of  | Key Size | Digest     |
   Security |          | Algorithms |
   ---------+----------+------------+-----------
   80       | 192      | SHA-256    | secp192r1
   ---------+----------+------------+-----------
   112      | 224      | SHA-256    | secp224r1
   ---------+----------+------------+-----------
   128      | 256      | SHA-256    | secp256r1
   ---------+----------+------------+-----------
   192      | 384      | SHA-384    | secp384r1
   ---------+----------+------------+-----------
   256      | 512      | SHA-512    | secp521r1
   ---------+----------+------------+-----------

   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 hash 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 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].

   As noted in [PKI-ALG], the use of MD2 and MD5 for new applications is
   discouraged.  It is still reasonable to use MD2 and MD5 to verify
   existing signatures.

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


Turner, et al            Expires May 21, 2009                 [Page 10]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   If an implementation 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, and algorithms. Most are
   registered in the ANSI X9.62 arc with the 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 been 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.

7. Acknowledgements

   The authors wish to thank Stephen Farrell, Alfred Hoenes, Johannes
   Merkle, Jim Schaad, and Carl Wallace for their valued input.

8. References

8.1. Normative References

   [FIPS180-3]  National Institute of Standards and Technology (NIST),
                FIPS Publication 180-3: Secure Hash Standard, October
                2008.

   [FIPS186-3]  National Institute of Standards and Technology (NIST),
                FIPS Publication 186-3: Digital Signature Standard,
                (draft) November 2008.

   [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-ALG]    Polk, W., Housley, R. and L. Bassham, "Algorithm
                Identifiers for the Internet X.509 Public Key
                Infrastructure", RFC 3279, April 2002.

   [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.


Turner, et al            Expires May 21, 2009                 [Page 11]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   [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 and Certificate Revocation List (CRL)
                Profile", RFC 4055, June 2005.

   [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.680]      ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
                1:2002. Information Technology - Abstract Syntax
                Notation One.

8.2. Informative References

   [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-05.txt, work-in-
                progress, October 2008.

   [SP800-56A]  National Institute of Standards and Technology (NIST),
                Special Publication 800-56A: Recommendation for 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 - Part 1 (Revised), March 2007.

   [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            Expires May 21, 2009                 [Page 12]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


Appendix A. ASN.1 Module

   NOTE: The values for TBA1-3 will be included during AUTH48.

   //** RFC Editor: Remove this note prior to publication **//

   PKIX1Algorithms2008 { iso(1) identified-organization(3) dod(6)
     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) TBA1 }

   DEFINITIONS EXPLICIT TAGS ::=

   BEGIN

   -- EXPORTS ALL;

   IMPORTS

   -- From RFC 4055 [RSAOAEP]

   id-sha224, id-sha256, id-sha384, id-sha512
     FROM PKIX1-PSS-OAEP-Algorithms
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
         id-mod-pkix1-rsa-pkalgs(33) }

   ;

   --
   -- Message Digest Algorithms
   --

   -- MD-2
   -- Parameters are NULL

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

   -- MD-5
   -- Parameters are NULL

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







Turner, et al            Expires May 21, 2009                 [Page 13]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   -- SHA-1
   -- Parameters are preferred absent

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

   -- SHA-224
   -- Parameters are absent

   -- 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
   -- Parameters are absent

   -- 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
   -- Parameters are absent

   -- 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
   -- Parameters are absent

   -- id-sha512 OBJECT IDENTIFIER ::= {
   --   joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
   --   csor(3) nistalgorithm(4) hashalgs(2) 3 }















Turner, et al            Expires May 21, 2009                 [Page 14]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 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 }

   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
   }



Turner, et al            Expires May 21, 2009                 [Page 15]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 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 Unrestricted Algorithm ID, Parameters, and Keys
   -- (ECDSA keys use id-ecPublicKey)

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

   -- Parameters for both Restricted and Unrestricted

   ECParameters ::= CHOICE {
     namedCurve         OBJECT IDENTIFIER
     -- implicitCurve   NULL
     -- specifiedCurve  SpecifiedECDomain
   }
     -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
     -- Details for SpecifiedECDomain can be found in [X9.62].
     -- Any future additions to this CHOICE should be coordinated
     -- with ANSI X9.

   ECPoint ::= OCTET STRING

   -- Sec 2.1.2 Restricted Algorithm IDs, Parameters, and Keys: ECDH

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

   -- Parameters are ECParameters.  1988 ASN.1 for ECParameters is found
   -- in Appendix A.3.

   -- ECPoint ::= OCTET STRING

   -- Sec 2.1.2 Restricted Algorithm IDs, Parameters, and Keys: ECMQV

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

   -- Parameters are ECParameters.

   -- ECPoint ::= OCTET STRING


Turner, et al            Expires May 21, 2009                 [Page 16]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   --
   -- Signature Algorithms
   --

   -- RSA with MD-2
   -- Parameters are NULL

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

   -- RSA with MD-5
   -- Parameters are NULL

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

   -- RSA with SHA-1
   -- Parameters are NULL

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

   -- DSA with SHA-1
   -- Parameters are ABSENT

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

   -- DSA with SHA-224
   -- Parameters are ABSENT

   id-dsa-with-sha224 OBJECT IDENTIFIER  ::=  {
     joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
     csor(3) algorithms(4) id-dsa-with-sha2(3) 1 }

   -- DSA with SHA-256
   -- Parameters are ABSENT

   id-dsa-with-sha256 OBJECT IDENTIFIER  ::=  {
     joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
     csor(3) algorithms(4) id-dsa-with-sha2(3) 2 }

   -- ECDSA with SHA-1
   -- Parameters are ABSENT

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


Turner, et al            Expires May 21, 2009                 [Page 17]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   -- ECDSA with SHA-224
   -- Parameters are ABSENT

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

   -- ECDSA with SHA-256
   -- Parameters are ABSENT

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

   -- ECDSA with SHA-384
   -- Parameters are ABSENT

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

   -- ECDSA with SHA-512
   -- Parameters are ABSENT

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

   --
   -- Signature Values
   --

   -- DSA

   DSA-Sig-Value ::= SEQUENCE {
     r  INTEGER,
     s  INTEGER
   }

   -- ECDSA

   ECDSA-Sig-Value ::= SEQUENCE {
     r  INTEGER,
     s  INTEGER
   }




Turner, et al            Expires May 21, 2009                 [Page 18]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   --
   -- Named Elliptic Curves
   --

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

   -- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
   -- 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 }

   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 }




Turner, et al            Expires May 21, 2009                 [Page 19]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 2008


   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 }

   END

































Turner, et al            Expires May 21, 2009                 [Page 20]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 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 May 21, 2009                 [Page 21]


Internet-Draft     ECC SubjectPublicKeyInfo Format         October 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 May 21, 2009                 [Page 22]