[要約] RFC 5915は、楕円曲線暗号の秘密鍵の構造に関する仕様です。このRFCの目的は、楕円曲線暗号の秘密鍵の表現と交換を標準化することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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:
この構文は、PKCS＃8 [RFC5208]で定義されているように、PrivateKeyInfoを使用してECプライベートキーを配布する場合に役立ちます。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）octet stringであるprivatekeyフィールドのecprivatekey。
When an EC public key is included in the distributed PrivateKeyInfo, the publicKey field in ECPrivateKey is used.
ECの公開キーが分散型PrivateKeyInfoに含まれている場合、EcprivateKeyのPublicKeyフィールドが使用されます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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:
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はプライベートキーです。これは、[RFC3447]で定義されている整数からオクテットの弦楽 - プリミティブ（I2OSP）を介して、符号なしの整数から得られた、長さの天井のオクテット文字列（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は、特定の楕円曲線ドメインパラメーターのセットに必要な値を完全に識別するオブジェクト識別子です。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 PublicKeyには、問題の秘密鍵に関連付けられた楕円曲線公開キーが含まれています。公開キーの形式は、[RFC5480]のセクション2.2で指定されています。ASN.1はPublicKeyがオプションであることを示していますが、このドキュメントに準拠する実装には、常にPublicKeyフィールドを含める必要があります。PublicKeyフィールドは、このドキュメントの範囲を超えた別のメカニズムを介して公開キーが配布されている場合に省略できます。秘密鍵とパラメーターを考えると、公開鍵はいつでも再計算される可能性があります。この分野は、消費者にとって利便性として存在します。
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オブジェクトのローカルストレージは、このドキュメントの範囲外です。ただし、1つの一般的な形式では、.pemファイル拡張子を使用します。これは、以下の間に挟まれたder-Encoded ecprivateKeyオブジェクトのbase64エンコード（[RFC4648]のセクション4を参照）であるPEMエンコードです。
-----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をエンコードすると、キーが別の当事者への輸送のために暗号化された場合、相互運用性が促進されます。Der-Encoded EcprivateKeyをエンコードするPEMは一般的です。"Proc-Type："および "dek-info：" fields [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] Linn、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] 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、「Public-Key Cryptography Standards（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] Turner、S.、Brown、D.、Yiu、K.、Housley、R。、およびT. Polk、「Elliptic Curve Cryptography Subject Public Key Information」、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. 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）の基準、「Sec 1：Elliptic Curve Cryptography」、バージョン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）、標準エンコーディングルール（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。、「Public-Key Cryptography Standards（PKCS）＃8：Private-Key Information Syntax Specificationバージョン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]で定義されている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) }
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) }
;
;
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つのルーチンは同じ出力をもたらします。
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・ゴヨに感謝したいと思います。著者はまた、パシ・エロネン、アルフレッド・ホーネス、ジョエル・ジェグリー、アヴシャローム・ホイ、ラス・ヒューズリー、ジム・シャード、カール・ウォレスのコメントに感謝したいと思います。
Authors' Addresses
著者のアドレス
Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA
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
Daniel R. L. Brown Certicom Corp 5520 Explorer Drive＃400 Mississauga、L4W 5L1 Canada
EMail: dbrown@certicom.com