1. イントロダクション
トランスポート層セキュリティ(TLS)プロトコルバージョン1.2は[RFC5246]で規定されています。その仕様には、TLSへの拡張機能のためのフレームワーク、そのような拡張機能を設計する際の考慮事項([RFC5246]のセクション7.4.1.4を参照)、および新しい拡張コードポイントの割り当てに関するIANA考慮事項が含まれていますが、署名アルゴリズム([RFC5246]のセクション7.4.1.4.1を参照)以外の特定の拡張機能は指定していません。
本文書は、既存のTLS拡張機能の仕様を提供します。これは、ほとんどの場合、TLS 1.0(RFC 2246)およびTLS 1.1(RFC 4346)のTLS拡張機能をカバーしていたRFC 4366からの資料の適応と編集です。
1.1. 対象となる特定の拡張機能
ここで説明する拡張機能は、TLSプロトコルメッセージフォーマットによって提供される機能の拡張に焦点を当てています。新しい暗号スイートの追加などの他の問題は先送りされています。
本文書で定義される拡張タイプは次のとおりです:
enum {
server_name(0), max_fragment_length(1),
client_certificate_url(2), trusted_ca_keys(3),
truncated_hmac(4), status_request(5), (65535)
} ExtensionType;
具体的には、本文書で説明される拡張機能:
-
サーバー名表示(Server Name Indication): TLSクライアントが、接続しているサーバーの名前をTLSサーバーに提供できるようにします。この機能は、単一の基礎となるネットワークアドレスで複数の「仮想」サーバーをホストするサーバーへの安全な接続を容易にするために望ましいものです。
-
最大フラグメント長のネゴシエーション(Maximum Fragment Length Negotiation): TLSクライアントとサーバーが、送信される最大フラグメント長をネゴシエートできるようにします。この機能は、一部のクライアント間のメモリ制約、および一部のアクセスネットワーク間の帯域幅制約の結果として望ましいものです。
-
クライアント証明書URL(Client Certificate URLs): TLSクライアントとサーバーが、クライアント証明書URLの使用をネゴシエートできるようにします。この機能は、制約のあるクライアントのメモリを節約するために望ましいものです。
-
信頼できるCA表示(Trusted CA Indication): TLSクライアントが、TLSサーバーに対して、どの認証局(CA)ルート鍵を所有しているかを示すことができるようにします。この機能は、メモリ制限のために少数のCAルート鍵のみを格納できるTLSクライアントに関与する複数のハンドシェイク失敗を防ぐために望ましいものです。
-
切り詰められたHMAC(Truncated HMAC): TLSクライアントとサーバーが、切り詰められたメッセージ認証コード(MAC)の使用をネゴシエートできるようにします。この機能は、制約のあるアクセスネットワークで帯域幅を節約するために望ましいものです。
-
証明書ステータスリクエスト(Certificate Status Request): TLSクライアントとサーバーが、TLSハンドシェイク中にサーバーがクライアントに証明書ステータス情報(例:オンライン証明書ステータスプロトコル(OCSP)[RFC2560]レスポンス)を送信することをネゴシエートできるようにします。この機能は、制約のあるアクセスネットワークを介して証明書失効リスト(CRL)を送信することを回避し、帯域幅を節約するために望ましいものです。
TLSクライアントとサーバーは、本文書で説明されている拡張機能を使用することができます。拡張機能は下位互換性を持つように設計されており、拡張機能をサポートするTLSクライアントは拡張機能をサポートしないTLSサーバーと通信でき、その逆も可能です。
これらの拡張機能に関連付けられたメッセージでTLSハンドシェイク中に送信されるものは、「Finished」メッセージに含まれるハッシュ計算に含まれなければなりません(MUST)。
1.2. 本文書で使用される規約
本文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、[RFC2119]に記載されているように解釈されるものとします。