One document matched: draft-turner-ecprivatekey-02.txt

Differences from draft-turner-ecprivatekey-01.txt


Network Working Group                                 Sean Turner, IECA 
Internet Draft                                      Dan Brown, Certicom 
Intended Status: Informational                         December 4, 2009 
Expires: June 4, 2010 
 
 
                                      
                   Elliptic Curve Private Key Structure 
                     draft-turner-ecprivatekey-02.txt 


Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and 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 4, 2010. 

Copyright Notice 

   Copyright (c) 2009 IETF Trust and the persons identified as the 
   document authors.  All rights reserved. 

   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents in effect on the date of 
   publication of this document (http://trustee.ietf.org/license-info). 
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 






 
 
 
Turner & Brown           Expires June 4, 2010                  [Page 1] 

Internet-Draft   Elliptic Curve Private Key Structure     December 2009 
    

Abstract 

   This document specifies the syntax and semantics for conveying 
   Elliptic Curve (EC) private key information.  This syntax and 
   semantics defined herein are based on a similar syntax and semantics 
   defined in Standards for Efficient Cryptography Group (SECG).  

1. Introduction 

   This document specifies a syntax and semantics for Elliptic Curve 
   (EC) private key information.  EC private key information includes a 
   private key and optionally parameters.  Additionally, it may include 
   the corresponding public key.  The syntax and semantics defined 
   herein are based on a similar syntax and semantics defined in 
   Standards for Efficient Cryptography Group (SECG) [SECG1]. 

   Most Public Key Infrastructures (PKIs) mandate local key generation; 
   however, there are some PKIs that also support centralized key 
   generation (e.g., the public-private key pair is generated by a CA).  
   The structure defined in this document allows the entity that 
   generates the private and public keys to distribute the key pair and 
   optionally the associated domain parameters. 

   A scenario in which this syntax is useful distributes EC private keys 
   using PrivateKeyInfo, as defined in PKCS #8 [RFC5208]. Distributing 
   an EC private key with PKCS#8 [RFC5208] involves including: 
   a) id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]) with the 
   namedCurve as the parameters in the privateKeyAlgorithm field 
   b) ECPrivateKey in the PrivateKey field, which is an OCTET STRING. 
   When the public key is included, it is present in the ECPrivateKey 
   publicKey field not in the PKCS#8 publicKey field. 

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












 
 
Turner & Brown           Expires June 4, 2010                  [Page 2] 

Internet-Draft   Elliptic Curve Private Key Structure     December 2009 
    

3. Elliptic Curve Private Key Format 

   This section gives the syntax for an EC private key.  Computationally 
   an EC private key is an unsigned integer, but for representation, EC 
   private key information SHALL have ASN.1 type ECPrivateKey: 

   ECPrivateKey ::= SEQUENCE { 
     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), 
     privateKey     OCTET STRING, 
     parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 
     publicKey  [1] BIT STRING OPTIONAL 
   } 

    The fields of type ECPrivateKey have the following meanings:  

    o version specifies the syntax version number of the elliptic curve 
     private key structure. For this version of the document, it SHALL 
     be set to ecPrivkeyVer1, which is of type INTEGER and whose value 
     is one (1). 

    o privateKey is the private key.  It is an octet string of length 
     ceiling (log2(n/8)) (where n is the order of the curve) obtained 
     from the unsigned integer via the Integer-to-Octet-String-
     Primitive (I2OSP) defined in [RFC3447]. 

    o parameters specifies the elliptic curve domain parameters 
     associated to the private key. The type ECParameters are discussed 
     in [RFC5480]. As specified in [RFC5480], only the namedCurve 
     CHOICE, which is an object identifier that fully identifies the 
     required values for a particular set of elliptic curve domain 
     parameters, is permitted. Though the ASN.1 indicates parameters is 
     OPTIONAL, implementations that conform to this document MUST 
     always include the parameters field. 

    o publicKey contains the elliptic curve public key associated with 
     the private key in question. The format of the public key is 
     specified in Section 2.2 of [RFC5480]. Though the ASN.1 indicates 
     publicKey is OPTIONAL, implementations that conform to this 
     document SHOULD always include the publicKey field. The publicKey 
     field can be omitted when the public key has been distributed via 
     another mechanism, which is beyond the scope of this document.  
     Given the private key and the parameters the public key can always 
     be recomputed, this field exists as a convenience to the consumer. 

4. Other Considerations 

   When generating a transfer encoding, generators SHOULD use DER 
   [X.690] and receivers SHOULD be prepared to handle BER [X.690] and 
   DER [X.690]. 
 
 
Turner & Brown           Expires June 4, 2010                  [Page 3] 

