RFC 5915

Elliptic Curve Private Key Structure 🎀✨

RFC 5915, published by the IETF in June 2010 🌸 It's an Informational doc (not a Standards Track spec), with ISSN 2070-1721. The authors are S. Turner (IECA) and D. Brown (Certicom). The header doesn't list anything it obsoletes or updates, so it's a standalone doc 💅

---

Abstract ✨

okay so this doc is all about how to write down an Elliptic Curve (EC) private key in a standard way 🔐 The rules and meanings are based on what the Standards for Efficient Cryptography Group (SECG) already defined. We're not inventing a new thing here, just making sure everyone's on the same page 🫶

Status of This Memo 📜

tl;dr: this is not an Internet Standards Track spec. It's published just for info 🦋

It's an IETF product, so it reflects consensus from the IETF community. It got public review and was approved by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is up for any level of Internet Standard, though. See Section 2 of RFC 5741 for the deets 💅

Want the latest status, errata, or a place to send feedback? Head to http://www.rfc-editor.org/info/rfc5915 💖

Copyright Notice ©️

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

This doc falls under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. Read those carefully, bestie, because they spell out your rights and restrictions 🧾 Any Code Components pulled out of this doc have to include the Simplified BSD License text (see Section 4.e of the Trust Legal Provisions), and they come with no warranty, as the Simplified BSD License describes 🫶

1. Introduction 🧚

So this doc gives you a syntax and semantics for EC private key information 🔑 That info has a private key and parameters, and it may also include the matching public key 💜 The rules here come from SECG's similar stuff [SECG1] 🍓

Most PKIs require local key generation, which is the main vibe. A few PKIs also do centralized key generation, where a Certification Authority makes the public-private key pair for you 👑 This structure lets whoever generated the keys hand over the key pair and its domain parameters 🎁

This syntax is especially useful when you're sending EC private keys around in PrivateKeyInfo, which is defined in PKCS #8 [RFC5208] 🦋 To distribute an EC private key with PKCS#8 [RFC5208], you include:

• a) id-ecPublicKey, id-ecDH, or id-ecMQV (from [RFC5480]), with the namedCurve as the parameters in the privateKeyAlgorithm field; and
• b) ECPrivateKey in the PrivateKey field, which is an OCTET STRING.

And if an EC public key is part of the distributed PrivateKeyInfo, the publicKey field inside ECPrivateKey is the one that gets used 🫶

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

3. Elliptic Curve Private Key Format 🔐

Here's the syntax for an EC private key ✨ Mathematically, an EC private key is an unsigned integer. For representation, though, EC private key information SHALL have the ASN.1 type ECPrivateKey:

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

Here's what each field of ECPrivateKey means 💖

• version is the syntax version number of the EC private key structure 🎀 For this version of the doc, it SHALL be set to ecPrivkeyVer1, which is an INTEGER with a value of one (1) 🍓
• privateKey is the private key itself 🗝️ It's an octet string of length ceiling (log2(n)/8) (where n is the order of the curve), made from the unsigned integer using the Integer-to-Octet-String-Primitive (I2OSP) defined in [RFC3447] 🧚
• parameters gives the EC domain parameters tied to the private key 👑 The ECParameters type is discussed in [RFC5480]. As [RFC5480] says, only the namedCurve CHOICE is allowed 🙈 namedCurve is an object identifier that fully pins down the values for one particular set of EC domain parameters. Even though the ASN.1 marks parameters as OPTIONAL, implementations that conform to this doc MUST always include the parameters field 🚨
• publicKey holds the EC public key that goes with the private key in question 💜 Its format is specified in Section 2.2 of [RFC5480] 🌸 Even though the ASN.1 says publicKey is OPTIONAL, implementations that conform to this doc SHOULD always include the publicKey field ✨ It can be left out when the public key was distributed some other way, which is outside this doc's scope 🦋 Since you can always recompute the public key from the private key and the parameters, this field is just a convenience for the consumer 🫶

4. Other Considerations 🌈

When you're generating a transfer encoding, generators SHOULD use Distinguished Encoding Rules (DER) [X.690], and receivers SHOULD be ready to handle Basic Encoding Rules (BER) [X.690] as well as DER [X.690] 💅

Section 1 described a format for transporting EC private keys (aka converting ECPrivateKey to PrivateKeyInfo [PKCS#8]). BUT, and this is the fun part 🙈 the same format can also be used for local storage!

Storing an unencrypted ECPrivateKey object locally is out of scope for this doc 🔒 Still, one super popular format uses the .pem file extension 🍓 It's the PEM encoding, which is Base64 (see Section 4 of [RFC4648]) applied to the DER-encoded ECPrivateKey object, sandwiched between these two lines:

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

Another local storage format uses the .der file extension 🧁 In that case, the file is a DER [X.690] encoding of the ECPrivateKey object 💜

Storing an encrypted ECPrivateKey object locally is also out of scope for this doc 🙅 Still, ECPrivateKey should be the format for the plaintext key being encrypted ✨ DER-encoding the ECPrivateKey [X.690] promotes interoperability if the key gets encrypted for transport to another party 🫶 PEM-encoding the DER-encoded ECPrivateKey is common. The Proc-Type: and DEK-INFO: fields [RFC1421] go first, followed by the DER-encoded ECPrivateKey, all sandwiched between:

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

Appendix B. Differences with SECG1 🎀

okay so bestie, this appendix is basically the "how is this different from SECG1" tea ☕ and it's giving very organised list energy 💅 Here's the lowdown on what's changed:

1. This document uses the I2OSP routine defined in [RFC3447] while SECG1 defines its own routine. ✨ Like, two different routines, but they literally give the same output 🫶
2. SECG1 constrains its parameters (i.e., the curves) to SECGCurveNames. 🌸 This document constrains the parameters to NamedCurve from [RFC5480]. 💖 Different name lists, same vibe of "pick from the approved curves" 🧚
3. This document REQUIRES parameters be present 🔥 while SECG1 does not. Like, the parameters are not optional here, bestie 😭
4. This document specifies requirements for encoding rules 🦋 while SECG1 did not. So this one actually spells out how to encode things, no cap 💜

Acknowledgements 🌈

the authors are SO grateful to Simon Blake-Wilson and John O. Goyo for their work on defining the structure in [SECG1] 🙈 They also want to thank Pasi Eronen, Alfred Hoenes, Joel Jaegglie, Avshalom Houri, Russ Housley, Jim Schaad, and Carl Wallace for their comments. Iconic squad 👑✨

---

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 🦋