5915
INFORMATIONAL
Elliptic Curve Private Key Structure
Authors: S. Turner, D. Brown
Date: June 2010
Working Group: NON WORKING GROUP
Stream: IETF
Abstract
This document specifies the syntax and semantics for conveying Elliptic Curve (EC) private key information. The syntax and semantics defined herein are based on similar syntax and semantics defined by the Standards for Efficient Cryptography Group (SECG). This document is not an Internet Standards Track specification; it is published for informational purposes.
RFC 5915
INFORMATIONAL
Errata Exist
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5915 IECA
Category: Informational D. Brown
ISSN: 2070-1721 Certicom
June 2010
<span class="h1">Elliptic Curve Private Key Structure</span>
Abstract
This document specifies the syntax and semantics for conveying
Elliptic Curve (EC) private key information. The syntax and
semantics defined herein are based on similar syntax and semantics
defined by the Standards for Efficient Cryptography Group (SECG).
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc5915">http://www.rfc-editor.org/info/rfc5915</a>.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Turner & Brown Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc5915">RFC 5915</a> Elliptic Curve Private Key Structure June 2010</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies a syntax and semantics for Elliptic Curve
(EC) private key information. EC private key information includes a
private key and parameters. Additionally, it may include the
corresponding public key. The syntax and semantics defined herein
are based on similar syntax and semantics defined by the Standards
for Efficient Cryptography Group (SECG) [<a href="#ref-SECG1" title=""SEC 1: Elliptic Curve Cryptography"">SECG1</a>].
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
Certification Authority). The structure defined in this document
allows the entity that generates the private and public keys to
distribute the key pair and the associated domain parameters.
This syntax is useful when distributing EC private keys using
PrivateKeyInfo, as defined in PKCS #8 [<a href="./rfc5208" title=""Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2"">RFC5208</a>]. Distributing an EC
private key with PKCS#8 [<a href="./rfc5208" title=""Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2"">RFC5208</a>] involves including:
a) id-ecPublicKey, id-ecDH, or id-ecMQV (from [<a href="./rfc5480" title=""Elliptic Curve Cryptography Subject Public Key Information"">RFC5480</a>]) with the
namedCurve as the parameters in the privateKeyAlgorithm field; and
b) ECPrivateKey in the PrivateKey field, which is an OCTET STRING.
When an EC public key is included in the distributed PrivateKeyInfo,
the publicKey field in ECPrivateKey is used.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Elliptic Curve Private Key Format</span>
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
}
<span class="grey">Turner & Brown Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc5915">RFC 5915</a> Elliptic Curve Private Key Structure June 2010</span>
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 [<a href="./rfc3447" title=""Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1"">RFC3447</a>].
o parameters specifies the elliptic curve domain parameters
associated to the private key. The type ECParameters is discussed
in [<a href="./rfc5480" title=""Elliptic Curve Cryptography Subject Public Key Information"">RFC5480</a>]. As specified in [<a href="./rfc5480" title=""Elliptic Curve Cryptography Subject Public Key Information"">RFC5480</a>], only the namedCurve
CHOICE is permitted. namedCurve is an object identifier that
fully identifies the required values for a particular set of
elliptic curve domain parameters. Though the ASN.1 indicates that
the parameters field 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 <a href="./rfc5480#section-2.2">Section 2.2 of [RFC5480]</a>. 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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Other Considerations</span>
When generating a transfer encoding, generators SHOULD use
Distinguished Encoding Rules (DER) [<a href="#ref-X.690" title=" Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)">X.690</a>] and receivers SHOULD be
prepared to handle Basic Encoding Rules (BER) [<a href="#ref-X.690" title=" Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)">X.690</a>] and DER
[<a href="#ref-X.690" title=" Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)">X.690</a>].
<a href="#section-1">Section 1</a> described a format for transporting EC private keys (i.e.,
converting ECPrivateKey to PrivateKeyInfo [PKCS#8]); however, this
format can also be used for local storage.
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 the PEM encoding, which is the Base64 encoding (see
<a href="./rfc4648#section-4">Section 4 of [RFC4648]</a>), of the DER-encoded ECPrivateKey object that
is sandwiched between:
<span class="grey">Turner & Brown Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc5915">RFC 5915</a> Elliptic Curve Private Key Structure June 2010</span>
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
Another local storage format uses the .der file extension. In this
case, it is a DER [<a href="#ref-X.690" title=" Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)">X.690</a>] 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. DER [<a href="#ref-X.690" title=" Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER)">X.690</a>] encoding the ECPrivateKey
will promote interoperability if the key is encrypted for transport
to another party. PEM encoding the DER-encoded ECPrivateKey is
common; "Proc-Type:" and "DEK-INFO:" fields [<a href="./rfc1421" title=""Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures"">RFC1421</a>] followed by the
DER-encoded ECPrivateKey are sandwiched between:
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
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. The consequences of disclosure depend on the purpose
of the private key. If a private key is used for signature, then the
disclosure allows unauthorized signing. If a private key is used for
key management, then disclosure allows unauthorized parties to access
the managed keying material. The encryption algorithm used in the
encryption process must be as 'strong' as the key it is protecting.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-RFC1421">RFC1421</a>] Linn, J., "Privacy Enhancement for Internet Electronic
Mail: Part I: Message Encryption and Authentication
Procedures", <a href="./rfc1421">RFC 1421</a>, February 1993.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3447">RFC3447</a>] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", <a href="./rfc3447">RFC 3447</a>, February 2003.
[<a id="ref-RFC4648">RFC4648</a>] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", <a href="./rfc4648">RFC 4648</a>, October 2006.
<span class="grey">Turner & Brown Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc5915">RFC 5915</a> Elliptic Curve Private Key Structure June 2010</span>
[<a id="ref-RFC5480">RFC5480</a>] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk,
"Elliptic Curve Cryptography Subject Public Key
Information", <a href="./rfc5480">RFC 5480</a>, March 2009.
[<a id="ref-RFC5912">RFC5912</a>] Schaad, J. and P. Hoffman, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)" <a href="./rfc5912">RFC 5912</a>,
June 2010.
[<a id="ref-SECG1">SECG1</a>] Standards for Efficient Cryptography Group (SECG), "SEC 1:
Elliptic Curve Cryptography", Version 2.0, May 2009.
[<a id="ref-X.680">X.680</a>] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002,
Information Technology - Abstract Syntax Notation One.
[<a id="ref-X.681">X.681</a>] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002,
Information Technology - Abstract Syntax Notation One:
Information Object Specification.
[<a id="ref-X.682">X.682</a>] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002,
Information Technology - Abstract Syntax Notation One:
Constraint Specification.
[<a id="ref-X.683">X.683</a>] ITU-T Recommendation X.683 (2002) | ISO/IEC 8824-4:2002,
Information Technology - Abstract Syntax Notation One:
Parameterization of ASN.1 Specifications, 2002.
[<a id="ref-X.690">X.690</a>] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002,
Information Technology - ASN.1 encoding rules:
Specification of Basic Encoding Rules (BER), Canonical
Encoding Rules (CER) and Distinguished Encoding Rules
(DER).
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-RFC5208">RFC5208</a>] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8:
Private-Key Information Syntax Specification Version 1.2",
<a href="./rfc5208">RFC 5208</a>, May 2008.
<span class="grey">Turner & Brown Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc5915">RFC 5915</a> Elliptic Curve Private Key Structure June 2010</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. ASN.1 Module</span>
This appendix provides ASN.1 definitions for the structures described
in this specification using ASN.1 as defined in [<a href="#ref-X.680">X.680</a>], [<a href="#ref-X.681">X.681</a>],
[<a href="#ref-X.682">X.682</a>], and [<a href="#ref-X.683" title=" Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications">X.683</a>] for compilers that support the 2002 ASN.1.
ECPrivateKey { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-ecprivateKey(65) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
-- FROM New PKIX ASN.1 [<a href="./rfc5912" title=""New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"">RFC5912</a>]
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
<span class="h2"><a class="selflink" id="appendix-B" href="#appendix-B">Appendix B</a>. Differences with SECG1</span>
This appendix lists the differences between this document and
[<a href="#ref-SECG1" title=""SEC 1: Elliptic Curve Cryptography"">SECG1</a>]:
1. This document uses the I2OSP routine defined in [<a href="./rfc3447" title=""Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1"">RFC3447</a>] while
SECG1 defines its own routine. The two routines result in the
same output.
<span class="grey">Turner & Brown Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc5915">RFC 5915</a> Elliptic Curve Private Key Structure June 2010</span>
2. SECG1 constrains its parameters (i.e., the curves) to
SECGCurveNames. This document constrains the parameters to
NamedCurve from [<a href="./rfc5480" title=""Elliptic Curve Cryptography Subject Public Key Information"">RFC5480</a>].
3. This document requires parameters be present while SECG1 does
not.
4. This document specifies requirements for encoding rules while
SECG1 did not.
Acknowledgements
The authors would like to thank Simon Blake-Wilson and John O. Goyo
for their work on defining the structure in [<a href="#ref-SECG1" title=""SEC 1: Elliptic Curve Cryptography"">SECG1</a>]. The authors
would also like to thank Pasi Eronen, Alfred Hoenes, Joel Jaegglie,
Avshalom Houri, Russ Housley, Jim Schaad, and Carl Wallace for their
comments.
Authors' Addresses
Sean Turner
IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
EMail: [email protected]
Daniel R. L. Brown
Certicom Corp
5520 Explorer Drive #400
Mississauga, ON L4W 5L1
Canada
EMail: [email protected]
Turner & Brown Informational [Page 7]
Annotations
Select text to annotate