[要約] RFC 3546は、Transport Layer Security（TLS）拡張機能に関する仕様であり、TLSプロトコルの機能を拡張するための方法を提供しています。目的は、セキュリティとプライバシーの向上、通信の効率化、および新しい機能の追加です。
Network Working Group S. Blake-Wilson
Request for Comments: 3546 BCI
Updates: 2246 M. Nystrom
Category: Standards Track RSA Security
D. Hopwood
Independent Consultant
J. Mikkelsen
Transactionware
T. Wright
Vodafone
June 2003
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 (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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 1.0 clients that support the extensions and TLS 1.0 servers that do not support the extensions, and vice versa.
拡張機能は、TLSクライアントとサーバーが使用できます。拡張機能は逆方向に互換性があります - 拡張機能をサポートするTLS 1.0クライアントと、拡張機能をサポートしていないTLS 1.0サーバー間の通信が可能です。
Conventions used in this Document
このドキュメントで使用されている規則
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 [キーワード]に記載されているとおりに解釈されます。
Table of Contents
目次
1. Introduction ............................................. 2
2. General Extension Mechanisms ............................. 4
2.1. Extended Client Hello ............................... 5
2.2. Extended Server Hello ............................... 5
2.3. Hello Extensions .................................... 6
2.4. Extensions to the handshake protocol ................ 7
3. Specific Extensions ...................................... 8
3.1. Server Name Indication .............................. 8
3.2. Maximum Fragment Length Negotiation ................. 10
3.3. Client Certificate URLs ............................. 11
3.4. Trusted CA Indication ............................... 14
3.5. Truncated HMAC ...................................... 15
3.6. Certificate Status Request........................... 16
4. Error alerts .............................................. 18
5. Procedure for Defining New Extensions...................... 20
6. Security Considerations .................................. 21
6.1. Security of server_name ............................. 21
6.2. Security of max_fragment_length ..................... 21
6.3. Security of client_certificate_url .................. 22
6.4. Security of trusted_ca_keys ......................... 23
6.5. Security of truncated_hmac .......................... 23
6.6. Security of status_request .......................... 24
7. Internationalization Considerations ...................... 24
8. IANA Considerations ...................................... 24
9. Intellectual Property Rights ............................. 26
10. Acknowledgments .......................................... 26
11. Normative References ..................................... 27
12. Informative References ................................... 28
13. Authors' Addresses ....................................... 28
14. Full Copyright Statement ................................. 29
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 like wireless networks.
TLSは現在、さまざまな運用環境で使用されています。これらの多くは、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 are designed to:
具体的には、このドキュメントで説明されている拡張機能は、次のように設計されています。
- Allow TLS clients to provide to the TLS server the name of the server they are contacting. This functionality is desirable 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 1.0 clients and TLS 1.0 servers. The extensions are designed to be backwards compatible - meaning that TLS 1.0 clients that support the extensions can talk to TLS 1.0 servers that do not support the extensions, and vice versa.
このドキュメントで説明されている拡張機能は、TLS 1.0クライアントとTLS 1.0サーバーで使用できます。拡張機能は、逆方向に互換性があるように設計されています。つまり、拡張機能をサポートするTLS 1.0クライアントは、拡張機能をサポートしていないTLS 1.0サーバーに通知できます。
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 1.0 [TLS] requires servers to accept extended client hello messages, even if the server does not "understand" the extension.
- クライアントは通常、セクション2.1で説明されている拡張クライアントのhelloメッセージを介して拡張機能の使用を要求します。TLS 1.0 [TLS]では、サーバーが拡張機能を「理解」していなくても、サーバーに拡張クライアントのハローメッセージを受け入れる必要があります。
- For the specific extensions described here, no mandatory server response is required when clients request extended functionality.
- ここで説明する特定の拡張機能の場合、クライアントが拡張機能を要求する場合、必須のサーバー応答は必要ありません。
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.
ただし、後方互換性はサポートされていますが、一部の制約されたクライアントは、そのようなクライアントの限られた機能の結果として拡張機能をサポートしていないサーバーとの通信を拒否することを余儀なくされる場合があります。
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 1.0. 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 1.0への特定の拡張機能について説明します。セクション4では、TLS拡張機能で使用するための新しいエラーアラートについて説明します。ドキュメントの最後のセクションは、IPR、セキュリティに関する考慮事項、アプリケーション/PKIX-PKIPATH MIMEタイプの登録、謝辞、および参照をアドレスします。
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 [MAILING LIST].
これらの一般的な拡張メカニズムは、クライアントとサーバーが特定の拡張機能を使用するかどうか、特定の拡張機能を使用する方法を交渉できるようにするために必要です。説明されている拡張フォーマットは[メーリングリスト]に基づいています。
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 1.0 servers.
[TLS]、セクション7.4.1.2では、追加情報をクライアントHelloメッセージに追加できることに注意してください。したがって、上記で定義された拡張クライアントのHelloの使用は、既存のTLS 1.0サーバーを「壊す」べきではありません。
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 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で指定された拡張クライアントのハローメッセージを介してクライアントが拡張機能を要求したときに、サーバーハローメッセージの代わりに送信される場合があります。拡張サーバーハローメッセージフォーマットは次のとおりです。
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 1.0 clients.
拡張サーバーのhelloメッセージは、拡張クライアントのhelloメッセージにのみ応答して送信されることに注意してください。これにより、拡張サーバーのHelloメッセージが既存のTLS 1.0クライアントを「壊す」可能性がある可能性が妨げられます。
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;
Note that for all extension types (including those defined in 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 initiated" extensions may be provided in the future within this framework by requiring the client to first send an empty extension to indicate that it supports a particular extension.
それにもかかわらず、「サーバーが開始された」拡張機能は、クライアントが最初に空の拡張子を送信して特定の拡張子をサポートすることを示すことにより、このフレームワーク内で将来提供される場合があります。
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 all the extensions defined in this document are relevant only when a session is initiated. However, 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. If the resumption request is denied, then a new set of extensions will be negotiated as normal. If, on the other hand, the older session is resumed, then the server MUST ignore extensions appearing in the client hello, and send a server hello containing no extensions; in this case the extension functionality negotiated during the original session initiation is applied to the resumed session.
最後に、このドキュメントで定義されているすべての拡張機能は、セッションが開始された場合にのみ関連することに注意してください。ただし、セッションの再開を要求するクライアントは、一般的にサーバーがこのリクエストを受け入れるかどうかを知りません。したがって、通常、新しいセッションのためにそうする場合は、拡張クライアントの挨拶を送信する必要があります。再開リクエストが拒否された場合、新しい拡張機能のセットは通常のように交渉されます。一方、古いセッションが再開された場合、サーバーはクライアント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ハンドシェイク中に送信されるこれらの拡張機能に関連付けられたメッセージは、「完成」メッセージに含まれるハッシュ計算に含める必要があることに注意してください。
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 to provide maximum fragment length negotiation. Section 3.3 describes the extension to allow client certificate URLs. Section 3.4 describes the extension to allow a client to indicate which CA root keys it possesses. Section 3.5 describes the extension to allow the use of truncated HMAC. Section 3.6 describes the extension to support 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で説明されているコンバージョン操作を実行する必要があります。セット）。IDNAは、ラベルを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, then upgrades to TLS, and 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セッションのハンドシェイクで確立されている場合、クライアントはアプリケーションレイヤーで別のサーバー名を要求しようとしてはなりません。
[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 "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. That 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」アラートを送信する可能性があります。
[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 to send 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 1.0 servers.)
（既存のTLS 1.0サーバーを「壊す」ことを避けるために、クライアント証明書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, or
- Certificateurl.Typeが「個人_CERTS」の場合、各URLは、最初にクライアントの証明書のURLを使用して、単一のderエンコードX.509v3証明書を指します。
- 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 is either 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証明書メッセージで使用されているものと同じであるが、証明書がある順序とは反対のURLSと同じであることに注意してください。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.
この拡張機能をサポートするサーバーは、証明書URLの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.
サーバーが特定の証明書で証明書を取得する際に不合理な遅延に遭遇した場合、タイムアウトして「証明書_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 rootキーのアイデンティティは提供されていません。
- "key_sha1_hash" - contains the SHA-1 hash of the CA root key. For DSA and 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ハッシュが含まれています。DSAおよびECDSAキーの場合、これは「subjectpublickey」値のハッシュです。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に、空の「extension_Data」を使用して、タイプ「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 as 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 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 " - このアラートは、証明書のハッシュがcirtermant_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;
Traditionally for Internet protocols, the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion, and RFCs usually define the procedure to be used by the IANA. However, there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which may result in a significant reduction in overall security.
従来、インターネットプロトコルについては、インターネットが割り当てられた数字当局（IANA）は、将来の拡張に新しい値の割り当てを処理し、RFCは通常、IANAが使用する手順を定義します。ただし、新機能と既存の機能の間でこのプロトコルで発生する可能性のある微妙な（そして微妙ではない）相互作用があり、全体的なセキュリティが大幅に減少する可能性があります。
Therefore, requests to define new extensions (including assigning extension and error alert numbers) must be approved by IETF Standards Action.
したがって、新しい拡張機能を定義するリクエスト（拡張機能とエラーアラート番号の割り当てを含む）は、IETF標準アクションによって承認される必要があります。
The following considerations should be taken into account when designing new extensions:
新しい拡張機能を設計する際には、以下の考慮事項を考慮する必要があります。
- 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, and 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 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].
追加のセキュリティ上の考慮事項は、TLS 1.0 RFC [TLS]で説明されています。
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 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 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 allowing 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, the possibility for loops and deadlocks to be created exists and should be addressed. In the case of FTP, attacks similar to FTP bounce attacks arise.
関係する詳細なセキュリティの懸念は、サーバーがサポートする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 being 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, with unusual protocols offering limited security or whose security is not well-understood being 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 the handshake messages 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 future, if either the client or the server for a given session were updated to take into account the problem, they 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. A client that requires OCSP validation of certificates SHOULD either contact the OCSP server directly in this case, 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を使用してエンコードされます。将来の拡張機能がテキスト文字列を使用している場合、国際化を設計で考慮する必要があります。
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メディアタイプ名：アプリケーション
MIME subtype name: pkix-pkipath
MIMEサブタイプ名：pkix-pkipath
Required parameters: none 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 that will be 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: this memo, and [PKIX].
公開された仕様：このメモ、および[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 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
意図された使用法：共通
Author/Change controller:
Magnus Nystrom <magnus@rsasecurity.com>
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in RFC 2028. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、RFC 2028に記載されています。この仕様の実施者またはユーザーによるそのような独自の権利を使用するための一般的なライセンスまたは許可を取得するために行われたのは、IETF事務局から取得できます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this document. Please address the information to the IETF Executive Director.
IETFは、この文書を実践するために必要なテクノロジーをカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するように関心のある当事者を招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
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。and T. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[IDNA] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[IDNA] Faltstrom、P.、Hoffman、P。and 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, "Internet X.509 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 - Operation Protocols: FTP and HTTP", RFC 2585, May 1999.
[PKIOP] Housley、R。およびP. Hoffman、「インターネットX.509公開キーインフラストラクチャ - 操作プロトコル：FTPおよびHTTP」、RFC 2585、1999年5月。
[PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[Pkix] Housley、R.、Polk、W.、Ford、W。and D. Solo、「インターネット公開キーインフラストラクチャ - 証明書および証明書取消リスト（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月。
[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI] Berners-Lee、T.、Fielding、R。and L. Masinter、「ユニフォームリソース識別子（URI）：汎用構文」、RFC 2396、1998年8月。
[UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[UTF8] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、RFC 2279、1998年1月。
[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。
[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月。
[MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General ClientHello extension mechanism and virtual hosting," ietf-tls mailing list posting, August 14, 2000.
[メーリングリスト] J. Mikkelsen、R。Eberhard、およびJ. Kistler、「一般的なクライアントヘロ拡張メカニズムと仮想ホスティング」、IETF-TLSメーリングリストの投稿、2000年8月14日。
[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月。
Simon Blake-Wilson BCI EMail: sblakewilson@bcisse.com
Simon Blake-Wilson BCIメール：sblakewilson@bcisse.com
Magnus Nystrom RSA Security EMail: magnus@rsasecurity.com
Magnus nystrom RSAセキュリティメール：magnus@rsasecurity.com
David Hopwood Independent Consultant EMail: david.hopwood@zetnet.co.uk
David Hopwood独立コンサルタントメール：David.hopwood@zetnet.co.uk
Jan Mikkelsen Transactionware EMail: janm@transactionware.com
Jan Mikkelsenトランザクションウェアメール：janm@transactionware.com
Tim Wright Vodafone EMail: timothy.wright@vodafone.com
Tim Wright Vodafoneメール：timothy.wright@vodafone.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。