Skip to main content

Elliptic Curve Cryptography Subject Public Key Information
draft-ietf-pkix-ecc-subpubkeyinfo-11

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5480.
Authors Tim Polk , Russ Housley , Sean Turner , Daniel R. L. Brown , Kelvin Yiu
Last updated 2021-09-02 (Latest revision 2008-12-12)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5480 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Pasi Eronen
Send notices to (None)
draft-ietf-pkix-ecc-subpubkeyinfo-11
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: June 11, 2009                                   Tim Polk, NIST 
                                                      December 11, 2008 
                                      
                                      
        Elliptic Curve Cryptography Subject Public Key Information 
                 draft-ietf-pkix-ecc-subpubkeyinfo-11.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 June 11, 2009. 

Copyright Notice 

   Copyright (C) The IETF Trust (2008). 

Abstract 

   This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates Sections 2.3.5 and 5, and 
   the ASN.1 module of Algorithms and Identifiers for the Internet X.509 

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   Public Key Infrastructure Certificate and Certificate Revocation List 
   (CRL) Profile, RFC 3279. 

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.2. Subject Public Key........................................7 
   3. Key Usage Bits.................................................8 
   4. Security Considerations........................................9 
   5. ASN.1 Considerations..........................................11 
   6. IANA Considerations...........................................11 
   7. Acknowledgments...............................................12 
   8. References....................................................12 
      8.1. Normative References.....................................12 
      8.2. Informative References...................................13 
   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 RFC 3279 [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 for Certification Authorities (CAs) that implement ECC 
   algorithms and relying parties that claim to process ECC algorithms. 

   The ASN.1 module in this document includes ASN.1 for ECC algorithms.  
   It also includes ASN.1 for non-ECC algorithms defined in [PKI-ALG] 
   and [PKI-ADALG] even though the associated text is unaffected.  By 

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   updating all of the ASN.1 from [PKI-ALG] in this document, 
   implementers only need to use the module found in this document. 

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 parameters for the 
        ECC public key. 

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

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

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: 

      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 (see Section 3).  id-ecPublicKey MUST be supported.  
        See Section 2.1.1.  This value is also included in certificates 
        when a public 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 public key (ECPoint) syntax is described in Section 2.2. 

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

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   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 domain parameters to be 
        inherited.  This choice MUST NOT be used. 

      o specifiedCurve, which is of type SpecifiedECDomain type 
        (defined in [X9.62]), allows all of the elliptic curve domain 
        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 elliptic curve domain parameters may 
   be located.  If the elliptic curve domain 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 documents can 
   publish other name curve identifiers.  The NIST named curves 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 secp256r1 curve was referred to as 
     -- prime256v1.   

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

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

     sect163k1 OBJECT IDENTIFIER ::= { 
       iso(1) identified-organization(3) certicom(132) curve(0) 1 } 

     sect163r2 OBJECT IDENTIFIER ::= { 
       iso(1) identified-organization(3) certicom(132) curve(0) 15 } 

     secp224r1 OBJECT IDENTIFIER ::= {  
       iso(1) identified-organization(3) certicom(132) curve(0) 33 } 

     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 } 

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 family schemes 
 
 
Turner, et al           Expires June 11, 2009                  [Page 6] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement 
   family schemes. 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) }  

   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 of the ECC 
   public key 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 key MUST 
        be rejected if any other value is included in the first octet.  

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

3. Key Usage Bits 

   If the keyUsage extension is present in a Certification Authority 
   (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 
   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 End Entity (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; 

   one of the following MAY be present: 

     encipherOnly; or 
     decipherOnly. 

   If the keyUsage extension is present in a certificate that indicates 
   id-ecDH or id-ecMQV in subjectPublicKeyInfo, then the following 
   values MUST NOT be present: 

     digitalSignature; 
     nonRepudiation; 
 
 
Turner, et al           Expires June 11, 2009                  [Page 8] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

     keyTransport; 
     keyCertSign; and 
     cRLSign. 

4. Security Considerations 

   The security considerations in [PKI-ALG] apply. 

   When implementing ECC in X.509 Certificates and Certificate 
   Revocation Lists (CRLs), there are three algorithm related choices 
   that need to be made for the signatureAlgorithm field in a 
   Certificate: 

   1) What is the public key size? 

   2) What is the hash algorithm [FIPS180-3]? 

   3) What is the curve? 

   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. 

 
 
Turner, et al           Expires June 11, 2009                  [Page 9] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

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

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   constrained devices.  Since the signer does not know the environment 
   that the recipient will use to validate the signature, it is better 
   to use a hash function that provides the desired 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 Menezes-Okamoto-Vanstone (MOV) condition [X9.62] 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 [PKI-ALG].   If an implementation needs to use these options, 
   then use the [X9.62] ASN.1 module. This RFC contains a conformant 
   subset of the ASN.1 module defined in [X9.62]. 

   If an 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 arc, and many of the curves, which are 
   in the Certicom Inc. arc (these curves have been adopted by ANSI and 
   NIST). Additionally, an object identifier is used to identify the 
   ASN.1 module found in Appendix A. It is defined in an arc delegated 

 
 
Turner, et al           Expires June 11, 2009                 [Page 11] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   by IANA to the PKIX Working Group.  No further action by IANA is 
   necessary for this document or any anticipated updates. 

7. Acknowledgments 

   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. 

   [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 Group (SECG), "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. 

 
 
Turner, et al           Expires June 11, 2009                 [Page 12] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

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

Appendix A. ASN.1 Module 

   NOTE: The value for TBA1 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; 

 
 
Turner, et al           Expires June 11, 2009                 [Page 13] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   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 } 

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

 
 
Turner, et al           Expires June 11, 2009                 [Page 14] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   -- SHA-256 
   -- Parameters are preferred 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 preferred 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 preferred 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 } 

   -- 
   -- Public Key (PK) Algorithms 
   -- 

   -- RSA PK Algorithm and Key 

   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, Key, 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 
   } 
 
 
Turner, et al           Expires June 11, 2009                 [Page 15] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   -- Diffie-Hellman PK Algorithm, Key, 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 Algorithm ID, Key, and Parameters  
   -- (ECDSA keys use id-ecPublicKey) 

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

   ECPoint ::= OCTET STRING 

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

 
 
Turner, et al           Expires June 11, 2009                 [Page 16] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

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

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

   -- ECPoint ::= OCTET STRING 

   -- Parameters are ECParameters. 

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

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

   -- ECPoint ::= OCTET STRING 

   -- Parameters are ECParameters. 

   -- 
   -- 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 } 
 
 
Turner, et al           Expires June 11, 2009                 [Page 17] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

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

   -- 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 } 
 
 
Turner, et al           Expires June 11, 2009                 [Page 18] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 2008 
    

   -- 
   -- Signature Values 
   -- 

   -- DSA 

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

   -- ECDSA 

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

   -- 
   -- 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 secp256r1 curve was referred to as prime256v1.   

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

 
 
Turner, et al           Expires June 11, 2009                 [Page 19] 


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

   END 

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


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 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 June 11, 2009                 [Page 21] 


Internet-Draft     ECC SubjectPublicKeyInfo Format        November 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 June 11, 2009                 [Page 22]