idnits 2.17.1 draft-turner-ecprivatekey-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 3, 2010) is 5193 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 269 -- Looks like a reference, but probably isn't: '1' on line 270 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: A later version (-08) exists of draft-ietf-pkix-new-asn1-07 -- Obsolete informational reference (is this intentional?): RFC 5208 (Obsoleted by RFC 5958) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Sean Turner, IECA 2 Internet Draft Dan Brown, Certicom 3 Intended Status: Informational February 3, 2010 4 Expires: August 3, 2010 6 Elliptic Curve Private Key Structure 7 draft-turner-ecprivatekey-04.txt 9 Abstract 11 This document specifies the syntax and semantics for conveying 12 Elliptic Curve (EC) private key information. This syntax and 13 semantics defined herein are based on a similar syntax and semantics 14 defined in Standards for Efficient Cryptography Group (SECG). 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on August 3, 2010. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 1. Introduction 56 This document specifies a syntax and semantics for Elliptic Curve 57 (EC) private key information. EC private key information includes a 58 private key and parameters. Additionally, it may include the 59 corresponding public key. The syntax and semantics defined herein 60 are based on a similar syntax and semantics defined in Standards for 61 Efficient Cryptography Group (SECG) [SECG1]. 63 Most Public Key Infrastructures (PKIs) mandate local key generation; 64 however, there are some PKIs that also support centralized key 65 generation (e.g., the public-private key pair is generated by a CA). 66 The structure defined in this document allows the entity that 67 generates the private and public keys to distribute the key pair and 68 the associated domain parameters. 70 A scenario in which this syntax is useful distributes EC private keys 71 using PrivateKeyInfo, as defined in PKCS #8 [RFC5208]. Distributing 72 an EC private key with PKCS#8 [RFC5208] involves including: 73 a) id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]) with the 74 namedCurve as the parameters in the privateKeyAlgorithm field 75 b) ECPrivateKey in the PrivateKey field, which is an OCTET STRING. 76 When a public key is included, the publicKey field in ECPrivateKey is 77 used. 79 2. Terminology 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 3. Elliptic Curve Private Key Format 87 This section gives the syntax for an EC private key. Computationally 88 an EC private key is an unsigned integer, but for representation, EC 89 private key information SHALL have ASN.1 type ECPrivateKey: 91 ECPrivateKey ::= SEQUENCE { 92 version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), 93 privateKey OCTET STRING, 94 parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 95 publicKey [1] BIT STRING OPTIONAL 96 } 97 The fields of type ECPrivateKey have the following meanings: 99 o version specifies the syntax version number of the elliptic curve 100 private key structure. For this version of the document, it SHALL 101 be set to ecPrivkeyVer1, which is of type INTEGER and whose value 102 is one (1). 104 o privateKey is the private key. It is an octet string of length 105 ceiling (log2(n/8)) (where n is the order of the curve) obtained 106 from the unsigned integer via the Integer-to-Octet-String- 107 Primitive (I2OSP) defined in [RFC3447]. 109 o parameters specifies the elliptic curve domain parameters 110 associated to the private key. The type ECParameters are discussed 111 in [RFC5480]. As specified in [RFC5480], only the namedCurve 112 CHOICE is permitted. namedCurve is an object identifier that fully 113 identifies the required values for a particular set of elliptic 114 curve domain parameters. Though the ASN.1 indicates that the 115 parameters field is OPTIONAL, implementations that conform to this 116 document MUST always include the parameters field. 118 o publicKey contains the elliptic curve public key associated with 119 the private key in question. The format of the public key is 120 specified in Section 2.2 of [RFC5480]. Though the ASN.1 indicates 121 publicKey is OPTIONAL, implementations that conform to this 122 document SHOULD always include the publicKey field. The publicKey 123 field can be omitted when the public key has been distributed via 124 another mechanism, which is beyond the scope of this document. 125 Given the private key and the parameters the public key can always 126 be recomputed; this field exists as a convenience to the consumer. 128 4. Other Considerations 130 When generating a transfer encoding, generators SHOULD use DER 131 [X.690] and receivers SHOULD be prepared to handle BER [X.690] and 132 DER [X.690]. 134 Section 1 described a format for transporting EC private keys (i.e., 135 converting ECPrivateKey to PrivateKeyInfo [PKCS#8]); however, this 136 format can also be used for local storage. 138 Local storage of an unencrypted ECPrivateKey object is out of scope 139 of this document. However, one popular format uses the .pem file 140 extension. It is a PEM encoding, which is the Base64 encoding 141 [RFC4648], of the DER encoded ECPrivateKey object sandwiched between: 143 -----BEGIN EC PRIVATE KEY----- 144 -----END EC PRIVATE KEY----- 145 Another local storage format uses the .der file extension. In this 146 case, it is a DER [X.690] encoding of the ECPrivateKey object. 148 Local storage of an encrypted ECPrivateKey object is out of scope of 149 this document. However, ECPrivateKey should be the format for the 150 plaintext key being encrypted. DER [X.690] encoding ECPrivateKey 151 will promote interoperability if the key is encrypted for transport 152 to another party. PEM encoding the DER encoded ECPrivateKey is 153 common; "Proc-Type:" and "DEK-INFO:" fields [RFC1421] followed by the 154 DER Encoded ECPrivateKey are sandwiched between: 156 -----BEGIN EC PRIVATE KEY----- 157 -----END EC PRIVATE KEY----- 159 5. Security Considerations 161 This structure does not protect the EC private key information in any 162 way. This structure should be combined with a security protocol to 163 protect it. 165 Protection of the private-key information is vital to public-key 166 cryptography. The consequences of disclosure depends on the purpose 167 of the private key. If a private key is used for signature, then the 168 disclosure allows unauthorized signing. If a private key is used for 169 key management, then disclosure allows unauthorized parties to access 170 the managed keying material. The encryption algorithm used in the 171 encryption process must be as 'strong' as the key it is protecting. 173 6. IANA Considerations 175 None: All identifiers are already registered. Please remove this 176 section prior to publication as an RFC. 178 7. References 180 7.1. Normative References 182 [RFC1421] J. Linn, "Privacy Enhancement for Internet Electronic 183 Mail: Part I: Message Encryption and Authentication 184 Procedures," RFC 1421, February 1993. 186 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", BCP 14, RFC 2119, March 1997. 189 [RFC3447] Kaliski, B., and J. Jonsson, "Public-Key Cryptography 190 Standards (PKCS) #1: RSA Cryptography Specifications 191 Version 2.1", RFC 3447, February 2003. 193 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 194 Encodings", RFC 4648, October 2006. 196 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and W. Polk, 197 "Elliptic Curve Cryptography Subject Public Key 198 Information", RFC 5480, March 2009. 200 [RFCXXXX] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX", 201 draft-ietf-pkix-new-asn1-07.txt, work-in-progress. 203 /** 204 RFC Editor: Please replace "RFCXXXX" with "RFC####" where ### 205 is the number of the published RFC. 206 **/ 208 [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 209 1: Elliptic Curve Cryptography", Version 2.0, May 2009. 211 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 212 Information Technology - Abstract Syntax Notation One. 214 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 215 Information Technology - Abstract Syntax Notation One: 216 Information Object Specification. 218 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 219 Information Technology - Abstract Syntax Notation One: 220 Constraint Specification. 222 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 223 Information Technology - Abstract Syntax Notation One: 224 Parameterization of ASN.1 Specifications, 2002. 226 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 227 Information Technology - ASN.1 encoding rules: 228 Specification of Basic Encoding Rules (BER), Canonical 229 Encoding Rules (CER) and Distinguished Encoding Rules 230 (DER). 232 7.2. Informative References 234 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) 235 #8: Private-Key Information Syntax Specification Version 236 1.2, RFC 5208, May 2008. 238 Appendix A ASN.1 Module 240 This appendix provides ASN.1 definitions for the structures described 241 in this specification using ASN.1 as defined in [X.680], [X.681], 242 [X.682], and [X.683] for compilers that support the 2002 ASN.1. 244 ECPrivateKey { iso(1) identified-organization(3) dod(6) 245 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 246 id-mod-ecprivateKey(65) } 248 DEFINITIONS EXPLICIT TAGS ::= 250 BEGIN 252 -- EXPORTS ALL; 254 IMPORTS 256 -- FROM New PKIX ASN.1 [RFCXXXX] 258 ECParameters, NamedCurve 259 FROM PKIXAlgs-2009 260 { iso(1) identified-organization(3) dod(6) internet(1) 261 security(5) mechanisms(5) pkix(7) id-mod(0) 262 id-mod-pkix1-algorithms2008-02(56) } 264 ; 266 ECPrivateKey ::= SEQUENCE { 267 version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), 268 privateKey OCTET STRING, 269 parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 270 publicKey [1] BIT STRING OPTIONAL 271 } 273 END 275 Appendix B Differences with SECG1 277 This appendix lists the differences between this document and 278 [SECG1]: 280 1. This document uses the I2OSP routine defined in [RFC3447] while 281 SECG1 defines its own routine. The two routines result in the same 282 output. 284 2. SECG1 constrains its parameters (i.e., the curves) to 285 SECGCurveNames. This document constrains the parameters to 286 NamedCurve from [RFC5480]. 288 3. This document requires parameters be present while SECG1 does not. 290 4. This document specifies requirements for encoding rules while 291 SECG1 did not. 293 Acknowledgements 295 The authors would like to thank Simon Blake-Wilson and John O. Goyo 296 for their work on defining the structure in [SECG1]. The authors 297 would also like to thank Pasi Eronen, Alfred Hoenes, Joel Jaegglie, 298 Avshalom Houri, Russ Housley, Jim Schaad, and Carl Wallace for their 299 comments. 301 Authors' Addresses 303 Sean Turner 304 IECA, Inc. 305 3057 Nutley Street, Suite 106 306 Fairfax, VA 22031 307 USA 309 EMail: turners@ieca.com 311 Daniel R. L. Brown 312 Certicom Corp 313 5520 Explorer Drive #400 314 Mississauga, ON L4W 5L1 315 CANADA 317 Email: dbrown@certicom.com