[要約] RFC 5480は、X.509証明書とCertificate Revocation Lists (CRLs)における楕円曲線暗号(ECC)の公開鍵の使用を規定しています。この文書の目的は、ECC公開鍵を扱う際のデータ構造とアルゴリズムの識別子を標準化することにあります。これにより、デジタル署名、鍵交換、鍵導出などのセキュリティ機能を提供する際の互換性と信頼性が向上します。関連するRFCにはRFC 5280（X.509証明書とCRLのプロファイル）、RFC 3279（他の暗号アルゴリズムの公開鍵の仕様）、RFC 4492（TLSでのECCの使用）などがあります。RFC 5480は、セキュリティが重要な通信において、効率的かつ強固な暗号化手段を提供するための基盤を築いています。
Network Working Group S. Turner
Request for Comments: 5480 IECA
Updates: 3279 D. Brown
Category: Standards Track Certicom
K. Yiu
Microsoft
R. Housley
Vigil Security
T. Polk
NIST
March 2009
Elliptic Curve Cryptography Subject Public Key Information
楕円曲線暗号化対象公開鍵情報
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279.
このドキュメントは、楕円曲線暗号化をサポートする証明書の主題公開情報フィールドの構文とセマンティクスを指定します。このドキュメントは、セクション2.3.5および5、および「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイルのアルゴリズムと識別子」のASN.1モジュールを更新します。RFC3279。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Subject Public Key Information Fields ...........................3
2.1. Elliptic Curve Cryptography Public Key Algorithm
Identifiers ................................................3
2.2. Subject Public Key .........................................7
3. Key Usage Bits ..................................................7
4. Security Considerations .........................................8
5. ASN.1 Considerations ...........................................10
6. IANA Considerations ............................................11
7. Acknowledgments ................................................11
8. References .....................................................11
8.1. Normative References ......................................11
8.2. Informative References ....................................12
Appendix A. ASN.1 Module ..........................................13
This document specifies the format of the subjectPublicKeyInfo field in X.509 certificates [PKI] that use Elliptic Curve Cryptography (ECC). It updates RFC 3279 [PKI-ALG]. This document specifies the encoding formats for public keys used with the following ECC algorithms:
このドキュメントは、楕円曲線暗号化（ECC）を使用するX.509証明書[PKI]のsubjectpublickeyinfoフィールドの形式を指定します。RFC 3279 [pki-alg]を更新します。このドキュメントは、次のECCアルゴリズムで使用されるパブリックキーのエンコード形式を指定します。
o Elliptic Curve Digital Signature Algorithm (ECDSA);
o 楕円曲線デジタル署名アルゴリズム（ECDSA）;
o Elliptic Curve Diffie-Hellman (ECDH) family schemes; and
o 楕円曲線diffie-hellman（ECDH）ファミリースキーム。と
o Elliptic Curve Menezes-Qu-Vanstone (ECMQV) family schemes.
o 楕円曲線Menezes-qu-Vanstone（ECMQV）ファミリースキーム。
Two methods for specifying the algorithms that can be used with the subjectPublicKey are defined. One method allows the key to be used with any ECC algorithm, while the other method restricts the usage of the key to specific algorithms. To promote interoperability, this document indicates which is required to implement for Certification Authorities (CAs) that implement ECC algorithms and relying parties that claim to process ECC algorithms.
subjectpublickeyで使用できるアルゴリズムを指定する2つの方法が定義されています。1つのメソッドでは、キーを任意のECCアルゴリズムで使用できますが、もう1つのメソッドは特定のアルゴリズムのキーの使用を制限します。相互運用性を促進するために、このドキュメントは、ECCアルゴリズムを実装し、ECCアルゴリズムを処理すると主張する当事者に依存する認定当局（CAS）に実装するために必要なものを示します。
The ASN.1 [X.680] module in this document includes ASN.1 for ECC algorithms. It also includes ASN.1 for non-ECC algorithms defined in [PKI-ALG] and [PKI-ADALG], even though the associated text is unaffected. By updating all of the ASN.1 from [PKI-ALG] in this document, implementers only need to use the module found in this document.
このドキュメントのASN.1 [X.680]モジュールには、ECCアルゴリズムのASN.1が含まれます。また、関連するテキストが影響を受けていない場合でも、[pki-alg]および[pki-adalg]で定義された非ECCアルゴリズムのASN.1も含まれます。このドキュメントの[pki-alg]からすべてのASN.1を更新することにより、実装者はこのドキュメントにあるモジュールを使用する必要のみが必要です。
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 [MUSTSHOULD].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[必須]に記載されているように解釈される。
In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax:
X.509証明書では、件名PublicKeyInfoフィールドには件名PublicKeyInfoタイプがあり、次のASN.1構文があります。
SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING
}
The fields in SubjectPublicKeyInfo have the following meanings:
subjectpublickeyinfoのフィールドには、次の意味があります。
o algorithm is the algorithm identifier and parameters for the ECC public key.
o アルゴリズムは、ECC公開キーのアルゴリズム識別子とパラメーターです。
o subjectPublicKey is the ECC public key. See Section 2.2.
o subjectpublickeyはECC公開キーです。セクション2.2を参照してください。
The AlgorithmIdentifier type, which is included for convenience [PKI], is defined as follows:
利便性[PKI]のために含まれているアルゴリズムIdentifierタイプは、次のように定義されています。
AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL
}
The fields in AlgorithmIdentifier have the following meanings:
Algorithmidentifierのフィールドには、次の意味があります。
o algorithm identifies the cryptographic algorithm with an object identifier. See Section 2.1.
o アルゴリズムは、オブジェクト識別子を使用して暗号化アルゴリズムを識別します。セクション2.1を参照してください。
o parameters, which are optional, are the associated parameters for the algorithm identifier in the algorithm field. See Section 2.1.1.
o オプションであるパラメーターは、アルゴリズムフィールドのアルゴリズム識別子の関連パラメーターです。セクション2.1.1を参照してください。
The algorithm field in the SubjectPublicKeyInfo structure [PKI] indicates the algorithm and any associated parameters for the ECC public key (see Section 2.2). Three algorithm identifiers are defined in this document:
件名PublicKeyInfo構造[PKI]のアルゴリズムフィールドは、ECC公開キーのアルゴリズムと関連するパラメーターを示します（セクション2.2を参照）。このドキュメントでは、3つのアルゴリズム識別子が定義されています。
o id-ecPublicKey indicates that the algorithms that can be used with the subject public key are unrestricted. The key is only restricted by the values indicated in the key usage certificate extension (see Section 3). id-ecPublicKey MUST be supported. See Section 2.1.1. This value is also included in certificates when a public key is used with ECDSA.
o ID-Ecpublickeyは、主題の公開キーで使用できるアルゴリズムが無制限であることを示しています。キーは、キー使用証明書延長に示されている値によってのみ制限されます（セクション3を参照）。id-ecpublickeyをサポートする必要があります。セクション2.1.1を参照してください。この値は、ECDSAで公開キーが使用される場合にも証明書に含まれています。
o id-ecDH indicates that the algorithm that can be used with the subject public key is restricted to the Elliptic Curve Diffie-Hellman algorithm. See Section 2.1.2. id-ecDH MAY be supported.
o ID-ECDHは、サブジェクトの公開キーで使用できるアルゴリズムが楕円曲線diffie-hellmanアルゴリズムに制限されていることを示します。セクション2.1.2を参照してください。ID-ECDHがサポートされる場合があります。
o id-ecMQV indicates that the algorithm that can be used with the subject public key is restricted to the Elliptic Curve Menezes-Qu-Vanstone key agreement algorithm. See Section 2.1.2. id-ecMQV MAY be supported.
o ID-ECMQVは、サブジェクトの公開キーとともに使用できるアルゴリズムが楕円曲線Menezes-QU-Vanstoneキー契約アルゴリズムに制限されていることを示します。セクション2.1.2を参照してください。ID-ECMQVがサポートされる場合があります。
The "unrestricted" algorithm identifier is:
「無制限の」アルゴリズム識別子は次のとおりです。
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
The public key (ECPoint) syntax is described in Section 2.2.
公開キー（ECPOINT）構文については、セクション2.2で説明しています。
The parameter for id-ecPublicKey is as follows and MUST always be present:
id-ecpublickeyのパラメーターは次のとおりであり、常に存在する必要があります。
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X9.
The fields in ECParameters have the following meanings:
Ecparametersのフィールドには次の意味があります。
o namedCurve identifies all the required values for a particular set of elliptic curve domain parameters to be represented by an object identifier. This choice MUST be supported. See Section 2.1.1.1.
o namedCurveは、オブジェクト識別子によって表される楕円曲線ドメインパラメーターの特定のセットに必要なすべての値を識別します。この選択をサポートする必要があります。セクション2.1.1.1を参照してください。
o implicitCurve allows the elliptic curve domain parameters to be inherited. This choice MUST NOT be used.
o ImplicitCurveを使用すると、楕円曲線ドメインパラメーターを継承できます。この選択を使用してはなりません。
o specifiedCurve, which is of type SpecifiedECDomain type (defined in [X9.62]), allows all of the elliptic curve domain parameters to be explicitly specified. This choice MUST NOT be used. See Section 5, "ASN.1 Considerations".
o 指定されたセカムタイプ（[x9.62]で定義）の型であるspecifiedcurveは、すべての楕円曲線ドメインパラメーターを明示的に指定できるようにします。この選択を使用してはなりません。セクション5「ASN.1考慮事項」を参照してください。
The addition of any new choices in ECParameters needs to be coordinated with ANSI X9.
Ecparametersに新しい選択肢を追加することは、ANSI X9と調整する必要があります。
The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place within a certificate where the elliptic curve domain parameters may be located. If the elliptic curve domain parameters are not present, then clients MUST reject the certificate.
subjectpublickeyinfo内のアルゴリズムdididentifierは、楕円曲線ドメインパラメーターを配置できる証明書内の唯一の場所です。楕円曲線ドメインパラメーターが存在しない場合、クライアントは証明書を拒否する必要があります。
The namedCurve field in ECParameters uses object identifiers to name well-known curves. This document publishes curve identifiers for the fifteen NIST-recommended curves [FIPS186-3]. Other documents can publish other name curve identifiers. The NIST-named curves are:
EcparametersのAndamentCurveフィールドは、オブジェクト識別子を使用して、よく知られている曲線を挙げます。このドキュメントでは、15のNIST推奨曲線[FIPS186-3]の曲線識別子を公開しています。他のドキュメントは、他の名前の曲線識別子を公開できます。NIST名の曲線は次のとおりです。
-- Note that in [X9.62] the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example, secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in [PKI-ALG] the secp192r1 curve was referred to as
-- prime192v1 and the secp256r1 curve was referred to as
-- prime256v1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
-- P-224, secp256r1 as P-256, secp384r1 as P-384, and secp521r1 as
-- P-521.
secp192r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 1 }
sect163k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 1 }
sect163r2 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 15 }
secp224r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 33 }
sect233k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 26 }
sect233r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 27 }
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
sect283k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 16 }
sect283r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 17 }
secp384r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 34 }
sect409k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 36 }
sect409r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 37 }
secp521r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 35 }
sect571k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 38 }
sect571r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 39 }
Two "restricted" algorithms are defined for key agreement algorithms: the Elliptic Curve Diffie-Hellman (ECDH) key agreement family schemes and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement family schemes. Both algorithms are identified by an object identifier and have parameters. The object identifier varies based on the algorithm, but the parameters are always ECParameters and they MUST always be present (see Section 2.1.1).
主要な契約アルゴリズムに対して2つの「制限された」アルゴリズムが定義されています：楕円曲線diffie-hellman（ecdh）キー契約ファミリースキームと楕円曲線Menezes-qu-vanstone（ECMQV）キー契約ファミリースキーム。両方のアルゴリズムはオブジェクト識別子によって識別され、パラメーターがあります。オブジェクト識別子はアルゴリズムに基づいて異なりますが、パラメーターは常にエクパラメーターであり、常に存在する必要があります（セクション2.1.1を参照）。
The ECDH algorithm uses the following object identifier:
ECDHアルゴリズムは、次のオブジェクト識別子を使用します。
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
The ECMQV algorithm uses the following object identifier:
ECMQVアルゴリズムは、次のオブジェクト識別子を使用します。
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key. ECC public keys have the following syntax:
subjectpublickeyinfoのsubjectpublickeyはECC公開キーです。ECCパブリックキーには次の構文があります。
ECPoint ::= OCTET STRING
Implementations of Elliptic Curve Cryptography according to this document MUST support the uncompressed form and MAY support the compressed form of the ECC public key. The hybrid form of the ECC public key from [X9.62] MUST NOT be used. As specified in [SEC1]:
楕円曲線暗号化の実装このドキュメントによると、非圧縮フォームをサポートし、ECC公開キーの圧縮形式をサポートする必要があります。[x9.62]のECC公開キーのハイブリッド形式を使用してはなりません。[SEC1]で指定されているように：
o The elliptic curve public key (a value of type ECPoint that is an OCTET STRING) is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, and so on; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. Conversion routines are found in Sections 2.3.1 and 2.3.2 of [SEC1].
o Elliptic Curveの公開キー（Octet文字列であるタイプECポイントの値）は、次のように件名（タイプビット文字列の値）にマッピングされます。文字列値など;Octet文字列の最も重要なビットは、ビット文字列の最も重要なビットになります。変換ルーチンは、[SEC1]のセクション2.3.1および2.3.2にあります。
o The first octet of the OCTET STRING indicates whether the key is compressed or uncompressed. The uncompressed form is indicated by 0x04 and the compressed form is indicated by either 0x02 or 0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if any other value is included in the first octet.
o Octet文字列の最初のオクテットは、キーが圧縮されているか非圧縮されているかを示します。非圧縮フォームは0x04で示され、圧縮形式は0x02または0x03で示されます（[SEC1]の2.3.3を参照）。最初のオクテットに他の値が含まれている場合、公開鍵は拒否されなければなりません。
If the keyUsage extension is present in a Certification Authority (CA) certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, then any combination of the following values MAY be present:
keyUSAGE拡張機能が、subjectpublickeyinfoのid-ecpublickeyを示す認定機関（CA）証明書に存在する場合、次の値の任意の組み合わせが存在する場合があります。
digitalSignature;
nonRepudiation;
keyAgreement;
keyCertSign; and
cRLSign.
If the CA certificate keyUsage extension asserts keyAgreement, then it MAY assert either encipherOnly or decipherOnly. However, this specification RECOMMENDS that if keyCertSign or cRLSign is present, then keyAgreement, encipherOnly, and decipherOnly SHOULD NOT be present.
CA証明書KeyUSAGE拡張がKeyAgreementを主張する場合、cipheronlyまたはDecipheronlyのいずれかを主張する場合があります。ただし、この仕様では、keycertsignまたはcrlsignが存在する場合、keyagreement、cipheronly、およびdecipheronlyが存在しないことを推奨しています。
If the keyUsage extension is present in an End Entity (EE) certificate that indicates id-ecPublicKey in SubjectPublicKeyInfo, then any combination of the following values MAY be present:
keyuSage拡張機能が、subjectpublickeyinfoのid-ecpublickeyを示す最終エンティティ（EE）証明書に存在する場合、次の値の任意の組み合わせが存在する場合があります。
digitalSignature; nonRepudiation; and keyAgreement.
デジタル署名;非控除;およびキーアグメント。
If the EE certificate keyUsage extension asserts keyAgreement, then it MAY assert either encipherOnly or decipherOnly.
EE証明書KeyUSAGE拡張がKeyAgreementを主張する場合、cipheronlyまたはDecipheronlyのいずれかを主張する場合があります。
If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following MUST be present:
keyUSAGE拡張機能が、subjectpublickeyinfoでid-ecdhまたはid-ecmqvを示す証明書に存在する場合、以下が存在する必要があります。
keyAgreement;
keyagreement;
one of the following MAY be present:
次のいずれかが存在する場合があります。
encipherOnly; or decipherOnly.
cifheronly;またはdecipheronly。
If the keyUsage extension is present in a certificate that indicates id-ecDH or id-ecMQV in SubjectPublicKeyInfo, then the following values MUST NOT be present:
keyUSAGE拡張機能が、subjectpublickeyinfoでid-ecdhまたはid-ecmqvを示す証明書に存在する場合、次の値を存在しないでください。
digitalSignature;
nonRepudiation;
keyTransport;
keyCertSign; and
cRLSign.
The security considerations in [PKI-ALG] apply.
[pki-alg]のセキュリティ上の考慮事項が適用されます。
When implementing ECC in X.509 Certificates and Certificate Revocation Lists (CRLs), there are three algorithm-related choices that need to be made for the signatureAlgorithm field in a Certificate or CertificateList: 1) What is the public key size?
X.509証明書と証明書の取り消しリスト（CRL）にECCを実装する場合、証明書または証明書の署名項目フィールドに対して行う必要がある3つのアルゴリズム関連の選択肢があります。
2) What is the hash algorithm [FIPS180-3]?
2) ハッシュアルゴリズム[FIPS180-3]とは何ですか？
3) What is the curve?
3) 曲線は何ですか？
Consideration must be given by the CA to the strength of the security provided by each of these choices. Security is measured in bits, where a strong symmetric cipher with a key of X bits is said to provide X bits of security. It is recommended that the bits of security provided by each choice are roughly equivalent. The following table provides comparable minimum bits of security [SP800-57] for the ECDSA key sizes and message digest algorithms. It also lists curves (see Section 2.1.1.1) for the key sizes.
CAは、これらのそれぞれの選択によって提供されるセキュリティの強さを考慮しなければなりません。セキュリティはビットで測定されます。ビットでは、Xビットのキーを持つ強力な対称暗号がXビットのセキュリティを提供すると言われています。各選択によって提供されるセキュリティのビットは、ほぼ同等であることをお勧めします。次の表は、ECDSAキーサイズとメッセージダイジェストアルゴリズムのセキュリティ[SP800-57]の同等の最小ビットを示しています。また、キーサイズの曲線（セクション2.1.1.1を参照）をリストします。
Minimum | ECDSA | Message | Curves
Bits of | Key Size | Digest |
Security | | Algorithms |
---------+----------+------------+-----------
80 | 160-223 | SHA-1 | sect163k1
| | SHA-224 | secp163r2
| | SHA-256 | secp192r1
| | SHA-384 |
| | SHA-512 |
---------+----------+------------+-----------
112 | 224-255 | SHA-224 | secp224r1
| | SHA-256 | sect233k1
| | SHA-384 | sect233r1
| | SHA-512 |
---------+----------+------------+-----------
128 | 256-383 | SHA-256 | secp256r1
| | SHA-384 | sect283k1
| | SHA-512 | sect283r1
---------+----------+------------+-----------
192 | 384-511 | SHA-384 | secp384r1
| | SHA-512 | sect409k1
| | | sect409r1
---------+----------+------------+-----------
256 | 512+ | SHA-512 | secp521r1
| | | sect571k1
| | | sect571r1
---------+----------+------------+-----------
To promote interoperability, the following choices are RECOMMENDED:
Minimum | ECDSA | Message | Curves
Bits of | Key Size | Digest |
Security | | Algorithms |
---------+----------+------------+-----------
80 | 192 | SHA-256 | secp192r1
---------+----------+------------+-----------
112 | 224 | SHA-256 | secp224r1
---------+----------+------------+-----------
128 | 256 | SHA-256 | secp256r1
---------+----------+------------+-----------
192 | 384 | SHA-384 | secp384r1
---------+----------+------------+-----------
256 | 512 | SHA-512 | secp521r1
---------+----------+------------+-----------
Using a larger hash value and then truncating it consumes more processing power than is necessary. This is more important on constrained devices. Since the signer does not know the environment that the recipient will use to validate the signature, it is better to use a hash function that provides the desired hash value output size, and no more.
より大きなハッシュ値を使用してから、それを切り捨てると、必要以上の処理能力が消費されます。これは、制約されたデバイスでより重要です。署名者は、受信者が署名を検証するために使用する環境を知らないため、目的のハッシュ値出力サイズを提供するハッシュ関数を使用する方が良いです。
There are security risks with using keys not associated with well-known and widely reviewed curves. For example, the curve may not satisfy the Menezes-Okamoto-Vanstone (MOV) condition [X9.62] or the curve may be vulnerable to the Anomalous attack [X9.62]. Additionally, either a) all of the arithmetic properties of a candidate ECC public key must be validated to ensure that it has the unique correct representation in the correct (additive) subgroup (and therefore is also in the correct EC group) specified by the associated ECC domain parameters, or b) some of the arithmetic properties of a candidate ECC public key must be validated to ensure that it is in the correct group (but not necessarily the correct subgroup) specified by the associated ECC domain parameters [SP800-56A].
よく知られている広くレビューされた曲線に関連付けられていないキーを使用することには、セキュリティリスクがあります。たとえば、曲線は、メネゼス・オカモト・ヴァンストーン（MOV）条件[x9.62]を満たしていないか、曲線が異常な攻撃[x9.62]に対して脆弱である可能性があります。さらに、a）候補ECC公開キーのすべての算術プロパティを検証して、関連する（したがって、添加剤）サブグループ（したがって、正しいECグループにもある）に固有の正しい表現があることを確認する必要があります。ECCドメインパラメーター、またはb）候補ECC公開キーの算術特性の一部を検証して、関連するECCドメインパラメーター[SP800-56A]によって指定された正しいグループ（必ずしも正しいサブグループ）にあることを確認する必要があります。。
As noted in [PKI-ALG], the use of MD2 and MD5 for new applications is discouraged. It is still reasonable to use MD2 and MD5 to verify existing signatures.
[PKI-Alg]で述べたように、新しいアプリケーションにMD2とMD5の使用が推奨されています。MD2とMD5を使用して既存の署名を検証することは依然として妥当です。
[X9.62] defines additional options for ECParameters and ECDSA-Sig-Value [PKI-ALG]. If an implementation needs to use these options, then use the [X9.62] ASN.1 module. This RFC contains a conformant subset of the ASN.1 module defined in [X9.62].
[X9.62]は、EcParametersおよびECDSA-SIG-Value [PKI-Alg]の追加オプションを定義します。実装でこれらのオプションを使用する必要がある場合は、[x9.62] asn.1モジュールを使用します。このRFCには、[x9.62]で定義されているASN.1モジュールの適合サブセットが含まれています。
If an implementation generates a PER [X.691] encoding using the ASN.1 module found in this specification, it might not achieve the same encoded output as one that uses the [X9.62] module. PER is not required by either the PKIX or S/MIME environments. If an implementation environment requires PER, then implementation concerns are less likely with the use of the [X9.62] module.
この仕様にあるASN.1モジュールを使用して実装が[x.691]を生成する場合、[x9.62]モジュールを使用するものと同じエンコード出力を達成できない場合があります。PKIXまたはS/MIME環境のいずれでもPERは必要ありません。実装環境がPERを必要とする場合、[X9.62]モジュールの使用により、実装の懸念は低くなります。
This document makes extensive use of object identifiers to register public key types, elliptic curves, and algorithms. Most are registered in the ANSI X9.62 arc, with the exception of the hash algorithms (which are in the NIST arc) and many of the curves (which are in the Certicom Inc. arc; these curves have been adopted by ANSI and NIST). Additionally, an object identifier is used to identify the ASN.1 module found in Appendix A. It is defined in an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates.
このドキュメントは、オブジェクト識別子を広く使用して、公開キータイプ、楕円曲線、およびアルゴリズムを登録します。ほとんどがANSI X9.62アークに登録されていますが、ハッシュアルゴリズム（NISTアークにある）と多くの曲線（Certicom Inc. ARCにあります。これらの曲線はANSIおよびNISTによって採用されています。）。さらに、オブジェクト識別子は、付録AにあるASN.1モジュールを識別するために使用されます。これは、IANAによってPKIXワーキンググループに委任されたアークで定義されています。このドキュメントまたは予想される更新には、IANAによるさらなるアクションは必要ありません。
The authors wish to thank Stephen Farrell, Alfred Hoenes, Johannes Merkle, Jim Schaad, and Carl Wallace for their valued input.
著者は、Stephen Farrell、Alfred Hoenes、Johannes Merkle、Jim Schaad、およびCarl Wallaceの大切な入力に感謝したいと考えています。
[FIPS180-3] National Institute of Standards and Technology (NIST), FIPS Publication 180-3: Secure Hash Standard, October 2008.
[FIPS180-3]国立標準技術研究所（NIST）、FIPS出版180-3：Secure Hash Standard、2008年10月。
[FIPS186-3] National Institute of Standards and Technology (NIST), FIPS Publication 186-3: Digital Signature Standard, (draft) November 2008.
[FIPS186-3]国立標準技術研究所（NIST）、FIPS Publication 186-3：Digital Signature Standard、（ドラフト）2008年11月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[PKI] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[PKI] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、「Internet X.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル"、RFC 5280、2008年5月。
[PKI-ALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[Pki-Alg] Bassham、L.、Polk、W。、およびR. Housley、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイルのアルゴリズムと識別子」、RFC 3279、2002年4月。
[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 4055, June 2005.
[RSAOAEP] Schaad、J.、Kaliski、B。、およびR. Housley、「インターネットで使用するRSA暗号化の追加アルゴリズムと識別子X.509公開鍵インフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 4055、2005年6月。
[SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 1.0, September 2000.
[SEC1]効率的な暗号化グループ（SECG）の基準、「Sec 1：Elliptic Curve Cryptography」、バージョン1.0、2000年9月。
[X9.62] American National Standards Institute (ANSI), ANS X9.62-2005: The Elliptic Curve Digital Signature Algorithm (ECDSA), 2005.
[X9.62] American National Standards Institute（ANSI）、ANS X9.62-2005：The Elliptic Curve Digital Signature Algorithm（ECDSA）、2005年。
[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。
[PKI-ADALG] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. Polk, "Internet X.509 Public Key Infrastructure: Additional Algorithms and Identifiers for DSA and ECDSA", Work in Progress, October 2008.
[Pki-Adalg] Dang、Q.、Santesson、S.、Moriarty、K.、Brown、D。、およびT. Polk、「Internet X.509公開キーインフラストラクチャ：DSAおよびECDSAの追加アルゴリズムと識別子」、仕事進行中、2008年10月。
[SP800-56A] National Institute of Standards and Technology (NIST), Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised), March 2007.
[SP800-56A]国立標準技術研究所（NIST）、特別出版800-56A：2007年3月、個別の対数暗号化（改訂）を使用したペアワイズの主要確立スキームの推奨。
[SP800-57] National Institute of Standards and Technology (NIST), Special Publication 800-57: Recommendation for Key Management - Part 1 (Revised), March 2007.
[SP800-57]国立標準技術研究所（NIST）、特別出版800-57：キー管理の推奨 - パート1（改訂）、2007年3月。
[X.691] ITU-T Recommendation X.691 (2002) | ISO/IEC 8825-2:2002. Information Technology - ASN.1 Encoding Rules: Specification of Packed Encoding Rules.
[X.691] ITU-T推奨X.691（2002）|ISO/IEC 8825-2：2002。情報技術-ASN.1エンコーディングルール：パックされたエンコードルールの仕様。
PKIX1Algorithms2008 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 45 }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
始める
-- EXPORTS ALL;
- すべてをエクスポートします。
IMPORTS
輸入
-- From RFC 4055 [RSAOAEP]
-RFC4055から[rsaoaep]
id-sha224, id-sha256, id-sha384, id-sha512
FROM PKIX1-PSS-OAEP-Algorithms
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-rsa-pkalgs(33) }
;
;
-- -- Message Digest Algorithms --
---メッセージダイジェストアルゴリズム -
-- MD-2
-- Parameters are NULL
id-md2 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 2 }
-- MD-5
-- Parameters are NULL
id-md5 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549)digestAlgorithm(2) 5 }
-- SHA-1
-- Parameters are preferred absent
id-sha1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) oiw(14) secsig(3)
algorithm(2) 26 }
-- SHA-224
-- Parameters are preferred absent
-- id-sha224 OBJECT IDENTIFIER ::= {
-- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
-- csor(3) nistalgorithm(4) hashalgs(2) 4 }
-- SHA-256
-- Parameters are preferred absent
-- id-sha256 OBJECT IDENTIFIER ::= {
-- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
-- csor(3) nistalgorithm(4) hashalgs(2) 1 }
-- SHA-384
-- Parameters are preferred absent
-- id-sha384 OBJECT IDENTIFIER ::= {
-- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
-- csor(3) nistalgorithm(4) hashalgs(2) 2 }
-- SHA-512
-- Parameters are preferred absent
-- id-sha512 OBJECT IDENTIFIER ::= {
-- joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
-- csor(3) nistalgorithm(4) hashalgs(2) 3 }
-- -- Public Key (PK) Algorithms --
---公開キー（PK）アルゴリズム -
-- RSA PK Algorithm and Key
-RSA PKアルゴリズムとキー
rsaEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1 }
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e
}
-- DSA PK Algorithm, Key, and Parameters
-DSA PKアルゴリズム、キー、およびパラメーター
id-dsa OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 }
DSAPublicKey ::= INTEGER -- public key, y
DSS-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER
}
-- Diffie-Hellman PK Algorithm, Key, and Parameters
-diffie-hellman PKアルゴリズム、キー、およびパラメーター
dhpublicnumber OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-x942(10046) number-type(2) 1 }
DHPublicKey ::= INTEGER -- public key, y = g^x mod p
DomainParameters ::= SEQUENCE {
p INTEGER, -- odd prime, p=jq +1
g INTEGER, -- generator, g
q INTEGER, -- factor of p-1
j INTEGER OPTIONAL, -- subgroup factor, j>= 2
validationParms ValidationParms OPTIONAL
}
ValidationParms ::= SEQUENCE {
seed BIT STRING,
pgenCounter INTEGER
}
-- KEA PK Algorithm and Parameters
-KEA PKアルゴリズムとパラメーター
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101)
dod(2) infosec(1) algorithms(1) 22 }
KEA-Parms-Id ::= OCTET STRING
-- Sec 2.1.1 Unrestricted Algorithm ID, Key, and Parameters
-- (ECDSA keys use id-ecPublicKey)
id-ecPublicKey OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
ECPoint ::= OCTET STRING
-- Parameters for both Restricted and Unrestricted
- 制限されていないものと制限されていない両方のパラメーター
ECParameters ::= CHOICE {
namedCurve OBJECT IDENTIFIER
-- implicitCurve NULL
-- specifiedCurve SpecifiedECDomain
}
-- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
-- Details for SpecifiedECDomain can be found in [X9.62].
-- Any future additions to this CHOICE should be coordinated
-- with ANSI X9.
-- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECDH
-sec 2.1.2制限されたアルゴリズムID、キー、およびパラメーター：ECDH
id-ecDH OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecdh(12) }
-- ECPoint ::= OCTET STRING
-- Parameters are ECParameters.
- パラメーターはecparametersです。
-- Sec 2.1.2 Restricted Algorithm IDs, Key, and Parameters: ECMQV
-sec 2.1.2制限されたアルゴリズムID、キー、およびパラメーター：ECMQV
id-ecMQV OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) schemes(1)
ecmqv(13) }
-- ECPoint ::= OCTET STRING
-- Parameters are ECParameters.
- パラメーターはecparametersです。
-- -- Signature Algorithms --
---署名アルゴリズム -
-- RSA with MD-2
-- Parameters are NULL
md2WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2 }
-- RSA with MD-5
-- Parameters are NULL
md5WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4 }
-- RSA with SHA-1
-- Parameters are NULL
sha1WithRSAEncryption OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5 }
-- DSA with SHA-1
-- Parameters are ABSENT
id-dsa-with-sha1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 3 }
-- DSA with SHA-224
-- Parameters are ABSENT
id-dsa-with-sha224 OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) algorithms(4) id-dsa-with-sha2(3) 1 }
-- DSA with SHA-256
-- Parameters are ABSENT
id-dsa-with-sha256 OBJECT IDENTIFIER ::= {
joint-iso-ccitt(2) country(16) us(840) organization(1) gov(101)
csor(3) algorithms(4) id-dsa-with-sha2(3) 2 }
-- ECDSA with SHA-1
-- Parameters are ABSENT
ecdsa-with-SHA1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) 1 }
-- ECDSA with SHA-224
-- Parameters are ABSENT
ecdsa-with-SHA224 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 1 }
-- ECDSA with SHA-256
-- Parameters are ABSENT
ecdsa-with-SHA256 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 2 }
-- ECDSA with SHA-384
-- Parameters are ABSENT
ecdsa-with-SHA384 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 3 }
-- ECDSA with SHA-512
-- Parameters are ABSENT
ecdsa-with-SHA512 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4)
ecdsa-with-SHA2(3) 4 }
-- -- Signature Values --
---署名値 -
-- DSA
-DSA
DSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
-- ECDSA
-ECDSA
ECDSA-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
-- -- Named Elliptic Curves --
---名前付き楕円曲線 -
-- Note that in [X9.62] the curves are referred to as 'ansiX9' as
-- opposed to 'sec'. For example secp192r1 is the same curve as
-- ansix9p192r1.
-- Note that in [PKI-ALG] the secp192r1 curve was referred to as
-- prime192v1 and the secp256r1 curve was referred to as prime256v1.
-- Note that [FIPS186-3] refers to secp192r1 as P-192, secp224r1 as
-- P-224, secp256r1 as P-256, secp384r1 as P-384, and secp521r1 as
-- P-521.
secp192r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 1 }
sect163k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 1 }
sect163r2 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 15 }
secp224r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 33 }
sect233k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 26 }
sect233r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 27 }
secp256r1 OBJECT IDENTIFIER ::= {
iso(1) member-body(2) us(840) ansi-X9-62(10045) curves(3)
prime(1) 7 }
sect283k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 16 }
sect283r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 17 }
secp384r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 34 }
sect409k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 36 }
sect409r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 37 }
secp521r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 35 }
sect571k1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 38 }
sect571r1 OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) certicom(132) curve(0) 39 }
END
終わり
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
Kelvin Yiu Microsoft One Microsoft Way Redmond, WA 98052-6399 USA
Kelvin Yiu Microsoft One Microsoft Way Redmond、WA 98052-6399 USA
EMail: kelviny@microsoft.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
Russ Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
Russ Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170 USA
EMail: housley@vigilsec.com
Tim Polk NIST Building 820, Room 426 Gaithersburg, MD 20899
Tim Polk Nist Building 820、Room 426 Gaithersburg、MD 20899
EMail: wpolk@nist.gov