idnits 2.17.00 (12 Aug 2021) /tmp/idnits3668/draft-turner-ecprivatekey-03.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 2, 2010) is 4490 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 272 -- Looks like a reference, but probably isn't: '1' on line 273 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) == Outdated reference: draft-ietf-pkix-new-asn1 has been published as RFC 5912 -- 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 2, 2010 4 Expires: August 2, 2010 6 Elliptic Curve Private Key Structure 7 draft-turner-ecprivatekey-03.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 2, 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 There are two possible locations to carry a public key. When one is 77 included, the publicKey field in the ECPrivateKey is used. The 78 publicKey field in PKCS#8 is not used. 80 2. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 3. Elliptic Curve Private Key Format 88 This section gives the syntax for an EC private key. Computationally 89 an EC private key is an unsigned integer, but for representation, EC 90 private key information SHALL have ASN.1 type ECPrivateKey: 92 ECPrivateKey ::= SEQUENCE { 93 version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), 94 privateKey OCTET STRING, 95 parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 96 publicKey [1] BIT STRING OPTIONAL 97 } 99 The fields of type ECPrivateKey have the following meanings: 101 o version specifies the syntax version number of the elliptic curve 102 private key structure. For this version of the document, it SHALL 103 be set to ecPrivkeyVer1, which is of type INTEGER and whose value 104 is one (1). 106 o privateKey is the private key. It is an octet string of length 107 ceiling (log2(n/8)) (where n is the order of the curve) obtained 108 from the unsigned integer via the Integer-to-Octet-String- 109 Primitive (I2OSP) defined in [RFC3447]. 111 o parameters specifies the elliptic curve domain parameters 112 associated to the private key. The type ECParameters are discussed 113 in [RFC5480]. As specified in [RFC5480], only the namedCurve 114 CHOICE is permitted. namedCurve is an object identifier that fully 115 identifies the required values for a particular set of elliptic 116 curve domain parameters. Though the ASN.1 indicates that the 117 parameters field is OPTIONAL, implementations that conform to this 118 document MUST always include the parameters field. 120 o publicKey contains the elliptic curve public key associated with 121 the private key in question. The format of the public key is 122 specified in Section 2.2 of [RFC5480]. Though the ASN.1 indicates 123 publicKey is OPTIONAL, implementations that conform to this 124 document SHOULD always include the publicKey field. The publicKey 125 field can be omitted when the public key has been distributed via 126 another mechanism, which is beyond the scope of this document. 127 Given the private key and the parameters the public key can always 128 be recomputed; this field exists as a convenience to the consumer. 130 4. Other Considerations 132 When generating a transfer encoding, generators SHOULD use DER 133 [X.690] and receivers SHOULD be prepared to handle BER [X.690] and 134 DER [X.690]. 136 Section 1 described a format for transporting EC private keys (i.e., 137 converting ECPrivateKey to PrivateKeyInfo [PKCS#8]); however, this 138 format can also be used for local storage. 140 Local storage of an unencrypted ECPrivateKey object is out of scope 141 of this document. However, one popular format uses the .pem file 142 extension. It is a PEM encoding, which is the Base64 encoding 143 [RFC4648], of the DER encoded ECPrivateKey object sandwiched between: 145 -----BEGIN EC PRIVATE KEY----- 146 -----END EC PRIVATE KEY----- 148 Another local storage format uses the .der file extension. In this 149 case, it is a DER [X.690] encoding of the ECPrivateKey object. 151 Local storage of an encrypted ECPrivateKey object is out of scope of 152 this document. However, ECPrivateKey should be the format for the 153 plaintext key being encrypted. DER [X.690] encoding ECPrivateKey 154 will promote interoperability if the key is encrypted for transport 155 to another party. PEM encoding the DER encoded ECPrivateKey is 156 common; "Proc-Type:" and "DEK-INFO:" fields [RFC1421] followed by the 157 DER Encoded ECPrivateKey are sandwiched between: 159 -----BEGIN EC PRIVATE KEY----- 160 -----END EC PRIVATE KEY----- 162 5. Security Considerations 164 This structure does not protect the EC private key information in any 165 way. This structure should be combined with a security protocol to 166 protect it. 168 Protection of the private-key information is vital to public-key 169 cryptography. The consequences of disclosure depends on the purpose 170 of the private key. If a private key is used for signature, then the 171 disclosure allows unauthorized signing. If a private key is used for 172 key management, then disclosure allows unauthorized parties to access 173 the managed keying material. The encryption algorithm used in the 174 encryption process must be as 'strong' as the key it is protecting. 176 6. IANA Considerations 178 None: All identifiers are already registered. Please remove this 179 section prior to publication as an RFC. 181 7. References 183 7.1. Normative References 185 [RFC1421] J. Linn, "Privacy Enhancement for Internet Electronic 186 Mail: Part I: Message Encryption and Authentication 187 Procedures," RFC 1421, February 1993. 189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 190 Requirement Levels", BCP 14, RFC 2119, March 1997. 192 [RFC3447] Kaliski, B., and J. Jonsson, "Public-Key Cryptography 193 Standards (PKCS) #1: RSA Cryptography Specifications 194 Version 2.1", RFC 3447, February 2003. 196 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 197 Encodings", RFC 4648, October 2006. 199 [RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and W. Polk, 200 "Elliptic Curve Cryptography Subject Public Key 201 Information", RFC 5480, March 2009. 203 [RFCXXXX] Schaad, J., and P. Hoffman, "New ASN.1 Modules for PKIX", 204 draft-ietf-pkix-new-asn1-07.txt, work-in-progress. 206 /** 207 RFC Editor: Please replace "RFCXXXX" with "RFC####" where ### 208 is the number of the published RFC. 209 **/ 211 [SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 212 1: Elliptic Curve Cryptography", Version 2.0, May 2009. 214 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002. 215 Information Technology - Abstract Syntax Notation One. 217 [X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002. 218 Information Technology - Abstract Syntax Notation One: 219 Information Object Specification. 221 [X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002. 222 Information Technology - Abstract Syntax Notation One: 223 Constraint Specification. 225 [X.683] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002. 226 Information Technology - Abstract Syntax Notation One: 227 Parameterization of ASN.1 Specifications, 2002. 229 [X.690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002. 230 Information Technology - ASN.1 encoding rules: 231 Specification of Basic Encoding Rules (BER), Canonical 232 Encoding Rules (CER) and Distinguished Encoding Rules 233 (DER). 235 7.2. Informative References 237 [RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) 238 #8: Private-Key Information Syntax Specification Version 239 1.2, RFC 5208, May 2008. 241 Appendix A ASN.1 Module 243 This appendix provides ASN.1 definitions for the structures described 244 in this specification using ASN.1 as defined in [X.680], [X.681], 245 [X.682], and [X.683] for compilers that support the 2002 ASN.1. 247 ECPrivateKey { iso(1) identified-organization(3) dod(6) 248 internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 249 id-mod-ecprivateKey(65) } 251 DEFINITIONS EXPLICIT TAGS ::= 253 BEGIN 255 -- EXPORTS ALL; 257 IMPORTS 259 -- FROM New PKIX ASN.1 [RFCXXXX] 261 ECParameters, NamedCurve 262 FROM PKIXAlgs-2009 263 { iso(1) identified-organization(3) dod(6) internet(1) 264 security(5) mechanisms(5) pkix(7) id-mod(0) 265 id-mod-pkix1-algorithms2008-02(56) } 267 ; 269 ECPrivateKey ::= SEQUENCE { 270 version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1), 271 privateKey OCTET STRING, 272 parameters [0] ECParameters {{ NamedCurve }} OPTIONAL, 273 publicKey [1] BIT STRING OPTIONAL 274 } 276 END 277 Appendix B Differences with SECG1 279 This appendix lists the differences between this document and 280 [SECG1]: 282 1. This document uses the I2OSP routine defined in [RFC3447] while 283 SECG1 defines its own routine. The two routines result in the same 284 output. 286 2. SECG1 constrains its parameters (i.e., the curves) to 287 SECGCurveNames. This document constrains the parameters to 288 NamedCurve from [RFC5480]. 290 3. This document requires parameters be present while SECG1 does not. 292 4. This document specifies requirements for encoding rules while 293 SECG1 did not. 295 Acknowledgements 297 The authors would like to thank Simon Blake-Wilson and John O. Goyo 298 for their work on defining the structure in [SECG1]. The authors 299 would also like to thank Pasi Eronen, Alfred Hoenes, Joel Jaegglie, 300 Avshalom Houri, Russ Housley, Jim Schaad, and Carl Wallace for their 301 comments. 303 Authors' Addresses 305 Sean Turner 306 IECA, Inc. 307 3057 Nutley Street, Suite 106 308 Fairfax, VA 22031 309 USA 311 EMail: turners@ieca.com 313 Daniel R. L. Brown 314 Certicom Corp 315 5520 Explorer Drive #400 316 Mississauga, ON L4W 5L1 317 CANADA 319 Email: dbrown@certicom.com