RFC4492 日本語訳
4492 Elliptic Curve Cryptography (ECC) Cipher Suites for TransportLayer Security (TLS). S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk,B. Moeller. May 2006. (Format: TXT=72231 bytes) (Updated by RFC5246) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループS.ブレーク-ウィルソンの要求をネットワークでつないでください: 4492年のSafeNetカテゴリ: 情報のN.のCorriente B.メラールール-UniボーフムBolyardサン・マイクロシステムズV.グプタSun研究室C.タカの2006年5月
Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)
トランスポート層セキュリティのための楕円曲線暗号(ECC)暗号スイート(TLS)
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)インターネット協会(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.
このドキュメントはTransport Layer Security(TLS)プロトコルのためにElliptic Curve Cryptography(ECC)に基づく新しい主要な交換アルゴリズムを説明します。 特に、それは新しい認証機構としてTLS握手におけるElliptic Curveディフィー-ヘルマン(ECDH)の主要な協定の使用とElliptic Curve Digital Signature Algorithm(ECDSA)の使用を指定します。
Blake-Wilson, et al. Informational [Page 1] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[1ページ]のRFC4492ECC暗号スイート
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
1. 序論…3 2. 主要な交換アルゴリズム…4 2.1. ECDH_ECDSA…6 2.2. ECDHE_ECDSA…6 2.3. ECDH_RSA…7 2.4. ECDHE_RSA…7 2.5. ECDH、_やがて…7 3. クライアント認証…8 3.1. ECDSA_サイン…8 3.2. ECDSA_は_ECDHを修理しました…9 3.3. RSA_は_ECDHを修理しました…9 4. ECCのためのTLS拡張子…9 5. データ構造と計算…10 5.1. クライアント、こんにちは、拡大…10 5.1.1. 楕円曲線拡大であるとサポートされます…12 5.1.2. サポートしているポイントは拡大をフォーマットします…13 5.2. サーバ、こんにちは、拡大…14 5.3. サーバ証明書…15 5.4. サーバの主要な交換…17 5.5. 要求を証明してください…21 5.6. クライアント証明書…22 5.7. クライアントの主要な交換…23 5.8. 証明書、確かめます。25 5.9. 楕円曲線証明書…26 5.10. ECDH、ECDSA、およびRSA計算…26 6. スイートを解いてください…27 7. セキュリティ問題…28 8. IANA問題…29 9. 承認…29 10. 参照…30 10.1. 標準の参照…30 10.2. 有益な参照…31付録A.同等物は曲がります(有益な)…32
Blake-Wilson, et al. Informational [Page 2] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[2ページ]のRFC4492ECC暗号スイート
1. Introduction
1. 序論
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.
楕円形のCurve Cryptography(ECC)は魅力的な公開鍵暗号系と、特にモバイル(すなわち、ワイヤレスの)の環境のために現れています。 RSAなどの現在一般的な暗号系と比べて、ECCは、より小さい主要なサイズと共に同等なセキュリティを提供します。 これは以下のテーブルで例証されます、[18]に基づいて。[18]はそれらを攻撃するための最もよく知られているアルゴリズムに基づく左右対称の、そして、非対称に主要な暗号系のために大体の匹敵する主要なサイズを与えます。
Symmetric | ECC | DH/DSA/RSA
------------+---------+-------------
80 | 163 | 1024
112 | 233 | 2048
128 | 283 | 3072
192 | 409 | 7680
256 | 571 | 15360
左右対称| 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
このドキュメントはECCをサポートするTLSに追加について説明します、ともに1.0[2]とTLSバージョンへのTLSバージョンに適切です。1.1[3]。 特に、それは定義します。
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 そしてTLS premaster秘密を確立する長期的であるかはかないキーによるElliptic Curveディフィー-ヘルマン(ECDH)の主要な協定体系の使用。
o the use of fixed-ECDH certificates and ECDSA for authentication of
TLS peers.
o 固定ECDH証明書とECDSAのTLSの認証の使用はじっと見ます。
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はECCベースの主要な交換アルゴリズムの概要をTLSに供給します。 セクション3はECC証明書のクライアント認証の使用について説明します。 クライアントが特定のカーブとポイント形式の使用を交渉できるTLS拡張子はセクション4に提示されます。 セクション5はECCベースの握手、TLSメッセージにおけるそれらのコード化、およびそれらのメッセージの処理に必要である様々なデータ構造を指定します。 セクション6は、新しいECCベースの暗号スイートを定義して、この仕様のすべての実装のために推薦されるようにこれらの小さい部分集合を特定します。 セクション7はセキュリティ問題について論じます。 セクション8はこのドキュメントによって作成された名前空間にIANA問題について説明します。 セクション9は承認を与えます。
Blake-Wilson, et al. Informational [Page 3] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[3ページ]のRFC4492ECC暗号スイート
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Key Exchange Algorithms
2. 主要な交換アルゴリズム
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ベースの主要な交換アルゴリズムを導入します。 彼らは皆、TLS premaster秘密を計算するのにECDHを使用します、そして、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_をまねます)。(それぞれ[2]と[3])を見てください。
Key
Exchange
Algorithm Description
--------- -----------
主要な交換アルゴリズム記述--------- -----------
ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
ECDSA-署名入りの証書があるECDH_ECDSA Fixed ECDH。
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
ECDSA署名があるECDHE_ECDSA Ephemeral ECDH。
ECDH_RSA Fixed ECDH with RSA-signed certificates.
RSA-署名入りの証書があるECDH_RSA Fixed ECDH。
ECDHE_RSA Ephemeral ECDH with RSA signatures.
RSA署名があるECDHE_RSA Ephemeral ECDH。
ECDH_anon Anonymous ECDH, no signatures.
_更生会ECDH、やがて、いいえ。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を見てください)。 しかしながら、コンピュータはかかりました。
Blake-Wilson, et al. Informational [Page 4] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[4ページ]のRFC4492ECC暗号スイート
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キーの間には、どんな構造的な違いもないことに注意してください。 証明書発行人は、ECC公開鍵の使用をある計算[15]に制限するのにX.509 v3 keyUsageとextendedKeyUsage拡張子を使用するかもしれません。 ECDHにおける使用が受入れられるなら、このドキュメントはECDHできるとして主要なECCを示します。 ECDSAできる、同様に定義されます。
Client Server
------ ------
クライアントサーバ------ ------
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*+
<-------- ServerHelloDone
Certificate*+
ClientKeyExchange
CertificateVerify*+
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
ClientHello-------->ServerHello証明書*ServerKeyExchange*CertificateRequest*+<。-------- ServerHelloDone証明書*+ClientKeyExchange CertificateVerify*+[ChangeCipherSpec]は終わりました。-------->[ChangeCipherSpec]<。-------- 終わっています。
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握手におけるメッセージ流動
Blake-Wilson, et al. Informational [Page 5] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[5ページ]のRFC4492ECC暗号スイート
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、サーバのCertificateメッセージ、ServerKeyExchange、ClientKeyExchange、CertificateRequest、クライアントのCertificateメッセージ、およびCertificateVerifyだけに直接的な衝撃を持っています。 次に、私たちはこれらのメッセージの内容と処理で、よりすばらしい詳細にそれぞれのECCの主要な交換アルゴリズムを説明します。 博覧会の容易さのために、私たちはセクション4までセクション3までのクライアント認証と関連メッセージ(図1の+を同一視する)と任意のECC特有の拡大(Helloメッセージに影響を与える)の議論を延期します。
2.1. ECDH_ECDSA
2.1. ECDH_ECDSA
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_を使用すると_ECDHが修理されたか、またはRSA_が_ECDHを修理した時を除いて、その場合、セクション3.2かセクション3.3からの変更は適用されます)。
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で指定されるように実行されます。
2.2. ECDHE_ECDSA
2.2. ECDHE_ECDSA
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.
サーバはServerKeyExchangeメッセージのはかないECDH公開鍵と対応するカーブの仕様を送ります。 サーバのCertificateで公開鍵に対応する秘密鍵を使用して、これらのパラメタと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)を実行して、前マスター秘密として結果の共有秘密キーを使用します。
Blake-Wilson, et al. Informational [Page 6] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[6ページ]のRFC4492ECC暗号スイート
2.3. ECDH_RSA
2.3. ECDH_RSA
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と同じです。
2.4. ECDHE_RSA
2.4. ECDHE_RSA
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.
サーバの証明書が署名のために認可されたRSA公開鍵を含まなければならないのを除いて、この主要な交換アルゴリズムはECDHE_ECDSAと同じです、そして、対応するRSA秘密鍵でServerKeyExchangeメッセージにおける署名を計算しなければなりません。 サーバ証明書とRSAを契約しなければなりません。
2.5. ECDH_anon
2.5. ECDH、_やがて。
In ECDH_anon, the server's Certificate, the CertificateRequest, the client's Certificate, and the CertificateVerify messages MUST NOT be sent.
ECDH_では、やがて、サーバのCertificate、CertificateRequest、クライアントのCertificate、およびCertificateVerifyメッセージを送ってはいけません。
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.
サーバはServerKeyExchangeメッセージの対応するカーブのはかないECDH公開鍵と仕様を送らなければなりません。 これらのパラメタに署名してはいけません。
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.)
ECDHE_ECDSA、ECDH_RSA、およびECDHE_RSAの主要な交換アルゴリズムが、ECDH_ECDSAである間サーバの証明書が特定の署名体系を契約されるのを必要とすることに注意してください、この仕様。([2]と[3])でDH_DSS、DHE_DSS、DH_RSA、およびDHE_RSAの類例に従う場合、制限は証明書チェーンにおけるほかの場所で使用された署名体系につけ込みません。 (しばしば、そのような制限は役に立ちます、そして、これが証明権威の署名習慣で考慮に入れられると予想されます。 しかしながら、そのような制限は厳密に一般に必要ではありません: クライアントが与えられたチェーンを完全に有効にする能力を超えていても、クライアントは、証明書が中間的証明書の1つとしてチェーンに現れる信じられた証明権威を当てにすることによって、サーバの証明書を有効にすることができるかもしれません。)
Blake-Wilson, et al. Informational [Page 7] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[7ページ]のRFC4492ECC暗号スイート
3. Client Authentication
3. クライアント認証
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_サイン、_ECDHが修理されたECDSA_、およびRSA_は_ECDHを修理しました。 非匿名のECC主要な交換アルゴリズムのどれかがセクション2で説明されて、他の非匿名(非ECCの)の主要な交換アルゴリズムがTLS[2][3]で定義されている状態で、ECDSA_サインメカニズムは使用可能です。 _ECDHが修理されたECDSA_と_ECDHメカニズムが修理されたRSA_はECDH_ECDSAとECDH_RSAと共に使用可能です。 長期のECDHクライアントキーの使用はこれらのアルゴリズムの前進の秘密保持の特性を危険にさらすでしょう、したがって、ECDHE_ECDSAとECDHE_RSAとの彼らの使用は禁止されています。
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メッセージにこれらの証明書タイプのより多くのひとりを含んでいることによって、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.
これらの条件が満たされないなら、クライアントは証明書を全く含まないクライアントCertificateメッセージを送るべきです。 この場合、セクション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.
クライアントが、適切な証明書を持って、認証にそれを使用しても構わないと思っているなら、それは、クライアントのCertificateメッセージ(セクション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.
以下に注意してください。 サーバが異なったタイプのクライアント証明書を要求するのは(そして、送るクライアント)、サーバ証明書より許されています。
3.1. ECDSA_sign
3.1. ECDSA_サイン
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メッセージに署名を含んでいることによって公認されたキーに対応していると立証します。
Blake-Wilson, et al. Informational [Page 8] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[8ページ]のRFC4492ECC暗号スイート
3.2. ECDSA_fixed_ECDH
3.2. _ECDHが修理されたECDSA_
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_サインか非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メッセージは送ってはいけません。 前マスター秘密を計算するためにサーバによって必要とされたクライアントのECDH公開鍵がクライアントの証明書の中に利用可能であるので、ClientKeyExchangeは空です。 サーバ(Finishedメッセージのうまくいっている交換で、示される)が、秘密鍵の所有物が公認された公開鍵、およびCertificateVerifyメッセージに対応していると立証するとき、同じ前マスター秘密に到着するクライアントの能力は不要です。
3.3. RSA_fixed_ECDH
3.3. _ECDHが修理されたRSA_
This authentication mechanism is identical to ECDSA_fixed_ECDH except that the client's certificate MUST be signed with RSA.
この認証機構はクライアントの証明書とRSAを契約しなければならないのを除いて、_ECDHが修理されたECDSA_と同じです。
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_サイン、ECDSA_が_ECDHを固定して、RSA_が特定の署名体系を契約されるために_メカニズムが必要とするECDHクライアント認証にクライアントの証明書を固定していた間この仕様が証明書チェーンにおけるほかの場所で使用された署名体系に制限を課さないことに注意してください。 (しばしば、そのような制限は役に立ちます、そして、これが証明権威の署名習慣で考慮に入れられると予想されます。 しかしながら、そのような制限は厳密に一般に必要ではありません: サーバが与えられたチェーンを完全に有効にする能力を超えていても、サーバは、中間的証明書の1つとしてチェーンに現れる信頼アンカーに頼ることによって、クライアント証明書を有効にすることができるかもしれません。)
4. TLS Extensions for ECC
4. ECCのためのTLS拡張子
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
2つの新しいTLS拡張子がこの仕様に基づき定義されます: (i) サポートしている楕円曲線拡大、および(ii)サポートしているポイント形式拡大。 これらで、新しいセッションを始める握手の間、特定のカーブとポイント形式(例えば、解凍にされるに対してそれぞれ圧縮される)の使用を交渉します。 強制的なそうするかもしれないクライアントにとって、これらの拡大は特に関連しています。
Blake-Wilson, et al. Informational [Page 9] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[9ページ]のRFC4492ECC暗号スイート
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.
単に限られた数のカーブかポイント形式をサポートしてください。 それらは[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.
SHOULDがこれらの拡大を含んでいるというClientHelloメッセージでECC暗号スイートを提案するTLSクライアント。 ECC暗号がスイートであると実装するサーバはこれらの拡大をサポートしなければなりません、そして、クライアントがこれらの拡張子を使用して、クライアントによって指定されたカーブと圧縮のテクニックの選択を尊敬している間、握手を終了できないなら、サーバはECC暗号スイートの使用を交渉してはいけません。 これは交渉されたECC握手が次にクライアントのものがサーバのECキーに対処できないことのため中止される可能性を排除します。
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メッセージでこれらの拡大を入れてはいけません。 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メッセージに現れるSupported Elliptic Curves ExtensionとSupported Point Formats Extensionを無視します。 これらの拡大は新しいセッションを交渉する握手の間、役割を果たすだけです。
5. Data Structures and Computations
5. データ構造と計算
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を広げるどんな他のもののそれらにも合併されるべきです。 複数の形式が選んだ()節で選ばれている状態で指定しないかもしれないenumがすべての可能な値、および構造をタイプするこの手段はすべての可能なケースを示すかもしれないというわけではありません。
5.1. Client Hello Extensions
5.1. クライアント、こんにちは、拡大
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]、Supported Elliptic Curves Extension、およびSupported Point Formats Extensionで説明されるようにClientHelloメッセージで含むことができる2つのTLS拡張子を指定します。
Blake-Wilson, et al. Informational [Page 10] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[10ページ]のRFC4492ECC暗号スイート
When these extensions are sent:
これらの拡大を送るとき:
The extensions SHOULD be sent along with any ClientHello message that proposes ECC cipher suites.
拡大SHOULD、ECC暗号スイートを提案するあらゆるClientHelloメッセージと共に送ってください。
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]で説明されます、そして、この仕様は2つの新しいタイプをExtensionTypeに加えます。
enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType;
楕円形の_カーブ(10)、ec_ポイント_形式(11)をenumする、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であるとサポートされます): クライアントによってサポートされた楕円曲線のセットを示します。 この拡大のために、不透明な拡大_データ・フィールドは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であるとサポートされます): クライアントが分析できるポイント形式のセットを示します。 この拡大のために、不透明な拡大_データ・フィールドは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はSupported Elliptic Curves ExtensionとSupported Point Formats Extensionの両方を送ります。 本当にSupported Point Formats Extensionを送るなら、それは項目の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つを交渉しなければなりません。(Cf。 セクション5.3と5.4).
Blake-Wilson, et al. Informational [Page 11] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[11ページ]のRFC4492ECC暗号スイート
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、およびServerKeyExchangeメッセージで主要な(ii)はかない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.
サーバがそれ自体を列挙されたカーブとポイント形式に制限している間、Supported Elliptic Curves Extensionを理解していないか、Supported Point Formats Extensionを理解していないか、またはECC握手を終了できないなら、それはECC暗号スイートの使用を交渉してはいけません。 これは一般的な暗号スイートの不足による致命的な握手故障警報をもたらして、どんな他の暗号スイートがクライアントによって提案されて、サーバによって支えられるかによるかもしれません。
5.1.1. Supported Elliptic Curves Extension
5.1.1. 楕円曲線拡大であるとサポートされます。
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;
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))は(0xFE00..0xFEFF)を予約しました、任意の_明白な_主要な_カーブ(0xFF01)、任意の_明白な_char2_カーブ(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など: 対応する命名されたカーブかクラスの明らかに定義されたカーブのサポートを示します。 ここで定義された命名されたカーブはSEC2[13]で指定されたものです。 また、これらのカーブの多くもANSI X9.62[7]とFIPS186-2[11]でお勧めであることに注意してください。 値の0xFE00から0xFEFFは私的使用目的で予約されます。 値の0xFF01と0xFF02は、クライアントが任意の第1をサポートするのを示します、そして、特性-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;
structのNamedCurveの楕円形の_カーブ_リスト<1..2^16-1>、EllipticCurveList。
Blake-Wilson, et al. Informational [Page 12] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[12ページ]のRFC4492ECC暗号スイート
Items in elliptic_curve_list are ordered according to the client's preferences (favorite choice first).
クライアントの好み(特選している1のお気に入りの番目)に従って、楕円形の_カーブ_リストの商品を注文します。
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つの八重奏が拡大タイプ(Elliptic Curves Extensionであるとサポートされる)を示すことに注意してください:
00 0A 00 06 00 04 00 13 00 15
00 0A00 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 0A00 04 00 02ff02
5.1.2. Supported Point Formats Extension
5.1.2. サポートしているポイントは拡大をフォーマットします。
enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..255)
} ECPointFormat;
enum、解凍、(0) ansiX962_が_第1(1)を圧縮して、ansiX962_が_char2(2)を圧縮した、(248 .255)を予約する、ECPointFormat。
struct {
ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList;
struct ECPointFormat ec_ポイント_形式_リスト<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.
3ポイントの形式はECPointFormatの上の定義に含まれています。 このドキュメントの実装がそれらのサポートしているカーブのすべてのためにそれをサポートしなければならないので、解凍されたポイント形式は省略時書式です。 圧縮されたポイント形式は、ポイントのy-座標のx-座標と1ビットだけを含んでいることによって、帯域幅を減少させます。 このドキュメントの実装は_圧縮された_第1をansiX962にサポートするかもしれません、そして、ansiX962_は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).
クライアントの好み(特選している1のお気に入りの番目)に従って、ec_ポイント_形式_リストの商品を注文します。
Blake-Wilson, et al. Informational [Page 13] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[13ページ]のRFC4492ECC暗号スイート
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つの八重奏が拡大タイプ(Point Formats Extensionであるとサポートされる)を示すことに注意してください:
00 0B 00 02 01 00
00 0B00 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_は_第1を圧縮しました、値1)を好みますが、圧縮形式(ansiX962_は_char2を圧縮しました、値2)より特性-2つの分野の場合で解凍された形式(値0)を好むクライアントは以下の八重奏から成る拡大を含んでいることによって、これらの好みを示すかもしれません:
00 0B 00 04 03 01 00 02
00 0B00 04 03 01 00 02
5.2. Server Hello Extension
5.2. サーバ、こんにちは、拡大
This section specifies a TLS extension that can be included with the ServerHello message as described in [4], the Supported Point Formats Extension.
このセクションは[4](Supported Point Formats Extension)で説明されるように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.
Supported Point Formats ExtensionはServerHelloメッセージにECC暗号スイートを交渉するときSupported Point Formats Extensionを含むClientHelloメッセージに対応して含まれています。
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_を使用するときServerKeyExchangeメッセージに現れるカーブのためにキーがアルゴリズムを交換するか、またはカーブに、それはECDH_ECDSAかECDH_RSAの主要な交換アルゴリズムを使用するときCertificateメッセージに現れるサーバの公開鍵に使用されます)。
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).
サーバのSupported Point Formats Extensionには、クライアントのSupported Point Formats Extensionと同じ構造があります(セクション5.1.2を見てください)。 サーバの好み(特選している1のお気に入りの番目)に従って、ここの楕円形の_カーブ_リストの商品を注文します。 サーバがクライアントのリストで見つけられなかった項目を含むかもしれないことに注意してください(例えば、サーバは、クライアントがこの形式を分析さえできないとき、圧縮形式でポイントを受けるのを好むかもしれません: それにもかかわらず、同じクライアントは圧縮形式でポイントを出力できるかもしれません)。
Blake-Wilson, et al. Informational [Page 14] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[14ページ]のRFC4492ECC暗号スイート
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.
Supported Point Formats Extensionを含むClientHelloメッセージに対応してECC暗号スイートを選択するサーバは(他のものと一緒に加えて)ServerHelloメッセージにこの拡大を追加します、それが分析できるポイント形式を列挙して。 使用されると、Supported Point Formats Extensionは項目の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.
Supported Point Formats Extensionを含むServerHelloメッセージを受け取るクライアントは握手の間、ポイント形式のサーバの選択に敬意を払わなければなりません。(Cf。 セクション5.6と5.7). ServerHelloと共にSupported Point Formats Extensionを全く受け取らないなら、これは解凍されたポイント形式だけを許容する拡大に同等です。
5.3. Server Certificate
5.3. サーバ証明書
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).
以下に注意してください。 サーバのCertificateメッセージは証明書のチェーンを運ぶことができます。 Table3で言及された制限はサーバの証明書(最初にチェーンにおける)だけに適用されます。
Blake-Wilson, et al. Informational [Page 15] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[15ページ]のRFC4492ECC暗号スイート
Key Exchange Algorithm Server Certificate Type
---------------------- -----------------------
主要な交換アルゴリズムサーバ証明書タイプ---------------------- -----------------------
ECDH_ECDSA Certificate MUST contain an
ECDH-capable public key. It
MUST be signed with ECDSA.
ECDH_ECDSA CertificateはECDHできる公開鍵を含まなければなりません。 ECDSAをそれと契約しなければなりません。
ECDHE_ECDSA Certificate MUST contain an
ECDSA-capable public key. It
MUST be signed with ECDSA.
ECDHE_ECDSA CertificateはECDSAできる公開鍵を含まなければなりません。 ECDSAをそれと契約しなければなりません。
ECDH_RSA Certificate MUST contain an
ECDH-capable public key. It
MUST be signed with RSA.
ECDH_RSA Certificateは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 Certificateはデジタル署名における使用のために認可されたRSA公開鍵を含まなければなりません。 RSAをそれと契約しなければなりません。
Table 3: Server Certificate Types
テーブル3: サーバ証明書タイプ
Structure of this message:
このメッセージの構造:
Identical to the TLS Certificate format.
TLS Certificate形式と同じです。
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.)
サーバは、適切な証明書チェーンを組み立てて、Certificateメッセージのクライアントまでそれを運びます。 クライアントがSupported Elliptic Curves Extensionを使用したなら、サーバの証明書の公開鍵はクライアントの楕円曲線の選択を尊敬しなければなりません。 クライアントが適切なタイプの明白なカーブのサポートを示していない場合、特に、公開鍵は命名されたカーブ(明白なカーブと同じカーブでない)を使わなければなりません。 クライアントがSupported Point Formats Extensionを使用したなら、サーバの公開鍵ポイントとカーブの(明白なカーブの場合における)ベースポイントの両方がクライアントのポイント形式の選択を尊敬しなければなりません。 (これらの要件を満たすことができないサーバはServerHelloメッセージでECC暗号スイートを選んではいけません。)
Blake-Wilson, et al. Informational [Page 16] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[16ページ]のRFC4492ECC暗号スイート
Actions of the receiver:
受信機の運動:
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.)
クライアントは、証明書チェーンを有効にして、サーバの公開鍵を抽出して、交渉された主要な交換アルゴリズムに、主要なタイプが適切であることをチェックします。 (致命的な握手失敗の可能な理由は取り扱い楕円曲線とポイント形式のためのクライアントの能力が超えられているということです。 Cf。 セクション5.1。)
5.4. Server Key Exchange
5.4. サーバの主要な交換
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_がやがて交換アルゴリズムを合わせると、このメッセージを送ります。
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;
明白な_第1(1)(明白な_char2(2))が予約(248 .255)にされるのである_カーブ(3)と命名したenum、ECCurveType。
explicit_prime: Indicates the elliptic curve domain parameters are
conveyed verbosely, and the underlying finite field is a prime
field.
明白な_第1: 表示、楕円曲線ドメインパラメタは冗長に伝えられて、基本的な有限分野は素体です。
explicit_char2: Indicates the elliptic curve domain parameters are
conveyed verbosely, and the underlying finite field is a
characteristic-2 field.
明白な_char2: 表示、楕円曲線ドメインパラメタは冗長に伝えられて、基本的な有限分野は特性-2分野です。
named_curve: Indicates that a named curve is used. This option
SHOULD be used when applicable.
命名された_カーブ: 命名されたカーブが使用されているのを示します。 これはSHOULDにゆだねます。適切であるときに、使用されます。
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;
struct不透明なa<1..2^8-1>; 不透明なb<1..2^8-1>;ECCurve。
Blake-Wilson, et al. Informational [Page 17] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[17ページ]のRFC4492ECC暗号スイート
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: これらのパラメタは楕円曲線の係数を指定します。 .3セクション4.3ANSI X9.62[7]の変換ルーチンに従って、各値はフィールド要素のバイトストリング表現を含んでいます。
struct {
opaque point <1..2^8-1>;
} ECPoint;
struct、不透明なポイント<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.
ポイント: これは.6セクション4.3ANSI X9.62[7]の変換ルーチンに従う楕円曲線ポイントのバイトストリング表現です。 このバイトストリングは解凍されるところの楕円曲線ポイントか圧縮形式を表すかもしれません。 この拡張子が使用されたなら、それはクライアントがSupported Point Formats Extensionを通して要求したことに従わなければなりません。
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
enumに__基礎_3項式、ec_基礎pentanomialをecする、ECBasisType。
ec_basis_trinomial: Indicates representation of a characteristic-2
field using a trinomial basis.
ec_基礎_3項式: 3項式基礎を使用することで特性-2分野の表現を示します。
ec_basis_pentanomial: Indicates representation of a
characteristic-2 field using a pentanomial basis.
ec_基礎_pentanomial: pentanomial基礎を使用することで特性-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>;
ケースec_3項式: 不透明なk<1..2^8-1>; ケースec_pentanomial: 不透明なk1<1..2^8-1>; ECCurveが曲がるというECPointが基礎づける不透明なk2<1..2^8-1>(不透明なk3<1..2^8-1>)を選択してください(基礎); オーダー<1..2^8-1>について不透明にしてください; 不透明な補助因子<1..2^8-1>。
Blake-Wilson, et al. Informational [Page 18] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[18ページ]のRFC4492ECC暗号スイート
case named_curve:
NamedCurve namedcurve;
};
} ECParameters;
命名された_カーブをケースに入れてください: NamedCurve namedcurve。 }; } ECParameters。
curve_type: This identifies the type of the elliptic curve domain
parameters.
_タイプを曲がらせてください: これは楕円曲線ドメインパラメタのタイプを特定します。
prime_p: This is the odd prime defining the field Fp.
_pを用意してください: これは分野Fpを定義する奇素数です。
curve: Specifies the coefficients a and b of the elliptic curve E.
以下を曲がらせてください。 楕円曲線Eの係数aとbを指定します。
base: Specifies the base point G on the elliptic curve.
以下を基礎づけてください。 楕円曲線のベースポイントGを指定します。
order: Specifies the order n of the base point.
オーダー: ベースポイントの注文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).
補助因子: 補助因子h=#E(Fq)/nを指定します。#そこでは、E(Fq)は分野Fq(FpかF2^mのどちらか)の上で定義された楕円曲線Eのポイントの数を表します。
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: pentanomial表現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拡張子だけで許されています)。 これは任意の_明白な_主要な_カーブ(0xFF01)と任意の_明白な_char2_カーブ(0xFF02)に適用されます。
struct {
ECParameters curve_params;
ECPoint public;
} ServerECDHParams;
struct ECParametersカーブ_params; ECPoint公衆;ServerECDHParams。
curve_params: Specifies the elliptic curve domain parameters
associated with the ECDH public key.
_paramsを曲がらせてください: ECDH公開鍵に関連している楕円曲線ドメインパラメタを指定します。
public: The ephemeral ECDH public key.
公衆: はかないECDH公開鍵。
Blake-Wilson, et al. Informational [Page 19] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[19ページ]のRFC4492ECC暗号スイート
The ServerKeyExchange message is extended as follows.
ServerKeyExchangeメッセージは以下の通り広げられます。
enum { ec_diffie_hellman } KeyExchangeAlgorithm;
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;
ケースec_diffie_hellman: ServerECDHParams params(_paramsであると署名される署名)を選択してください、(KeyExchangeAlgorithm)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.
署名している_params: 適用されたそのハッシュに適切な署名があるparamsのハッシュ。 サーバのCertificateメッセージの公認された公開鍵に対応する秘密鍵は署名に使用されます。
enum { ecdsa } SignatureAlgorithm;
enumのecdsa SignatureAlgorithm。
select (SignatureAlgorithm) {
case ecdsa:
digitally-signed struct {
opaque sha_hash[sha_size];
};
} Signature;
(SignatureAlgorithm)を選択してください、ecdsa: デジタルに署名しているstructをケースに入れてください、不透明なsha_ハッシュ[sha_サイズ];、;、署名。
ServerKeyExchange.signed_params.sha_hash
SHA(ClientHello.random + ServerHello.random +
ServerKeyExchange.params);
ServerKeyExchange.signed_params.sha_ハッシュ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].
以下に注意してください。 _やがて、SignatureAlgorithmはECDHにおける、主要な交換アルゴリズムの、そして、「匿名」のECDHE_RSAのための"rsa"です。 これらのケースはTLS[2][3]で定義されます。 SignatureAlgorithmはECDHE_ECDSAのための"ecdsa"です。 ECDSA署名は、セクション5.10で説明されるように生成されて、確かめられます、そして、sha_ハッシュのための上のテンプレートのSHAはそれに従って、SHA-1以外のハッシュアルゴリズムを指示するかもしれません。 ANSI X9.62に従って、ECDSA署名は1組の整数、r、およびsから成ります。 デジタルに署名している要素は不透明なベクトル<0としてコード化されます。2^16-1 >。それの内容は以下のASN.1記法[8]に対応する[9]をコード化するDERです。
Blake-Wilson, et al. Informational [Page 20] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[20ページ]のRFC4492ECC暗号スイート
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
以下をEcdsa-Sig評価してください:= 系列r整数、s整数
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.
サーバはIEEE1363[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.)
クライアントは、署名(存在しているとき)について確かめて、ServerKeyExchangeメッセージからサーバの楕円曲線ドメインパラメタとはかないECDH公開鍵を検索します。 (致命的な握手失敗の可能な理由は取り扱い楕円曲線とポイント形式のためのクライアントの能力が超えられているということです。 Cf。 セクション5.1。)
5.5. Certificate Request
5.5. 証明書要求
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_サイン(64)、_ecdh(65)、_ecdh(66)、(255)が修理されたecdsa_が修理されたrsa_をenumする、ClientCertificateType。
ecdsa_sign, etc. Indicates that the server would like to use the
corresponding client authentication method specified in Section 3.
ecdsa_サインなど サーバがセクション3で指定された対応するクライアント認証方法を使用したがっているのを示します。
Blake-Wilson, et al. Informational [Page 21] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[21ページ]のRFC4492ECC暗号スイート
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.
クライアントはそれには使用のための適当な証明書が要求されたメソッドのどれかであるかどうかと、クライアント認証を続けるかどうかと決心しています。
5.6. Client Certificate
5.6. クライアント証明書
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に対応して送られて、クライアント認証を続けると決めました。 (サーバであるならSupported Point Formats Extensionを使用した注意、ECDSA_サインによる使用に適していると証明書を考えることができるだけです、_ECDHが修理されたRSA_、そして、公開鍵ポイントがそれで指定したなら_ECDH認証方法が修理されたECDSA_はポイント形式のサーバの選択を尊敬します。 ポイントが解凍されたポイント形式で表されて、Supported Point Formats Extensionが全く使用されていないなら、これらの認証方法で使用に適していると証明書を考えることができるだけです。)
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).
以下に注意してください。 クライアントのCertificateメッセージは証明書のチェーンを運ぶことができます。 Table4で言及された制限はクライアントの証明書(最初にチェーンにおける)だけに適用されます。
Blake-Wilson, et al. Informational [Page 22] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[22ページ]のRFC4492ECC暗号スイート
Client
Authentication Method Client Certificate Type
--------------------- -----------------------
クライアント認証メソッドクライアント証明書タイプ--------------------- -----------------------
ECDSA_sign Certificate MUST contain an
ECDSA-capable public key and
be signed with ECDSA.
ECDSA_サインCertificateを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.
_ECDH Certificateが修理されたECDSA_はサーバの長期の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.
_ECDH Certificateが修理されたRSA_はサーバの長期のECDHキーと同じ楕円曲線にECDHできる公開鍵を含まなければなりません。 この証明書とRSAを契約しなければなりません。
Table 4: Client Certificate Types
テーブル4: クライアント証明書タイプ
Structure of this message:
このメッセージの構造:
Identical to the TLS client Certificate format.
TLSクライアントCertificate形式と同じです。
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サーバは、証明書チェーンを有効にして、クライアントの公開鍵を抽出して、クライアント認証方法に、主要なタイプが適切であることをチェックします。
5.7. Client Key Exchange
5.7. クライアントの主要な交換
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.
すべての主要な交換アルゴリズムでこのメッセージを送ります。_ECDHが固定されているECDSA_か_ECDHが固定されているRSA_でのクライアント認証が使用されているなら、このメッセージは空です。 さもなければ、それはクライアントのはかないECDH公開鍵を含んでいます。
Blake-Wilson, et al. Informational [Page 23] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[23ページ]のRFC4492ECC暗号スイート
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;
enumの暗黙の、そして、明白な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メッセージ(「明白な」)で。 (クライアントが_ECDHが修理されたECDSA_か_ECDHクライアント認証機構が修理されたRSA_を使用する時を除いて、これはECC暗号スイートで「明白です」。)
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: ECPoint ecdh_Yc;
} ecdh_public;
} ClientECDiffieHellmanPublic;
struct、(PublicValueEncoding)を選択してください、ケース暗黙:、struct、;、ケース明白である、: ECPoint ecdh_Yc;、ecdh_公衆;、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: バイトストリングECPoint.point、どれが解凍されるところに楕円曲線ポイントを表すかもしれないか、そして、または圧縮形式としてクライアントのはかないECDH公開鍵を含んでいます。 ここで、この拡張子を使用されて、この拡張子が使用されなかったなら解凍しなければならないなら、形式はサーバがSupported Point Formats Extensionを通して要求したことに従わなければなりません。
struct {
select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
(KeyExchangeAlgorithm)を選択してください。struct、ec_diffie_hellmanをケースに入れてください: ClientECDiffieHellmanPublic、_キーを交換してください;、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.
クライアントはそれがECKAS-DH1計画通りにサーバからIEEE1363[6]から受け取ったパラメタに対応するはかないECDH公開鍵を選択します。 それは、上で定義された書式を使用することでClientKeyExchangeメッセージのクライアントにこの情報を伝えます。
Blake-Wilson, et al. Informational [Page 24] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[24ページ]のRFC4492ECC暗号スイート
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キーと同じ楕円曲線にあるのをチェックします。
5.8. Certificate Verify
5.8. 証明書は確かめます。
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_サインメカニズムを使用することで認証されるとき。
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.
このメッセージは秘密鍵の所有物がクライアントのCertificateメッセージの公開鍵に対応していると立証する署名を含んでいます。
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メッセージと基本的なSignatureタイプは[2]と[3]で定義されます、そして、後者はここ、セクション5.4で広げられます。 ecdsaケースのために、CertificateVerifyメッセージの署名分野は今までのところ交換されている握手メッセージに関して計算されたECDSA署名を含んでいます、他の調印アルゴリズムが[2]と[3]にある状態で、まさにCertificateVerifyと同様です:
CertificateVerify.signature.sha_hash
SHA(handshake_messages);
CertificateVerify.signature.sha_細切れ肉料理SHA(握手_メッセージ)。
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_細切れ肉料理のための上のテンプレートのSHAはそれに従って、SHA-1以外の細切れ肉料理アルゴリズムを指示するかもしれません。 ANSI X9.62に従って、ECDSA署名は1組の整数、r、およびsから成ります。 デジタルにサインされた要素は不透明なベクトル<0としてコード化されます。2^16-1 >。それの内容は以下のASN.1記法[8]に対応する[9]をコード化するDERです。
Ecdsa-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER
}
以下をEcdsa-Sig評価してください:= 系列r整数、s整数
Blake-Wilson, et al. Informational [Page 25] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[25ページ]のRFC4492ECC暗号スイート
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.
クライアントがクライアントで始まって、送るか、または受け取るすべての握手メッセージの上の署名を計算する、こんにちは、そして、包含だけでないまでのこのメッセージ。 それは、署名を計算するのに公認された公開鍵に対応する秘密鍵を使用します。(署名は上で定義された書式で伝えられます)。
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メッセージからクライアントの署名を抽出して、それがクライアントのCertificateメッセージで受けた公開鍵を使用することで署名について確かめます。
5.9. Elliptic Curve Certificates
5.9. 楕円曲線証明書
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].
ECDSA MUSTを使用することで、ECC公開鍵を含んでいるか、またはサインされたX.509証明書はそれを取り替えるか、または広げる[14]か別のRFCに従います。 クライアントSHOULDはANSI X9.62[7]、FIPS186-2[11]、およびSEC2[13]のお勧めの楕円曲線ドメインパラメタを使用します。
5.10. ECDH, ECDSA, and RSA Computations
5.10. ECDH、ECDSA、およびRSA計算
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.
[6]によると、すべてのECDH計算(共有秘密キー計算と同様にパラメタとキー生成を含んでいる)が主要な派生機能(KDF)としてアイデンティティ地図があるECKAS-DH1計画を使用することで実行されます、前マスター秘密が八重奏ストリングとして表されたECDH共有秘密キー楕円曲線ポイントのx-座標であるように。 FE2OSPによって出力されるこの八重奏ストリング(1363年のIEEE用語のZ)(Octet String Conversion PrimitiveへのField Element)がどんな与えられた分野への恒長も持っていることに注意してください。 この八重奏ストリングで見つけられた先行ゼロに先端を切らせてはいけません。
(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.)
(アイデンティティKDFのこの使用が専門的表現であることに注意してください。 完全な絵はECDHがTLSが直接使われないので重要な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
ANSI X9.62[7]かその後継者によると、すべてのECDSA計算を実行しなければなりません。 サインされるべきであるか、または確かめられるべきデータは、論じ尽くされて直接追加論じ尽くすことのないECDSAアルゴリズムで結果走行です。 デフォルトハッシュ関数はSHA-1[10]です、そして、sha_サイズ(セクション5.4と5.8を見る)は20です。 しかしながら、FIPS180-2[10]で指定された新しいSHAハッシュ関数の1つなどの代替のハッシュ関数はECの公衆を含む証明書であるなら代わりに使用されるかもしれません。
Blake-Wilson, et al. Informational [Page 26] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[26ページ]のRFC4492ECC暗号スイート
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 RFCsは、subjectPublicKeyInfoのパラメタ分野の公開鍵と共に使用されるためにハッシュ関数を指定するのを選ぶかもしれません。)
All RSA signatures must be generated and verified according to PKCS#1 [12] block type 1.
PKCS#1[12]ゴシック体1によると、すべてのRSA署名について発生して、確かめなければなりません。
6. Cipher Suites
6. 暗号スイート
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 }
0xC0、_ヌル_SHA=0×01があるCipherSuite TLS_ECDH_ECDSA_、0xC0、_RC4_128_SHA=0×02があるCipherSuite TLS_ECDH_ECDSA_、0xC0、_3DES_EDE_CBC_SHA=0×03があるCipherSuite TLS_ECDH_ECDSA_、0xC0、_AES_128_CBC_SHA=0×04があるCipherSuite TLS_ECDH_ECDSA_、_AES_256_CBC_SHA=があるCipherSuite TLS_ECDH_ECDSA_0xC0、0×05
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 }
0xC0、_ヌル_SHA=0×06があるCipherSuite TLS_ECDHE_ECDSA_、0xC0、_RC4_128_SHA=0×07があるCipherSuite TLS_ECDHE_ECDSA_、0xC0、_3DES_EDE_CBC_SHA=0×08があるCipherSuite TLS_ECDHE_ECDSA_、0xC0、_AES_128_CBC_SHA=0×09があるCipherSuite TLS_ECDHE_ECDSA_、_AES_256_CBC_SHA=があるCipherSuite TLS_ECDHE_ECDSA_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_ECDH_RSA_が_ヌル_SHAと共に0xC0、0x0Bと等しい、CipherSuite TLS_ECDH_RSA_が_RC4_128_SHAと共に0xC0、0x0Cと等しい、CipherSuite TLS_ECDH_RSA_が_3DES_EDE_CBC_SHAと共に0xC0、0x0Dと等しい、CipherSuite TLS_ECDH_RSA_が_AES_128_CBC_SHAと共に0xC0、0x0Eと等しい、_AES_256_CBC_SHA=があるCipherSuite TLS_ECDH_RSA_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 }
0xC0、_ヌル_SHA=0×10があるCipherSuite TLS_ECDHE_RSA_、0xC0、_RC4_128_SHA=0×11があるCipherSuite TLS_ECDHE_RSA_、0xC0、_3DES_EDE_CBC_SHA=0×12があるCipherSuite TLS_ECDHE_RSA_、0xC0、_AES_128_CBC_SHA=0×13があるCipherSuite TLS_ECDHE_RSA_、_AES_256_CBC_SHA=があるCipherSuite TLS_ECDHE_RSA_0xC0、0×14
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 }
CipherSuite TLS_ECDH、_やがて_ヌル_SHAと_が0xC0、0×15と等しい、CipherSuite TLS_ECDH、___RC4_で、やがて、128_SHAが0xC0、0×16と等しい、CipherSuite TLS_ECDH、___3DES_EDE_で、やがて、CBC_SHAが0xC0、0×17と等しい、CipherSuite TLS_ECDH、___AES_で、やがて、128_CBC_SHAが0xC0、0×18と等しい、CipherSuite TLS_ECDH_、やがて、_AES_256_CBC_SHA=がある_0xC0、0×19
Table 5: TLS ECC cipher suites
テーブル5: TLS ECC暗号スイート
Blake-Wilson, et al. Informational [Page 27] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[27ページ]のRFC4492ECC暗号スイート
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は以下の暗号スイートのすべてを支持します、そして、クライアント実現SHOULDは少なくともそれらの1つを支持します: __3DES_エーデCBC_SHAとTLS_ECDH_ECDSA_、_AES_128_CBC_SHAとTLS_ECDH_ECDSA_、_3DES_EDE_CBC_SHAとTLS_ECDHE_RSA_、および_AES_128_CBC_SHAとTLS_ECDHE_RSA_。
7. Security Considerations
7. セキュリティ問題
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.
[6]と[7]でECCに特定のセキュリティ議論を見つけることができます。 implementersとユーザが考えなければならない1つの切迫した課題は楕円曲線選択です。 Table1で適切な楕円曲線サイズを選択するときの指導を与えます。
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の上を曲がるより保守的であると考えられるかもしれません)。 しかしながら、また、代数構造が実現効率につながることができることに注意してください。そうすれば、したがって、implementersとユーザは、効率の必要性に対して保守主義のバランスをとる必要があってもよいです。 具体的な攻撃はほんのわずかな特別なクラスの「スーパー-単数」カーブなどのカーブだけに対して知られています、そして、これらのクラスはこれが[6]に参照をつけると記録するECC規格から除かれます、[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].
ただ一つの楕円曲線が広く使用されるとき、別の問題は突発故障の可能性です。 この場合、楕円曲線に対する攻撃は多くのキーの妥協をもたらすかもしれません。 一方、この関心は、広く使用されたカーブに関連している効率と相互運用性改良に対してバランスをとる必要があるかもしれません。 [5]、[6]、[7]、および[11]で楕円曲線選択のかなりの追加情報を見つけることができます。
Blake-Wilson, et al. Informational [Page 28] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[28ページ]のRFC4492ECC暗号スイート
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.
また、Implementersとユーザは、彼らが前進の秘密主義を必要とするかどうか考えなければなりません。 サーバとクライアントのものである静的で、公認されたキーが妥協するなら妥協して、前進の秘密主義はセッションキーがない特性を示します。 ECDHE_ECDSAとECDHE_RSAの主要な交換アルゴリズムはサーバの主要な妥協の場合、前進の秘密主義保護を提供します、ECDH_ECDSAとECDH_RSAはそうしませんが。 同様に、クライアントが静的で、公認されたキーを提供しているなら、ECDSA_サインクライアント認証はクライアントの主要な妥協の場合、前進の秘密主義保護を提供します、ECDSA_が_ECDHを修理しました、そして、RSA_はECDHが修理しない_を修理しましたが。 したがって、主要な交換において、完全な前進の秘密主義保護、ECDHE_ECDSAまたはECDHE_RSAを入手するのは使用されているに違いありません、必要なら、ECDSA_サインがクライアント認証に使用されている状態で。 ここで、一方、前進の秘密主義のセキュリティ利益は、別の選択肢で提供された改良された効率に対してバランスをとる必要があるかもしれません。
8. IANA Considerations
8. IANA問題
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].
それぞれの名前スペースと、このドキュメントは、初期の値の課題を定義して、兵士のUseのために予約された256の値(NamedCurve)か8つの値(ECPointFormatとECCurveType)の範囲を定義します。 どんな追加課題もIETF Consensus動作[16]を必要とします。
9. Acknowledgements
9. 承認
The authors wish to thank Bill Anderson and Tim Dierks.
作者はビル・アンダーソンとティムDierksに感謝したがっています。
Blake-Wilson, et al. Informational [Page 29] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[29ページ]のRFC4492ECC暗号スイート
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[1] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、RFC2119、1997年3月。
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[2] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[3] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[3] Dierks、T.、およびE.レスコラ、「トランスポート層セキュリティ(TLS)は2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。
[4] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", RFC
4366, April 2006.
[4] ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。
[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
<http://www.secg.org/>.
[5]SECG、「楕円曲線暗号」、SEC1、2000、<http://www.secg.org/>。
[6] IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000.
[6]IEEE、「公開鍵暗号のための標準の仕様」、IEEE1363、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] 国際電気通信連合、「情報技術--Syntax Notation One(ASN.1)を抜き取ってください」 「基本的な記法の仕様」、ITU-T Recommendation 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] 国際電気通信連合、「情報技術--ASN.1コード化は以下を統治します」。 「基本的な符号化規則(BER)、正準な符号化規則(CER)、および顕著な符号化規則(DER)の仕様」、ITU-T推薦X.690、2002。
[10] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
[10]NIST、「安全な細切れ肉料理規格」、FIPS180-2、2002。
[11] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[11]NIST、「デジタル署名基準」、FIPS186-2、2000。
[12] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
1.5", PKCS 1, November 1993.
[12] RSA研究所、「PKCS#1:」 RSA Encryption Standard、バージョン1.5インチ、PKCS1、11月1993日
[13] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
2000, <http://www.secg.org/>.
[13]SECG、「お勧めの楕円曲線ドメインパラメタ。」SEC2、2000、<http://www.secg.org/>。
Blake-Wilson, et al. Informational [Page 30] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[30ページ]のRFC4492ECC暗号スイート
[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] ポーク、T.、Housley、R.、およびL.Bassham、「インターネットX.509公開鍵暗号基盤証明書と証明書取消しのためのアルゴリズムと識別子は(CRL)プロフィールをリストアップします」、RFC3279、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.、ポーク、T.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(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、「RFCsにIANA問題部に書くためのガイドライン」、RFC2434、1998年10月。
10.2. Informative References
10.2. 有益な参照
[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] ハーパー、G.、メネゼス、A.、およびS.Vanstone、「非常にわずかなキー長がある公開カギ暗号系」を暗号理論で進みます--EUROCRYPT92年(LNCS658、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.フェルヘール、「暗号化キーサイズを選択します」、暗号理論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、2002年6月のP.、「トランスポート層セキュリティ(TLS)のためのエー・イー・エス(AES)Ciphersuites」RFC3268。
Blake-Wilson, et al. Informational [Page 31] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[31ページ]のRFC4492ECC暗号スイート
Appendix A. Equivalent Curves (Informative)
付録のA.の同等なカーブ(有益)です。
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
------------+---------------+-------------
------------------------------------------ 異なった規格組織によって選ばれたカーブ名------------+---------------+------------- SECG| ANSI X9.62| NIST------------+---------------+------------- sect163k1| | NIST K-163sect163r1| | sect163r2| | NIST B-163 sect193r1| | sect193r2| | sect233k1| | NIST K-233sect233r1| | NIST B-233 sect239k1| | sect283k1| | NIST K-283sect283r1| | NIST B-283 sect409k1| | NIST K-409sect409r1| | NIST B-409 sect571k1| | NIST K-571sect571r1| | 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によって定義された同等なカーブ
Blake-Wilson, et al. Informational [Page 32] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[32ページ]のRFC4492ECC暗号スイート
Authors' Addresses
作者のアドレス
Simon Blake-Wilson SafeNet Technologies BV Amstelveenseweg 88-90 1075 XJ, Amsterdam NL
サイモンブレーク-ウィルソンSafeNet技術BV Amstelveenseweg88-90 1075XJ、アムステルダムNL
Phone: +31 653 899 836 EMail: sblakewilson@safenet-inc.com
以下に電話をしてください。 +31 653 899 836はメールされます: sblakewilson@safenet-inc.com
Nelson Bolyard Sun Microsystems Inc. 4170 Network Circle MS SCA17-201 Santa Clara, CA 95054 US
ネルソンBolyardサン・マイクロシステムズ4170ネットワーク円のMS SCA17-201カリフォルニア95054サンタクララ(米国)
Phone: +1 408 930 1443 EMail: nelson@bolyard.com
以下に電話をしてください。 +1 1443年の408 930メール: nelson@bolyard.com
Vipul Gupta Sun Microsystems Laboratories 16 Network Circle MS UMPK16-160 Menlo Park, CA 94025 US
UMPK16-160メンローパークさん、Vipulグプタサン・マイクロシステムズ研究所16ネットワーク円のカリフォルニア94025米国
Phone: +1 650 786 7551 EMail: vipul.gupta@sun.com
以下に電話をしてください。 +1 7551年の650 786メール: vipul.gupta@sun.com
Chris Hawk Corriente Networks LLC 1563 Solano Ave., #484 Berkeley, CA 94707 US
クリスタカのCorrienteがLLC1563ソラノAveをネットワークでつなぐ、#484カリフォルニア94707バークレー(米国)
Phone: +1 510 527 0601 EMail: chris@corriente.net
以下に電話をしてください。 +1 0601年の510 527メール: chris@corriente.net
Blake-Wilson, et al. Informational [Page 33] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[33ページ]のRFC4492ECC暗号スイート
Bodo Moeller Ruhr-Uni Bochum Horst-Goertz-Institut, Lehrstuhl fuer Kommunikationssicherheit IC 4/139 44780 Bochum DE
ボーデメラールール-UniボーフムホルストゲルツInstitut、Lehrstuhl fuer Kommunikationssicherheit IC4/139 44780ボーフムDE
Phone: +49 234 32 26795 EMail: bodo@openssl.org
以下に電話をしてください。 +49 234 32 26795はメールされます: bodo@openssl.org
Blake-Wilson, et al. Informational [Page 34] RFC 4492 ECC Cipher Suites for TLS May 2006
ブレーク-ウィルソン、他 TLS2006年5月のための情報[34ページ]のRFC4492ECC暗号スイート
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Blake-Wilson, et al. Informational [Page 35]
ブレーク-ウィルソン、他 情報[35ページ]
一覧
スポンサーリンク
