Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5915 IECA
Category: Informational D. Brown
ISSN: 2070-1721 Certicom
June 2010
Internet Engineering Task Force (IETF) S. Turner
Request for Comments: 5915 IECA
Category: Informational D. Brown
ISSN: 2070-1721 Certicom
June 2010
Elliptic Curve Private Key Structure
椭圆曲线私钥结构
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).
本文档规定了传递椭圆曲线（EC）私钥信息的语法和语义。本文定义的语法和语义基于高效密码组标准（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 Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5915.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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) [SECG1].
本文档指定了椭圆曲线（EC）私钥信息的语法和语义。EC私钥信息包括私钥和参数。此外，它可以包括相应的公钥。本文定义的语法和语义基于高效加密集团标准（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 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.
大多数公钥基础设施（PKI）要求生成本地密钥；但是，有些PKI也支持集中密钥生成（例如，公私密钥对由证书颁发机构生成）。本文档中定义的结构允许生成私钥和公钥的实体分发密钥对和相关域参数。
This syntax is useful when distributing EC private keys using PrivateKeyInfo, as defined in PKCS #8 [RFC5208]. Distributing an EC private key with PKCS#8 [RFC5208] involves including:
此语法在使用PrivateKeyInfo分发EC私钥时非常有用，如PKCS#8[RFC5208]中所定义。使用PKCS#8[RFC5208]分发EC私钥包括：
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.
a) id ecPublicKey、id ecDH或id ecMQV（来自[RFC5480]），名称为curve作为privateKeyAlgorithm字段中的参数；b）PrivateKey字段中的ECPrivateKey，它是一个八位字节字符串。
When an EC public key is included in the distributed PrivateKeyInfo, the publicKey field in ECPrivateKey is used.
当分布式PrivateKeyInfo中包含EC公钥时，将使用ECPrivateKey中的公钥字段。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
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:
本节给出EC私钥的语法。计算上，EC私钥是无符号整数，但为了表示，EC私钥信息应具有ASN.1类型的ECPrivateKey：
ECPrivateKey ::= SEQUENCE {
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
privateKey OCTET STRING,
parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
publicKey [1] BIT STRING OPTIONAL
}
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:
ECPrivateKey类型的字段具有以下含义：
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 version指定椭圆曲线私钥结构的语法版本号。对于本版本的文件，应将其设置为ECPRIVEKEYVER1，类型为整数，其值为一（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 privateKey是私钥。它是长度上限为log2（n）/8（其中n是曲线的顺序）的八位字节字符串，通过[RFC3447]中定义的整数到八位字节字符串原语（I2OSP）从无符号整数获得。
o parameters specifies the elliptic curve domain parameters associated to the private key. The type ECParameters is discussed in [RFC5480]. As specified in [RFC5480], 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 parameters指定与私钥关联的椭圆曲线域参数。[RFC5480]中讨论了类型参数。如[RFC5480]所述，仅允许选择namedCurve。namedCurve是一个对象标识符，它完全标识一组特定椭圆曲线域参数所需的值。尽管ASN.1指出参数字段是可选的，但符合本文档的实现必须始终包含参数字段。
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.
o 公钥包含与相关私钥关联的椭圆曲线公钥。[RFC5480]第2.2节规定了公钥的格式。尽管ASN.1指出公钥是可选的，但是符合本文档的实现应该始终包括公钥字段。当公钥已通过其他机制分发时，可以省略公钥字段，这超出了本文档的范围。给定私钥和参数，公钥总是可以重新计算；此字段的存在是为了方便消费者。
When generating a transfer encoding, generators SHOULD use Distinguished Encoding Rules (DER) [X.690] and receivers SHOULD be prepared to handle Basic Encoding Rules (BER) [X.690] and DER [X.690].
生成传输编码时，生成器应使用可分辨编码规则（DER）[X.690]，接收方应准备好处理基本编码规则（BER）[X.690]和DER[X.690]。
Section 1 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.
第1节描述了传输EC私钥的格式（即，将ECPrivateKey转换为PrivateKeyInfo[PKCS#8]）；但是，此格式也可用于本地存储。
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 Section 4 of [RFC4648]), of the DER-encoded ECPrivateKey object that is sandwiched between:
未加密ECPrivateKey对象的本地存储超出了本文档的范围。但是，一种流行的格式使用.pem文件扩展名。这是PEM编码，即DER编码的ECPrivateKey对象的Base64编码（参见[RFC4648]第4节），它夹在以下两者之间：
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
-----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.690] encoding of the ECPrivateKey object.
另一种本地存储格式使用.der文件扩展名。在这种情况下，它是ECPrivateKey对象的DER[X.690]编码。
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 [X.690] 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 [RFC1421] followed by the DER-encoded ECPrivateKey are sandwiched between:
加密的ECPrivateKey对象的本地存储超出了本文档的范围。但是，ECPrivateKey应该是加密的明文密钥的格式。DER[X.690]对ECPrivateKey进行编码将促进互操作性，前提是对密钥进行加密以传输到另一方。PEM编码DER编码的ECPrivateKey是常见的；“Proc Type:”和“DEK-INFO:”字段[RFC1421]后跟DER编码的ECPrivateKey夹在以下字段之间：
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
-----BEGIN EC PRIVATE KEY-----
-----END EC PRIVATE KEY-----
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.
此结构不会以任何方式保护EC私钥信息。该结构应与安全协议相结合以保护它。
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.
私钥信息的保护对于公钥密码学至关重要。披露的后果取决于私钥的用途。如果私钥用于签名，则公开允许未经授权的签名。如果私钥用于密钥管理，则披露允许未经授权方访问托管密钥材料。加密过程中使用的加密算法必须与其所保护的密钥一样“强大”。
[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[RFC1421]Linn，J.，“互联网电子邮件的隐私增强：第一部分：信息加密和认证程序”，RFC 14211993年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC4648，2006年10月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]Turner，S.，Brown，D.，Yiu，K.，Housley，R.，和T.Polk，“椭圆曲线加密主题公钥信息”，RFC 54802009年3月。
[RFC5912] Schaad, J. and P. Hoffman, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)" RFC 5912, June 2010.
[RFC5912]Schaad，J.和P.Hoffman，“使用X.509（PKIX）的公钥基础设施的新ASN.1模块”，RFC 5912，2010年6月。
[SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009.
[SECG1]高效密码集团标准（SECG），“第1节：椭圆曲线密码术”，版本2.0，2009年5月。
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, Information Technology - Abstract Syntax Notation One.
[X.680]ITU-T建议X.680（2002）| ISO/IEC 8824-1:2002，信息技术-抽象语法符号一。
[X.681] ITU-T Recommendation X.681 (2002) | ISO/IEC 8824-2:2002, Information Technology - Abstract Syntax Notation One: Information Object Specification.
[X.681]ITU-T建议X.681（2002）| ISO/IEC 8824-2:2002，信息技术-抽象语法符号1：信息对象规范。
[X.682] ITU-T Recommendation X.682 (2002) | ISO/IEC 8824-3:2002, Information Technology - Abstract Syntax Notation One: Constraint Specification.
[X.682]ITU-T建议X.682（2002）| ISO/IEC 8824-3:2002，信息技术-抽象语法符号1：约束规范。
[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.
[X.683]ITU-T建议X.683（2002）| ISO/IEC 8824-4:2002，信息技术-抽象语法符号一：ASN.1规范的参数化，2002年。
[X.690] 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).
[X.690]ITU-T建议X.690（2002）| ISO/IEC 8825-1:2002，信息技术-ASN.1编码规则：基本编码规则（BER）、规范编码规则（CER）和区分编码规则（DER）规范。
[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2", RFC 5208, May 2008.
[RFC5208]Kaliski，B.，“公钥密码标准（PKCS）#8：私钥信息语法规范版本1.2”，RFC 5208，2008年5月。
This appendix provides 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.
本附录使用[X.680]、[X.681]、[X.682]和[X.683]中定义的ASN.1为支持2002 ASN.1的编译器提供了本规范中所述结构的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) }
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 ::=
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
开始
-- EXPORTS ALL;
--全部出口；
IMPORTS
进口
-- FROM New PKIX ASN.1 [RFC5912]
--来自新的PKIX ASN.1[RFC5912]
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) }
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
}
ECPrivateKey ::= SEQUENCE {
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
privateKey OCTET STRING,
parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
publicKey [1] BIT STRING OPTIONAL
}
END
终止
This appendix lists the differences between this document and [SECG1]:
本附录列出了本文件与[SECG1]之间的差异：
1. This document uses the I2OSP routine defined in [RFC3447] while SECG1 defines its own routine. The two routines result in the same output.
1. 本文档使用[RFC3447]中定义的I2OSP例程，而SECG1定义了自己的例程。这两个例程产生相同的输出。
2. SECG1 constrains its parameters (i.e., the curves) to SECGCurveNames. This document constrains the parameters to NamedCurve from [RFC5480].
2. SECG1将其参数（即曲线）约束为SECGCurveNames。本文档将参数限制为[RFC5480]中的NamedCurve。
3. This document requires parameters be present while SECG1 does not.
3. 本文档要求参数存在，而SECG1不存在。
4. This document specifies requirements for encoding rules while SECG1 did not.
4. 本文件规定了编码规则的要求，而SECG1没有规定。
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, Joel Jaegglie, Avshalom Houri, Russ Housley, Jim Schaad, and Carl Wallace for their comments.
作者要感谢Simon Blake Wilson和John O.Goyo在[SECG1]中定义结构的工作。作者还想感谢帕西·埃隆、阿尔弗雷德·霍恩斯、乔尔·贾格利、阿夫沙洛姆·胡里、罗斯·霍斯利、吉姆·沙阿德和卡尔·华莱士的评论。
Authors' Addresses
作者地址
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
Sean Turner IECA，Inc.美国弗吉尼亚州费尔法克斯市努特利街3057号106室，邮编22031
EMail: turners@ieca.com
EMail: turners@ieca.com
Daniel R. L. Brown Certicom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1 Canada
Daniel R.L.Brown Certicom Corp 5520探索者大道#400号，位于加拿大密西西比州的L4W 5L1
EMail: dbrown@certicom.com
EMail: dbrown@certicom.com