Internet-Draft   Elliptic Curve Private Key Structure     December 2009 
    

   Local storage of an unencrypted ECPrivateKey object is out of scope 
   of this document.  However, one popular format uses the .pem file 
   extension.  It is a PEM encoding, which is the Base64 encoding 
   [RFC4648], of the DER encoded ECPrivateKey object sandwiched between: 

   -----BEGIN EC PRIVATE KEY----- 
   -----END EC PRIVATE KEY----- 

   Another local storage format uses the .der file extension.  In this 
   case, it is a DER [X.609] encoding of the ECPrivateKey object. 

   Local storage of an encrypted ECPrivateKey object is out of scope of 
   this document.  However, ECPrivateKey should be the format for the 
   plaintext key being encrypted, and DER encoding it will promote 
   interoperability if the key is encrypted for transport to another 
   party.  See [RFC5208]. 

5. Security Considerations 

   This structure does not protect the EC private key information in any 
   way.  This structure should be combined with a security protocol to 
   protect it.  

   Protection of the private-key information is vital to public-key 
   cryptography.  Disclosure of the private-key material to another 
   entity can lead to masquerades.  The encryption algorithm used in the 
   encryption process must be as 'strong' as the key it is protecting. 

6. IANA Considerations 

   None: All identifiers are already registered.  Please remove this 
   section prior to publication as an RFC. 

7. References 

 7.1. Normative References 

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

   [RFC3447]  Kaliski, B., and J. Jonsson, "Public-Key Cryptography 
               Standards (PKCS) #1: RSA Cryptography Specifications 
               Version 2.1", RFC 3447, February 2003. 

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data 
               Encodings", RFC 4648, October 2006. 



 
 
Turner & Brown           Expires June 4, 2010                  [Page 4] 

Internet-Draft   Elliptic Curve Private Key Structure     December 2009 
    

   [RFC5480]  Turner, S., Brown, D., Yiu, K., Housley, R., and W. Polk, 
               "Elliptic Curve Cryptography Subject Public Key 
               Information", RFC 5480, March 2009. 

   [RFCXXXX]  Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX", 
               draft-ietf-pkix-new-asn1-07.txt, work-in-progress. 

   /** 
         RFC Editor: Please replace "RFCXXXX" with "RFC####" where ### 
         is the number of the published RFC. 
   **/ 

   [SECG1]    Standards for Efficient Cryptography Group (SECG), "SEC 
               1: Elliptic Curve Cryptography", Version 2.0, May 2009. 

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

 7.2. Informative References 

   [RFC5208]  Kaliski, B., "Public-Key Cryptography Standards (PKCS) 
               #8: Private-Key Information Syntax Specification Version 
               1.2, RFC 5208, May 2008. 














 
 
Turner & Brown           Expires June 4, 2010                  [Page 5] 

Internet-Draft   Elliptic Curve Private Key Structure     December 2009 
    

 Appendix A ASN.1 Module 

   This appendix provides 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] for compilers that support the 
   2002 ASN.1.  

   ECPrivateKey-2009-02 { id-tbd } 

   DEFINITIONS EXPLICIT TAGS ::= 

   BEGIN 

   -- EXPORTS ALL; 

   IMPORTS 

   -- FROM [RFCXXXX] 

   ECParameters, NamedCurve 
     FROM PKIXAlgs-2009 
       { iso(1) identified-organization(3) dod(6) internet(1) 
         security(5) mechanisms(5) pkix(7) id-mod(0) 
         id-mod-pkix1-algorithms2008-02(56) } 

   ; 

   ECPrivateKey ::= SEQUENCE { 
     version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), 
     privateKey     OCTET STRING, 
     parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 
     publicKey  [1] BIT STRING OPTIONAL 
   }  

   END 

Acknowledgements 

   The authors would like to thank Simon Blake-Wilson and John O. Goyo 
   for their work on defining the structure in [SECG1].  The authors 
   would also like to thank Pasi Eronen, Alfred Hoenes, Russ Housley, 
   and Jim Schaad for their comments. 







 
 
Turner & Brown           Expires June 4, 2010                  [Page 6] 

Internet-Draft   Elliptic Curve Private Key Structure     December 2009 
    

Authors' Addresses 

   Sean Turner 
   IECA, Inc. 
   3057 Nutley Street, Suite 106 
   Fairfax, VA 22031 
   USA 

   EMail: turners@ieca.com 

   Daniel R. L. Brown 
   Certicom Corp 
   5520 Explorer Drive #400 
   Mississauga, ON L4W 5L1 
   CANADA 

   Email: dbrown@certicom.com 

    






























 
 
Turner & Brown           Expires June 4, 2010                  [Page 7]

PAFTECH AB 2003-20262026-04-23 03:56:37