[要約] RFC 4366、現在はRFC 5246によって置き換えられていますが、Transport Layer Security (TLS) Extensionsに関する文書です。このRFCは、TLSプロトコルの拡張性を高めるためのメカニズムを導入し、クライアントとサーバー間でのセキュリティ機能の交渉をより柔軟に行うことを目的としています。利用場面としては、セキュアな通信を必要とするあらゆるインターネットアプリケーションでの使用が想定されます。関連するRFCとしては、RFC 5246 (TLS 1.2の定義)、RFC 8446 (TLS 1.3の定義)、そしてTLS拡張をさらに詳細に扱うRFC 6066があります。これらの文書は、TLSプロトコルの進化と共に、セキュリティ、互換性、および機能性を向上させるための基盤を提供します。
Network Working Group S. Blake-Wilson
Request for Comments: 4366 BCI
Obsoletes: 3546 M. Nystrom
Updates: 4346 RSA Security
Category: Standards Track D. Hopwood
Independent Consultant
J. Mikkelsen
Transactionware
T. Wright
Vodafone
April 2006
Transport Layer Security (TLS) Extensions
トランスポートレイヤーセキュリティ（TLS）拡張機能
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
このドキュメントでは、レイヤーセキュリティ（TLS）を輸送するための機能を追加するために使用できる拡張機能について説明します。TLSハンドシェイククライアントとサーバーHellosに、これらの一般的なメカニズムを使用した特定の拡張機能の両方の一般的な拡張メカニズムを提供します。
The extensions may be used by TLS clients and servers. The extensions are backwards compatible: communication is possible between TLS clients that support the extensions and TLS servers that do not support the extensions, and vice versa.
拡張機能は、TLSクライアントとサーバーが使用できます。拡張機能は逆方向に互換性があります。拡張機能をサポートするTLSクライアントと、拡張機能をサポートしていないTLSサーバー間で通信が可能です。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................5
2. General Extension Mechanisms ....................................5
2.1. Extended Client Hello ......................................5
2.2. Extended Server Hello ......................................6
2.3. Hello Extensions ...........................................6
2.4. Extensions to the Handshake Protocol .......................8
3. Specific Extensions .............................................8
3.1. Server Name Indication ....................................9
3.2. Maximum Fragment Length Negotiation ......................11
3.3. Client Certificate URLs ..................................12
3.4. Trusted CA Indication ....................................15
3.5. Truncated HMAC ............................................16
3.6. Certificate Status Request ................................17
4. Error Alerts ...................................................19
5. Procedure for Defining New Extensions ..........................20
6. Security Considerations ........................................21
6.1. Security of server_name ...................................22
6.2. Security of max_fragment_length ...........................22
6.3. Security of client_certificate_url ........................22
6.4. Security of trusted_ca_keys ...............................24
6.5. Security of truncated_hmac ................................24
6.6. Security of status_request ................................25
7. Internationalization Considerations ............................25
8. IANA Considerations ............................................25
9. Acknowledgements ...............................................27
10. Normative References ..........................................27
11. Informative References ........................................28
This document describes extensions that may be used to add functionality to Transport Layer Security (TLS). It provides both generic extension mechanisms for the TLS handshake client and server hellos, and specific extensions using these generic mechanisms.
このドキュメントでは、レイヤーセキュリティ（TLS）を輸送するための機能を追加するために使用できる拡張機能について説明します。TLSハンドシェイククライアントとサーバーHellosに、これらの一般的なメカニズムを使用した特定の拡張機能の両方の一般的な拡張メカニズムを提供します。
TLS is now used in an increasing variety of operational environments, many of which were not envisioned when the original design criteria for TLS were determined. The extensions introduced in this document are designed to enable TLS to operate as effectively as possible in new environments such as wireless networks.
TLSは現在、さまざまな運用環境で使用されていますが、その多くは、TLSの元の設計基準が決定されたときに想定されていません。このドキュメントで導入された拡張機能は、ワイヤレスネットワークなどの新しい環境で可能な限り効果的に動作できるように設計されています。
Wireless environments often suffer from a number of constraints not commonly present in wired environments. These constraints may include bandwidth limitations, computational power limitations, memory limitations, and battery life limitations.
ワイヤレス環境は、有線環境では一般的に存在しない多くの制約に苦しむことがよくあります。これらの制約には、帯域幅の制限、計算電力の制限、メモリの制限、およびバッテリー寿命の制限が含まれる場合があります。
The extensions described here focus on extending the functionality provided by the TLS protocol message formats. Other issues, such as the addition of new cipher suites, are deferred.
ここで説明する拡張機能は、TLSプロトコルメッセージ形式によって提供される機能の拡張に焦点を当てています。新しい暗号スイートの追加など、他の問題が延期されます。
Specifically, the extensions described in this document:
具体的には、このドキュメントで説明されている拡張機能：
- Allow TLS clients to provide to the TLS server the name of the server they are contacting. This functionality is desirable in order to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address.
- TLSクライアントがTLSサーバーに連絡しているサーバーの名前を提供できるようにします。この機能は、単一の基礎となるネットワークアドレスで複数の「仮想」サーバーをホストするサーバーへの安全な接続を容易にするために望ましいです。
- Allow TLS clients and servers to negotiate the maximum fragment length to be sent. This functionality is desirable as a result of memory constraints among some clients, and bandwidth constraints among some access networks.
- TLSクライアントとサーバーが送信される最大フラグメント長をネゴシエートさせることを許可します。この機能は、一部のクライアント間のメモリの制約と、一部のアクセスネットワーク間の帯域幅の制約の結果として望ましいものです。
- Allow TLS clients and servers to negotiate the use of client certificate URLs. This functionality is desirable in order to conserve memory on constrained clients.
- TLSクライアントとサーバーがクライアント証明書のURLの使用をネゴシエートできるようにします。この機能は、制約されたクライアントのメモリを節約するために望ましいです。
- Allow TLS clients to indicate to TLS servers which CA root keys they possess. This functionality is desirable in order to prevent multiple handshake failures involving TLS clients that are only able to store a small number of CA root keys due to memory limitations.
- TLSクライアントが、それらが所有するCAルートキーをTLSサーバーに示すことを許可します。この機能は、メモリの制限により少数のCAルートキーのみを保存できるTLSクライアントが関与する複数の握手障害を防ぐために望ましいです。
- Allow TLS clients and servers to negotiate the use of truncated MACs. This functionality is desirable in order to conserve bandwidth in constrained access networks.
- TLSクライアントとサーバーが切り捨てられたMacの使用を交渉できるようにします。この機能は、制約付きアクセスネットワークの帯域幅を保存するために望ましいです。
- Allow TLS clients and servers to negotiate that the server sends the client certificate status information (e.g., an Online Certificate Status Protocol (OCSP) [OCSP] response) during a TLS handshake. This functionality is desirable in order to avoid sending a Certificate Revocation List (CRL) over a constrained access network and therefore save bandwidth.
- TLSクライアントとサーバーが、TLSハンドシェイク中にサーバーがクライアント証明書ステータス情報（オンライン証明書ステータスプロトコル（OCSP）[OCSP]応答）を送信することを交渉できるようにします。この機能は、制約されたアクセスネットワークを介して証明書取消リスト（CRL）を送信しないため、帯域幅を保存するために望ましいです。
In order to support the extensions above, general extension mechanisms for the client hello message and the server hello message are introduced.
上記の拡張機能をサポートするために、クライアントのhelloメッセージとサーバーのhelloメッセージの一般的な拡張メカニズムが導入されます。
The extensions described in this document may be used by TLS clients and servers. The extensions are designed to be backwards compatible, meaning that TLS clients that support the extensions can talk to TLS servers that do not support the extensions, and vice versa. The document therefore updates TLS 1.0 [TLS] and TLS 1.1 [TLSbis].
このドキュメントで説明されている拡張機能は、TLSクライアントとサーバーが使用できます。拡張機能は、逆方向に互換性があるように設計されています。つまり、拡張機能をサポートするTLSクライアントは、拡張機能をサポートしていないTLSサーバーと通信できます。したがって、このドキュメントはTLS 1.0 [TLS]およびTLS 1.1 [TLSBIS]を更新します。
Backwards compatibility is primarily achieved via two considerations:
後方互換性は、主に2つの考慮事項によって達成されます。
- Clients typically request the use of extensions via the extended client hello message described in Section 2.1. TLS requires servers to accept extended client hello messages, even if the server does not "understand" the extension.
- クライアントは通常、セクション2.1で説明されている拡張クライアントのhelloメッセージを介して拡張機能の使用を要求します。TLSは、サーバーが拡張機能を「理解」していない場合でも、サーバーに拡張クライアントのハローメッセージを受け入れる必要があります。
- For the specific extensions described here, no mandatory server response is required when clients request extended functionality.
- ここで説明する特定の拡張機能の場合、クライアントが拡張機能を要求する場合、必須のサーバー応答は必要ありません。
Essentially, backwards compatibility is achieved based on the TLS requirement that servers that are not "extensions-aware" ignore data added to client hellos that they do not recognize; for example, see Section 7.4.1.2 of [TLS].
基本的に、「拡張が認識していない」サーバーがクライアントのHellosに追加されたデータを認識していないことを無視するというTLS要件に基づいて、後方互換性が達成されます。たとえば、[TLS]のセクション7.4.1.2を参照してください。
Note, however, that although backwards compatibility is supported, some constrained clients may be forced to reject communications with servers that do not support the extensions as a result of the limited capabilities of such clients.
ただし、後方互換性はサポートされていますが、一部の制約されたクライアントは、そのようなクライアントの限られた機能の結果として拡張機能をサポートしていないサーバーとの通信を拒否することを余儀なくされる場合があることに注意してください。
This document is a revision of the RFC3546 [RFC3546]. The only major change concerns the definition of new extensions. New extensions can now be defined via the IETF Consensus Process (rather than requiring a standards track RFC). In addition, a few minor clarifications and editorial improvements were made.
このドキュメントは、RFC3546 [RFC3546]の改訂です。唯一の主要な変更は、新しい拡張機能の定義に関するものです。新しい拡張機能は、IETFコンセンサスプロセスを介して定義できるようになりました（標準トラックRFCを要求するのではなく）。さらに、いくつかの小さな説明と編集の改善が行われました。
The remainder of this document is organized as follows. Section 2 describes general extension mechanisms for the client hello and server hello handshake messages. Section 3 describes specific extensions to TLS. Section 4 describes new error alerts for use with the TLS extensions. The final sections of the document address IPR, security considerations, registration of the application/pkix-pkipath MIME type, acknowledgements, and references.
このドキュメントの残りの部分は、次のように整理されています。セクション2では、クライアントの一般的な拡張メカニズムについて説明します。こんにちは、サーバーハローハンドシェイクメッセージについて説明します。セクション3では、TLSへの特定の拡張機能について説明します。セクション4では、TLS拡張機能で使用するための新しいエラーアラートについて説明します。ドキュメントの最後のセクションは、IPR、セキュリティに関する考慮事項、アプリケーション/PKIX-PKIPATH MIMEタイプの登録、謝辞、および参照をアドレスします。
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 BCP 14, RFC 2119 [KEYWORDS].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [キーワード]に記載されているとおりに解釈されます。
This section presents general extension mechanisms for the TLS handshake client hello and server hello messages.
このセクションでは、TLSハンドシェイククライアントのHelloとServer Helloメッセージの一般的な拡張メカニズムを示します。
These general extension mechanisms are necessary in order to enable clients and servers to negotiate whether to use specific extensions, and how to use specific extensions. The extension formats described are based on [MAILINGLIST].
これらの一般的な拡張メカニズムは、クライアントとサーバーが特定の拡張機能を使用するかどうか、特定の拡張機能を使用する方法を交渉できるようにするために必要です。説明されている拡張フォーマットは、[MailingList]に基づいています。
Section 2.1 specifies the extended client hello message format, Section 2.2 specifies the extended server hello message format, and Section 2.3 describes the actual extension format used with the extended client and server hellos.
セクション2.1拡張クライアントのHelloメッセージフォーマットを指定し、セクション2.2に拡張サーバーのHelloメッセージ形式を指定し、セクション2.3には、拡張クライアントとサーバーHellosで使用される実際の拡張形式について説明します。
Clients MAY request extended functionality from servers by sending the extended client hello message format in place of the client hello message format. The extended client hello message format is:
クライアントは、クライアントのハローメッセージ形式の代わりに拡張クライアントのhelloメッセージ形式を送信することにより、サーバーから拡張機能を要求する場合があります。拡張クライアントのハローメッセージフォーマットは次のとおりです。
struct {
ProtocolVersion client_version;
Random random;
SessionID session_id;
CipherSuite cipher_suites<2..2^16-1>;
CompressionMethod compression_methods<1..2^8-1>;
Extension client_hello_extension_list<0..2^16-1>;
} ClientHello;
Here the new "client_hello_extension_list" field contains a list of extensions. The actual "Extension" format is defined in Section 2.3.
ここで、新しい「client_hello_extension_list」フィールドには、拡張機能のリストが含まれています。実際の「拡張機能」形式は、セクション2.3で定義されています。
In the event that a client requests additional functionality using the extended client hello, and this functionality is not supplied by the server, the client MAY abort the handshake.
クライアントが拡張クライアントHelloを使用して追加の機能を要求した場合、この機能はサーバーによって提供されない場合、クライアントはハンドシェイクを中止する場合があります。
Note that [TLS], Section 7.4.1.2, allows additional information to be added to the client hello message. Thus, the use of the extended client hello defined above should not "break" existing TLS servers.
[TLS]、セクション7.4.1.2では、追加情報をクライアントHelloメッセージに追加できることに注意してください。したがって、上記で定義されている拡張クライアントのHelloの使用は、既存のTLSサーバーを「壊す」べきではありません。
A server that supports the extensions mechanism MUST accept only client hello messages in either the original or extended ClientHello format and (as for all other messages) MUST check that the amount of data in the message precisely matches one of these formats. If it does not, then it MUST send a fatal "decode_error" alert. This overrides the "Forward compatibility note" in [TLS].
拡張メカニズムをサポートするサーバーは、元のクライアントまたは拡張されたClientHello形式のいずれかのクライアントハローメッセージのみを受け入れる必要があり、（他のすべてのメッセージについて）メッセージ内のデータの量がこれらの形式のいずれかと正確に一致することを確認する必要があります。そうでない場合は、致命的な「decode_error」アラートを送信する必要があります。これにより、[TLS]の「フォワード互換性ノート」がオーバーライドされます。
The extended server hello message format MAY be sent in place of the server hello message when the client has requested extended functionality via the extended client hello message specified in Section 2.1. The extended server hello message format is:
拡張サーバーのハローメッセージ形式は、セクション2.1で指定された拡張クライアントのハローメッセージを介してクライアントが拡張機能を要求したときにサーバーのhelloメッセージの代わりに送信される場合があります。拡張サーバーハローメッセージフォーマットは次のとおりです。
struct {
ProtocolVersion server_version;
Random random;
SessionID session_id;
CipherSuite cipher_suite;
CompressionMethod compression_method;
Extension server_hello_extension_list<0..2^16-1>;
} ServerHello;
Here the new "server_hello_extension_list" field contains a list of extensions. The actual "Extension" format is defined in Section 2.3.
ここで、新しい「server_hello_extension_list」フィールドには、拡張機能のリストが含まれています。実際の「拡張機能」形式は、セクション2.3で定義されています。
Note that the extended server hello message is only sent in response to an extended client hello message. This prevents the possibility that the extended server hello message could "break" existing TLS clients.
拡張サーバーのhelloメッセージは、拡張クライアントのhelloメッセージにのみ応答して送信されることに注意してください。これにより、拡張サーバーのHelloメッセージが既存のTLSクライアントを「壊す」可能性がある可能性が妨げられます。
The extension format for extended client hellos and extended server hellos is:
拡張クライアントHellosおよび拡張サーバーHellosの拡張形式は次のとおりです。
struct {
ExtensionType extension_type;
opaque extension_data<0..2^16-1>;
} Extension;
Here:
ここ：
- "extension_type" identifies the particular extension type.
- 「extension_type」は、特定の拡張型タイプを識別します。
- "extension_data" contains information specific to the particular extension type.
- 「Extension_Data」には、特定の拡張型タイプに固有の情報が含まれています。
The extension types defined in this document are:
このドキュメントで定義されている拡張タイプは次のとおりです。
enum {
server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5), (65535)
} ExtensionType;
The list of defined extension types is maintained by the IANA. The current list can be found at: http://www.iana.org/assignments/tls-extensiontype-values. See Sections 5 and 8 for more information on how new values are added.
定義された拡張タイプのリストは、IANAによって維持されます。現在のリストは、http：//www.iana.org/assignments/tls-extensiontype-valuesにあります。新しい値の追加方法については、セクション5および8を参照してください。
Note that for all extension types (including those defined in the future), the extension type MUST NOT appear in the extended server hello unless the same extension type appeared in the corresponding client hello. Thus clients MUST abort the handshake if they receive an extension type in the extended server hello that they did not request in the associated (extended) client hello.
すべての拡張タイプ（将来定義されているものを含む）について、拡張タイプは、対応するクライアントのhelloに同じ拡張タイプが表示されない限り、拡張サーバーのhelloに表示されないことに注意してください。したがって、クライアントは、関連する（拡張）クライアントのhelloで要求しなかった拡張サーバーのhelloで拡張タイプを受け取った場合、ハンドシェイクを中止する必要があります。
Nonetheless, "server-oriented" extensions may be provided in the future within this framework. Such an extension (say, of type x) would require the client to first send an extension of type x in the (extended) client hello with empty extension_data to indicate that it supports the extension type. In this case, the client is offering the capability to understand the extension type, and the server is taking the client up on its offer.
それにもかかわらず、「サーバー指向の」拡張機能は、このフレームワーク内で将来提供される場合があります。このような拡張機能（たとえば、タイプxの）では、クライアントが最初に（拡張）クライアントのタイプxの拡張機能を送信して、empty endix_dataをhello hello helloで送信する必要があります。この場合、クライアントは拡張機能タイプを理解する機能を提供しており、サーバーはクライアントをそのオファーに取り上げています。
Also note that when multiple extensions of different types are present in the extended client hello or the extended server hello, the extensions may appear in any order. There MUST NOT be more than one extension of the same type.
また、異なるタイプの複数の拡張機能が拡張クライアントHelloまたは拡張サーバーHelloに存在する場合、拡張機能が任意の順序で表示される場合があることに注意してください。同じタイプの拡張機能が1つ以上ないはずです。
Finally, note that an extended client hello may be sent both when starting a new session and when requesting session resumption. Indeed, a client that requests resumption of a session does not in general know whether the server will accept this request, and therefore it SHOULD send an extended client hello if it would normally do so for a new session. In general the specification of each extension type must include a discussion of the effect of the extension both during new sessions and during resumed sessions.
最後に、新しいセッションを開始するときとセッションの再開を要求するときの両方で、拡張クライアントのHelloが送信される場合があることに注意してください。実際、セッションの再開を要求するクライアントは、一般的にサーバーがこのリクエストを受け入れるかどうかを知りません。したがって、通常、新しいセッションのためにそうする場合は、拡張クライアントのhelloを送信する必要があります。一般に、各拡張タイプの仕様には、新しいセッション中および再開されたセッション中の両方の拡張機能の効果に関する議論を含める必要があります。
This document suggests the use of two new handshake messages, "CertificateURL" and "CertificateStatus". These messages are described in Section 3.3 and Section 3.6, respectively. The new handshake message structure therefore becomes:
このドキュメントは、2つの新しい握手メッセージ「certifativeurl」と「cermotionatestatus」の使用を提案しています。これらのメッセージは、それぞれセクション3.3とセクション3.6で説明されています。したがって、新しい握手メッセージ構造は次のようになります。
enum {
hello_request(0), client_hello(1), server_hello(2),
certificate(11), server_key_exchange (12),
certificate_request(13), server_hello_done(14),
certificate_verify(15), client_key_exchange(16),
finished(20), certificate_url(21), certificate_status(22),
(255)
} HandshakeType;
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (HandshakeType) {
case hello_request: HelloRequest;
case client_hello: ClientHello;
case server_hello: ServerHello;
case certificate: Certificate;
case server_key_exchange: ServerKeyExchange;
case certificate_request: CertificateRequest;
case server_hello_done: ServerHelloDone;
case certificate_verify: CertificateVerify;
case client_key_exchange: ClientKeyExchange;
case finished: Finished;
case certificate_url: CertificateURL;
case certificate_status: CertificateStatus;
} body;
} Handshake;
This section describes the specific TLS extensions specified in this document.
このセクションでは、このドキュメントで指定された特定のTLS拡張機能について説明します。
Note that any messages associated with these extensions that are sent during the TLS handshake MUST be included in the hash calculations involved in "Finished" messages.
TLSハンドシェイク中に送信されるこれらの拡張機能に関連付けられたメッセージは、「完成」メッセージに含まれるハッシュ計算に含める必要があることに注意してください。
Note also that all the extensions defined in this section are relevant only when a session is initiated. When a client includes one or more of the defined extension types in an extended client hello while requesting session resumption:
また、このセクションで定義されているすべての拡張機能は、セッションが開始された場合にのみ関連することに注意してください。クライアントが、セッション再開を要求しながら、拡張クライアントのHelloに1つ以上の定義された拡張機能を含める場合：
- If the resumption request is denied, the use of the extensions is negotiated as normal.
- 再開要求が拒否された場合、拡張機能の使用は通常どおり交渉されます。
- If, on the other hand, the older session is resumed, then the server MUST ignore the extensions and send a server hello containing none of the extension types. In this case, the functionality of these extensions negotiated during the original session initiation is applied to the resumed session.
- 一方、古いセッションが再開された場合、サーバーは拡張機能を無視し、拡張機能タイプを含むサーバーHelloを送信する必要があります。この場合、元のセッション開始中に交渉されたこれらの拡張機能の機能が再開されたセッションに適用されます。
Section 3.1 describes the extension of TLS to allow a client to indicate which server it is contacting. Section 3.2 describes the extension that provides maximum fragment length negotiation. Section 3.3 describes the extension that allows client certificate URLs. Section 3.4 describes the extension that allows a client to indicate which CA root keys it possesses. Section 3.5 describes the extension that allows the use of truncated HMAC. Section 3.6 describes the extension that supports integration of certificate status information messages into TLS handshakes.
セクション3.1では、TLSの拡張について説明して、クライアントが連絡しているサーバーを示すことができます。セクション3.2では、最大フラグメントの長さの交渉を提供する拡張機能について説明します。セクション3.3では、クライアント証明書のURLを許可する拡張機能について説明します。セクション3.4では、クライアントが持っているCAルートキーを示すことができる拡張機能について説明します。セクション3.5では、切り捨てられたHMACの使用を可能にする拡張機能について説明します。セクション3.6では、証明書ステータス情報メッセージのTLSハンドシェイクへの統合をサポートする拡張機能について説明します。
TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting. It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address.
TLSは、クライアントがサーバーに連絡しているサーバーの名前を指示するメカニズムを提供しません。クライアントがこの情報を提供して、単一の基礎となるネットワークアドレスで複数の「仮想」サーバーをホストするサーバーへの安全な接続を促進することが望ましい場合があります。
In order to provide the server name, clients MAY include an extension of type "server_name" in the (extended) client hello. The "extension_data" field of this extension SHALL contain "ServerNameList" where:
サーバー名を提供するために、クライアントには（拡張）クライアントのhelloにタイプ「server_name」の拡張機能を含めることができます。この拡張機能の「拡張子」フィールドには、「servernamelist」が含まれます。
struct {
NameType name_type;
select (name_type) {
case host_name: HostName;
} name;
} ServerName;
enum {
host_name(0), (255)
} NameType;
opaque HostName<1..2^16-1>;
struct {
ServerName server_name_list<1..2^16-1>
} ServerNameList;
Currently, the only server names supported are DNS hostnames; however, this does not imply any dependency of TLS on DNS, and other name types may be added in the future (by an RFC that updates this document). TLS MAY treat provided server names as opaque data and pass the names and types to the application.
現在、サポートされているサーバー名はDNSホスト名です。ただし、これはDNSに対するTLSの依存性を意味するものではなく、他の名前のタイプが将来追加される可能性があります（このドキュメントを更新するRFCによって）。TLSは、提供されたサーバー名を不透明なデータとして扱い、名前とタイプをアプリケーションに渡すことができます。
"HostName" contains the fully qualified DNS hostname of the server, as understood by the client. The hostname is represented as a byte string using UTF-8 encoding [UTF8], without a trailing dot.
「ホスト名」には、クライアントが理解しているように、サーバーの完全な資格のあるDNSホスト名が含まれています。ホスト名は、後続のドットなしでUTF-8エンコード[UTF8]を使用してバイト文字列として表されます。
If the hostname labels contain only US-ASCII characters, then the client MUST ensure that labels are separated only by the byte 0x2E, representing the dot character U+002E (requirement 1 in Section 3.1 of [IDNA] notwithstanding). If the server needs to match the HostName against names that contain non-US-ASCII characters, it MUST perform the conversion operation described in Section 4 of [IDNA], treating the HostName as a "query string" (i.e., the AllowUnassigned flag MUST be set). Note that IDNA allows labels to be separated by any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61; therefore, servers MUST accept any of these characters as a label separator. If the server only needs to match the HostName against names containing exclusively ASCII characters, it MUST compare ASCII names case-insensitively.
ホスト名のラベルにUS-ASCII文字のみが含まれている場合、クライアントは、ラベルがバイト0x2Eによってのみ分離されていることを確認する必要があります。サーバーが非US-ASCII文字を含む名前とホスト名を一致させる必要がある場合、[idna]のセクション4で説明されている変換操作を実行する必要があり、ホスト名を「クエリ文字列」として扱う必要があります（つまり、Allowunassignedフラグは必要です。悩ませる）。IDNAは、Unicode文字U 002E、U 3002、U FF0E、およびU FF61のいずれかによってラベルを分離できることに注意してください。したがって、サーバーはこれらの文字のいずれかをラベルセパレーターとして受け入れる必要があります。サーバーがHostNameをASCII文字のみを含む名前と一致させる必要がある場合、ASCII名をケースインセンシティで比較する必要があります。
Literal IPv4 and IPv6 addresses are not permitted in "HostName".
リテラルIPv4およびIPv6アドレスは、「ホスト名」では許可されていません。
It is RECOMMENDED that clients include an extension of type "server_name" in the client hello whenever they locate a server by a supported name type.
クライアントがサポートされている名前タイプでサーバーを見つけるたびに、クライアントのhelloにタイプ「server_name」の拡張機能を含めることをお勧めします。
A server that receives a client hello containing the "server_name" extension MAY use the information contained in the extension to guide its selection of an appropriate certificate to return to the client, and/or other aspects of security policy. In this event, the server SHALL include an extension of type "server_name" in the (extended) server hello. The "extension_data" field of this extension SHALL be empty.
「server_name」拡張機能を含むクライアントのhelloを受信するサーバーは、拡張機能に含まれる情報を使用して、適切な証明書を選択するためにクライアントに戻るための適切な証明書、および/またはセキュリティポリシーのその他の側面を導くことができます。この場合、サーバーには（拡張）サーバーのhelloに「server_name」の拡張機能が含まれます。この拡張機能の「extension_Data」フィールドは空にする必要があります。
If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal).
サーバーがクライアントのHello Extensionを理解しているが、サーバー名を認識していない場合、「Unecognized_name」アラート（致命的かもしれない）を送信する必要があります。
If an application negotiates a server name using an application protocol and then upgrades to TLS, and if a server_name extension is sent, then the extension SHOULD contain the same name that was negotiated in the application protocol. If the server_name is established in the TLS session handshake, the client SHOULD NOT attempt to request a different server name at the application layer.
アプリケーションがアプリケーションプロトコルを使用してサーバー名をネゴシエートしてからTLSにアップグレードし、server_name拡張子が送信された場合、拡張子にはアプリケーションプロトコルでネゴシエートされた同じ名前を含める必要があります。Server_NameがTLSセッションのハンドシェイクで確立されている場合、クライアントはアプリケーションレイヤーで別のサーバー名を要求しようとしてはなりません。
Without this extension, TLS specifies a fixed maximum plaintext fragment length of 2^14 bytes. It may be desirable for constrained clients to negotiate a smaller maximum fragment length due to memory limitations or bandwidth limitations.
この拡張機能がなければ、TLSは2^14バイトの固定最大プレーンテキストフラグメント長を指定します。制約されたクライアントが、メモリの制限または帯域幅の制限により、より小さな最大フラグメント長を交渉することが望ましい場合があります。
In order to negotiate smaller maximum fragment lengths, clients MAY include an extension of type "max_fragment_length" in the (extended) client hello. The "extension_data" field of this extension SHALL contain:
より少ない最大フラグメント長を交渉するために、クライアントには（拡張）クライアントのhelloに「max_fragment_length」の拡張が含まれる場合があります。この拡張機能の「extension_Data」フィールドには、次のものが含まれます。
enum{
2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
} MaxFragmentLength;
whose value is the desired maximum fragment length. The allowed values for this field are: 2^9, 2^10, 2^11, and 2^12.
その値は、望ましい最大フラグメント長です。このフィールドの許容値は、2^9、2^10、2^11、および2^12です。
Servers that receive an extended client hello containing a "max_fragment_length" extension MAY accept the requested maximum fragment length by including an extension of type "max_fragment_length" in the (extended) server hello. The "extension_data" field of this extension SHALL contain a "MaxFragmentLength" whose value is the same as the requested maximum fragment length.
「max_fragment_length」拡張機能を含む拡張クライアントのhelloを受信するサーバーは、（拡張）サーバーのhelloに「max_fragment_length」の拡張を含めることにより、要求された最大フラグメント長を受け入れることができます。この拡張機能の「extension_Data」フィールドには、要求された最大フラグメント長と同じ「maxfragmentlength」が含まれます。
If a server receives a maximum fragment length negotiation request for a value other than the allowed values, it MUST abort the handshake with an "illegal_parameter" alert. Similarly, if a client receives a maximum fragment length negotiation response that differs from the length it requested, it MUST also abort the handshake with an "illegal_parameter" alert.
サーバーが許可された値以外の値の最大フラグメント長交渉リクエストを受信した場合、「Illegal_Parameter」アラートで握手を中止する必要があります。同様に、クライアントが要求した長さとは異なる最大フラグメント長のネゴシエーション応答を受信した場合、「Illegal_Parameter」アラートで握手を中止する必要があります。
Once a maximum fragment length other than 2^14 has been successfully negotiated, the client and server MUST immediately begin fragmenting messages (including handshake messages), to ensure that no fragment larger than the negotiated length is sent. Note that TLS already requires clients and servers to support fragmentation of handshake messages.
2^14以外の最大フラグメント長が正常にネゴシエートされると、クライアントとサーバーはすぐに断片化メッセージ（ハンドシェイクメッセージを含む）を開始する必要があります。TLSはすでにクライアントとサーバーにハンドシェイクメッセージの断片化をサポートする必要があることに注意してください。
The negotiated length applies for the duration of the session including session resumptions.
ネゴシエートされた長さは、セッションの繰り返しを含むセッションの期間中に適用されます。
The negotiated length limits the input that the record layer may process without fragmentation (that is, the maximum value of TLSPlaintext.length; see [TLS], Section 6.2.1). Note that the output of the record layer may be larger. For example, if the negotiated length is 2^9=512, then for currently defined cipher suites (those defined in [TLS], [KERB], and [AESSUITES]), and when null compression is used, the record layer output can be at most 793 bytes: 5 bytes of headers, 512 bytes of application data, 256 bytes of padding, and 20 bytes of MAC. This means that in this event a TLS record layer peer receiving a TLS record layer message larger than 793 bytes may discard the message and send a "record_overflow" alert, without decrypting the message.
交渉された長さは、断片化なしでレコードレイヤーが処理できる入力を制限します（つまり、tlsplaintext.lengthの最大値; [TLS]、セクション6.2.1を参照）。レコード層の出力が大きい場合があることに注意してください。たとえば、交渉された長さが2^9 = 512の場合、現在定義されている暗号スイート（[TLS]、[縁石]、および[aessuites]で定義されているもの）の場合、およびnull圧縮を使用すると、記録層出力はできます。最大793バイト：5バイトのヘッダー、512バイトのアプリケーションデータ、256バイトのパディング、および20バイトのMac。これは、このイベントで、793バイトを超えるTLSレコードレイヤーメッセージを受信するTLSレコードレイヤーピアがメッセージを破棄し、メッセージを解読せずに「Record_Overflow」アラートを送信する可能性があることを意味します。
Without this extension, TLS specifies that when client authentication is performed, client certificates are sent by clients to servers during the TLS handshake. It may be desirable for constrained clients to send certificate URLs in place of certificates, so that they do not need to store their certificates and can therefore save memory.
この拡張機能がないと、TLSは、クライアント認証が実行されると、クライアント証明書がTLSハンドシェイク中にクライアントによってサーバーに送信されることを指定します。制約されたクライアントが証明書の代わりに証明書URLを送信することが望ましい場合があります。そうすることで、証明書を保存する必要がないため、メモリを保存できます。
In order to negotiate sending certificate URLs to a server, clients MAY include an extension of type "client_certificate_url" in the (extended) client hello. The "extension_data" field of this extension SHALL be empty.
証明書のURLの送信をサーバーに交渉するために、クライアントには（拡張）クライアントのhelloに「client_certificate_url」の拡張機能を含めることができます。この拡張機能の「extension_Data」フィールドは空にする必要があります。
(Note that it is necessary to negotiate use of client certificate URLs in order to avoid "breaking" existing TLS servers.)
（既存のTLSサーバーを「壊す」ことを避けるために、クライアント証明書URLの使用を交渉する必要があることに注意してください。）
Servers that receive an extended client hello containing a "client_certificate_url" extension MAY indicate that they are willing to accept certificate URLs by including an extension of type "client_certificate_url" in the (extended) server hello. The "extension_data" field of this extension SHALL be empty.
「client_certificate_url」拡張機能を含む拡張クライアントのhelloを受信するサーバーは、（拡張）サーバーのhelloに「client_certificate_url」の拡張機能を含めることにより、証明書URLを受け入れることをいとわないことを示している場合があります。この拡張機能の「extension_Data」フィールドは空にする必要があります。
After negotiation of the use of client certificate URLs has been successfully completed (by exchanging hellos including "client_certificate_url" extensions), clients MAY send a "CertificateURL" message in place of a "Certificate" message:
クライアント証明書の使用の交渉後（「client_certificate_url」拡張機能を含むhellosを交換することにより）正常に完了した後、クライアントは「証明書」メッセージの代わりに「certilementurl」メッセージを送信することができます。
enum {
individual_certs(0), pkipath(1), (255)
} CertChainType;
enum {
false(0), true(1)
} Boolean;
struct {
CertChainType type;
URLAndOptionalHash url_and_hash_list<1..2^16-1>;
} CertificateURL;
struct {
opaque url<1..2^16-1>;
Boolean hash_present;
select (hash_present) {
case false: struct {};
case true: SHA1Hash;
} hash;
} URLAndOptionalHash;
opaque SHA1Hash[20];
不透明なsha1hash [20];
Here "url_and_hash_list" contains a sequence of URLs and optional hashes.
ここでは、「url_and_hash_list」には、一連のURLとオプションのハッシュが含まれています。
When X.509 certificates are used, there are two possibilities:
X.509証明書を使用する場合、2つの可能性があります。
- If CertificateURL.type is "individual_certs", each URL refers to a single DER-encoded X.509v3 certificate, with the URL for the client's certificate first.
- Certificateurl.Typeが「個人_CERTS」の場合、各URLは単一のderエンコードされたx.509v3証明書を指し、クライアントの証明書のURLを最初に指します。
- If CertificateURL.type is "pkipath", the list contains a single URL referring to a DER-encoded certificate chain, using the type PkiPath described in Section 8.
- Certificateurl.Typeが「PKIPATH」の場合、リストにはセクション8で説明されているタイプPKIPATHを使用して、DERエンコードされた証明書チェーンを指す単一のURLが含まれています。
When any other certificate format is used, the specification that describes use of that format in TLS should define the encoding format of certificates or certificate chains, and any constraint on their ordering.
他の証明書形式が使用される場合、TLSでその形式の使用を説明する仕様は、証明書または証明書チェーンのエンコード形式、および注文に対する制約を定義する必要があります。
The hash corresponding to each URL at the client's discretion either is not present or is the SHA-1 hash of the certificate or certificate chain (in the case of X.509 certificates, the DER-encoded certificate or the DER-encoded PkiPath).
クライアントの裁量で各URLに対応するハッシュは、存在しないか、証明書または証明書チェーンのSHA-1ハッシュです（X.509証明書、DERエンコードされた証明書またはDERエンコードされたPKIPATHの場合）。
Note that when a list of URLs for X.509 certificates is used, the ordering of URLs is the same as that used in the TLS Certificate message (see [TLS], Section 7.4.2), but opposite to the order in which certificates are encoded in PkiPath. In either case, the self-signed root certificate MAY be omitted from the chain, under the assumption that the server must already possess it in order to validate it.
X.509証明書のURLのリストが使用される場合、URLの順序はTLS証明書メッセージ（[TLS]、セクション7.4.2を参照）で使用されているものと同じであるが、証明書の順序とは反対のものであることに注意してください。pkipathでエンコードされています。どちらの場合でも、サーバーが検証するためにサーバーが既に所有している必要があるという仮定の下で、チェーンから自己署名のルート証明書を省略することができます。
Servers receiving "CertificateURL" SHALL attempt to retrieve the client's certificate chain from the URLs and then process the certificate chain as usual. A cached copy of the content of any URL in the chain MAY be used, provided that a SHA-1 hash is present for that URL and it matches the hash of the cached copy.
「証明書」を受信するサーバーは、URLからクライアントの証明書チェーンを取得し、通常どおり証明書チェーンを処理しようとするものとします。チェーン内の任意のURLのコンテンツのキャッシュされたコピーを使用することができます。ただし、そのURLにSHA-1ハッシュが存在し、キャッシュコピーのハッシュと一致します。
Servers that support this extension MUST support the http: URL scheme for certificate URLs, and MAY support other schemes. Use of other schemes than "http", "https", or "ftp" may create unexpected problems.
この拡張機能をサポートするサーバーは、証明書URLのHTTP：URLスキームをサポートし、他のスキームをサポートする必要があります。「HTTP」、「HTTPS」、または「FTP」以外のスキームの使用は、予期しない問題を引き起こす可能性があります。
If the protocol used is HTTP, then the HTTP server can be configured to use the Cache-Control and Expires directives described in [HTTP] to specify whether and for how long certificates or certificate chains should be cached.
使用されるプロトコルがHTTPである場合、HTTPサーバーはCache-Controlを使用するように構成でき、[http]で説明されているディレクティブの有効期限が切れて、証明書または証明書チェーンをキャッシュするかどうか、およびどのくらいの期間にわたって指定します。
The TLS server is not required to follow HTTP redirects when retrieving the certificates or certificate chain. The URLs used in this extension SHOULD therefore be chosen not to depend on such redirects.
TLSサーバーは、証明書または証明書チェーンを取得する際にHTTPリダイレクトに従う必要はありません。したがって、この拡張機能で使用されるURLは、そのようなリダイレクトに依存しないように選択する必要があります。
If the protocol used to retrieve certificates or certificate chains returns a MIME-formatted response (as HTTP does), then the following MIME Content-Types SHALL be used: when a single X.509v3 certificate is returned, the Content-Type is "application/pkix-cert" [PKIOP], and when a chain of X.509v3 certificates is returned, the Content-Type is "application/pkix-pkipath" (see Section 8).
証明書または証明書チェーンを取得するために使用されるプロトコルがMIME形式の応答を返す場合（HTTPがそうであるように）、次のMIMEコンテンツタイプを使用するものとします。単一のX.509V3証明書を返した場合、コンテンツタイプは「アプリケーション」です。/pkix-cert "[pkiop]、およびx.509v3証明書のチェーンが返されると、コンテンツタイプは「アプリケーション/pkix-pkipath」です（セクション8を参照）。
If a SHA-1 hash is present for an URL, then the server MUST check that the SHA-1 hash of the contents of the object retrieved from that URL (after decoding any MIME Content-Transfer-Encoding) matches the given hash. If any retrieved object does not have the correct SHA-1 hash, the server MUST abort the handshake with a "bad_certificate_hash_value" alert.
SHA-1ハッシュがURLに存在する場合、サーバーは、そのURLから取得されたオブジェクトの内容のSHA-1ハッシュ（MIMEコンテンツ移動エンコードをデコードした後）が与えられたハッシュと一致することを確認する必要があります。取得したオブジェクトに正しいSHA-1ハッシュがない場合、サーバーは「bad_certificate_hash_value」アラートで握手を中止する必要があります。
Note that clients may choose to send either "Certificate" or "CertificateURL" after successfully negotiating the option to send certificate URLs. The option to send a certificate is included to provide flexibility to clients possessing multiple certificates.
クライアントは、証明書URLを送信するオプションを正常に交渉した後、「証明書」または「証明書」のいずれかを送信することを選択できることに注意してください。複数の証明書を所有するクライアントに柔軟性を提供するために、証明書を送信するオプションが含まれています。
If a server encounters an unreasonable delay in obtaining certificates in a given CertificateURL, it SHOULD time out and signal a "certificate_unobtainable" error alert.
サーバーが特定の証明書で証明書の取得に不合理な遅延に遭遇した場合、タイムアウトして「certificate_unobtainable」エラーアラートを信号する必要があります。
Constrained clients that, due to memory limitations, possess only a small number of CA root keys may wish to indicate to servers which root keys they possess, in order to avoid repeated handshake failures.
メモリの制限のために、繰り返しの握手の故障を避けるために、彼らが持っているルートキーをサーバーに示すことを望むかもしれない少数のCAルートキーのみを持っていることを制約したクライアント。
In order to indicate which CA root keys they possess, clients MAY include an extension of type "trusted_ca_keys" in the (extended) client hello. The "extension_data" field of this extension SHALL contain "TrustedAuthorities" where:
どのCAルートキーが所有しているかを示すために、クライアントには（拡張）クライアントのhelloにタイプ「trusted_ca_keys」の拡張が含まれる場合があります。この拡張機能の「extension_Data」フィールドには、「TrustedAuthorities」が含まれます。
struct {
TrustedAuthority trusted_authorities_list<0..2^16-1>;
} TrustedAuthorities;
struct {
IdentifierType identifier_type;
select (identifier_type) {
case pre_agreed: struct {};
case key_sha1_hash: SHA1Hash;
case x509_name: DistinguishedName;
case cert_sha1_hash: SHA1Hash;
} identifier;
} TrustedAuthority;
enum {
pre_agreed(0), key_sha1_hash(1), x509_name(2),
cert_sha1_hash(3), (255)
} IdentifierType;
opaque DistinguishedName<1..2^16-1>;
Here "TrustedAuthorities" provides a list of CA root key identifiers that the client possesses. Each CA root key is identified via either:
ここでは、「TrusteDauthorities」に、クライアントが所有するCAルートキー識別子のリストを提供します。各CAルートキーは、次のいずれかで識別されます。
- "pre_agreed": no CA root key identity supplied.
- 「Pre_Agreed」：CAルートキーのアイデンティティは提供されていません。
- "key_sha1_hash": contains the SHA-1 hash of the CA root key. For Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) keys, this is the hash of the "subjectPublicKey" value. For RSA keys, the hash is of the big-endian byte string representation of the modulus without any initial 0-valued bytes. (This copies the key hash formats deployed in other environments.)
- 「key_sha1_hash」：CaルートキーのSHA-1ハッシュが含まれています。Digital Signature Algorithm（DSA）およびElliptic Curve Digital Signature Algorithm（ECDSA）キーの場合、これは「件名」値のハッシュです。RSAキーの場合、ハッシュは、初期の0値バイトなしでモジュラスのビッグエンディアンバイト文字列表現のものです。（これは、他の環境に展開されているキーハッシュフォーマットをコピーします。）
- "x509_name": contains the DER-encoded X.509 DistinguishedName of the CA.
- "x509_name"：ca.
- "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded Certificate containing the CA root key.
- 「CERT_SHA1_HASH」：CAルートキーを含むDERエンコードされた証明書のSHA-1ハッシュが含まれています。
Note that clients may include none, some, or all of the CA root keys they possess in this extension.
クライアントには、この拡張機能に所有しているCAルートキーの一部、一部、またはすべてが含まれる場合があることに注意してください。
Note also that it is possible that a key hash or a Distinguished Name alone may not uniquely identify a certificate issuer (for example, if a particular CA has multiple key pairs). However, here we assume this is the case following the use of Distinguished Names to identify certificate issuers in TLS.
また、重要なハッシュまたは著名な名前のみが証明書発行者を一意に識別できない可能性があることに注意してください（たとえば、特定のCAに複数のキーペアがある場合）。ただし、ここでは、TLSの証明書発行者を識別するために著名な名前を使用した後の場合であると仮定します。
The option to include no CA root keys is included to allow the client to indicate possession of some pre-defined set of CA root keys.
CAルートキーを含めるオプションは、クライアントがCAルートキーのいくつかの定義されたセットの所有を示すことができるようにします。
Servers that receive a client hello containing the "trusted_ca_keys" extension MAY use the information contained in the extension to guide their selection of an appropriate certificate chain to return to the client. In this event, the server SHALL include an extension of type "trusted_ca_keys" in the (extended) server hello. The "extension_data" field of this extension SHALL be empty.
「Trusted_ca_keys」拡張機能を含むクライアントのhelloを受信するサーバーは、拡張機能に含まれる情報を使用して、クライアントに戻るための適切な証明書チェーンの選択をガイドすることができます。この場合、サーバーには（拡張）サーバーHelloに「Trusted_ca_keys」のタイプの拡張機能を含めるものとします。この拡張機能の「extension_Data」フィールドは空にする必要があります。
Currently defined TLS cipher suites use the MAC construction HMAC with either MD5 or SHA-1 [HMAC] to authenticate record layer communications. In TLS, the entire output of the hash function is used as the MAC tag. However, it may be desirable in constrained environments to save bandwidth by truncating the output of the hash function to 80 bits when forming MAC tags.
現在定義されているTLS暗号スイートは、MD5またはSHA-1 [HMAC]を備えたMac構造HMACを使用して、レコードレイヤー通信を認証します。TLSでは、ハッシュ関数の出力全体がMacタグとして使用されます。ただし、MACタグを形成するときにハッシュ関数の出力を80ビットに切り捨てることにより、帯域幅を節約することは、制約された環境で望ましい場合があります。
In order to negotiate the use of 80-bit truncated HMAC, clients MAY include an extension of type "truncated_hmac" in the extended client hello. The "extension_data" field of this extension SHALL be empty.
80ビットの切り捨てられたHMACの使用を交渉するために、クライアントには、拡張クライアントのhelloにタイプ「truncated_hmac」の拡張が含まれる場合があります。この拡張機能の「extension_Data」フィールドは空にする必要があります。
Servers that receive an extended hello containing a "truncated_hmac" extension MAY agree to use a truncated HMAC by including an extension of type "truncated_hmac", with empty "extension_data", in the extended server hello.
「Truncated_HMAC」拡張機能を含む拡張Helloを受信するサーバーは、拡張サーバーのHelloに、「Truncated_Hmac」、空の「拡張子」を使用して、タイプ「Truncated_Hmac」の拡張機能を含めることにより、切り捨てられたHMACを使用することに同意する場合があります。
Note that if new cipher suites are added that do not use HMAC, and the session negotiates one of these cipher suites, this extension will have no effect. It is strongly recommended that any new cipher suites using other MACs consider the MAC size an integral part of the cipher suite definition, taking into account both security and bandwidth considerations.
HMACを使用しない新しい暗号スイートが追加され、セッションがこれらの暗号スイートの1つを交渉する場合、この拡張機能は効果がないことに注意してください。他のMacを使用する新しい暗号スイートは、セキュリティと帯域幅の考慮事項の両方を考慮して、Macサイズを暗号スイート定義の不可欠な部分と見なすことを強くお勧めします。
If HMAC truncation has been successfully negotiated during a TLS handshake, and the negotiated cipher suite uses HMAC, both the client and the server pass this fact to the TLS record layer along with the other negotiated security parameters. Subsequently during the session, clients and servers MUST use truncated HMACs, calculated as specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and only the first 10 bytes of the HMAC output are transmitted and checked. Note that this extension does not affect the calculation of the pseudo-random function (PRF) as part of handshaking or key derivation.
TLSの握手中にHMACの切り捨てが正常に交渉され、交渉された暗号スイートがHMACを使用している場合、クライアントとサーバーの両方がこの事実をTLSレコードレイヤーに他のネゴシエートされたセキュリティパラメーターとともに渡します。その後、セッション中に、クライアントとサーバーは[HMAC]で指定されているように計算された切り捨てられたHMACを使用する必要があります。つまり、cipherspec.hash_sizeは10バイトで、HMAC出力の最初の10バイトのみが送信されてチェックされます。この拡張は、ハンドシェイクまたはキー導出の一部として、擬似ランダム関数（PRF）の計算に影響しないことに注意してください。
The negotiated HMAC truncation size applies for the duration of the session including session resumptions.
ネゴシエートされたHMAC切り捨てサイズは、セッションの繰り返しを含むセッションの期間中に適用されます。
Constrained clients may wish to use a certificate-status protocol such as OCSP [OCSP] to check the validity of server certificates, in order to avoid transmission of CRLs and therefore save bandwidth on constrained networks. This extension allows for such information to be sent in the TLS handshake, saving roundtrips and resources.
制約付きクライアントは、CRLの送信を回避し、したがって制約付きネットワークの帯域幅を節約するために、サーバー証明書の有効性を確認するために、OCSP [OCSP]などの証明書ステータスプロトコルを使用することをお勧めします。この拡張機能により、このような情報をTLSの握手で送信し、往復とリソースを節約できます。
In order to indicate their desire to receive certificate status information, clients MAY include an extension of type "status_request" in the (extended) client hello. The "extension_data" field of this extension SHALL contain "CertificateStatusRequest" where:
証明書のステータス情報を受け取るという欲求を示すために、クライアントには（拡張）クライアントのhelloにタイプ「status_request」の拡張が含まれる場合があります。この拡張機能の「拡張機能_DATA」フィールドには、「certificatestatusRequest」を含めるものとします。
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPStatusRequest;
} request;
} CertificateStatusRequest;
enum { ocsp(1), (255) } CertificateStatusType;
struct {
ResponderID responder_id_list<0..2^16-1>;
Extensions request_extensions;
} OCSPStatusRequest;
opaque ResponderID<1..2^16-1>;
opaque Extensions<0..2^16-1>;
In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence has the special meaning that the responders are implicitly known to the server, e.g., by prior arrangement. "Extensions" is a DER encoding of OCSP request extensions.
OCSPSTATUSREQUESTでは、「Responderids」は、クライアントが信頼するOCSPレスポンダーのリストを提供します。ゼロの長さの「Responder_id_list」シーケンスには、レスポンダーがサーバーに対して暗黙的に知られているという特別な意味があります。「拡張機能」は、OCSP要求拡張機能のderエンコードです。
Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero-length "request_extensions" value means that there are no extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for the "Extensions" type).
[OCSP]で定義されている「responderid」と「拡張」の両方がderエンコードされたasn.1タイプです。「拡張機能」は[pkix]からインポートされます。ゼロ長さの「request_extensions」値は、拡張機能がないことを意味します（「拡張機能」タイプには有効ではないゼロ長ASN.1シーケンスとは対照的です）。
In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is unclear about its encoding; for clarification, the nonce MUST be a DER-encoded OCTET STRING, which is encapsulated as another OCTET STRING (note that implementations based on an existing OCSP client will need to be checked for conformance to this requirement).
「ID-PKIX-OCSP-NONCE」OCSP拡張の場合、[OCSP]はそのエンコードについて不明です。明確化のために、NonCeはDer-Encoded Octet Stringでなければなりません。これは別のOctet文字列としてカプセル化されています（既存のOCSPクライアントに基づく実装は、この要件への適合を確認する必要があることに注意してください）。
Servers that receive a client hello containing the "status_request" extension MAY return a suitable certificate status response to the client along with their certificate. If OCSP is requested, they SHOULD use the information contained in the extension when selecting an OCSP responder and SHOULD include request_extensions in the OCSP request.
「Status_Request」拡張機能を含むクライアントのHelloを受信するサーバーは、証明書とともにクライアントに適切な証明書ステータス応答を返す場合があります。OCSPが要求された場合、OCSP Responderを選択するときに拡張機能に含まれる情報を使用する必要があり、OCSPリクエストにrequest_extensionsを含める必要があります。
Servers return a certificate response along with their certificate by sending a "CertificateStatus" message immediately after the "Certificate" message (and before any "ServerKeyExchange" or "CertificateRequest" messages). If a server returns a
サーバーは、「証明書」メッセージの直後（および「serverKeyExchange」または「certificateRequest」メッセージの直前）の直後に「証明書」メッセージを送信することにより、証明書とともに証明書の応答を返します。サーバーがaを返す場合
"CertificateStatus" message, then the server MUST have included an extension of type "status_request" with empty "extension_data" in the extended server hello.
「CertificateStatus」メッセージでは、サーバーには、拡張サーバーのhelloに空の「extension_data」を使用して、タイプ「status_request」の拡張機能が含まれている必要があります。
struct {
CertificateStatusType status_type;
select (status_type) {
case ocsp: OCSPResponse;
} response;
} CertificateStatus;
opaque OCSPResponse<1..2^24-1>;
An "ocsp_response" contains a complete, DER-encoded OCSP response (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that only one OCSP response may be sent.
「OCSP_RESPONSE」には、完全なDERエンコードされたOCSP応答が含まれます（[OCSP]で定義されたASN.1型OCSPRESPONSEを使用）。OCSP応答は1つだけ送信されることに注意してください。
The "CertificateStatus" message is conveyed using the handshake message type "certificate_status".
「cirtermatestatus」メッセージは、握手メッセージタイプ「certificate_status」を使用して伝えられます。
Note that a server MAY also choose not to send a "CertificateStatus" message, even if it receives a "status_request" extension in the client hello message.
サーバーは、クライアントのhelloメッセージで「status_request」拡張子を受信した場合でも、「cirtermatestatus」メッセージを送信しないことも選択できます。
Note in addition that servers MUST NOT send the "CertificateStatus" message unless it received a "status_request" extension in the client hello message.
さらに、サーバーは、クライアントのhelloメッセージで「status_request」拡張子を受け取っていない限り、「sermistatestatus」メッセージを送信してはなりません。
Clients requesting an OCSP response and receiving an OCSP response in a "CertificateStatus" message MUST check the OCSP response and abort the handshake if the response is not satisfactory.
OCSP応答を要求し、「証明書」メッセージでOCSP応答を受信するクライアントは、OCSP応答をチェックし、応答が満足のいくものでない場合はハンドシェイクを中止する必要があります。
This section defines new error alerts for use with the TLS extensions defined in this document.
このセクションでは、このドキュメントで定義されているTLS拡張機能で使用する新しいエラーアラートを定義します。
The following new error alerts are defined. To avoid "breaking" existing clients and servers, these alerts MUST NOT be sent unless the sending party has received an extended hello message from the party they are communicating with.
次の新しいエラーアラートが定義されています。既存のクライアントやサーバーを「破る」ことを避けるために、送信者が通信している当事者から拡張ハローメッセージを受け取っていない限り、これらのアラートを送信してはなりません。
- "unsupported_extension": this alert is sent by clients that receive an extended server hello containing an extension that they did not put in the corresponding client hello (see Section 2.3). This message is always fatal.
- 「unsupported_extension」：このアラートは、対応するクライアントのhelloに入れなかった拡張機能を含む拡張サーバーのhelloを受け取るクライアントによって送信されます（セクション2.3を参照）。このメッセージは常に致命的です。
- "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal.
- 「Unecognized_name」：このアラートは、server_name拡張機能要求を受信するサーバーによって送信されますが、サーバー名は認識されません。このメッセージは致命的かもしれません。
- "certificate_unobtainable": this alert is sent by servers who are unable to retrieve a certificate chain from the URL supplied by the client (see Section 3.3). This message MAY be fatal; for example, if client authentication is required by the server for the handshake to continue and the server is unable to retrieve the certificate chain, it may send a fatal alert.
- 「certificate_unobtainable」：このアラートは、クライアントが提供するURLから証明書チェーンを取得できないサーバーによって送信されます（セクション3.3を参照）。このメッセージは致命的かもしれません。たとえば、ハンドシェイクが継続するためにサーバーがクライアント認証を必要とし、サーバーが証明書チェーンを取得できない場合、致命的なアラートを送信する場合があります。
- "bad_certificate_status_response": this alert is sent by clients that receive an invalid certificate status response (see Section 3.6). This message is always fatal.
- 「bad_certificate_status_response」：このアラートは、無効な証明書ステータス応答を受け取るクライアントによって送信されます（セクション3.6を参照）。このメッセージは常に致命的です。
- "bad_certificate_hash_value": this alert is sent by servers when a certificate hash does not match a client-provided certificate_hash. This message is always fatal.
- 「bad_certificate_hash_value」：証明書のハッシュがクライアントが提供する証明書_hashと一致しない場合、このアラートはサーバーによって送信されます。このメッセージは常に致命的です。
These error alerts are conveyed using the following syntax:
これらのエラーアラートは、次の構文を使用して伝達されます。
enum {
close_notify(0),
unexpected_message(10),
bad_record_mac(20),
decryption_failed(21),
record_overflow(22),
decompression_failure(30),
handshake_failure(40),
/* 41 is not defined, for historical reasons */
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
unsupported_extension(110), /* new */
certificate_unobtainable(111), /* new */
unrecognized_name(112), /* new */
bad_certificate_status_response(113), /* new */
bad_certificate_hash_value(114), /* new */
(255)
} AlertDescription;
The list of extension types, as defined in Section 2.3, is maintained by the Internet Assigned Numbers Authority (IANA). Thus, an application needs to be made to the IANA in order to obtain a new extension type value. Since there are subtle (and not-so-subtle) interactions that may occur in this protocol between new features and existing features that may result in a significant reduction in overall security, new values SHALL be defined only through the IETF Consensus process specified in [IANA].
セクション2.3で定義されている拡張タイプのリストは、インターネットが割り当てられた番号当局（IANA）によって維持されます。したがって、新しい拡張型タイプ値を取得するには、IANAにアプリケーションを作成する必要があります。新機能と全体的なセキュリティの大幅な削減をもたらす可能性のある既存の機能との間にこのプロトコルで発生する可能性のある微妙な（そしてそれほど微妙ではない）相互作用があるため、[[[]で指定されたIETFコンセンサスプロセスによってのみ新しい値が定義されます。イアナ]。
(This means that new assignments can be made only via RFCs approved by the IESG.) The following considerations should be taken into account when designing new extensions:
（これは、IESGによって承認されたRFCを介してのみ新しい割り当てを行うことができることを意味します。）新しい拡張機能を設計する際には、以下の考慮事項を考慮する必要があります。
- All of the extensions defined in this document follow the convention that for each extension that a client requests and that the server understands, the server replies with an extension of the same type.
- このドキュメントで定義されているすべての拡張機能は、クライアントが要求する各拡張機能について、サーバーが同じタイプの拡張機能で返信することを理解している条約に従います。
- Some cases where a server does not agree to an extension are error conditions, and some simply a refusal to support a particular feature. In general, error alerts should be used for the former, and a field in the server extension response for the latter.
- サーバーが拡張機能に同意しない場合は、エラー条件であり、特定の機能をサポートすることを単に拒否する場合もあります。一般に、前者にはエラーアラートを使用し、後者のサーバー拡張応答のフィールドを使用する必要があります。
- Extensions should as far as possible be designed to prevent any attack that forces use (or non-use) of a particular feature by manipulation of handshake messages. This principle should be followed regardless of whether the feature is believed to cause a security problem.
- 拡張機能は、ハンドシェイクメッセージの操作によって特定の機能の使用（または使用不使用）を強制する攻撃を防ぐように可能な限り設計する必要があります。この原則は、機能がセキュリティの問題を引き起こすと考えられているかどうかに関係なく、従うべきです。
Often the fact that the extension fields are included in the inputs to the Finished message hashes will be sufficient, but extreme care is needed when the extension changes the meaning of messages sent in the handshake phase. Designers and implementors should be aware of the fact that until the handshake has been authenticated, active attackers can modify messages and insert, remove, or replace extensions.
多くの場合、拡張フィールドが完成したメッセージハッシュへの入力に含まれているという事実で十分ですが、拡張がハンドシェイクフェーズで送信されたメッセージの意味を変更する場合、極端な注意が必要です。設計者と実装者は、握手が認証されるまで、アクティブな攻撃者がメッセージを変更し、拡張機能を挿入、削除、または交換できるという事実に注意する必要があります。
- It would be technically possible to use extensions to change major aspects of the design of TLS; for example, the design of cipher suite negotiation. This is not recommended; it would be more appropriate to define a new version of TLS, particularly since the TLS handshake algorithms have specific protection against version rollback attacks based on the version number. The possibility of version rollback should be a significant consideration in any major design change.
- 技術的には、拡張機能を使用してTLSの設計の主要な側面を変更することができます。たとえば、暗号スイート交渉の設計。これは推奨されません。特にTLSハンドシェイクアルゴリズムは、バージョン番号に基づいてバージョンロールバック攻撃に対して特定の保護があるため、TLSの新しいバージョンを定義する方が適切です。バージョンロールバックの可能性は、主要な設計変更において重要な考慮事項である必要があります。
Security considerations for the extension mechanism in general and for the design of new extensions are described in the previous section. A security analysis of each of the extensions defined in this document is given below.
一般的な拡張メカニズムと新しい拡張機能の設計についてのセキュリティ上の考慮事項については、前のセクションで説明します。このドキュメントで定義されている各拡張機能のセキュリティ分析を以下に示します。
In general, implementers should continue to monitor the state of the art and address any weaknesses identified.
一般に、実装者は最先端を監視し続け、特定された弱点に対処する必要があります。
Additional security considerations are described in the TLS 1.0 RFC [TLS] and the TLS 1.1 RFC [TLSbis].
追加のセキュリティ上の考慮事項は、TLS 1.0 RFC [TLS]およびTLS 1.1 RFC [TLSBIS]で説明されています。
If a single server hosts several domains, then clearly it is necessary for the owners of each domain to ensure that this satisfies their security needs. Apart from this, server_name does not appear to introduce significant security issues.
単一のサーバーがいくつかのドメインをホストする場合、各ドメインの所有者がセキュリティのニーズを満たすことを確認することが明らかに必要です。これとは別に、server_nameは重要なセキュリティの問題を導入していないようです。
Implementations MUST ensure that a buffer overflow does not occur, whatever the values of the length fields in server_name.
実装は、server_nameの長さフィールドの値が何であれ、バッファオーバーフローが発生しないようにする必要があります。
Although this document specifies an encoding for internationalized hostnames in the server_name extension, it does not address any security issues associated with the use of internationalized hostnames in TLS (in particular, the consequences of "spoofed" names that are indistinguishable from another name when displayed or printed). It is recommended that server certificates not be issued for internationalized hostnames unless procedures are in place to mitigate the risk of spoofed hostnames.
このドキュメントは、server_name拡張機能の国際化ホスト名のエンコーディングを指定していますが、TLSでの国際化ホスト名の使用に関連するセキュリティの問題には対処されません（特に、表示または表示されたときに別の名前と区別できない「スプーフィングされた」名前の結果には対処されません。印刷）。スプーフィングされたホスト名のリスクを軽減する手順が整っていない限り、国際化されたホスト名でサーバー証明書を発行しないことをお勧めします。
The maximum fragment length takes effect immediately, including for handshake messages. However, that does not introduce any security complications that are not already present in TLS, since TLS requires implementations to be able to handle fragmented handshake messages.
最大フラグメントの長さは、ハンドシェイクメッセージを含め、すぐに有効になります。ただし、TLSには断片化されたハンドシェイクメッセージを処理できるために実装が必要なため、TLSにはまだ存在していないセキュリティの合併症は導入されません。
Note that as described in Section 3.2, once a non-null cipher suite has been activated, the effective maximum fragment length depends on the cipher suite and compression method, as well as on the negotiated max_fragment_length. This must be taken into account when sizing buffers, and checking for buffer overflow.
セクション3.2で説明されているように、非ヌル暗号スイートがアクティブ化されると、有効な最大フラグメント長は暗号スイートと圧縮法、およびネゴシエートされたMAX_FRAGMENT_LENGTHに依存することに注意してください。これは、バッファをサイジングし、バッファオーバーフローをチェックするときに考慮する必要があります。
There are two major issues with this extension.
この拡張機能には2つの大きな問題があります。
The first major issue is whether or not clients should include certificate hashes when they send certificate URLs.
最初の主要な問題は、クライアントが証明書URLを送信するときに証明書のハッシュを含める必要があるかどうかです。
When client authentication is used *without* the client_certificate_url extension, the client certificate chain is covered by the Finished message hashes. The purpose of including hashes and checking them against the retrieved certificate chain is to ensure that the same property holds when this extension is used, i.e., that all of the information in the certificate chain retrieved by the server is as the client intended.
クライアント認証が使用されている * client_certificate_url拡張機能 *なしで *クライアント証明書チェーンは、完成したメッセージのハッシュでカバーされます。ハッシュを含めて検索された証明書チェーンに対してそれらをチェックする目的は、この拡張機能が使用されているときに同じプロパティが保持されることを確認することです。つまり、サーバーによって取得された証明書チェーン内のすべての情報がクライアントの意図に従ってであることを確認することです。
On the other hand, omitting certificate hashes enables functionality that is desirable in some circumstances; for example, clients can be issued daily certificates that are stored at a fixed URL and need not be provided to the client. Clients that choose to omit certificate hashes should be aware of the possibility of an attack in which the attacker obtains a valid certificate on the client's key that is different from the certificate the client intended to provide. Although TLS uses both MD5 and SHA-1 hashes in several other places, this was not believed to be necessary here. The property required of SHA-1 is second pre-image resistance.
一方、証明書のハッシュを省略すると、状況によっては望ましい機能が可能になります。たとえば、クライアントは、固定URLに保存され、クライアントに提供される必要はない毎日の証明書を発行できます。証明書のハッシュを省略することを選択するクライアントは、攻撃者がクライアントが提供する証明書とは異なる有効な証明書をクライアントのキーに取得する攻撃の可能性を認識する必要があります。TLSは他のいくつかの場所でMD5ハッシュとSHA-1の両方のハッシュを使用していますが、これはここでは必要ではないと考えられていました。SHA-1に必要な特性は、2番目の前イメージ抵抗です。
The second major issue is that support for client_certificate_url involves the server's acting as a client in another URL protocol. The server therefore becomes subject to many of the same security concerns that clients of the URL scheme are subject to, with the added concern that the client can attempt to prompt the server to connect to some (possibly weird-looking) URL.
2番目の主要な問題は、client_certificate_urlのサポートには、別のURLプロトコルでサーバーがクライアントとして機能することです。したがって、サーバーは、URLスキームのクライアントが対象となるのと同じセキュリティ上の懸念の多くの対象となり、クライアントがサーバーに一部の（おそらく奇妙に見える）URLに接続するように促すことを試みることができるという追加の懸念があります。
In general, this issue means that an attacker might use the server to indirectly attack another host that is vulnerable to some security flaw. It also introduces the possibility of denial of service attacks in which an attacker makes many connections to the server, each of which results in the server's attempting a connection to the target of the attack.
一般に、この問題は、攻撃者がサーバーを使用して、セキュリティの欠陥に対して脆弱な別のホストを間接的に攻撃する可能性があることを意味します。また、攻撃者がサーバーに多くの接続を行うサービス攻撃の拒否の可能性を紹介します。それぞれがサーバーが攻撃のターゲットに接続することを試みます。
Note that the server may be behind a firewall or otherwise able to access hosts that would not be directly accessible from the public Internet. This could exacerbate the potential security and denial of service problems described above, as well as allow the existence of internal hosts to be confirmed when they would otherwise be hidden.
サーバーはファイアウォールの背後にあるか、パブリックインターネットから直接アクセスできないホストにアクセスできる場合があることに注意してください。これにより、上記の潜在的なセキュリティとサービス拒否の問題が悪化し、内部ホストの存在が隠されている場合に確認される可能性があります。
The detailed security concerns involved will depend on the URL schemes supported by the server. In the case of HTTP, the concerns are similar to those that apply to a publicly accessible HTTP proxy server. In the case of HTTPS, loops and deadlocks may be created, and this should be addressed. In the case of FTP, attacks arise that are similar to FTP bounce attacks.
関係する詳細なセキュリティの懸念は、サーバーがサポートするURLスキームに依存します。HTTPの場合、懸念は、公開されているHTTPプロキシサーバーに適用されるものと類似しています。HTTPSの場合、ループとデッドロックが作成される場合があり、これに対処する必要があります。FTPの場合、FTPバウンス攻撃に似た攻撃が発生します。
As a result of this issue, it is RECOMMENDED that the client_certificate_url extension should have to be specifically enabled by a server administrator, rather than be enabled by default. It is also RECOMMENDED that URI protocols be enabled by the administrator individually, and only a minimal set of protocols be enabled. Unusual protocols that offer limited security or whose security is not well-understood SHOULD be avoided.
この問題の結果として、client_certificate_url拡張機能は、デフォルトで有効にするのではなく、サーバー管理者によって具体的に有効にされる必要があることをお勧めします。また、URIプロトコルを管理者によって個別に有効にすることをお勧めし、プロトコルの最小セットのみを有効にすることをお勧めします。限られたセキュリティを提供する、またはそのセキュリティが十分に理解されていない異常なプロトコルは避けるべきです。
As discussed in [URI], URLs that specify ports other than the default may cause problems, as may very long URLs (which are more likely to be useful in exploiting buffer overflow bugs).
[URI]で説明したように、デフォルト以外のポートを指定するURLは、非常に長いURL（バッファオーバーフローバグの悪用に役立つ可能性が高い）と同様に問題を引き起こす可能性があります。
Also note that HTTP caching proxies are common on the Internet, and some proxies do not check for the latest version of an object correctly. If a request using HTTP (or another caching protocol) goes through a misconfigured or otherwise broken proxy, the proxy may return an out-of-date response.
また、HTTPキャッシュプロキシはインターネット上で一般的であり、一部のプロキシはオブジェクトの最新バージョンを正しくチェックしていないことに注意してください。HTTP（または別のキャッシュプロトコル）を使用したリクエストが誤解された、または壊れたプロキシを通過する場合、プロキシは時代遅れの応答を返す場合があります。
It is possible that which CA root keys a client possesses could be regarded as confidential information. As a result, the CA root key indication extension should be used with care.
クライアントが所有するCAルートキーが機密情報と見なされる可能性があります。その結果、CAルートキー表示拡張は注意して使用する必要があります。
The use of the SHA-1 certificate hash alternative ensures that each certificate is specified unambiguously. As for the previous extension, it was not believed necessary to use both MD5 and SHA-1 hashes.
SHA-1証明書ハッシュの代替の使用により、各証明書が明確に指定されていることが保証されます。以前の拡張に関しては、MD5とSHA-1の両方のハッシュを使用する必要はないとは考えられていませんでした。
It is possible that truncated MACs are weaker than "un-truncated" MACs. However, no significant weaknesses are currently known or expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
切り捨てられたMacは、「不自然な」Macよりも弱い可能性があります。ただし、MD5またはSHA-1を使用してHMACには現在、80ビットに切り捨てられたHMACには、存在すると予想される有意な弱点は現在知られていません。
Note that the output length of a MAC need not be as long as the length of a symmetric cipher key, since forging of MAC values cannot be done off-line: in TLS, a single failed MAC guess will cause the immediate termination of the TLS session.
Mac値の鍛造をオフラインで実行できないため、Macの出力の長さは対称的な暗号キーの長さと同じ長さである必要はないことに注意してください。TLSでは、単一のMACの推測がTLSの即時終了を引き起こすことに注意してください。セッション。
Since the MAC algorithm only takes effect after all handshake messages that affect extension parameters have been authenticated by the hashes in the Finished messages, it is not possible for an active attacker to force negotiation of the truncated HMAC extension where it would not otherwise be used (to the extent that the handshake authentication is secure). Therefore, in the event that any security problem were found with truncated HMAC in the future, if either the client or the server for a given session were updated to take the problem into account, it would be able to veto use of this extension.
MACアルゴリズムは、拡張パラメーターに影響を与えるすべての握手メッセージが完成したメッセージのハッシュによって認証された後にのみ有効になるため、アクティブな攻撃者が使用されない切り捨てられたHMAC拡張の交渉を強制することはできません（それ以外の場合は使用できません（ハンドシェイク認証が安全である限り）。したがって、将来的に切り捨てられたHMACでセキュリティの問題が見つかった場合、特定のセッションのクライアントまたはサーバーのいずれかを更新して問題を考慮した場合、この拡張機能の使用を拒否できるようになります。
If a client requests an OCSP response, it must take into account that an attacker's server using a compromised key could (and probably would) pretend not to support the extension. In this case, a client that requires OCSP validation of certificates SHOULD either contact the OCSP server directly or abort the handshake.
クライアントがOCSP応答を要求する場合、侵害されたキーを使用して攻撃者のサーバーが拡張機能をサポートしない可能性がある（そしておそらくそうする）ことを考慮する必要があります。この場合、証明書のOCSP検証を必要とするクライアントは、OCSPサーバーに直接連絡するか、ハンドシェイクを中止する必要があります。
Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may improve security against attacks that attempt to replay OCSP responses; see Section 4.4.1 of [OCSP] for further details.
OCSP NonCe Request Extension（ID-PKIX-OCSP-Nonce）の使用は、OCSP応答を再生しようとする攻撃に対するセキュリティを改善する場合があります。詳細については、[OCSP]のセクション4.4.1を参照してください。
None of the extensions defined here directly use strings subject to localization. Domain Name System (DNS) hostnames are encoded using UTF-8. If future extensions use text strings, then internationalization should be considered in their design.
ここで定義されている拡張機能はいずれも、ローカリゼーションの対象となる文字列を直接使用していません。ドメイン名システム（DNS）ホスト名は、UTF-8を使用してエンコードされます。将来の拡張機能がテキスト文字列を使用している場合、国際化を設計で考慮する必要があります。
Sections 2.3 and 5 describe a registry of ExtensionType values to be maintained by the IANA. ExtensionType values are to be assigned via IETF Consensus as defined in RFC 2434 [IANA]. The initial registry corresponds to the definition of "ExtensionType" in Section 2.3.
セクション2.3および5は、IANAによって維持される拡張タイプ値のレジストリについて説明します。extensionType値は、RFC 2434 [IANA]で定義されているIETFコンセンサスを介して割り当てられます。初期レジストリは、セクション2.3の「拡張タイプ」の定義に対応しています。
The MIME type "application/pkix-pkipath" has been registered by the IANA with the following template:
MIMEタイプ「アプリケーション/PKIX-PKIPATH」は、次のテンプレートでIANAによって登録されています。
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pkix-pkipath
MIME media type name: application MIME subtype name: pkix-pkipath Required parameters: none
MIMEメディアタイプ名：アプリケーションMIMEサブタイプ名：pkix-pkipath必要パラメーター：なし
Optional parameters: version (default value is "1")
オプションのパラメーター：バージョン（デフォルト値は「1」です）
Encoding considerations:
This MIME type is a DER encoding of the ASN.1 type PkiPath,
defined as follows:
PkiPath ::= SEQUENCE OF Certificate
PkiPath is used to represent a certification path. Within the
sequence, the order of certificates is such that the subject of
the first certificate is the issuer of the second certificate,
etc.
This is identical to the definition published in [X509-4th-TC1]; note that it is different from that in [X509-4th].
これは、[x509-4th-tc1]で公開されている定義と同じです。[x509-4th]のものとは異なることに注意してください。
All Certificates MUST conform to [PKIX]. (This should be interpreted as a requirement to encode only PKIX-conformant certificates using this type. It does not necessarily require that all certificates that are not strictly PKIX-conformant must be rejected by relying parties, although the security consequences of accepting any such certificates should be considered carefully.)
すべての証明書は[pkix]に準拠する必要があります。（これは、このタイプを使用してPKIXコンフォーント証明書のみをエンコードする要件として解釈する必要があります。厳密にPKIXコンフォーントではないすべての証明書を当事者に依存することによって拒否される必要があるとは限りませんが、そのような証明書を受け入れることのセキュリティ結果は慎重に検討する必要があります。）
DER (as opposed to BER) encoding MUST be used. If this type is sent over a 7-bit transport, base64 encoding SHOULD be used.
der（BERではなく）エンコードを使用する必要があります。このタイプが7ビット輸送で送信される場合、Base64エンコードを使用する必要があります。
Security considerations: The security considerations of [X509-4th] and [PKIX] (or any updates to them) apply, as well as those of any protocol that uses this type (e.g., TLS).
セキュリティ上の考慮事項：[x509-4th]および[pkix]（またはそれらに更新）のセキュリティ上の考慮事項、およびこのタイプを使用するプロトコル（TLSなど）のセキュリティに関する考慮事項。
Note that this type only specifies a certificate chain that can be assessed for validity according to the relying party's existing configuration of trusted CAs; it is not intended to be used to specify any change to that configuration.
このタイプは、依存している当事者の既存の信頼できるCAの構成に従って有効性を評価できる証明書チェーンのみを指定することに注意してください。その構成の変更を指定するために使用することは意図されていません。
Interoperability considerations: No specific interoperability problems are known with this type, but for recommendations relating to X.509 certificates in general, see [PKIX].
相互運用性の考慮事項：このタイプでは特定の相互運用性の問題は知られていませんが、一般的にX.509証明書に関連する推奨事項については、[PKIX]を参照してください。
Published specification: RFC 4366 (this memo), and [PKIX].
公開された仕様：RFC 4366（このメモ）、および[PKIX]。
Applications which use this media type: TLS. It may also be used by other protocols, or for general interchange of PKIX certificate chains.
このメディアタイプを使用するアプリケーション：TLS。また、他のプロトコルでも、PKIX証明書チェーンの一般的な交換にも使用できます。
Additional information: Magic number(s): DER-encoded ASN.1 can be easily recognized. Further parsing is required to distinguish it from other ASN.1 types. File extension(s): .pkipath Macintosh File Type Code(s): not specified
追加情報：マジック番号：der-Encoded asn.1は簡単に認識できます。他のasn.1タイプと区別するには、さらなる解析が必要です。ファイル拡張子：.pkipath macintoshファイルタイプコード：指定されていない
Person & email address to contact for further information:
Magnus Nystrom <magnus@rsasecurity.com>
Intended usage: COMMON
Change controller:
IESG <iesg@ietf.org>
The authors wish to thank the TLS Working Group and the WAP Security Group. This document is based on discussion within these groups.
著者は、TLSワーキンググループとWAPセキュリティグループに感謝したいと考えています。このドキュメントは、これらのグループ内での議論に基づいています。
[HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[HTTP] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP/1.1」、RFC 2616、1999年6月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA] Faltstrom、P.、Hoffman、P.、およびA. Costello、「アプリケーションの国際化ドメイン名（IDNA）」、RFC 3490、2003年3月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラオンライン証明書ステータスプロトコル」、RFC 2560、1999年6月。
[PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999.
[PKIOP] Housley、R。and P. Hoffman、「インターネットX.509公開キーインフラストラクチャ運用プロトコル：FTPおよびHTTP」、RFC 2585、1999年5月。
[PKIX] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[Pkix] Housley、R.、Polk、W.、Ford、W.、およびD. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[TLS] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[TLSbis] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[TLSBIS] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.1」、RFC 4346、2006年4月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[UTF8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、2003年11月。
[X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, "Information Systems - Open Systems Interconnection - The Directory: Public key and attribute certificate frameworks."
[X509-4th] ITU-T推奨X.509（2000）|ISO/IEC 9594-8：2001、「情報システム - オープンシステムの相互接続 - ディレクトリ：公開鍵と属性証明書フレームワーク」。
[X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1 to ISO/IEC 9594:8:2001.
[X509-4th-TC1] ITU-T推奨X.509（2000）Corrigendum 1（2001）|ISO/IEC 9594-8：2001/Cor.1：2002、Technical Corrigendum 1からISO/IEC 9594：8：2001。
[AESSUITES] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002.
[Aessuites] Chown、P。、「輸送層セキュリティ（TLS）のための高度な暗号化標準（AES）Ciphersuites」、RFC 3268、2002年6月。
[KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, October 1999.
[縁石] Medvinsky、A。およびM. Hur、「層のセキュリティ（TLS）へのKerberos cipherスイートの追加」、RFC 2712、1999年10月。
[MAILINGLIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General ClientHello extension mechanism and virtual hosting," ietf-tls mailing list posting, August 14, 2000.
[Mailinglist] J. Mikkelsen、R。Eberhard、およびJ. Kistler、「一般的なクライアントヘロ拡張メカニズムと仮想ホスティング」、IETF-TLSメーリングリストの投稿、2000年8月14日。
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[RFC3546] Blake-Wilson、S.、Nystrom、M.、Hopwood、D.、Mikkelsen、J。、およびT. Wright、「Transport Layer Security（TLS）Extensions」、RFC 3546、2003年6月。
Authors' Addresses
著者のアドレス
Simon Blake-Wilson BCI
サイモン・ブレイク・ウィルソンBCI
EMail: sblakewilson@bcisse.com
Magnus Nystrom RSA Security
Magnus Nystrom RSAセキュリティ
EMail: magnus@rsasecurity.com
David Hopwood Independent Consultant
デビッドホップウッド独立コンサルタント
EMail: david.hopwood@blueyonder.co.uk
Jan Mikkelsen Transactionware
Jan Mikkelsen Transactionware
EMail: janm@transactionware.com
Tim Wright Vodafone
ティム・ライト・ボーダフォン
EMail: timothy.wright@vodafone.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。