[要約] RFC 4492は、Transport Layer Security (TLS) プロトコルにおけるElliptic Curve Cryptography (ECC) の使用を定義する文書です。このRFCの目的は、セキュリティを強化しつつ、計算コストを低減するために、TLSプロトコルでのECCの利用方法を標準化することにあります。ECCは、鍵交換、デジタル署名、および鍵導出に利用され、特にリソースが限られた環境や高度なセキュリティが求められる場面で重宝されます。関連するRFCには、RFC 5246 (TLS 1.2の定義) やRFC 8446 (TLS 1.3の定義) などがあり、これらはTLSプロトコルのバージョンアップに伴いECCの利用をさらに推進しています。
Network Working Group S. Blake-Wilson
Request for Comments: 4492 SafeNet
Category: Informational N. Bolyard
Sun Microsystems
V. Gupta
Sun Labs
C. Hawk
Corriente
B. Moeller
Ruhr-Uni Bochum
May 2006
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
トランスポート層セキュリティ（TLS）用の楕円曲線暗号（ECC）暗号スイート
Status of This Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
This document describes new key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Elliptic Curve Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as a new authentication mechanism.
このドキュメントでは、トランスポート層セキュリティ（TLS）プロトコル用の楕円曲線暗号（ECC）に基づく新しい鍵交換アルゴリズムについて説明します。特に、TLSハンドシェイクにおける楕円曲線Diffie-Hellman（ECDH）鍵合意の使用と、新しい認証メカニズムとしての楕円曲線デジタル署名アルゴリズム（ECDSA）の使用を指定しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Key Exchange Algorithms .........................................4
2.1. ECDH_ECDSA .................................................6
2.2. ECDHE_ECDSA ................................................6
2.3. ECDH_RSA ...................................................7
2.4. ECDHE_RSA ..................................................7
2.5. ECDH_anon ..................................................7
3. Client Authentication ...........................................8
3.1. ECDSA_sign .................................................8
3.2. ECDSA_fixed_ECDH ...........................................9
3.3. RSA_fixed_ECDH .............................................9
4. TLS Extensions for ECC ..........................................9
5. Data Structures and Computations ...............................10
5.1. Client Hello Extensions ...................................10
5.1.1. Supported Elliptic Curves Extension ................12
5.1.2. Supported Point Formats Extension ..................13
5.2. Server Hello Extension ....................................14
5.3. Server Certificate ........................................15
5.4. Server Key Exchange .......................................17
5.5. Certificate Request .......................................21
5.6. Client Certificate ........................................22
5.7. Client Key Exchange .......................................23
5.8. Certificate Verify ........................................25
5.9. Elliptic Curve Certificates ...............................26
5.10. ECDH, ECDSA, and RSA Computations ........................26
6. Cipher Suites ..................................................27
7. Security Considerations ........................................28
8. IANA Considerations ............................................29
9. Acknowledgements ...............................................29
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Appendix A. Equivalent Curves (Informative) ......................32
Elliptic Curve Cryptography (ECC) is emerging as an attractive public-key cryptosystem, in particular for mobile (i.e., wireless) environments. Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes. This is illustrated in the following table, based on [18], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best-known algorithms for attacking them.
楕円曲線暗号（ECC）は、特にモバイル（ワイヤレス）環境向けの魅力的な公開鍵暗号システムとして登場しています。 RSAなどの現在普及している暗号化システムと比較して、ECCは同等のセキュリティをより小さな鍵サイズで提供します。これは、[18]に基づく次の表に示されています。これは、対称鍵と非対称鍵の暗号システムに対して、それらを攻撃するための最もよく知られたアルゴリズムに基づいて、おおよその同等の鍵サイズを提供します。
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
Table 1: Comparable Key Sizes (in bits)
表1：比較可能なキーサイズ（ビット単位）
Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for constrained environments.
鍵のサイズを小さくすると、電力、メモリ、帯域幅、および計算コストを節約できるため、ECCは制約のある環境で特に魅力的なものになります。
This document describes additions to TLS to support ECC, applicable both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In particular, it defines
このドキュメントでは、TLSバージョン1.0 [2]とTLSバージョン1.1 [3]の両方に適用可能な、ECCをサポートするためのTLSへの追加について説明します。特に、
o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme with long-term or ephemeral keys to establish the TLS premaster secret, and
o Ellipstic Curve Diffie-Hellman（ECDH）鍵合意方式を使用して、TLSプリマスターシークレットを確立するための長期鍵または短命鍵
o the use of fixed-ECDH certificates and ECDSA for authentication of TLS peers.
o TLSピアの認証のための固定ECDH証明書とECDSAの使用。
The remainder of this document is organized as follows. Section 2 provides an overview of ECC-based key exchange algorithms for TLS. Section 3 describes the use of ECC certificates for client authentication. TLS extensions that allow a client to negotiate the use of specific curves and point formats are presented in Section 4. Section 5 specifies various data structures needed for an ECC-based handshake, their encoding in TLS messages, and the processing of those messages. Section 6 defines new ECC-based cipher suites and identifies a small subset of these as recommended for all implementations of this specification. Section 7 discusses security considerations. Section 8 describes IANA considerations for the name spaces created by this document. Section 9 gives acknowledgements.
このドキュメントの残りの部分は、次のように構成されています。セクション2では、TLSのECCベースのキー交換アルゴリズムの概要を説明します。セクション3では、クライアント認証のためのECC証明書の使用について説明します。クライアントが特定の曲線とポイント形式の使用をネゴシエートできるようにするTLS拡張については、セクション4で説明します。セクション5では、ECCベースのハンドシェイクに必要なさまざまなデータ構造、TLSメッセージでのエンコード、およびそれらのメッセージの処理を指定します。セクション6では、新しいECCベースの暗号スイートを定義し、この仕様のすべての実装に推奨されるこれらの小さなサブセットを識別します。セクション7では、セキュリティの考慮事項について説明します。セクション8では、このドキュメントで作成された名前空間に関するIANAの考慮事項について説明します。セクション9は謝辞を与える。
This is followed by the lists of normative and informative references cited in this document, the authors' contact information, and statements on intellectual property rights and copyrights.
これに続いて、このドキュメントで引用された規範的で有益な参考文献のリスト、著者の連絡先情報、および知的財産権と著作権に関する声明が続きます。
Implementation of this specification requires familiarity with TLS [2][3], TLS extensions [4], and ECC [5][6][7][11][17].
この仕様の実装には、TLS [2] [3]、TLS拡張[4]、およびECC [5] [6] [7] [11] [17]に関する知識が必要です。
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 RFC 2119 [1].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [1]で説明されているように解釈されます。
This document introduces five new ECC-based key exchange algorithms for TLS. All of them use ECDH to compute the TLS premaster secret, and they differ only in the lifetime of ECDH keys (long-term or ephemeral) and the mechanism (if any) used to authenticate them. The derivation of the TLS master secret from the premaster secret and the subsequent generation of bulk encryption/MAC keys and initialization vectors is independent of the key exchange algorithm and not impacted by the introduction of ECC.
このドキュメントでは、TLS用の5つの新しいECCベースのキー交換アルゴリズムを紹介します。それらはすべてECDHを使用してTLSプリマスターシークレットを計算し、ECDHキーの有効期間（長期または一時的）とそれらを認証するために使用されるメカニズム（存在する場合）のみが異なります。プリマスターシークレットからのTLSマスターシークレットの派生、およびその後のバルク暗号化/ MACキーと初期化ベクトルの生成は、キー交換アルゴリズムに依存せず、ECCの導入による影響を受けません。
The table below summarizes the new key exchange algorithms, which mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and [3]), respectively.
以下の表は、DH_DSS、DHE_DSS、DH_RSA、DHE_RSA、およびDH_anon（[2]および[3]を参照）をそれぞれ模倣する新しい鍵交換アルゴリズムをまとめたものです。
Key
Exchange
Algorithm Description
--------- -----------
ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
ECDH_ECDSA ECDSA署名付き証明書を使用する固定ECDH。
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
ECDHE_ECDSA ECDSA署名付きの一時的なECDH。
ECDH_RSA Fixed ECDH with RSA-signed certificates.
ECDH_RSA RSA署名付き証明書を使用する固定ECDH。
ECDHE_RSA Ephemeral ECDH with RSA signatures.
ECDHE_RSA RSA署名付きの一時的なECDH。
ECDH_anon Anonymous ECDH, no signatures.
ECDH_anon匿名ECDH、署名なし。
Table 2: ECC Key Exchange Algorithms
表2：ECC鍵交換アルゴリズム
The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward secrecy. With ECDHE_RSA, a server can reuse its existing RSA certificate and easily comply with a constrained client's elliptic curve preferences (see Section 4). However, the computational cost
ECDHE_ECDSAおよびECDHE_RSA鍵交換メカニズムは、前方秘密性を提供します。 ECDHE_RSAを使用すると、サーバーは既存のRSA証明書を再利用し、制約されたクライアントの楕円曲線の設定に簡単に準拠できます（セクション4を参照）。ただし、計算コスト
incurred by a server is higher for ECDHE_RSA than for the traditional RSA key exchange, which does not provide forward secrecy.
サーバーで発生するECDHE_RSAの方が、転送秘密を提供しない従来のRSA鍵交換よりも高くなります。
The ECDH_RSA mechanism requires a server to acquire an ECC certificate, but the certificate issuer can still use an existing RSA key for signing. This eliminates the need to update the keys of trusted certification authorities accepted by TLS clients. The ECDH_ECDSA mechanism requires ECC keys for the server as well as the certification authority and is best suited for constrained devices unable to support RSA.
ECDH_RSAメカニズムでは、サーバーがECC証明書を取得する必要がありますが、証明書発行者は既存のRSAキーを署名に使用できます。これにより、TLSクライアントが受け入れる信頼された証明機関のキーを更新する必要がなくなります。 ECDH_ECDSAメカニズムには、サーバーと証明機関のECCキーが必要であり、RSAをサポートできない制約されたデバイスに最適です。
The anonymous key exchange algorithm does not provide authentication of the server or the client. Like other anonymous TLS key exchanges, it is subject to man-in-the-middle attacks. Implementations of this algorithm SHOULD provide authentication by other means.
匿名キー交換アルゴリズムは、サーバーまたはクライアントの認証を提供しません。他の匿名TLS鍵交換と同様に、中間者攻撃の対象になります。このアルゴリズムの実装は、他の方法で認証を提供する必要があります（SHOULD）。
Note that there is no structural difference between ECDH and ECDSA keys. A certificate issuer may use X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain computations [15]. This document refers to an ECC key as ECDH-capable if its use in ECDH is permitted. ECDSA-capable is defined similarly.
ECDHキーとECDSAキーの間に構造的な違いはないことに注意してください。証明書発行者は、X.509 v3 keyUsageおよびextendedKeyUsage拡張を使用して、ECC公開鍵の使用を特定の計算に制限することができます[15]。このドキュメントでは、ECDHでの使用が許可されている場合、ECCキーをECDH対応として参照します。 ECDSA対応も同様に定義されます。
Client Server
------ ------
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*+
<-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
* message is not sent under some conditions + message is not sent unless client authentication is desired
* 一部の条件ではメッセージは送信されません+クライアント認証が必要でない限りメッセージは送信されません
Figure 1: Message flow in a full TLS handshake
図1：完全なTLSハンドシェイクでのメッセージフロー
Figure 1 shows all messages involved in the TLS key establishment protocol (aka full handshake). The addition of ECC has direct impact only on the ClientHello, the ServerHello, the server's Certificate message, the ServerKeyExchange, the ClientKeyExchange, the CertificateRequest, the client's Certificate message, and the CertificateVerify. Next, we describe each ECC key exchange algorithm in greater detail in terms of the content and processing of these messages. For ease of exposition, we defer discussion of client authentication and associated messages (identified with a + in Figure 1) until Section 3 and of the optional ECC-specific extensions (which impact the Hello messages) until Section 4.
図1は、TLSキー確立プロトコル（フルハンドシェイク）に関係するすべてのメッセージを示しています。 ECCの追加は、ClientHello、ServerHello、サーバーの証明書メッセージ、ServerKeyExchange、ClientKeyExchange、CertificateRequest、クライアントの証明書メッセージ、およびCertificateVerifyにのみ直接影響します。次に、これらのメッセージの内容と処理の観点から、各ECC鍵交換アルゴリズムについて詳しく説明します。説明を簡単にするために、クライアント認証と関連メッセージ（図1で+で示されています）の説明はセクション3まで、オプションのECC固有の拡張（Helloメッセージに影響を与える）の説明はセクション4まで延期します。
In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public key and be signed with ECDSA.
ECDH_ECDSAでは、サーバーの証明書にECDH対応の公開鍵が含まれ、ECDSAで署名されている必要があります。
A ServerKeyExchange MUST NOT be sent (the server's certificate contains all the necessary keying information required by the client to arrive at the premaster secret).
ServerKeyExchangeを送信してはなりません（サーバーの証明書には、クライアントがプリマスターシークレットに到達するために必要なすべての必要なキー情報が含まれています）。
The client generates an ECDH key pair on the same curve as the server's long-term public key and sends its public key in the ClientKeyExchange message (except when using client authentication algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the modifications from Section 3.2 or Section 3.3 apply).
クライアントは、サーバーの長期公開鍵と同じ曲線でECDH鍵ペアを生成し、その公開鍵をClientKeyExchangeメッセージで送信します（クライアント認証アルゴリズムECDSA_fixed_ECDHまたはRSA_fixed_ECDHを使用する場合を除く）。適用）。
Both client and server perform an ECDH operation and use the resultant shared secret as the premaster secret. All ECDH calculations are performed as specified in Section 5.10.
クライアントとサーバーの両方がECDH操作を実行し、結果の共有シークレットをプリマスターシークレットとして使用します。すべてのECDH計算は、セクション5.10で指定されているように実行されます。
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.
ECDHE_ECDSAでは、サーバーの証明書にECDSA対応の公開鍵が含まれ、ECDSAで署名されている必要があります。
The server sends its ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST be signed with ECDSA using the private key corresponding to the public key in the server's Certificate.
サーバーは、短命ECDH公開鍵と、ServerKeyExchangeメッセージ内の対応する曲線の仕様を送信します。これらのパラメーターは、サーバーの証明書の公開鍵に対応する秘密鍵を使用してECDSAで署名する必要があります。
The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its public key in the ClientKeyExchange message.
クライアントは、サーバーの一時的なECDHキーと同じ曲線でECDHキーペアを生成し、その公開キーをClientKeyExchangeメッセージで送信します。
Both client and server perform an ECDH operation (Section 5.10) and use the resultant shared secret as the premaster secret.
クライアントとサーバーの両方がECDH操作（セクション5.10）を実行し、結果の共有シークレットをプリマスターシークレットとして使用します。
This key exchange algorithm is the same as ECDH_ECDSA except that the server's certificate MUST be signed with RSA rather than ECDSA.
この鍵交換アルゴリズムは、サーバーの証明書がECDSAではなくRSAで署名されている必要があることを除いて、ECDH_ECDSAと同じです。
This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message must be computed with the corresponding RSA private key. The server certificate MUST be signed with RSA.
この鍵交換アルゴリズムはECDHE_ECDSAと同じですが、サーバーの証明書には、署名が許可されたRSA公開鍵が含まれている必要があり、ServerKeyExchangeメッセージの署名は、対応するRSA秘密鍵で計算する必要があります。サーバー証明書はRSAで署名されている必要があります。
In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent.
ECDH_anonでは、サーバーの証明書、CertificateRequest、クライアントの証明書、およびCertificateVerifyメッセージを送信してはなりません（MUST NOT）。
The server MUST send an ephemeral ECDH public key and a specification of the corresponding curve in the ServerKeyExchange message. These parameters MUST NOT be signed.
サーバーは、短命ECDH公開鍵と、ServerKeyExchangeメッセージ内の対応する曲線の仕様を送信する必要があります。これらのパラメータは署名してはいけません。
The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its public key in the ClientKeyExchange message.
クライアントは、サーバーの一時的なECDHキーと同じ曲線でECDHキーペアを生成し、その公開キーをClientKeyExchangeメッセージで送信します。
Both client and server perform an ECDH operation and use the resultant shared secret as the premaster secret. All ECDH calculations are performed as specified in Section 5.10.
クライアントとサーバーの両方がECDH操作を実行し、結果の共有シークレットをプリマスターシークレットとして使用します。すべてのECDH計算は、セクション5.10で指定されているように実行されます。
Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA key exchange algorithms require the server's certificate to be signed with a particular signature scheme, this specification (following the similar cases of DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3]) does not impose restrictions on signature schemes used elsewhere in the certificate chain. (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices. However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a client to completely validate a given chain, the client may be able to validate the server's certificate by relying on a trusted certification authority whose certificate appears as one of the intermediate certificates in the chain.)
ECDH_ECDSA、ECDHE_ECDSA、ECDH_RSA、およびECDHE_RSA鍵交換アルゴリズムでは、サーバーの証明書に特定の署名方式で署名する必要がありますが、この仕様（[2]および[ 3]）は、証明書チェーンの他の場所で使用される署名スキームに制限を課しません。 （多くの場合、このような制限は有用であり、認証局の署名慣行で考慮に入れられることが予想されます。ただし、一般にそのような制限は厳密には必要ありません。完全に検証するクライアントの能力を超えている場合でも特定のチェーンでは、クライアントは、証明書がチェーンの中間証明書の1つとして表示される信頼できる認証局に依存することにより、サーバーの証明書を検証できる場合があります。
This document defines three new client authentication mechanisms, each named after the type of client certificate involved: ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH. The ECDSA_sign mechanism is usable with any of the non-anonymous ECC key exchange algorithms described in Section 2 as well as other non-anonymous (non-ECC) key exchange algorithms defined in TLS [2][3]. The ECDSA_fixed_ECDH and RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the use of a long-term ECDH client key would jeopardize the forward secrecy property of these algorithms.
このドキュメントでは、3つの新しいクライアント認証メカニズムを定義します。それぞれ、関連するクライアント証明書のタイプに基づいて名前が付けられています。ECDSA_sign、ECDSA_fixed_ECDH、およびRSA_fixed_ECDHです。 ECDSA_signメカニズムは、セクション2で説明されている任意の非匿名ECC鍵交換アルゴリズム、およびTLS [2] [3]で定義されている他の非匿名（非ECC）鍵交換アルゴリズムで使用できます。 ECDSA_fixed_ECDHおよびRSA_fixed_ECDHメカニズムは、ECDH_ECDSAおよびECDH_RSAで使用できます。 ECDHE_ECDSAおよびECDHE_RSAと一緒に使用することは禁止されています。長期のECDHクライアントキーを使用すると、これらのアルゴリズムの転送秘密プロパティが危険にさらされるためです。
The server can request ECC-based client authentication by including one or more of these certificate types in its CertificateRequest message. The server must not include any certificate types that are prohibited for the negotiated key exchange algorithm. The client must check if it possesses a certificate appropriate for any of the methods suggested by the server and is willing to use it for authentication.
サーバーは、CertificateRequestメッセージにこれらの証明書タイプの1つ以上を含めることにより、ECCベースのクライアント認証を要求できます。サーバーには、ネゴシエートされたキー交換アルゴリズムで禁止されている証明書の種類を含めないでください。クライアントは、サーバーが提案するいずれかの方法に適した証明書を所有しており、認証にそれを使用するかどうかを確認する必要があります。
If these conditions are not met, the client should send a client Certificate message containing no certificates. In this case, the ClientKeyExchange should be sent as described in Section 2, and the CertificateVerify should not be sent. If the server requires client authentication, it may respond with a fatal handshake failure alert.
これらの条件が満たされない場合、クライアントは証明書を含まないクライアント証明書メッセージを送信する必要があります。この場合、セクション2の説明に従ってClientKeyExchangeを送信し、CertificateVerifyを送信しないでください。サーバーがクライアント認証を必要とする場合、致命的なハンドシェイク失敗アラートで応答することがあります。
If the client has an appropriate certificate and is willing to use it for authentication, it must send that certificate in the client's Certificate message (as per Section 5.6) and prove possession of the private key corresponding to the certified key. The process of determining an appropriate certificate and proving possession is different for each authentication mechanism and described below.
クライアントに適切な証明書があり、それを認証に使用する意思がある場合、クライアントはその証明書をクライアントの証明書メッセージ（セクション5.6に従って）で送信し、認証された鍵に対応する秘密鍵の所有を証明する必要があります。適切な証明書を決定して所持を証明するプロセスは、認証メカニズムごとに異なり、以下で説明します。
NOTE: It is permissible for a server to request (and the client to send) a client certificate of a different type than the server certificate.
注：サーバーがサーバー証明書とは異なるタイプのクライアント証明書を要求する（およびクライアントが送信する）ことは許可されます。
To use this authentication mechanism, the client MUST possess a certificate containing an ECDSA-capable public key and signed with ECDSA.
この認証メカニズムを使用するには、クライアントは、ECDSA対応の公開鍵を含み、ECDSAで署名された証明書を所有している必要があります。
The client proves possession of the private key corresponding to the certified key by including a signature in the CertificateVerify message as described in Section 5.8.
クライアントは、セクション5.8で説明されているように、CertificateVerifyメッセージに署名を含めることにより、認証されたキーに対応する秘密キーの所有を証明します。
To use this authentication mechanism, the client MUST possess a certificate containing an ECDH-capable public key, and that certificate MUST be signed with ECDSA. Furthermore, the client's ECDH key MUST be on the same elliptic curve as the server's long-term (certified) ECDH key. This might limit use of this mechanism to closed environments. In situations where the client has an ECC key on a different curve, it would have to authenticate using either ECDSA_sign or a non-ECC mechanism (e.g., RSA). Using fixed ECDH for both servers and clients is computationally more efficient than mechanisms providing forward secrecy.
この認証メカニズムを使用するには、クライアントはECDH対応の公開鍵を含む証明書を所有している必要があり、その証明書はECDSAで署名されている必要があります。さらに、クライアントのECDHキーは、サーバーの長期（認証済み）ECDHキーと同じ楕円曲線上にある必要があります。これにより、このメカニズムの使用が閉じた環境に制限される可能性があります。クライアントが別の曲線でECCキーを使用している状況では、ECDSA_signまたは非ECCメカニズム（RSAなど）を使用して認証する必要があります。サーバーとクライアントの両方に固定ECDHを使用すると、前方機密を提供するメカニズムよりも計算効率が高くなります。
When using this authentication mechanism, the client MUST send an empty ClientKeyExchange as described in Section 5.7 and MUST NOT send the CertificateVerify message. The ClientKeyExchange is empty since the client's ECDH public key required by the server to compute the premaster secret is available inside the client's certificate. The client's ability to arrive at the same premaster secret as the server (demonstrated by a successful exchange of Finished messages) proves possession of the private key corresponding to the certified public key, and the CertificateVerify message is unnecessary.
この認証メカニズムを使用する場合、クライアントは、セクション5.7で説明されているように空のClientKeyExchangeを送信する必要があり、CertificateVerifyメッセージを送信してはなりません（MUST NOT）。サーバーがプリマスターシークレットを計算するために必要なクライアントのECDH公開鍵はクライアントの証明書内で使用できるため、ClientKeyExchangeは空です。クライアントがサーバーと同じプリマスターシークレットに到達する能力（Finishedメッセージの交換が成功したことで示される）は、証明された公開鍵に対応する秘密鍵の所有を証明し、CertificateVerifyメッセージは不要です。
This authentication mechanism is identical to ECDSA_fixed_ECDH except that the client's certificate MUST be signed with RSA.
この認証メカニズムは、クライアントの証明書がRSAで署名されている必要があることを除いて、ECDSA_fixed_ECDHと同じです。
Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH client authentication mechanisms require the client's certificate to be signed with a particular signature scheme, this specification does not impose restrictions on signature schemes used elsewhere in the certificate chain. (Often such restrictions will be useful, and it is expected that this will be taken into account in certification authorities' signing practices. However, such restrictions are not strictly required in general: Even if it is beyond the capabilities of a server to completely validate a given chain, the server may be able to validate the clients certificate by relying on a trust anchor that appears as one of the intermediate certificates in the chain.)
ECDSA_sign、ECDSA_fixed_ECDH、およびRSA_fixed_ECDHクライアント認証メカニズムでは、クライアントの証明書に特定の署名スキームで署名する必要がありますが、この仕様では、証明書チェーンの他の場所で使用される署名スキームに制限はありません。 （多くの場合、このような制限は有用であり、これは証明機関の署名慣行で考慮に入れられることが予想されます。ただし、一般にそのような制限は厳密には必要ありません。完全に検証するサーバーの機能を超えている場合でも特定のチェーンでは、サーバーは、チェーンの中間証明書の1つとして表示されるトラストアンカーに依存することにより、クライアント証明書を検証できる場合があります。
Two new TLS extensions are defined in this specification: (i) the Supported Elliptic Curves Extension, and (ii) the Supported Point Formats Extension. These allow negotiating the use of specific curves and point formats (e.g., compressed vs. uncompressed, respectively) during a handshake starting a new session. These extensions are especially relevant for constrained clients that may only support a limited number of curves or point formats. They follow the general approach outlined in [4]; message details are specified in Section 5. The client enumerates the curves it supports and the point formats it can parse by including the appropriate extensions in its ClientHello message. The server similarly enumerates the point formats it can parse by including an extension in its ServerHello message.
この仕様では、2つの新しいTLS拡張が定義されています。（i）サポートされる楕円曲線拡張と（ii）サポートされるポイント形式拡張です。これらにより、新しいセッションを開始するハンドシェイク中に、特定の曲線とポイント形式（たとえば、それぞれ圧縮と非圧縮）の使用について交渉できます。これらの拡張機能は、限られた数の曲線またはポイント形式のみをサポートする可能性がある制約のあるクライアントに特に関連しています。それらは[4]で概説されている一般的なアプローチに従います。メッセージの詳細はセクション5で指定されています。クライアントは、ClientHelloメッセージに適切な拡張機能を含めることで、サポートする曲線と解析できるポイント形式を列挙します。サーバーも同様に、ServerHelloメッセージに拡張機能を含めることで、解析できるポイント形式を列挙します。
A TLS client that proposes ECC cipher suites in its ClientHello message SHOULD include these extensions. Servers implementing ECC cipher suites MUST support these extensions, and when a client uses these extensions, servers MUST NOT negotiate the use of an ECC cipher suite unless they can complete the handshake while respecting the choice of curves and compression techniques specified by the client. This eliminates the possibility that a negotiated ECC handshake will be subsequently aborted due to a client's inability to deal with the server's EC key.
ClientHelloメッセージでECC暗号スイートを提案するTLSクライアントには、これらの拡張を含める必要があります（SHOULD）。 ECC暗号スイートを実装するサーバーはこれらの拡張をサポートする必要があり、クライアントがこれらの拡張を使用する場合、サーバーは、クライアントが指定した曲線と圧縮技術の選択を尊重しながらハンドシェイクを完了できない限り、ECC暗号スイートの使用をネゴシエートしてはなりません。これにより、クライアントがサーバーのECキーを処理できないために、ネゴシエートされたECCハンドシェイクが後で中止される可能性がなくなります。
The client MUST NOT include these extensions in the ClientHello message if it does not propose any ECC cipher suites. A client that proposes ECC cipher suites may choose not to include these extensions. In this case, the server is free to choose any one of the elliptic curves or point formats listed in Section 5. That section also describes the structure and processing of these extensions in greater detail.
クライアントは、ECC暗号スイートを提案しない場合、ClientHelloメッセージにこれらの拡張を含めてはなりません（MUST NOT）。 ECC暗号スイートを提案するクライアントは、これらの拡張を含めないことを選択できます。この場合、サーバーはセクション5にリストされている楕円曲線またはポイント形式のいずれかを自由に選択できます。このセクションでは、これらの拡張の構造と処理についても詳しく説明しています。
In the case of session resumption, the server simply ignores the Supported Elliptic Curves Extension and the Supported Point Formats Extension appearing in the current ClientHello message. These extensions only play a role during handshakes negotiating a new session.
セッション再開の場合、サーバーは、現在のClientHelloメッセージに表示されるサポートされる楕円曲線拡張とサポートされるポイント形式拡張を単に無視します。これらの拡張機能は、新しいセッションをネゴシエートするハンドシェイク中にのみ役割を果たします。
This section specifies the data structures and computations used by ECC-based key mechanisms specified in Sections 2, 3, and 4. The presentation language used here is the same as that used in TLS [2][3]. Since this specification extends TLS, these descriptions should be merged with those in the TLS specification and any others that extend TLS. This means that enum types may not specify all possible values, and structures with multiple formats chosen with a select() clause may not indicate all possible cases.
このセクションでは、セクション2、3、および4で指定されたECCベースのキーメカニズムによって使用されるデータ構造と計算を指定します。ここで使用されるプレゼンテーション言語は、TLS [2] [3]で使用されるものと同じです。この仕様はTLSを拡張しているため、これらの説明は、TLS仕様やTLSを拡張するその他の説明とマージする必要があります。これは、列挙型がすべての可能な値を指定するわけではなく、select()句で選択された複数の形式の構造がすべての可能なケースを示すとは限らないことを意味します。
This section specifies two TLS extensions that can be included with the ClientHello message as described in [4], the Supported Elliptic Curves Extension and the Supported Point Formats Extension.
このセクションでは、[4]で説明されているように、ClientHelloメッセージに含めることができる2つのTLS拡張、サポートされる楕円曲線拡張とサポートされるポイント形式拡張を指定します。
When these extensions are sent:
これらの拡張機能が送信されると：
The extensions SHOULD be sent along with any ClientHello message that proposes ECC cipher suites.
拡張機能は、ECC暗号スイートを提案するClientHelloメッセージとともに送信する必要があります（SHOULD）。
Meaning of these extensions:
これらの拡張の意味：
These extensions allow a client to enumerate the elliptic curves it supports and/or the point formats it can parse.
これらの拡張機能により、クライアントは、サポートする楕円曲線や解析可能なポイント形式を列挙できます。
Structure of these extensions:
これらの拡張の構造：
The general structure of TLS extensions is described in [4], and this specification adds two new types to ExtensionType.
TLS拡張の一般的な構造は[4]で説明されており、この仕様ではExtensionTypeに2つの新しいタイプが追加されています。
enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType;
elliptic_curves (Supported Elliptic Curves Extension): Indicates the set of elliptic curves supported by the client. For this extension, the opaque extension_data field contains EllipticCurveList. See Section 5.1.1 for details.
elliptic_curves（サポートされる楕円曲線拡張）：クライアントがサポートする楕円曲線のセットを示します。この拡張の場合、不透明なextension_dataフィールドにはEllipticCurveListが含まれます。詳細については、セクション5.1.1を参照してください。
ec_point_formats (Supported Point Formats Extension): Indicates the set of point formats that the client can parse. For this extension, the opaque extension_data field contains ECPointFormatList. See Section 5.1.2 for details.
ec_point_formats（サポートされているポイント形式の拡張）：クライアントが解析できるポイント形式のセットを示します。この拡張の場合、不透明なextension_dataフィールドにECPointFormatListが含まれています。詳細については、セクション5.1.2を参照してください。
Actions of the sender:
送信者のアクション：
A client that proposes ECC cipher suites in its ClientHello message appends these extensions (along with any others), enumerating the curves it supports and the point formats it can parse. Clients SHOULD send both the Supported Elliptic Curves Extension and the Supported Point Formats Extension. If the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats.
ClientHelloメッセージでECC暗号スイートを提案するクライアントは、これらの拡張を（他の拡張とともに）追加し、サポートする曲線と解析できるポイント形式を列挙します。クライアントは、サポートされる楕円曲線拡張とサポートされるポイント形式拡張の両方を送信する必要があります（SHOULD）。サポートされているポイントフォーマット拡張が実際に送信される場合、ポイントフォーマットのリストの項目の1つとして値0（非圧縮）が含まれている必要があります。
Actions of the receiver:
レシーバーのアクション：
A server that receives a ClientHello containing one or both of these extensions MUST use the client's enumerated capabilities to guide its selection of an appropriate cipher suite. One of the proposed ECC cipher suites must be negotiated only if the server can successfully complete the handshake while using the curves and point formats supported by the client (cf. Sections 5.3 and 5.4).
これらの拡張の1つまたは両方を含むClientHelloを受信するサーバーは、クライアントの列挙された機能を使用して、適切な暗号スイートの選択をガイドする必要があります。提案されたECC暗号スイートの1つは、サーバーがクライアントがサポートする曲線と点の形式を使用してハンドシェイクを正常に完了できる場合にのみネゴシエートする必要があります（セクション5.3および5.4を参照）。
NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for (i) the ECDSA key in its certificate, and (ii) the ephemeral ECDH key in the ServerKeyExchange message. The server must consider the extensions in both cases.
注：ECDHE-ECDSA鍵交換に参加しているサーバーは、（i）証明書のECDSA鍵、および（ii）ServerKeyExchangeメッセージの一時ECDH鍵に異なる曲線を使用できます。サーバーはどちらの場合も拡張機能を考慮する必要があります。
If a server does not understand the Supported Elliptic Curves Extension, does not understand the Supported Point Formats Extension, or is unable to complete the ECC handshake while restricting itself to the enumerated curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite. Depending on what other cipher suites are proposed by the client and supported by the server, this may result in a fatal handshake failure alert due to the lack of common cipher suites.
サーバーがサポートされている楕円曲線拡張を理解していない、サポートされているポイント形式拡張を理解していない、または列挙された曲線とポイント形式に制限されているときにECCハンドシェイクを完了できない場合は、ECC暗号の使用について交渉してはなりませんスイート。クライアントによって提案され、サーバーによってサポートされている他の暗号スイートによっては、一般的な暗号スイートがないために、致命的なハンドシェイク失敗アラートが発生する場合があります。
enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25),
reserved (0xFE00..0xFEFF),
arbitrary_explicit_prime_curves(0xFF01),
arbitrary_explicit_char2_curves(0xFF02),
(0xFFFF)
} NamedCurve;
sect163k1, etc: Indicates support of the corresponding named curve or class of explicitly defined curves. The named curves defined here are those specified in SEC 2 [13]. Note that many of these curves are also recommended in ANSI X9.62 [7] and FIPS 186-2 [11]. Values 0xFE00 through 0xFEFF are reserved for private use. Values 0xFF01 and 0xFF02 indicate that the client supports arbitrary prime and characteristic-2 curves, respectively (the curve parameters must be encoded explicitly in ECParameters).
sect163k1など：対応する名前付き曲線または明示的に定義された曲線のクラスのサポートを示します。ここで定義されている名前付き曲線は、SEC 2 [13]で指定されているものです。これらの曲線の多くは、ANSI X9.62 [7]およびFIPS 186-2 [11]でも推奨されていることに注意してください。 0xFE00〜0xFEFFの値は、私的使用のために予約されています。値0xFF01および0xFF02は、クライアントが任意の素数曲線と特性2曲線をそれぞれサポートすることを示します（曲線パラメーターはECParametersで明示的にエンコードする必要があります）。
The NamedCurve name space is maintained by IANA. See Section 8 for information on how new value assignments are added.
NamedCurve名前空間は、IANAによって管理されています。新しい値の割り当てを追加する方法については、セクション8を参照してください。
struct {
NamedCurve elliptic_curve_list<1..2^16-1>
} EllipticCurveList;
Items in elliptic_curve_list are ordered according to the client's preferences (favorite choice first).
elliptic_curve_listの項目は、クライアントの設定に従って順序付けされます（最初にお気に入りの選択）。
As an example, a client that only supports secp192r1 (aka NIST P-192; value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) and prefers to use secp192r1 would include a TLS extension consisting of the following octets. Note that the first two octets indicate the extension type (Supported Elliptic Curves Extension):
例として、secp192r1（別名NIST P-192;値19 = 0x0013）およびsecp224r1（別名NIST P-224;値21 = 0x0015）のみをサポートし、secp192r1を使用することを好むクライアントは、以下で構成されるTLS拡張を含みます。オクテット。最初の2つのオクテットは拡張タイプ（サポートされる楕円曲線拡張）を示すことに注意してください。
00 0A 00 06 00 04 00 13 00 15
00 0A 00 06 00 04 00 13 00 15
A client that supports arbitrary explicit characteristic-2 curves (value 0xFF02) would include an extension consisting of the following octets:
任意の明示的な特性2曲線（値0xFF02）をサポートするクライアントには、次のオクテットで構成される拡張が含まれます。
00 0A 00 04 00 02 FF 02
00 0A 00 04 00 02 FF 02
enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..255)
} ECPointFormat;
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
Three point formats are included in the definition of ECPointFormat above. The uncompressed point format is the default format in that implementations of this document MUST support it for all of their supported curves. Compressed point formats reduce bandwidth by including only the x-coordinate and a single bit of the y-coordinate of the point. Implementations of this document MAY support the ansiX962_compressed_prime and ansiX962_compressed_char2 formats, where the former applies only to prime curves and the latter applies only to characteristic-2 curves. (These formats are specified in [7].) Values 248 through 255 are reserved for private use.
上記のECPointFormatの定義には、3つのポイント形式が含まれています。非圧縮ポイント形式は、このドキュメントの実装がサポートするすべての曲線でサポートする必要があるという点で、デフォルトの形式です。圧縮されたポイント形式は、ポイントのx座標とy座標の1ビットのみを含めることにより、帯域幅を削減します。このドキュメントの実装は、ansiX962_compressed_primeおよびansiX962_compressed_char2フォーマットをサポートする場合があります。前者はプライムカーブにのみ適用され、後者は特性2カーブにのみ適用されます。 （これらの形式は[7]で指定されています。）値248〜255は、私的使用のために予約されています。
The ECPointFormat name space is maintained by IANA. See Section 8 for information on how new value assignments are added.
ECPointFormat名前空間は、IANAによって維持されます。新しい値の割り当てを追加する方法については、セクション8を参照してください。
Items in ec_point_format_list are ordered according to the client's preferences (favorite choice first).
ec_point_format_listの項目は、クライアントの設定に従って順序付けされます（最初にお気に入りの選択）。
A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension):
非圧縮ポイント形式（値0）のみを解析できるクライアントには、次のオクテットで構成される拡張が含まれます。最初の2つのオクテットは拡張タイプ（サポートされているポイント形式の拡張）を示しています。
00 0B 00 02 01 00
00 0B 00 02 01 00
A client that in the case of prime fields prefers the compressed format (ansiX962_compressed_prime, value 1) over the uncompressed format (value 0), but in the case of characteristic-2 fields prefers the uncompressed format (value 0) over the compressed format (ansiX962_compressed_char2, value 2), may indicate these preferences by including an extension consisting of the following octets:
素数フィールドの場合は非圧縮フォーマット（値0）よりも圧縮フォーマット（ansiX962_compressed_prime、値1）を優先しますが、特性2フィールドの場合は圧縮フォーマット（値0）を優先します（ ansiX962_compressed_char2、値2）は、次のオクテットで構成される拡張を含めることにより、これらの設定を示す場合があります。
00 0B 00 04 03 01 00 02
00 0B 00 04 03 01 00 02
This section specifies a TLS extension that can be included with the ServerHello message as described in [4], the Supported Point Formats Extension.
このセクションでは、[4]の「サポートされているポイント形式の拡張」で説明されているように、ServerHelloメッセージに含めることができるTLS拡張を指定します。
When this extension is sent:
この拡張子が送信されると：
The Supported Point Formats Extension is included in a ServerHello message in response to a ClientHello message containing the Supported Point Formats Extension when negotiating an ECC cipher suite.
ECC暗号スイートのネゴシエーション時に、サポートされるポイントフォーマット拡張を含むClientHelloメッセージへの応答として、サポートされるポイントフォーマット拡張がServerHelloメッセージに含まれます。
Meaning of this extension:
この拡張子の意味：
This extension allows a server to enumerate the point formats it can parse (for the curve that will appear in its ServerKeyExchange message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key exchange algorithm, or for the curve that is used in the server's public key that will appear in its Certificate message when using the ECDH_ECDSA or ECDH_RSA key exchange algorithm).
この拡張により、サーバーは解析できるポイント形式を列挙できます（ECDHE_ECDSA、ECDHE_RSA、またはECDH_anon鍵交換アルゴリズムを使用するときにServerKeyExchangeメッセージに表示される曲線、またはサーバーの公開鍵で使用される曲線についてECDH_ECDSAまたはECDH_RSA鍵交換アルゴリズムを使用すると、証明書メッセージに表示されます）。
Structure of this extension:
この拡張の構造：
The server's Supported Point Formats Extension has the same structure as the client's Supported Point Formats Extension (see Section 5.1.2). Items in elliptic_curve_list here are ordered according to the server's preference (favorite choice first). Note that the server may include items that were not found in the client's list (e.g., the server may prefer to receive points in compressed format even when a client cannot parse this format: the same client may nevertheless be capable of outputting points in compressed format).
サーバーのサポートされているポイント形式の拡張機能は、クライアントのサポートされているポイント形式の拡張機能と同じ構造です（セクション5.1.2を参照）。ここのelliptic_curve_listの項目は、サーバーの設定に従って並べられます（最初にお気に入りの選択）。サーバーにはクライアントのリストにないアイテムが含まれる場合があることに注意してください（たとえば、クライアントがこの形式を解析できない場合でも、サーバーは圧縮形式でポイントを受け取ることを好む場合があります。それでも、同じクライアントが圧縮形式でポイントを出力できる場合があります。 ）。
Actions of the sender:
送信者のアクション：
A server that selects an ECC cipher suite in response to a ClientHello message including a Supported Point Formats Extension appends this extension (along with others) to its ServerHello message, enumerating the point formats it can parse. The Supported Point Formats Extension, when used, MUST contain the value 0 (uncompressed) as one of the items in the list of point formats.
サポートされているポイントフォーマット拡張を含むClientHelloメッセージに応答してECC暗号スイートを選択するサーバーは、この拡張を（他の拡張と共に）ServerHelloメッセージに追加し、解析できるポイントフォーマットを列挙します。サポートされるポイント形式の拡張機能を使用する場合、ポイント形式のリストの項目の1つとして値0（非圧縮）を含める必要があります。
Actions of the receiver:
レシーバーのアクション：
A client that receives a ServerHello message containing a Supported Point Formats Extension MUST respect the server's choice of point formats during the handshake (cf. Sections 5.6 and 5.7). If no Supported Point Formats Extension is received with the ServerHello, this is equivalent to an extension allowing only the uncompressed point format.
サポートされているポイントフォーマット拡張を含むServerHelloメッセージを受信するクライアントは、ハンドシェイク中にサーバーが選択したポイントフォーマットを尊重する必要があります（セクション5.6および5.7を参照）。 ServerHelloでサポートされているポイントフォーマット拡張が受信されない場合、これは非圧縮ポイントフォーマットのみを許可する拡張と同等です。
When this message is sent:
このメッセージが送信されると：
This message is sent in all non-anonymous ECC-based key exchange algorithms.
このメッセージは、すべての非匿名のECCベースの鍵交換アルゴリズムで送信されます。
Meaning of this message:
このメッセージの意味：
This message is used to authentically convey the server's static public key to the client. The following table shows the server certificate type appropriate for each key exchange algorithm. ECC public keys MUST be encoded in certificates as described in Section 5.9.
このメッセージは、サーバーの静的公開鍵をクライアントに認証するために使用されます。次の表は、各鍵交換アルゴリズムに適したサーバー証明書のタイプを示しています。セクション5.9で説明するように、ECC公開鍵は証明書にエンコードする必要があります。
NOTE: The server's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned in Table 3 apply only to the server's certificate (first in the chain).
注：サーバーの証明書メッセージは、証明書のチェーンを運ぶことができます。表3に記載されている制限は、サーバーの証明書（チェーンの最初）にのみ適用されます。
Key Exchange Algorithm Server Certificate Type
---------------------- -----------------------
ECDH_ECDSA Certificate MUST contain an ECDH-capable public key. It MUST be signed with ECDSA.
ECDH_ECDSA証明書には、ECDH対応の公開鍵が含まれている必要があります。 ECDSAで署名する必要があります。
ECDHE_ECDSA Certificate MUST contain an ECDSA-capable public key. It MUST be signed with ECDSA.
ECDHE_ECDSA証明書には、ECDSA対応の公開鍵が含まれている必要があります。 ECDSAで署名する必要があります。
ECDH_RSA Certificate MUST contain an ECDH-capable public key. It MUST be signed with RSA.
ECDH_RSA証明書には、ECDH対応の公開鍵が含まれている必要があります。 RSAで署名する必要があります。
ECDHE_RSA Certificate MUST contain an RSA public key authorized for use in digital signatures. It MUST be signed with RSA.
ECDHE_RSA証明書には、デジタル署名での使用が許可されたRSA公開鍵が含まれている必要があります。 RSAで署名する必要があります。
Table 3: Server Certificate Types
表3：サーバー証明書の種類
Structure of this message:
このメッセージの構造：
Identical to the TLS Certificate format.
TLS証明書形式と同じです。
Actions of the sender:
送信者のアクション：
The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves; in particular, the public key MUST employ a named curve (not the same curve as an explicit curve) unless the client has indicated support for explicit curves of the appropriate type. If the client has used a Supported Point Formats Extension, both the server's public key point and (in the case of an explicit curve) the curve's base point MUST respect the client's choice of point formats. (A server that cannot satisfy these requirements MUST NOT choose an ECC cipher suite in its ServerHello message.) Actions of the receiver:
サーバーは適切な証明書チェーンを構築し、それを証明書メッセージでクライアントに伝えます。クライアントがサポートされている楕円曲線拡張を使用している場合、サーバーの証明書の公開鍵はクライアントの楕円曲線の選択を尊重しなければなりません。特に、クライアントが適切なタイプの明示的な曲線のサポートを示さない限り、公開鍵は名前付き曲線（明示的な曲線と同じ曲線ではない）を使用する必要があります。クライアントがサポートされているポイントフォーマット拡張機能を使用している場合、サーバーの公開キーポイントと（明示的なカーブの場合）カーブのベースポイントの両方がクライアントのポイントフォーマットの選択を尊重する必要があります。 （これらの要件を満たせないサーバーは、ServerHelloメッセージでECC暗号スイートを選択してはなりません。）受信者のアクション：
The client validates the certificate chain, extracts the server's public key, and checks that the key type is appropriate for the negotiated key exchange algorithm. (A possible reason for a fatal handshake failure is that the client's capabilities for handling elliptic curves and point formats are exceeded; cf. Section 5.1.)
クライアントは証明書チェーンを検証し、サーバーの公開鍵を抽出して、鍵のタイプがネゴシエートされた鍵交換アルゴリズムに適していることを確認します。 （致命的なハンドシェイクの失敗の考えられる理由は、楕円曲線とポイント形式を処理するクライアントの能力を超えていることです。セクション5.1を参照してください。）
When this message is sent:
このメッセージが送信されると：
This message is sent when using the ECDHE_ECDSA, ECDHE_RSA, and ECDH_anon key exchange algorithms.
このメッセージは、ECDHE_ECDSA、ECDHE_RSA、およびECDH_anon鍵交換アルゴリズムを使用するときに送信されます。
Meaning of this message:
このメッセージの意味：
This message is used to convey the server's ephemeral ECDH public key (and the corresponding elliptic curve domain parameters) to the client.
このメッセージは、サーバーの一時的なECDH公開鍵（および対応する楕円曲線ドメインパラメーター）をクライアントに伝えるために使用されます。
Structure of this message:
このメッセージの構造：
enum { explicit_prime (1), explicit_char2 (2),
named_curve (3), reserved(248..255) } ECCurveType;
explicit_prime: Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a prime field.
explicit_prime：楕円曲線領域パラメーターが冗長に伝えられ、基になる有限体が素体であることを示します。
explicit_char2: Indicates the elliptic curve domain parameters are conveyed verbosely, and the underlying finite field is a characteristic-2 field.
explicit_char2：楕円曲線ドメインパラメーターが冗長に伝えられ、基になる有限体が特性2体であることを示します。
named_curve: Indicates that a named curve is used. This option SHOULD be used when applicable.
named_curve：名前付き曲線が使用されることを示します。このオプションは、該当する場合に使用してください。
Values 248 through 255 are reserved for private use.
248〜255の値は、私的使用のために予約されています。
The ECCurveType name space is maintained by IANA. See Section 8 for information on how new value assignments are added.
ECCurveType名前空間は、IANAによって維持されます。新しい値の割り当てを追加する方法については、セクション8を参照してください。
struct {
opaque a <1..2^8-1>;
opaque b <1..2^8-1>;
} ECCurve;
a, b: These parameters specify the coefficients of the elliptic curve. Each value contains the byte string representation of a field element following the conversion routine in Section 4.3.3 of ANSI X9.62 [7].
a、b：これらのパラメーターは、楕円曲線の係数を指定します。各値には、ANSI X9.62 [7]のセクション4.3.3の変換ルーチンに続くフィールド要素のバイト文字列表現が含まれています。
struct {
opaque point <1..2^8-1>;
} ECPoint;
point: This is the byte string representation of an elliptic curve point following the conversion routine in Section 4.3.6 of ANSI X9.62 [7]. This byte string may represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the client has requested through a Supported Point Formats Extension if this extension was used.
point：これは、ANSI X9.62 [7]のセクション4.3.6の変換ルーチンに従う楕円曲線ポイントのバイト文字列表現です。このバイト文字列は、圧縮されていない形式または圧縮された形式で楕円曲線ポイントを表す場合があります。この拡張が使用された場合、サポートされているポイントフォーマット拡張を通じてクライアントが要求したものに準拠する必要があります。
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
ec_basis_trinomial: Indicates representation of a characteristic-2 field using a trinomial basis.
ec_basis_trinomial：三項ベースを使用した特性2フィールドの表現を示します。
ec_basis_pentanomial: Indicates representation of a characteristic-2 field using a pentanomial basis.
ec_basis_pentanomial：5項ベースを使用して、特性2フィールドの表現を示します。
struct {
ECCurveType curve_type;
select (curve_type) {
case explicit_prime:
opaque prime_p <1..2^8-1>;
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
case explicit_char2:
uint16 m;
ECBasisType basis;
select (basis) {
case ec_trinomial:
opaque k <1..2^8-1>;
case ec_pentanomial:
opaque k1 <1..2^8-1>;
opaque k2 <1..2^8-1>;
opaque k3 <1..2^8-1>;
};
ECCurve curve;
ECPoint base;
opaque order <1..2^8-1>;
opaque cofactor <1..2^8-1>;
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
curve_type: This identifies the type of the elliptic curve domain parameters.
curve_type：楕円曲線ドメインパラメータのタイプを識別します。
prime_p: This is the odd prime defining the field Fp.
prime_p：これは、フィールドFpを定義する奇数の素数です。
curve: Specifies the coefficients a and b of the elliptic curve E.
curve：楕円曲線Eの係数aおよびbを指定します。
base: Specifies the base point G on the elliptic curve.
base：楕円曲線上の基点Gを指定します。
order: Specifies the order n of the base point.
order：基点の次数nを指定します。
cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq)
represents the number of points on the elliptic curve E defined
over the field Fq (either Fp or F2^m).
m: This is the degree of the characteristic-2 field F2^m.
m：これは、特性2フィールドF2 ^ mの次数です。
k: The exponent k for the trinomial basis representation x^m + x^k +1.
k：3項基底表現x ^ m + x ^ k +1の指数k。
k1, k2, k3: The exponents for the pentanomial representation x^m + x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
k1、k2、k3：5項表現の指数x ^ m + x ^ k3 + x ^ k2 + x ^ k1 + 1（k3> k2> k1など）。
namedcurve: Specifies a recommended set of elliptic curve domain parameters. All those values of NamedCurve are allowed that refer to a specific curve. Values of NamedCurve that indicate support for a class of explicitly defined curves are not allowed here (they are only permissible in the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02).
namedcurve：楕円曲線領域パラメーターの推奨されるセットを指定します。特定のカーブを参照するNamedCurveのすべての値が許可されます。明示的に定義されたカーブのクラスのサポートを示すNamedCurveの値は、ここでは許可されていません（これらはClientHello拡張でのみ許可されます）。これは、arbitrary_explicit_prime_curves（0xFF01）およびarbitrary_explicit_char2_curves（0xFF02）に適用されます。
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
curve_params: Specifies the elliptic curve domain parameters associated with the ECDH public key.
curve_params：ECDH公開鍵に関連付けられた楕円曲線ドメインパラメータを指定します。
public: The ephemeral ECDH public key.
public：エフェメラルECDH公開キー。
The ServerKeyExchange message is extended as follows.
ServerKeyExchangeメッセージは、次のように拡張されています。
enum { ec_diffie_hellman } KeyExchangeAlgorithm;
ec_diffie_hellman: Indicates the ServerKeyExchange message contains an ECDH public key.
ec_diffie_hellman：ServerKeyExchangeメッセージにECDH公開鍵が含まれていることを示します。
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman:
ServerECDHParams params;
Signature signed_params;
} ServerKeyExchange;
params: Specifies the ECDH public key and associated domain parameters.
params：ECDH公開鍵と関連するドメインパラメータを指定します。
signed_params: A hash of the params, with the signature appropriate to that hash applied. The private key corresponding to the certified public key in the server's Certificate message is used for signing.
signed_params：paramsのハッシュ。そのハッシュに適した署名が適用されます。サーバーの証明書メッセージで認証された公開鍵に対応する秘密鍵が署名に使用されます。
enum { ecdsa } SignatureAlgorithm;
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
} Signature;
ServerKeyExchange.signed_params.sha_hash SHA(ClientHello.random + ServerHello.random + ServerKeyExchange.params);
ServerKeyExchange.signed_params.sha_hash SHA（ClientHello.random + ServerHello.random + ServerKeyExchange.params）;
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange algorithm and "anonymous" for ECDH_anon. These cases are defined in TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA signatures are generated and verified as described in Section 5.10, and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature consists of a pair of integers, r and s. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, the contents of which are the DER encoding [9] corresponding to the following ASN.1 notation [8].
注：ECDHE_RSA鍵交換アルゴリズムの場合、SignatureAlgorithmは「rsa」であり、ECDH_anonの場合は「anonymous」です。これらのケースはTLS [2] [3]で定義されています。 SignatureAlgorithmはECDHE_ECDSAの「ecdsa」です。 ECDSA署名は、セクション5.10で説明されているように生成および検証されます。したがって、上のテンプレートのsha_hashのSHAは、SHA-1以外のハッシュアルゴリズムを示す場合があります。 ANSI X9.62に従い、ECDSA署名は整数のペアrとsで構成されています。デジタル署名された要素は、不透明なベクトル<0..2 ^ 16-1>としてエンコードされます。その内容は、次のASN.1表記[8]に対応するDERエンコード[9]です。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Actions of the sender:
送信者のアクション：
The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to these parameters according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the client in the ServerKeyExchange message using the format defined above.
サーバーは、IEEE 1363 [6]のECKAS-DH1スキームに従って、楕円曲線ドメインパラメータと、これらのパラメータに対応する短期ECDH公開鍵を選択します。上記で定義されたフォーマットを使用して、ServerKeyExchangeメッセージでこの情報をクライアントに伝えます。
Actions of the receiver:
レシーバーのアクション：
The client verifies the signature (when present) and retrieves the server's elliptic curve domain parameters and ephemeral ECDH public key from the ServerKeyExchange message. (A possible reason for a fatal handshake failure is that the client's capabilities for handling elliptic curves and point formats are exceeded; cf. Section 5.1.)
クライアントは署名（存在する場合）を検証し、サーバーの楕円曲線ドメインパラメータと一時的なECDH公開鍵をServerKeyExchangeメッセージから取得します。 （致命的なハンドシェイクの失敗の考えられる理由は、楕円曲線とポイント形式を処理するクライアントの能力を超えていることです。セクション5.1を参照してください。）
When this message is sent:
このメッセージが送信されると：
This message is sent when requesting client authentication.
このメッセージは、クライアント認証を要求するときに送信されます。
Meaning of this message:
このメッセージの意味：
The server uses this message to suggest acceptable client authentication methods.
サーバーはこのメッセージを使用して、受け入れ可能なクライアント認証方法を提案します。
Structure of this message:
このメッセージの構造：
The TLS CertificateRequest message is extended as follows.
TLS CertificateRequestメッセージは次のように拡張されます。
enum {
ecdsa_sign(64), rsa_fixed_ecdh(65),
ecdsa_fixed_ecdh(66), (255)
} ClientCertificateType;
ecdsa_sign, etc. Indicates that the server would like to use the corresponding client authentication method specified in Section 3.
ecdsa_signなど。サーバーがセクション3で指定された対応するクライアント認証方法を使用したいことを示します。
Actions of the sender:
送信者のアクション：
The server decides which client authentication methods it would like to use, and conveys this information to the client using the format defined above.
サーバーは、使用するクライアント認証方法を決定し、上記で定義されたフォーマットを使用してこの情報をクライアントに伝えます。
Actions of the receiver:
レシーバーのアクション：
The client determines whether it has a suitable certificate for use with any of the requested methods and whether to proceed with client authentication.
クライアントは、要求されたメソッドのいずれかで使用するための適切な証明書があるかどうか、およびクライアント認証を続行するかどうかを決定します。
When this message is sent:
このメッセージが送信されると：
This message is sent in response to a CertificateRequest when a client has a suitable certificate and has decided to proceed with client authentication. (Note that if the server has used a Supported Point Formats Extension, a certificate can only be considered suitable for use with the ECDSA_sign, RSA_fixed_ECDH, and ECDSA_fixed_ECDH authentication methods if the public key point specified in it respects the server's choice of point formats. If no Supported Point Formats Extension has been used, a certificate can only be considered suitable for use with these authentication methods if the point is represented in uncompressed point format.)
このメッセージは、クライアントに適切な証明書があり、クライアント認証を続行することを決定したときに、CertificateRequestへの応答として送信されます。 （サーバーがサポートされているポイント形式の拡張機能を使用している場合、証明書がECDSA_sign、RSA_fixed_ECDH、およびECDSA_fixed_ECDH認証方法での使用に適していると見なされるのは、サーバーで指定された公開キーポイントがポイント形式の選択を尊重している場合のみです。サポートされているポイント形式の拡張機能は使用されていません。証明書がこれらの認証方法での使用に適していると見なされるのは、ポイントが非圧縮のポイント形式で表されている場合のみです。）
Meaning of this message:
このメッセージの意味：
This message is used to authentically convey the client's static public key to the server. The following table summarizes what client certificate types are appropriate for the ECC-based client authentication mechanisms described in Section 3. ECC public keys must be encoded in certificates as described in Section 5.9.
このメッセージは、クライアントの静的公開鍵をサーバーに確実に伝えるために使用されます。次の表は、セクション3で説明されているECCベースのクライアント認証メカニズムに適切なクライアント証明書タイプをまとめたものです。セクション5.9で説明されているように、ECC公開鍵は証明書にエンコードする必要があります。
NOTE: The client's Certificate message is capable of carrying a chain of certificates. The restrictions mentioned in Table 4 apply only to the client's certificate (first in the chain).
注：クライアントの証明書メッセージは、証明書のチェーンを運ぶことができます。表4に記載されている制限は、クライアントの証明書（チェーンの最初）にのみ適用されます。
Client
Authentication Method Client Certificate Type
--------------------- -----------------------
ECDSA_sign Certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.
ECDSA_sign証明書は、ECDSA対応の公開鍵を含み、ECDSAで署名されている必要があります。
ECDSA_fixed_ECDH Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server's long-term ECDH key. This certificate MUST be signed with ECDSA.
ECDSA_fixed_ECDH証明書には、サーバーの長期ECDHキーと同じ楕円曲線上のECDH対応の公開キーが含まれている必要があります。この証明書はECDSAで署名されている必要があります。
RSA_fixed_ECDH Certificate MUST contain an ECDH-capable public key on the same elliptic curve as the server's long-term ECDH key. This certificate MUST be signed with RSA.
RSA_fixed_ECDH証明書には、サーバーの長期ECDHキーと同じ楕円曲線上のECDH対応の公開キーが含まれている必要があります。この証明書はRSAで署名する必要があります。
Table 4: Client Certificate Types
表4：クライアント証明書のタイプ
Structure of this message:
このメッセージの構造：
Identical to the TLS client Certificate format.
TLSクライアント証明書形式と同じです。
Actions of the sender:
送信者のアクション：
The client constructs an appropriate certificate chain, and conveys it to the server in the Certificate message.
クライアントは適切な証明書チェーンを構築し、それをCertificateメッセージでサーバーに伝えます。
Actions of the receiver:
レシーバーのアクション：
The TLS server validates the certificate chain, extracts the client's public key, and checks that the key type is appropriate for the client authentication method.
TLSサーバーは証明書チェーンを検証し、クライアントの公開鍵を抽出して、鍵のタイプがクライアント認証方式に適していることを確認します。
When this message is sent:
このメッセージが送信されると：
This message is sent in all key exchange algorithms. If client authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this message is empty. Otherwise, it contains the client's ephemeral ECDH public key.
このメッセージは、すべての鍵交換アルゴリズムで送信されます。 ECDSA_fixed_ECDHまたはRSA_fixed_ECDHによるクライアント認証が使用されている場合、このメッセージは空です。それ以外の場合は、クライアントの一時的なECDH公開鍵が含まれます。
Meaning of the message:
メッセージの意味：
This message is used to convey ephemeral data relating to the key exchange belonging to the client (such as its ephemeral ECDH public key).
このメッセージは、クライアントに属する鍵交換に関連する一時的なデータ（その一時的なECDH公開鍵など）を伝えるために使用されます。
Structure of this message:
このメッセージの構造：
The TLS ClientKeyExchange message is extended as follows.
TLS ClientKeyExchangeメッセージは、次のように拡張されています。
enum { implicit, explicit } PublicValueEncoding;
implicit, explicit: For ECC cipher suites, this indicates whether the client's ECDH public key is in the client's certificate ("implicit") or is provided, as an ephemeral ECDH public key, in the ClientKeyExchange message ("explicit"). (This is "explicit" in ECC cipher suites except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH client authentication mechanism.)
暗黙的、明示的：ECC暗号スイートの場合、これはクライアントのECDH公開鍵がクライアントの証明書内にある（「暗黙的」）か、一時的なECDH公開鍵としてClientKeyExchangeメッセージ内に提供される（「明示的」）かを示します。 （これは、クライアントがECDSA_fixed_ECDHまたはRSA_fixed_ECDHクライアント認証メカニズムを使用する場合を除いて、ECC暗号スイートでは「明示的」です。）
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: ECPoint ecdh_Yc;
} ecdh_public;
} ClientECDiffieHellmanPublic;
ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, which may represent an elliptic curve point in uncompressed or compressed format. Here, the format MUST conform to what the server has requested through a Supported Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not used.
ecdh_Yc：クライアントのエフェメラルECDH公開キーをバイト文字列ECPoint.pointとして含みます。これは、非圧縮形式または圧縮形式の楕円曲線ポイントを表す場合があります。ここで、フォーマットは、この拡張が使用された場合、サーバーがサポートされているポイントフォーマット拡張を介して要求したものに準拠しなければならず、この拡張が使用されなかった場合、圧縮解除されなければなりません。
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
Actions of the sender:
送信者のアクション：
The client selects an ephemeral ECDH public key corresponding to the parameters it received from the server according to the ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to the client in the ClientKeyExchange message using the format defined above.
クライアントは、IEEE 1363のECKAS-DH1スキームに従って、サーバーから受信したパラメーターに対応する一時ECDH公開鍵を選択します[6]。上記で定義されたフォーマットを使用して、ClientKeyExchangeメッセージでこの情報をクライアントに伝えます。
Actions of the receiver:
レシーバーのアクション：
The server retrieves the client's ephemeral ECDH public key from the ClientKeyExchange message and checks that it is on the same elliptic curve as the server's ECDH key.
サーバーは、ClientKeyExchangeメッセージからクライアントの一時的なECDH公開鍵を取得し、それがサーバーのECDH鍵と同じ楕円曲線上にあることを確認します。
When this message is sent:
このメッセージが送信されると：
This message is sent when the client sends a client certificate containing a public key usable for digital signatures, e.g., when the client is authenticated using the ECDSA_sign mechanism.
このメッセージは、クライアントがデジタル署名に使用できる公開鍵を含むクライアント証明書を送信するときに送信されます。たとえば、クライアントがECDSA_signメカニズムを使用して認証されるときに送信されます。
Meaning of the message:
メッセージの意味：
This message contains a signature that proves possession of the private key corresponding to the public key in the client's Certificate message.
このメッセージには、クライアントの証明書メッセージの公開鍵に対応する秘密鍵の所持を証明する署名が含まれています。
Structure of this message:
このメッセージの構造：
The TLS CertificateVerify message and the underlying Signature type are defined in [2] and [3], and the latter is extended here in Section 5.4. For the ecdsa case, the signature field in the CertificateVerify message contains an ECDSA signature computed over handshake messages exchanged so far, exactly similar to CertificateVerify with other signing algorithms in [2] and [3]:
TLS CertificateVerifyメッセージと基礎となる署名タイプは[2]と[3]で定義されており、後者はセクション5.4で拡張されています。 ecdsaの場合、CertificateVerifyメッセージの署名フィールドには、これまでに交換されたハンドシェイクメッセージで計算されたECDSA署名が含まれ、[2]と[3]の他の署名アルゴリズムを使用したCertificateVerifyとまったく同じです。
CertificateVerify.signature.sha_hash SHA(handshake_messages);
CertificateVerify.signature.sha_hash SHA（handshake_messages）;
ECDSA signatures are computed as described in Section 5.10, and SHA in the above template for sha_hash accordingly may denote a hash algorithm other than SHA-1. As per ANSI X9.62, an ECDSA signature consists of a pair of integers, r and s. The digitally-signed element is encoded as an opaque vector <0..2^16-1>, the contents of which are the DER encoding [9] corresponding to the following ASN.1 notation [8].
ECDSA署名はセクション5.10で説明されているように計算されます。したがって、上記のテンプレートのsha_hashのSHAは、SHA-1以外のハッシュアルゴリズムを示す場合があります。 ANSI X9.62に従い、ECDSA署名は整数のペアrとsで構成されています。デジタル署名された要素は、不透明なベクトル<0..2 ^ 16-1>としてエンコードされます。その内容は、次のASN.1表記[8]に対応するDERエンコード[9]です。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
Actions of the sender:
送信者のアクション：
The client computes its signature over all handshake messages sent or received starting at client hello and up to but not including this message. It uses the private key corresponding to its certified public key to compute the signature, which is conveyed in the format defined above.
クライアントは、クライアントhelloからこのメッセージまで（ただしこのメッセージを含まない）に送受信されたすべてのハンドシェイクメッセージの署名を計算します。認定された公開鍵に対応する秘密鍵を使用して署名を計算します。署名は上記で定義された形式で伝達されます。
Actions of the receiver:
レシーバーのアクション：
The server extracts the client's signature from the CertificateVerify message, and verifies the signature using the public key it received in the client's Certificate message.
サーバーは、CertificateVerifyメッセージからクライアントの署名を抽出し、クライアントの証明書メッセージで受け取った公開鍵を使用して署名を検証します。
X.509 certificates containing ECC public keys or signed using ECDSA MUST comply with [14] or another RFC that replaces or extends it. Clients SHOULD use the elliptic curve domain parameters recommended in ANSI X9.62 [7], FIPS 186-2 [11], and SEC 2 [13].
ECC公開鍵を含む、またはECDSAを使用して署名されたX.509証明書は、[14]またはそれを置換または拡張する別のRFCに準拠する必要があります。クライアントは、ANSI X9.62 [7]、FIPS 186-2 [11]、およびSEC 2 [13]で推奨されている楕円曲線ドメインパラメータを使用する必要があります（SHOULD）。
All ECDH calculations (including parameter and key generation as well as the shared secret calculation) are performed according to [6] using the ECKAS-DH1 scheme with the identity map as key derivation function (KDF), so that the premaster secret is the x-coordinate of the ECDH shared secret elliptic curve point represented as an octet string. Note that this octet string (Z in IEEE 1363 terminology) as output by FE2OSP, the Field Element to Octet String Conversion Primitive, has constant length for any given field; leading zeros found in this octet string MUST NOT be truncated.
すべてのECDH計算（パラメーターとキーの生成、および共有シークレットの計算を含む）は、キー導出関数（KDF）としてアイデンティティマップを使用するECKAS-DH1スキームを使用して[6]に従って実行されるため、プリマスターシークレットはxオクテット文字列として表されるECDH共有秘密楕円曲線点の座標。フィールド要素からオクテット文字列への変換プリミティブであるFE2OSPによって出力されるこのオクテット文字列（IEEE 1363用語ではZ）は、任意のフィールドに対して一定の長さを持つことに注意してください。このオクテット文字列で見つかった先行ゼロは切り詰めてはいけません。
(Note that this use of the identity KDF is a technicality. The complete picture is that ECDH is employed with a non-trivial KDF because TLS does not directly use the premaster secret for anything other than for computing the master secret. As of TLS 1.0 [2] and 1.1 [3], this means that the MD5- and SHA-1-based TLS PRF serves as a KDF; it is conceivable that future TLS versions or new TLS extensions introduced in the future may vary this computation.)
（ID KDFのこの使用は技術的なものであることに注意してください。全体像は、TLSがマスターシークレットの計算以外の目的でプリマスターシークレットを直接使用しないため、ECDHが重要なKDFと共に使用されることです。TLS1.0以降[2]と1.1 [3]は、MD5-およびSHA-1ベースのTLS PRFがKDFとして機能することを意味します。将来のTLSバージョンまたは将来導入される新しいTLS拡張がこの計算を変える可能性があると考えられます。）
All ECDSA computations MUST be performed according to ANSI X9.62 [7] or its successors. Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional hashing. The default hash function is SHA-1 [10], and sha_size (see Sections 5.4 and 5.8) is 20. However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-2 [10], may be used instead if the certificate containing the EC public
すべてのECDSA計算は、ANSI X9.62 [7]またはその後継に従って実行する必要があります。署名/検証されるデータはハッシュされ、結果は追加のハッシュなしでECDSAアルゴリズムを介して直接実行されます。デフォルトのハッシュ関数はSHA-1 [10]であり、sha_size（セクション5.4および5.8を参照）は20です。ただし、FIPS 180-2 [10]で指定されている新しいSHAハッシュ関数の1つなどの代替ハッシュ関数ECパブリックを含む証明書の場合、代わりに使用できます
key explicitly requires use of another hash function. (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response. Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)
キーは、別のハッシュ関数の使用を明示的に要求します。 （必要なハッシュ関数を指定するためのメカニズムは標準化されていませんが、この規定はそのような標準化を予想し、それに応じてこのドキュメントを更新する必要を取り除きます。将来のPKIX RFCは、たとえば、 subjectPublicKeyInfoのパラメータフィールドの公開キー。）
All RSA signatures must be generated and verified according to PKCS#1 [12] block type 1.
すべてのRSA署名は、PKCS＃1 [12]ブロックタイプ1に従って生成および検証する必要があります。
The table below defines new ECC cipher suites that use the key exchange algorithms specified in Section 2.
以下の表は、セクション2で指定された鍵交換アルゴリズムを使用する新しいECC暗号スイートを定義しています。
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x01 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x02 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 }
CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 }
CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 }
CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A }
CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B }
CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C }
CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D }
CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E }
CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F }
CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 }
CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 }
CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 }
CipherSuite TLS_ECDH_anon_WITH_NULL_SHA = { 0xC0, 0x15 }
CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 }
CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 }
CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 }
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 }
Table 5: TLS ECC cipher suites
表5：TLS ECC暗号スイート
The key exchange method, cipher, and hash algorithm for each of these cipher suites are easily determined by examining the name. Ciphers (other than AES ciphers) and hash algorithms are defined in [2] and [3]. AES ciphers are defined in [19].
これらの各暗号スイートの鍵交換方法、暗号、およびハッシュアルゴリズムは、名前を調べることで簡単に判別できます。暗号（AES暗号以外）とハッシュアルゴリズムは、[2]と[3]で定義されています。 AES暗号は[19]で定義されています。
Server implementations SHOULD support all of the following cipher suites, and client implementations SHOULD support at least one of them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
サーバーの実装は、次の暗号スイートをすべてサポートする必要があり（SHOULD）、クライアントの実装は、それらの少なくとも1つをサポートする必要があります：TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WIA_WITH_3ES_BCA_WITH_3DES_EDA_WITH_3DES_EDA_WITH_3DES_EDA_WITH_3DES_EDA_WITH_3DESC
Security issues are discussed throughout this memo.
セキュリティの問題は、このメモ全体で議論されています。
For TLS handshakes using ECC cipher suites, the security considerations in appendices D.2 and D.3 of [2] and [3] apply accordingly.
ECC暗号スイートを使用するTLSハンドシェイクの場合、[2]および[3]の付録D.2およびD.3のセキュリティに関する考慮事項が適宜適用されます。
Security discussions specific to ECC can be found in [6] and [7]. One important issue that implementers and users must consider is elliptic curve selection. Guidance on selecting an appropriate elliptic curve size is given in Table 1.
ECCに固有のセキュリティに関する議論は、[6]と[7]にあります。実装者とユーザーが考慮しなければならない1つの重要な問題は、楕円曲線の選択です。適切な楕円曲線サイズの選択に関するガイダンスを表1に示します。
Beyond elliptic curve size, the main issue is elliptic curve structure. As a general principle, it is more conservative to use elliptic curves with as little algebraic structure as possible. Thus, random curves are more conservative than special curves such as Koblitz curves, and curves over F_p with p random are more conservative than curves over F_p with p of a special form (and curves over F_p with p random might be considered more conservative than curves over F_2^m as there is no choice between multiple fields of similar size for characteristic 2). Note, however, that algebraic structure can also lead to implementation efficiencies, and implementers and users may, therefore, need to balance conservatism against a need for efficiency. Concrete attacks are known against only very few special classes of curves, such as supersingular curves, and these classes are excluded from the ECC standards that this document references [6], [7].
楕円曲線のサイズを超えて、主な問題は楕円曲線の構造です。一般的な原則として、代数的構造ができるだけ少ない楕円曲線を使用するほうが保守的です。したがって、ランダムカーブはKoblitzカーブなどの特別なカーブよりも保守的であり、pランダムなF_p上のカーブは、特別な形式のpを持つF_p上のカーブよりも保守的です（pランダムなF_p上のカーブは、カーブよりも保守的であると見なされる場合があります。特性2）のサイズが類似している複数のフィールド間の選択肢がないため、F_2 ^ m以上。ただし、代数的構造は実装効率にもつながる可能性があるため、実装者とユーザーは保守性と効率性のニーズのバランスを取る必要があることに注意してください。具体的な攻撃は、超特異曲線などのごくわずかな特殊なクラスのクラスに対してのみ知られており、これらのクラスは、このドキュメントが参照しているECC標準から除外されています[6]、[7]。
Another issue is the potential for catastrophic failures when a single elliptic curve is widely used. In this case, an attack on the elliptic curve might result in the compromise of a large number of keys. Again, this concern may need to be balanced against efficiency and interoperability improvements associated with widely-used curves. Substantial additional information on elliptic curve choice can be found in [5], [6], [7], and [11].
もう1つの問題は、単一の楕円曲線が広く使用されている場合の壊滅的な障害の可能性です。この場合、楕円曲線への攻撃により、多数の鍵が危険にさらされる可能性があります。繰り返しになりますが、この懸念は、広く使用されている曲線に関連する効率と相互運用性の改善とのバランスを取る必要がある場合があります。楕円曲線の選択に関する実質的な追加情報は、[5]、[6]、[7]、および[11]にあります。
Implementers and users must also consider whether they need forward secrecy. Forward secrecy refers to the property that session keys are not compromised if the static, certified keys belonging to the server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key exchange algorithms provide forward secrecy protection in the event of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. Similarly, if the client is providing a static, certified key, ECDSA_sign client authentication provides forward secrecy protection in the event of client key compromise, while ECDSA_fixed_ECDH and RSA_fixed_ECDH do not. Thus, to obtain complete forward secrecy protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, with ECDSA_sign used for client authentication if necessary. Here again the security benefits of forward secrecy may need to be balanced against the improved efficiency offered by other options.
実装者とユーザーは、転送秘密が必要かどうかも検討する必要があります。 Forward Secrecyとは、サーバーとクライアントに属する静的な認証済みキーが侵害されても、セッションキーは侵害されないという性質を指します。 ECDHE_ECDSAとECDHE_RSAの鍵交換アルゴリズムは、サーバーの鍵が危険にさらされた場合に前方機密保護を提供しますが、ECDH_ECDSAとECDH_RSAは提供しません。同様に、クライアントが静的な認証済みキーを提供している場合、ECDSA_signクライアント認証は、クライアントキーの侵害が発生した場合に転送秘密保護を提供しますが、ECDSA_fixed_ECDHおよびRSA_fixed_ECDHは提供しません。したがって、完全な前方機密保護を取得するには、鍵交換にECDHE_ECDSAまたはECDHE_RSAを使用し、必要に応じてクライアント認証にECDSA_signを使用する必要があります。ここでも、フォワードシークレットのセキュリティ上の利点は、他のオプションによって提供される効率の向上とバランスを取る必要がある場合があります。
This document describes three new name spaces for use with the TLS protocol:
このドキュメントでは、TLSプロトコルで使用する3つの新しい名前空間について説明します。
o NamedCurve (Section 5.1)
o NamedCurve（セクション5.1）
o ECPointFormat (Section 5.1)
o ECPointFormat（セクション5.1）
o ECCurveType (Section 5.4)
o ECCurveType（セクション5.4）
For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use. Any additional assignments require IETF Consensus action [16].
このドキュメントでは、名前空間ごとに初期値の割り当てを定義し、個人用に予約された256の値（NamedCurve）または8つの値（ECPointFormatおよびECCurveType）の範囲を定義します。追加の割り当てには、IETFコンセンサスアクション[16]が必要です。
The authors wish to thank Bill Anderson and Tim Dierks.
著者は、ビル・アンダーソンとティム・ディアクスに感謝したいと思います。
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[1] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[2] Dierks、T。およびC. Allen、「The TLS Protocol Version 1.0」、RFC 2246、1999年1月。
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[3] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.1」、RFC 4346、2006年4月。
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006.
[4] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J.、and T. Wright、 "Transport Layer Security（TLS）Extensions"、RFC 4366、April 2006。
[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, <http://www.secg.org/>.
[5] SECG、「Elliptic Curve Cryptography」、SEC 1、2000、<http://www.secg.org/>。
[6] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000.
[6] IEEE、「公開鍵暗号の標準仕様」、IEEE 1363、2000。
[7] ANSI, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998.
[7] ANSI、「金融サービス業界の公開鍵暗号化：楕円曲線デジタル署名アルゴリズム（ECDSA）」、ANSI X9.62、1998年。
[8] International Telecommunication Union, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, 2002.
[8] 国際電気通信連合、「情報技術-抽象構文記法1（ASN.1）：基本記法の仕様」、ITU-T勧告X.680、2002年。
[9] International Telecommunication Union, "Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, 2002.
[9] International Telecommunication Union、「Information technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、ITU-T Recommendation X.690、2002。
[10] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
[10] NIST、「Secure Hash Standard」、FIPS 180-2、2002。
[11] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[11] NIST、「デジタル署名標準」、FIPS 186-2、2000。
[12] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1.5", PKCS 1, November 1993.
[12] RSA Laboratories、「PKCS＃1：RSA Encryption Standard version 1.5」、PKCS 1、1993年11月。
[13] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 2000, <http://www.secg.org/>.
[13] SECG、「推奨楕円曲線ドメインパラメータ」、SEC 2、2000、<http://www.secg.org/>。
[14] Polk, T., Housley, R., and L. Bassham, "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279, April 2002.
[14] Polk、T.、Housley、R。、およびL. Bassham、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profileのアルゴリズムと識別子」、RFC 3279、2002年4月。
[15] Housley, R., Polk, T., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[15] Housley、R.、Polk、T.、Ford、W。、およびD. Solo、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 3280、2002年4月。
[16] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, October 1998.
[16] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、RFC 2434、1998年10月。
[17] Harper, G., Menezes, A., and S. Vanstone, "Public-Key Cryptosystems with Very Small Key Lengths", Advances in Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
[17] Harper、G.、Menezes、A。、およびS. Vanstone、「非常に短い鍵長の公開鍵暗号システム」、暗号学の進歩-EUROCRYPT '92、LNCS 658、1993。
[18] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", Journal of Cryptology 14 (2001) 255-293, <http://www.cryptosavvy.com/>.
[18] Lenstra、A。およびE. Verheul、「Selecting Cryptographic Key Sizes」、Journal of Cryptology 14（2001）255-293、<http://www.cryptosavvy.com/>。
[19] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[19] Chown、P。、「Advanced Encryption Standard（AES）Ciphersuites for Transport Layer Security（TLS）」、RFC 3268、2002年6月。
All of the NIST curves [11] and several of the ANSI curves [7] are equivalent to curves listed in Section 5.1.1. In the following table, multiple names in one row represent aliases for the same curve.
すべてのNIST曲線[11]といくつかのANSI曲線[7]は、セクション5.1.1にリストされている曲線と同等です。次の表では、1つの行にある複数の名前が同じ曲線のエイリアスを表しています。
------------------------------------------
Curve names chosen by
different standards organizations
------------+---------------+-------------
SECG | ANSI X9.62 | NIST
------------+---------------+-------------
sect163k1 | | NIST K-163
sect163r1 | |
sect163r2 | | NIST B-163
sect193r1 | |
sect193r2 | |
sect233k1 | | NIST K-233
sect233r1 | | NIST B-233
sect239k1 | |
sect283k1 | | NIST K-283
sect283r1 | | NIST B-283
sect409k1 | | NIST K-409
sect409r1 | | NIST B-409
sect571k1 | | NIST K-571
sect571r1 | | NIST B-571
secp160k1 | |
secp160r1 | |
secp160r2 | |
secp192k1 | |
secp192r1 | prime192v1 | NIST P-192
secp224k1 | |
secp224r1 | | NIST P-224
secp256k1 | |
secp256r1 | prime256v1 | NIST P-256
secp384r1 | | NIST P-384
secp521r1 | | NIST P-521
------------+---------------+-------------
Table 6: Equivalent curves defined by SECG, ANSI, and NIST
表6：SECG、ANSI、NISTで定義された等価曲線
Authors' Addresses
著者のアドレス
Simon Blake-Wilson SafeNet Technologies BV Amstelveenseweg 88-90 1075 XJ, Amsterdam NL
Simon Blake-Wilson SafeNet Technologies BV Amstelveenseweg 88-90 1075 XJ、アムステルダムNL
Phone: +31 653 899 836
EMail: sblakewilson@safenet-inc.com
Nelson Bolyard Sun Microsystems Inc. 4170 Network Circle MS SCA17-201 Santa Clara, CA 95054 US
Nelson Bolyard Sun Microsystems Inc. 4170 Network Circle MS SCA17-201 Santa Clara、CA 95054 US
Phone: +1 408 930 1443
EMail: nelson@bolyard.com
Vipul Gupta Sun Microsystems Laboratories 16 Network Circle MS UMPK16-160 Menlo Park, CA 94025 US
Vipul Gupta Sun Microsystems Laboratories 16 Network Circle MS UMPK16-160 Menlo Park、CA 94025 US
Phone: +1 650 786 7551
EMail: vipul.gupta@sun.com
Chris Hawk Corriente Networks LLC 1563 Solano Ave., #484 Berkeley, CA 94707 US
Chris Hawk Current Networks LLC 1563 Solano Ave.、＃484 Berkeley、CA 94707 US
Phone: +1 510 527 0601 EMail: chris@corriente.net Bodo Moeller Ruhr-Uni Bochum Horst-Goertz-Institut, Lehrstuhl fuer Kommunikationssicherheit IC 4/139 44780 Bochum DE
電話：+1 510 527 0601 Eメール：chris@corriente.net Bodo Moeller Ruhr-UniボーフムHorst-Goertz-Institut、通信セキュリティIC 4/139 44780 Bochum DE議長
Phone: +49 234 32 26795
EMail: bodo@openssl.org
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。