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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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プライベートキー情報は、秘密鍵とパラメータを含んでいます。さらに、それは対応する公開鍵を含むことができます。本明細書で定義された構文及び意味論は[SECG1】効率的な暗号グループの規格によって定義された同様の構文と意味論（SECG）に基づいています。
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]）privateKeyAlgorithmフィールドにパラメータとしてnamedCurve有します。およびb）オクテットストリングでのPrivateKey分野でECPrivateKey。
When an EC public key is included in the distributed PrivateKeyInfo, the publicKey field in ECPrivateKey is used.
EC公開鍵を配布PrivateKeyInfoでに含まれている場合は、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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
}
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バージョンは、楕円曲線プライベートキー構造の構文のバージョン番号を指定します。文書のこのバージョンのために、それは整数型とその値が1（1）であるであるecPrivkeyVer1、に設定されます。
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は、秘密鍵です。これは、整数のオクテットストリングプリミティブ（I2OSP）[RFC3447]で定義された介して符号なし整数から得られた長天井（LOG2（N）/ 8）（nは、曲線の次数である）のオクテット列であります。
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パラメータは、秘密鍵に関連付けられた楕円曲線ドメインパラメータを指定します。型ECParametersは、[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秘密鍵を輸送するためのフォーマットを説明し（すなわち、PrivateKeyInfoでECPrivateKey変換[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オブジェクトのローカルストレージは、この文書の範囲外です。しかし、1つの一般的なフォーマットは、.pemファイル拡張子を使用しています。これは、間に挟まれているDER符号化されECPrivateKeyオブジェクトの、Base64エンコードされPEMエンコード、（[RFC4648]のセクション4を参照します）。
-----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型：" および "DEK-INFO：" フィールド[RFC1421] DERエンコードECPrivateKey続くが挟まれています。
-----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]リン、J.、 "インターネット電子メールのためのプライバシー増進：パートI：メッセージの暗号化と認証手順"、RFC 1421、1993年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ジョンソン、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でデータエンコーディング"、RFC 4648、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]ターナー、S.、ブラウン、D.、耀輝、K.、Housley氏、R.、およびT.ポーク、 "楕円曲線暗号件名公開鍵情報"、RFC 5480、2009年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.ホフマン、RFC 5912、2010年6月 "公開鍵インフラストラクチャの使用X.509（PKIX）のための新しいASN.1モジュール"。
[SECG1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009.
[SECG1]効率的な暗号化グループ（SECG）の基準、 "SEC 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、情報技術 - 抽象構文記法1。
[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、情報技術 - 抽象構文記法1：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）の仕様、Canonicalの符号化規則（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月。
Appendix A. ASN.1 Module
付録A. ASN.1モジュール
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.683] [X.680]で定義されるように[X.682]、[X.681]、ASN.1を使用して本明細書に記載した構成のためのASN.1定義を提供し、そして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) }
ECPrivateKey {ISO（1）同定された組織（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（5）PKIX（7）ID-MOD（0）ID-MOD-ecprivateKey（65）}
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、PKIXALGS-2009 {ISO（1）同定された組織からのNamedCurve（3）DOD（6）インターネット（1）セキュリティ（5）メカニズム（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
終わり
Appendix B. Differences with SECG1
SECG1と付録B.違い
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.この文書は、SECG1が独自のルーチンを定義しながら、[RFC3447]で定義されI2OSPルーチンを使用します。 2つのルーチンは同じ出力になります。
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.
著者は、[SECG1]で構造を定義する上で自分の仕事のためにサイモン・ブレイク・ウィルソン、ジョンO.五葉に感謝したいと思います。著者はまた、彼らのコメントのためにパシEronen、アルフレッドHoenes、ジョエルJaegglie、Avshalomフーリー、ラスHousley、ジムSchaad、およびカール・ウォレスに感謝したいと思います。
Authors' Addresses
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
ショーン・ターナーIECA株式会社3057ナトリーストリート、スイート106バージニア州フェアファクス22031 USA
EMail: turners@ieca.com
メールアドレス：turners@ieca.com
Daniel R. L. Brown Certicom Corp 5520 Explorer Drive #400 Mississauga, ON L4W 5L1 Canada
L4W 5L1カナダONダニエル・R. L.ブラウンのCerticom社5520エクスプローラドライブ＃400ミシソーガ、
EMail: dbrown@certicom.com
メールアドレス：dbrown@certicom.com