ネットワーク WG
Request for Comments: 4366
Obsoletes: 3546
Updates: 4346
分類: Standards Track

D. Hopwood
BCI
M. Nystrom
RSA Security
Independent Consultant
J. Mikkelsen
Transactionware
T. Wright
Vodafone
2006年 4月

English

TLS 拡張
(Transport Layer Security (TLS) Extensions)

このメモの位置づけ

本書は、インターネット・コミュニティに対してインターネット・スタンダードトラックのプロトコルを規定するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態、およびステータスについては、"Internet Official Protocol Standards" (STD 1) の最新版を参照すること。このメモの配布に制限は無い。

著作権表記

Copyright (C) The Internet Society (2006).

要旨

本書は、TLS(Transport Layer Security)に機能を追加するために使われる可能性がある拡張について記述する。これは、TLS ハンドシェイクにおける client hello と server hello についての一般的な拡張メカニズムと、これらの一般的なメカニズムを使う具体的な拡張の両方を提供する。

この拡張は、TLS クライアントおよびサーバによって使われる可能性がある。この拡張には下位互換性がある。: 通信は、この拡張をサポートする TLS クライアントと、この拡張をサポートしない TLS サーバの間(および、この逆)において可能である。

目次

1. はじめに
1.1.本書における用語法
2 一般的な拡張メカニズム
2.1. 拡張された Client Hello
2.2. 拡張された Server Hello
2.3. Hello 拡張
2.4. ハンドシェイクプロトコルへの拡張
3. 具体的な拡張
3.1. サーバ名表示
3.2. 最大フラグメント長の交渉
3.3. クライアント証明書 URL
3.4. Trusted CA 表示
3.5. 切り詰められた HMAC
3.6. 証明書状態リクエスト
4. エラー警告
5. 新しい拡張を定義するための手続き
6. セキュリティについての考慮事項
6.1. server_name のセキュリティ
6.2. max_fragment_length のセキュリティ
6.3. client_certificate_url のセキュリティ
6.4. trusted_ca_keys のセキュリティ
6.5. truncated_hmac のセキュリティ
6.6. status_request のセキュリティ
7. 国際化についての考慮事項
8. IANA についての考慮事項
9. 謝辞
10. 規範的参考文献
11. 参考情報

 

1. はじめに English

本書は、TLS(Transport Layer Security)に機能を追加するために使われる可能性がある拡張について記述する。これは、TLS ハンドシェイクにおける client hello と server hello についての「一般的な拡張メカニズム」と、これらの「一般的なメカニズム」を使う「具体的な拡張」の両方を提供する。

TLS は、今や、ますます多様な運用環境において使われており、それらの多くは、TLS について、当初の設計クライテリアが決定されたとき、想定されていなかった。本書において紹介される拡張は、TLS がワイヤレスネットワークのような新しい環境において、可能な限り有効に動作することを可能にするために設計されたものである。

ワイヤレス環境は、しばしば、有線環境においては卑近には存在しない数多くの制約をわずらう。これらの制約は、帯域制限、消費電力制約、メモリ制約および電池寿命制約を含む可能性がある。

ここに記述された拡張は、TLS プロトコルメッセージフォーマットによって提供される機能を拡張することに焦点を当てている。新しいサイファースィートの追加のような他の論点は、見送られた。

具体的には、本書中に記述されている拡張は、下記のとおり。:

上記の拡張をサポートするために、client hello メッセージおよび server hello メッセージ用に一般的な拡張メカニズムが導入された。

本書中に記述された拡張は、TLS クライアントおよび TLS サーバによって使われる可能性がある。この拡張は、下位互換となるように設計された。これは、「拡張をサポートする TLS クライアントは、その拡張をサポートしない TLS サーバと話すことができること、および、その逆もできること(vice versa)」を意味する。それゆえ、本書は、TLS 1.0 [TLS] および TLS 1.1 [TLSbis] を更新する。

下位互換性は、主に、ふたつの考慮事項を通じて達成される。:

要するに、下位互換性は、「"extensions-aware" でないサーバは、解釈できない client hello に追加されたデータを無視する」という TLS 要件に基づいて達成される。例えば、[TLS] の 7.4.1.2 節を参照。

しかし、「下位互換性はサポートされているが、制約のあるクライアントには、そのようなクライアントの限られた能力の結果として、その拡張をサポートしないサーバとの通信を棄却することを強要されるものがある可能性があること」に注意。

本書は、RFC3546 [RFC3546] の改訂版である。唯一の主要な変更点は、新しい拡張の定義に関するものである。新しい拡張は、今や、(standard track RFC を要求するのではなく)IETF のコンセンサス過程を通じて定義される可能性がある。さらに、少数の軽微な(minor)明確化と、編集上の改良が行われた。

本書の以降の部分は、下記のように構成されている。2 章は、ハンドシェイクメッセージの client hello および server hello 用の一般的な拡張メカニズムを記述する。3 章は、TLS への具体的な拡張を記述する。4 章は、TLS 拡張と共に使う新しいエラー警告を記述する 。本書の最後は、IPR(知的財産権)、セキュリティについての考慮事項、application/pkix-pkipath MIME 種別の登録、謝辞および参考文献に対応する。

1.1. 本書における用語法 English

本書中の MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL は、BCP 14, RFC 2119 [KEYWORDS] に記述されたように解釈されるべきものである。

2. 一般的な拡張メカニズム English

本章は、TLS ハンドシェイクの client hello および server hello メッセージについて、一般的な拡張メカニズムを提供する。

これらの一般的な拡張メカニズムは、クライアントおよびサーバが「具体的な拡張を使うか否か?」や「どのように具体的な拡張を使うか?」を交渉することを可能にするために必要不可欠である。記述された拡張フォーマットは、[MAILINGLIST] に基づいている。

2.1 節は、拡張された client hello メッセージフォーマットを規定し、2.2 節は、拡張された server hello メッセージフォーマットを規定し、そして 2.3 節は、拡張された client hello および server hello と共に使われる実際の拡張フォーマットを記述する。

2.1. 拡張された Client Hello English

クライアントは、サーバから client hello メッセージフォーマットの代わりに拡張された client hello メッセージフォーマットを送ることによって、拡張された機能を要求する可能性がある(MAY)。拡張された client 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;

ここで、新しい "client_hello_extension_list" フィールドは、拡張の一覧を含む。実際の "Extension" フォーマットは、2.3節 に定義されている。

あるクライアントが拡張された client hello を使う追加的な機能を要求し、かつ、この機能がそのサーバによってサポートされていない際には、そのクライアントは、そのハンドシェイクを中止する可能性がある(MAY)

「[TLS] の 7.4.1.2節は、client hello メッセージに追加されるべき追加的な情報を許容すること」に注意。それゆえ、上で定義される拡張された client hello の利用は、既存の TLS サーバを "break"してはいけない。

この拡張メカニズムをサポートするサーバは、原型(original)か、あるいは、拡張された clientHello フォーマットのいずれかの client hello メッセージのみを受容しなければならない(MUST)。そして、(他のすべてのメッセージについては)「そのメッセージ中のデータの量は、これらのフォーマットのひとつと正確に一致すること」をチェックしなければならない(MUST)。チェックしない場合、これは、fatal "decode_error" 警告を送らなければならない(MUST)。これは、[TLS] 中の "Forward compatibility note" より優先する。

2.2. 拡張された Server Hello English

拡張された server hello メッセージフォーマットは、クライアントが 2.1 節に規定されている拡張された client hello メッセージを通じた拡張された機能性をリクエストしたとき、server hello メッセージの代わりに送られる可能性がある(MAY)。拡張された server 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;

ここで、新しい "server_hello_extension_list" フィールドは、拡張の一覧を含む。実際の "Extension" フォーマットは、2.3節に定義されている。

「拡張された server hello メッセージは、拡張 client hello メッセージへのレスポンスとしてのみ、送られること 」に注意。これは、「拡張された server hello メッセージは、既存の TLS クライアントを "break"する可能性がある」という可能性を提供する。

2.3. Hello 拡張 English

拡張された client hello および拡張された server hello についての拡張フォーマットは、下記のとおり。:

      struct {
          ExtensionType extension_type;
          opaque extension_data<0..2^16-1>;
      } Extension;

ここで:

本書中に定義された拡張種別は、下記のとおり。:

      enum {
          server_name(0), max_fragment_length(1),
          client_certificate_url(2), trusted_ca_keys(3),
          truncated_hmac(4), status_request(5), (65535)
      } ExtensionType;

定義された拡張種別の一覧は、IANA によって維持管理されている。現在の一覧は、こちらに在る。:
http://www.iana.org/assignments/tls-extensiontype-values
「どのように新しい値は、追加されるか?」についての情報の詳細は、5 章および 8 章を参照。

「(将来、定義されるものを含む)すべての拡張種別について、拡張種別は、同一の拡張種別が対応する client hello 中に現れない限り、その拡張されたサーバ hello 中に現れなければならない(MUST NOT)こと 」に注意。それゆえ、クライアントは、関連する(拡張された) client hello において要求しなかった、拡張された server hello 中の拡張種別を受け取る場合、そのハンドシェイクを中止しなければならない(MUST)

それにもかかわらず、"server-oriented" 拡張は、将来、このフレームワーク内に提供される可能性がある。このような拡張(例: of type x) は、そのクライアントに、まず、「それは、その拡張種別をサポートすること」を示すために、空の extension_data と共に、その(拡張された) client hello 中の種別 x の拡張を送ることを要求することになる。この場合、そのクライアントは、その拡張種別を解釈する能力を提供しており、そのサーバは、クライアントを、その申し出(offer)に応じて扱う。

「異なる種別をもつ複数の拡張が拡張された client hello もしくは拡張された server hello 中に在るとき、その拡張は、あらゆる順序で現れる可能性があること」にも注意。同一の種別の拡張が複数、存在してはならない(MUST NOT)

最後に、「拡張された client hello は、新しいセッションを開始するときと、セッション回復(resumption)を要求するときの両方、送られる可能性があること」に注意。本当に、セッションの回復(resumption)を要求するクライアントは、一般に、「サーバは、このリクエスを受容するか否か?」を知らない。それゆえ クライアントは、新しいセッションについて通常、行う場合、拡張された client hello を送る必要がある(SHOULD)。一般に、各拡張種別の仕様は、新規セッションと中断されたセッションの両方において、拡張の影響の検討を含まなければならない。

2.4. ハンドシェイクプロトコルへの拡張 English

本書は、ふたつの新しいハンドシェイクメッセージとして、"CertificateURL" と "CertificateStatus" の利用を示唆する。これらのメッセージは、順に、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;    /* ハンドシェイク種別 */
          uint24 length;             /* メッセージ中の byte 数 */
          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;   

3. 具体的な拡張 English

本章は、本書に規定されている具体的な TLS 拡張を記述する。

「TLS ハンドシェイクにおいて送られるこれらの拡張と関連するあらゆるメッセージは、"Finished" メッセージに含まれる ハッシュ計算中に含められなければならない(MUST)こと」に注意。

「本章において定義されるすべての拡張は、セッションが開始されたときのみ関連すること」にも注意。クライアントがセッション回復(resumption)を要求している間に(拡張された) client hello 中に、ひとつ、もしくは、複数の定義された拡張種別を含むとき :

3.1 節は、クライアントが「どのサーバに問い合わせているか?」を示すことができるようにする TLS の拡張を記述する。3.2 節は、最大フラグメント長の交渉を提供する拡張を記述する。3.3 節は、クライアント証明書 URL を許容する拡張を記述する。3.4 節は、クライアントが「どの CA ルート鍵を保持しているか?」を示すことができるようにする拡張を記述する。3.5 節は、「切り詰められた HMAC」を利用できるようにする拡張を記述する。3.6 節は、証明書状態情報メッセージの TLS ハンドシェイクへの統合をサポートする拡張を記述する。

3.1. サーバ名表示 English

TLS は、クライアント用に、サーバ宛にクライアントがコンタクトしようとしているサーバの名前を伝えるためのメカニズムを提供しない。これは、クライアント用に単一の基盤となっている(underlying)ネットワークアドレスで複数の「バーチャル」サーバをホストするサーバへのセキュアな接続を容易にするために、この情報を提供するために渇望される可能性がある。

サーバ名を提供するために、クライアントは、(拡張された) client hello 中に 種別が "server_name" の拡張を含む可能性がある(MAY)。この拡張の"extension_data" フィールドは、"ServerNameList" を納めるものとする(SHALL)。これは、下記のとおり。:

      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

現在、サポートされている唯一のサーバ名は、DNS hostname である。しかし、これは、いかなる TLS の DNS への依存性も意味しない。そして、他の名前種別が、将来、(本書を更新する RFC によって)追加される可能性がある。TLS は、提供されたサーバ名をオペイク(opaque)データとしてを扱い、その名前および種別を、そのアプリケーションに渡す可能性がある(MAY)

"HostName" は、クライアントによって理解されているように、サーバの完全に修飾された DNS hostname を納める。hostname は、連結するドット無しで UTF-8 符号化 [UTF8] を使って byte string として表現される。

その hostname ラベルが US-ASCII character のみを納める場合、そのクライアントは、「([IDNA] の 3.1節中の要件 1 に関わらず)ラベルがドット文字 U+002E に対応する byte 0x2E のみによって分離されていること」を確保しなければならない(MUST)。そのサーバが非 US-ASCII character を含む名前と HostName が一致する必要がある場合、これは、HostName を "query string" として扱う(すなわち、AllowUnassigned フラグがセットされなければならない(MUST))[IDNA] の 4章に記述されている慣行的な操作を行わなければならない(MUST)。「IDNA は、ラベルが Unicode character U+002E、U+3002、U+FF0E および U+FF61 のすべてによって分離されうるようにする。それゆえ、サーバは、label separator として、あらゆるこれらの特徴を受容しなければならない(MUST)こと」に注意。そのサーバが、その HostName を ASCII character のみを含んでいる名前と一致させる必要があるのみの場合、これは、ASCII 名を大文字/小文字を区別して(case-insensitively)比較しなければならない(MUST)

Literal な IPv4 アドレスと IPv6 アドレスは、"HostName"において許可されていない。

「クライアントは、あるサーバをサポートされている名前種別によって見つけ出す(locate)ときはいつでも、その client hello 中に種別が "server_name" の拡張を含むこと」が推奨される(RECOMMENDED)

"server_name" 拡張を納める client hello を受け取るサーバは、クライアント宛に返すための適切な証明書、かつ/または、セキュリティポリシーの他の観点の選択をガイドするために、その拡張中に納められている情報を使う可能性がある(MAY)。この際には、そのサーバは、(拡張された) server hello 中に 種別が "server_name" の拡張を含むものとする(SHALL)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

サーバが client hello 拡張を解釈できるが、そのサーバ名前を解釈できない場合、これは、"unrecognized_name" 警告(これは、fatal である可能性がある(MAY))を送る必要がある(SHOULD)

あるアプリケーションがサーバ名を、あるアプリケーションプロトコルで使うことを交渉し、TLS にアップグレードする場合、かつ server_name 拡張が送られる場合、その拡張は、そのアプリケーションプロトコルにおいて交渉されたのと同一の名前を含む必要がある(SHOULD)。その server_name が TLS セッションハンドシェイクにおいて確立している場合、そのクライアントは、そのアプリケーション層において異なるサーバ名を要求することを試みてはいけない(SHOULD NOT)

3.2. 最大フラグメント長の交渉 English

この拡張無しに、TLS は、固定最大 plaintext フラグメント長として 2^14 byte と規定する。これは、制約されたクライアント用に、メモリ制約もしくは帯域制限に起因して、より小さな最大フラグメント長を交渉するために渇望される可能性がある。

より小さい最大フラグメント長を交渉するために、クライアントは、(拡張された)client hello 中に種別が "max_fragment_length" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、下記を含むものとする(SHALL)。:

   enum{
       2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
   } MaxFragmentLength;

この値は、渇望される最大フラグメント長である。このフィールドについて、許容される値は、2^9、2^10、2^11 および 2^12 である。

"max_fragment_length" 拡張を含む拡張された client hello を受け取るサーバは、(拡張された) server hello 中に type"max_fragment_length" の拡張を含めることによって要求された最大フラグメント長を受容する可能性がある(MAY)。この拡張の "extension_data" フィールドは、"MaxFragmentLength"を納めるものとする(SHALL)。この値は、要求された最大フラグメント長と同一である。

あるサーバが許容された値以外の値についての最大フラグメント長の交渉 リクエストを受け取る場合、これは、そのハンドシェイクを "illegal_parameter" 警告 で中止しなければならない(MUST)。同様に、あるクライアントがリクエストしたものとは大きさが異なる最大フラグメント長交渉レスポンスを受け取る場合、これも、そのハンドシェイクを "illegal_parameter" 警告で中止しなければならない(MUST)

ひとだび、2^14 以外の最大フラグメント長が成功裡に交渉されたら、そのクライアントおよびサーバは、「交渉された長さより長いフラグメントは、送られないこと」を確保するために、(ハンドシェイクメッセージを含む)メッセージのフラグメント化をただちに始めなければならない(MUST)。「TLS は、クライアントおよびサーバにハンドシェイクメッセージのフラグメンテーションをサポートすることを要求していること」に注意。

交渉された長さは、セッション回復(resumption)を含む、そのセッションの持続(duration)について適用される。

交渉された長さは、そのレコード層がフラグメンテーション無しに処理できる input を制限する。(すなわち、TLSPlaintext.length の最大値。[TLS] 6.2.1節を参照。)「レコード層の output は、より大きい可能性があること」に注意。例えば、交渉された長さが 2^9=512 である場合、現在、定義されている サイファースィート([TLS]、[KERB] および [AESSUITES] 中に定義されているもの)について、かつ、null 圧縮が使われるとき、レコード層の output は、高々 793 byte である可能性がある(5 byte のヘッダー、512 byte のアプリケーションデータ、256 byte の padding および 20 byte の MAC)。これは、「この際には、793 byte より大きな TLS レコード層メッセージを受け取る TLS レコード層ピア(peer)は、そのメッセージを捨て(discard)、そのメッセージを復号することなく "record_overflow" 警告を送る可能性があること」を意味する。

3.3. クライアント証明書 URL English

この拡張無しに、TLS は、「クライアント認証が行われるとき、クライアント証明書は、クライアントによってサーバ宛に TLS ハンドシェイクにおいて送られること」を規定している。制約されたクライアント用に、それらの証明書を蓄積する必要がないようにして、メモリを節約できるようにするために、証明書の代わりに証明書 URL を送ることが渇望される可能性がある。

証明書 URL のサーバ宛の送信を交渉するために、クライアントは、(拡張された)client hello 中に種別が "client_certificate_url" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

(「既存の TLS サーバの "breaking" を避けるために、クライアント証明書 URL の利用を交渉することが必要不可欠であること」に注意。)

"client_certificate_url" 拡張を納める拡張された client hello を受け取るサーバは、「サーバは、(拡張された) server hello 中に種別が "client_certificate_url" の拡張を含めることによって証明書 URL を受容することを望んでいること」を示す可能性がある(MAY)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

クライアント証明書 URL の利用の交渉が成功裡に完了した後("client_certificate_url" 拡張を含む hello を交換することによって)、クライアントは、"Certificate" メッセージの代わりに "CertificateURL" メッセージを送る可能性がある(MAY)。:

      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];

ここで、"url_and_hash_list" は、一連の URL およびオプションとしてのハッシュを含む。

X.509 証明書が使われるとき、ふたつの可能性がある。:

あらゆる他の証明書フォーマットが使われるとき、TLS において、そのフォーマットの利用を記述している仕様は、証明書もしくは証明書チェーンの符号化フォーマット、および、それらの順序について、あらゆる制約を定義する必要がある。

各 URL に対応するハッシュはクライアントの裁量で、存在しないか、あるいは、その証明書もしくは証明書チェーンの SHA-1ハッシュであるか、 のいずれかとなる。(X.509 証明書の場合、DER で符号化された証明書 もしくは DER で符号化された PkiPath)。

「X.509 証明書について、URL の一覧が使われているとき、URL の順序は、TLS 証明書メッセージ ([TLS] 7.4.2 節を参照)において使われているものと同様であるが、証明書が PkiPath において符号化されている順序とは逆であること」に注意。いずれの場合においても、自己署名された ルート証明書は、「そのサーバは、それを検証するために、既に保持していなければならない」という想定のもとで、そのチェーンから削られる可能性がある(MAY)

"CertificateURL" を受け取るサーバは、クライアントの証明書チェーンをその URL から取得して、それから、いつもどおり、その証明書チェーンを処理することを試みるものとする(SHALL)。そのチェーン中のあらゆる URL のコンテンツのキャッシュされたコピーが、SHA-1 ハッシュがその URL について在り、かつ、それがキャッシュされ複製のハッシュと一致する場合、使われる可能性がある(MAY)

この拡張をサポートするサーバは、証明書 URL について http: URL スキームをサポートしなければならない(MUST)。そして、他のスキームをサポートする可能性がある(MAY)。"http"、"https" もしくは "ftp" 以外のスキームの利用は、予期されない問題を作り出す可能性がある。

使われるプロトコルが HTTP である場合、その HTTP サーバは、「証明書もしくは証明書チェーンは、キャッシュされる必要があるか否か?」そして「どれくらいの期間か?」を規定するために、[HTTP] に記述されているキャッシュ制御(Cache-Control)を使い、directive が期限切れとなるように設定されうる。

TLS サーバは、証明書もしくは証明書チェーンを受け取るとき、HTTP redirect に従うことを要しない。それゆえ、この拡張において使われる URL は、このような redirect に依存しないように選択される必要がある(SHOULD)

証明書もしくは証明書チェーンを取得するために使われるプロトコルが、(HTTP が行うように)MIME でフォーマット化された レスポンスを返す場合、下記の MIME Content-Types が、使われるものとする(SHALL)。: 単一の X.509v3 証明書が返されるとき、その Content-Type は、"application/pkix-cert" [PKIOP] である。そして、X.509v3 証明書の チェーンが返されるとき、その Content-Type は、application/pkix-pkipath" (8 章を参照)である。

ある URL について SHA-1 ハッシュが在る場合、そのサーバは、「その URL から(あらゆる MIME Content-Transfer-Encoding を復号した後に)取得された object のコンテンツの SHA-1 ハッシュは、与えられたハッシュと一致すること」をチェックしなければならない(MUST)。いかなる取得された object も正しい SHA-1 ハッシュをもたない場合、そのサーバは、そのハンドシェイクを "bad_certificate_hash_value" 警告で中止しなければならない(MUST)

「クライアントは、証明書 URL を送るオプションを成功裡に交渉した後に "Certificate" か、あるいは "CertificateURL"のいずれかを送ることを選択する可能性があること」に注意。証明書を送るオプションは、クライアントに複数の証明書を保持する柔軟性を提供するために含められる。

サーバが与えられた CertificateURL 中の証明書を取得する際に、原因不明の(unreasonable)遅延に遭遇する場合、これは、タイムアウトし、"certificate_unobtainable" エラー警告の信号を送る必要がある(SHOULD)

3.4. Trusted CA の表示 English

メモリ制約に起因して、少数の CA ルート鍵しか保持しない制約のあるクライアントは、繰り返されるハンドシェイクの失敗(failure)を避けるために、サーバ宛に「どの ルート鍵を保持しているか?」を示すことを望む可能性がある。

「クライアントは、どの CA ルート鍵を保持するか?」を示すために、クライアントは、(拡張された) client hello 中に 種別が "trusted_ca_keys" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、"TrustedAuthorities" を含むものとする(SHALL)。これは、下記のとおり。:

      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>;

ここで、"TrustedAuthorities" は、クライアントが処理する CA ルート鍵識別子(identifier)の一覧を提供する。各 CA ルート鍵は、下記のいずれかを通じて識別される。:

「クライアントは、この拡張中にクライアントが保持する CA ルート鍵を含まない、あるいは、いくらか、もしくは、すべてを含む可能性があること」に注意。

「鍵ハッシュ、もしくは、単体の Distinguished Name は、証明書の発行者を一意に識別しない可能性があること(例えば、特定の CA が複数の鍵ペアをもつ場合)」にも注意。しかし、ここで、我々は、「これは、TLS において証明書発行者を識別するための Distinguished Names の用法に従う場合である」と想定する。

CA ルート鍵を含めないオプションは、そのクライアントが何らか事前定義された一式の CA ルート鍵の保持を示すことができるようにするために含められる。

"trusted_ca_keys" 拡張を納める client hello を受け取るサーバは、そのクライアント宛に返す適切な証明書チェーンの選択をガイドするために、その拡張中に納められた情報を使う可能性がある(MAY)。この際には、そのサーバは、(拡張された)server hello 中に種別として"trusted_ca_keys" の拡張を含むものとする(SHALL)。この拡張の"extension_data" フィールドは、空であるものとする(SHALL)

3.5. 切り詰められた HMAC English

現在、定義されている TLS サイファースィートは、MAC 実装として HMAC を MD5 か、あるいは SHA-1 [HMAC] のいずれかと共に、レコード層の通信を認証する(authenticate)ためにを使う。TLS において、そのハッシュ関数の output 全体が、その MAC tag として使われる。しかし、制約された環境においては、MAC tag をフォーマットに合わせるとき、ハッシュ関数の output を 80 bit に切り詰めることによって、帯域を節約することが渇望される可能性がある。

80 bit に切り詰められた HMAC の利用を交渉するために、クライアントは、拡張された client hello 中に種別が "truncated_hmac" の拡張を含む可能性がある(MAY)。この拡張の "extension_data" フィールドは、空であるものとする(SHALL)

"truncated_hmac" 拡張を納める拡張された hello を受け取るサーバは、種別が "truncated_hmac"の拡張を拡張された server hello 中に空の "extension_data"と共に含めることによって、切り詰められた HMAC を使うことに合意する可能性がある(MAY)

「HMAC を使わない新しいサイファースィートが追加され、そのセッションがこれらのサイファースィートのひとつと交渉する場合、この拡張は影響を与えないこと」に注意。「他の MAC を使うあらゆる新しいサイファースィートは、セキュリティと帯域についての考慮事項の両方を考慮して、MAC 長を、そのサイファースィート定義の不可欠(integral)な部分と見なすこと」が強く推奨される。

HMAC の切り詰めが TLS ハンドシェイク において成功裡に交渉されていて、かつ、交渉されたサイファーが HMAC を使う場合、そのクライアントとサーバの両方は、この事実を他の交渉されたセキュリティパラメータと共に TLS レコード層に渡す。したがって、そのセッションにおいて、クライアントおよびサーバは、[HMAC] に規定されているように、計算された切り詰められた HMAC を使わなければならない(MUST)。すなわち、CipherSpec.hash_size は、10 byte であり、その HMAC output の最初の 10 byte のみが、転送されて、チェックされる。「この拡張は、ハンドシェイク過程もしくは鍵導出の一部として、PRF(pseudo-random function)の計算に影響を与えないこと」に注意。

交渉された HMAC の切り詰め(truncation)長(size)は、セッション回復( resumption)を含むセッションの継続(duration)に適用する。

3.6. 証明書状態リクエスト English

 

制約された(constrained)クライアントは、CRL の転送を避け、それによって、制約されたネットワーク上の帯域を節約するために、サーバ証明書の有効性(validity)をチェックするために OCSP [OCSP] のような証明書状態プロトコルを使うことを望む可能性がある。この拡張は、TLS ハンドシェイクにおいて、このような情報が通信遅延(roundtrip)や資源を節約して送られうるようにする。

証明書 status 情報を受け取るクライアントの渇望を示すために、クライアントは、(拡張された)client hello 中に種別が "status_request" の拡張を含む可能性がある(MAY)。この拡張の"extension_data" フィールドは、"CertificateStatusRequest" を含むものとする(SHALL)。ここでは、下記の処理が行われる。:

      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>;

OCSPStatusRequest において、"ResponderIDs" は、そのクライアントが信頼する OCSP responder の一覧を提供する。ゼロ長の "responder_id_list" sequence は、「その responder は、そのサーバに黙示的に知られている(例: 事前の調整(arrangement)によって)」という特別な意味をもつ。"Extensions" は、OCSP リクエスト拡張を DER で符号化したものである。

"ResponderID" および "Extensions" の両方は、[OCSP] に定義されているように、DER で符号化された ASN.1 type である。英単語の "Extensions(拡張)" は、[PKIX] から導入された。ゼロ長の "request_extensions"値は、「("Extensions" 種別としては妥当ではないゼロ長の ASN.1 SEQUENCE とは逆に)拡張は無いこと」を意味する。

"id-pkix-ocsp-nonce" OCSP 拡張の場合、[OCSP] は、その符号化について不明確である。明確化すると、この nonce は、別の OCTET STRING としてカプセル化される DER で符号化された OCTET STRING でなければならない(MUST)(「既存の OCSP クライアントに基づく実装は、この要件への準拠性についてチェックされる必要があること」に注意)。

"status_request" 拡張を納める client hello を受け取るサーバは、適切な証明書状態レスポンスを、それらの証明書と共にクライアント宛に返す可能性がある(MAY)。OCSP が要求される場合、それらは、OCSP responder を選択するとき、その拡張中に格納された情報を使う必要があり(SHOULD)、request_extensions を、その OCSP リクエスト中に含む必要がある(SHOULD)

サーバは、"CertificateStatus" メッセージを "Certificate" メッセージの直後(かつ、あらゆる "ServerKeyExchange" メッセージ、もしくは"CertificateRequest" メッセージの前)に送ることによって、サーバ証明書と共に証明書レスポンスを返す。サーバが "CertificateStatus" メッセージを返す場合、そのサーバは、拡張された server hello 中に空の "extension_data" と共に種別が "status_request" の拡張を含めていなければならない(MUST)

      struct {
          CertificateStatusType status_type;
          select (status_type) {
              case ocsp: OCSPResponse;
          } response;
      } CertificateStatus;
      opaque OCSPResponse<1..2^24-1>

"ocsp_response" は、完全な、DER で符号化された OCSP レスポンスを([OCSP] において定義されている ASN.1 表記の OCSPレスポンスを使って)納める。「ひとつの OCSP レスポンスのみが送られる可能性があること」に注意。

"CertificateStatus" メッセージは、ハンドシェイクメッセージ種別 "certificate_status"を使って運ばれる。

「サーバは、たとえ client hello メッセージ中の "status_request" 拡張を受け取る場合でも、"CertificateStatus" メッセージを送らないことも選択する可能性がある(MAY)こと」に注意。

「サーバは、client hello メッセージ中の "status_request" 拡張を受け取らない限り、"CertificateStatus" メッセージを送らなければならない(MUST NOT )こと」にも注意。

OCSP レスポンスを要求して、"CertificateStatus" メッセージ中の OCSP レスポンスを受け取るクライアントは、その OCSP レスポンスをチェックして、その レスポンスが十分なもの(satisfactory)でない場合、そのハンドシェイクを中止しなければならない(MUST)

4. エラー警告 English

本章は、本書中に定義される TLS 拡張を伴う用途に新しいエラー警告を定義する。

下記の新しいエラー警告が定義されている。既存のクライアントおよび サーバの "breaking" を避けるために、これらの警告は、送信主体が拡張された hello メッセージを通信相手の主体から受け取っていない限り、送られなければならない(MUST NOT)

これらの エラー警告は、下記の構文(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 は、経緯上の理由で定義されていない。 */
          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),           /* 新 */
          certificate_unobtainable(111),        /* 新 */
          unrecognized_name(112),               /* 新 */
          bad_certificate_status_response(113), /* 新 */
          bad_certificate_hash_value(114),      /* 新 */
          (255)
      } AlertDescription;

5. 新しい拡張を定義するための手続き English

拡張種別の一覧は、2.3節において定義したように、IANA(Internet Assigned Numbers Authority)によって維持管理されている。それゆえ、アプリケーションは、新しい拡張種別の値を取得するためには、IANA 宛に行われる必要がある。このプロトコルの新しい機能と既存の機能の間に生じる可能性がある微妙な(そして、さほど微妙とは言えない)相互作用(interactions)には、全体のセキュリティの顕著な低下(reduction)をもたらすがあるので、新しい値は、[IANA] に規定されている IETF のコンセンサス過程を通じてのみ定義されるものとする(SHALL)

(これは、「新しい割り当ては、IESG によって承認された RFC を通じてのみ行われる可能性があること」を意味する。)

下記の考慮事項が、新しい拡張を設計するとき、考慮される必要がある。:

しばしば、「拡張フィールドは、Finished メッセージ ハッシュへの input 中に含まれている」という事実で十分であるが、その拡張がハンドシェイク過程(phase)において送られるメッセージの意味を変えるとき、特段の注意が必要とされる。設計者および実装者は、「そのハンドシェイクが認証(authenticate)されるまでは、能動的(active)な攻撃者は、メッセージを改変し、拡張を挿入、削除もしくは置換できる」という事実を認識しておく必要がある。


6. セキュリティについての考慮事項 English

一般的な拡張メカニズム、および、新しい拡張の設計についての「セキュリティについての考慮事項」は、以前の章に記述されている。本書に定義されている拡張の各々のセキュリティ分析が、以降に提供される。

一般に、実装者は、脅威の動向(the state of the art)を監視することを続け、識別されたあらゆる弱点に対応する必要がある。

追加的なセキュリティについての考慮事項が、TLS 1.0 の RFC [TLS] および TLS 1.1の RFC [TLSbis] に記述されている。

6.1. server_name のセキュリティ English

単一のサーバが複数のドメインをホストする場合、明らかに、各ドメインのオーナーにとっては「これ(サーバ)が、セキュリティニーズを満たすこと」を確保することが必要不可欠である。これとは別に、server_name は、顕著なセキュリティ 論点をもたらすようには現れない。

実装は、「server_name 中の length フィールドの値がどのようなものであれ、バッファオーバーフローが起こらないこと」を確保しなければならない(MUST)

本書は、server_name 拡張中の国際化 hostname についての符号化を規定するが、これは、TLS における国際化 hostname の利用に関するいかなるセキュリティ論点(特に、表示されたとき、もしくは印刷されたとき、別の名前と区別できない「偽装された(spoofed)」名前の結末)にも対応しない。「サーバ証明書は、手続き(procedure)が偽装された(spoofed) hostname のリスクを緩和するために存在しない限り、国際化 hostname 用に発行されないこと」が推奨される。

6.2. max_fragment_length のセキュリティ English

最大フラグメント長は、ハンドシェイクメッセージを含めて、ただちに影響を与える。しかし、それは、TLS には無い、いかなるセキュリティの複雑な事項(complication)も持ち込まない。なぜならば、TLS は、実装にフラグメント化されたハンドシェイクメッセージを扱えることを要求するからである。

3.2節に記述されているように、ひとたび、非 null のサイファースィートが活性化されると、有効な(effective)最大フラグメント長は、交渉された max_fragment_length と共に、そのサイファースィートおよび圧縮方法に依存すること」に注意。これは、バッファの大きさを測るとき、そしてバッファオーバーフローについてチェックするとき、考慮されなければならない。

6.3. client_certificate_url のセキュリティ English

この拡張については、ふたつの主要な論点がある。

最初の主要な論点は、「クライアントは、証明書 URL を送るとき、証明書ハッシュを含む必要があるか否か?」である。

クライアント認証が client_certificate_url 拡張「無しに」使われるとき、そのクライアント証明書チェーンは、Finished メッセージハッシュによって対象範囲とされる。ハッシュを含めて、取得された証明書チェーンに照らして、それらをチェックすることの目的は、「この拡張が使われるとき、同一の属性が保持されること」すなわち、「そのサーバによって取得された証明書チェーン中のすべての情報は、意図したクライアントとしてのものであること」を確認することにある。

他方、証明書ハッシュを削除することは、いくつかの状況において渇望される機能を可能にする。例えば、クライアントには、固定(fixed)URL に蓄積され、そのクライアント宛には提供されない必要がある日々の(daily)証明書が発行される可能性がある。証明書ハッシュを省略することを選択したクライアントは、そのクライアントが提供することを意図した証明書とは異なるクライアントの鍵上の有効な(valid)証明書を、攻撃者が取得するような攻撃の可能性を認識しておく必要がある。TLS は、MD5 と SHA-1 の両方のハッシュを、いくつかの他の箇所に使うが、これは、ここで必要不可欠であるとは信じられていなかった。SHA-1 に要求される属性(property) は、第二原像攻撃(second pre-image)に耐性をもつ。

ふたつめの主要な論点は、「client_certificate_url についてのサポートは、別の URL プロトコルにおけるクライアントとしてふるまうサーバを巻き込むこと」である。それゆえ、そのサーバは、その URL スキームのクライアントが対象となるの同様の「セキュリティについての考慮事項」の多くの対象となるが、「クライアントは、そのサーバ宛に、どこかの(おそらく、つながっているように見える)URL に接続することを知らせることを試みる」という追加された関心事を伴う。

一般に、この論点は、「攻撃者は、そのサーバを、何らかのセキュリティの欠陥について、脆弱である別のホストを間接的に攻撃するために使う可能性があること」を意味する。これは、サービス妨害攻撃の可能性ももたらす。ここでは、攻撃者は、そのサーバ宛に多くの接続(connection)を作る。その各々は、「その攻撃の標的宛に、そのサーバが試みる接続」をもたらす。

「そのサーバは、ファイアウォールの背後に在る可能性があること、あるいは、さもなければ、公衆インターネットから直接のアクセスは不可能なホストにアクセスできること」に注意。これは、上記の潜在的なセキュリティ問題であったり、サービス妨害問題を実行可能であると共に、さもなければ隠されていたであろう内部ホストの存在を確認できるようにする可能性がある。

含まれる詳細なセキュリティの関心事は、そのサーバによってサポートされている URL スキームに依存する。HTTP の場合、その関心事は、公衆がアクセス可能な HTTP プロキシサーバに適用されるものと同様である。HTTPS の場合、ループ(loop)およびデッドロック(deadlock)が作り出される可能性があり、これは、対応される必要がある。FTP の場合、攻撃が発生する。これは、FTP bounce 攻撃と同様のものである。

この論点の結果として、「client_certificate_url 拡張は、デフォルトで有効化されているのではなく、サーバ運用管理者によって特定して有効にされる必要があること」が推奨される(RECOMMENDED)。「URI プロトコルは、その運用管理者によって個別に有効にされ、最小セットのプロトコルのみが有効にされこと」も 推奨される(RECOMMENDED)。限られたセキュリティしか提供しない特殊な(unusual)プロトコル、もしくは、そのセキュリティがよく理解されていない特殊な(unusual)プロトコルは、避けられる必要がある(SHOULD)

[URI] において検討されているように、デフォルト以外のポートを規定する URL は、とても長い URL が問題をもたらす可能性があるのと同様に、問題をもたらす可能性がある。(これは、バッファオーバーフロー脆弱性を攻略する際に有用となってしまう可能性が、より高い。)

「HTTP caching プロキシは、インターネット上で卑近であり、プロキシには最新バージョンの object について、正しくチェックしないものがあること」にも注意。HTTP(もしくは別のキャッシュを行うプロトコル)を使っている リクエストが誤設定されたプロクシ(もしくは、壊れたプロキシ)を通過する場合、そのプロキシは、期限切れの(out-of-date)レスポンスを返す可能性がある。

6.4. trusted_ca_keys のセキュリティ English

「どの CA ルート鍵をクライアントが保持しているかは、機密情報と見なされうる」可能性がある。結果として、CA ルート鍵 indication 拡張は、注意を払って使われる必要がある。

SHA-1 証明書ハッシュ代替(alternative)の利用は、「各証明書は、明確に(unambiguously)規定されること」を確保する。以前の拡張に関して、MD5 と SHA-1 ハッシュの両方を使うことが必要不可欠とは信じられていなかった。

6.5. truncated_hmac のセキュリティ English

「切り詰められた MAC は、『切り詰められていない』 MAC よりも弱い」という可能性がある。しかし、 MD5 もしくは SHA-1 で 80 bit に切り詰められた HMAC について、顕著な弱点は、現在、知られていないか、あるいは、存在することが予想されている。

「MAC の output 長は、MAC 値の偽造(forging)は、オフラインではできないので、公開鍵暗号技術の鍵ほどの長さである必要はない。: TLS において、1 回の失敗した(failed)MAC 推測(guess)が、その TLS セッションの即刻切断(immediate termination)をもたらすこと」に注意。

その MAC アルゴリズムは、すべてのハンドシェイクメッセージの後でのみ、影響を与えるので、能動的(active)な攻撃者が切り詰められた HMAC 拡張の交渉を、切り詰められた HMAC 拡張が使われないところに(「そのハンドシェイク認証(authentication)は、セキュアである」という程度までに)強要することは、不可能である。すべてのハンドシェイクメッセージは、「拡張パラメータが Finished メッセージ中のハッシュによって認証されている」ということに影響を与える。それゆえ、将来、何らかのセキュリティ問題が「切り詰められた HMAC」について見つかった際には、あるセッションについて、クライアントかサーバのいずれかが、その問題を考慮して更新された場合、この拡張の利用を拒否することは可能である。

6.6. status_request のセキュリティ English

クライアントが OCSP レスポンスを要求する場合、クライアントは、「侵害された(compromised)鍵を使う攻撃者のサーバは、その拡張をサポートしないふりをする(そして、おそらく)可能性があること」を考慮しなければならない。この場合、証明書の OCSP 検証(validation)を要求するクライアントは、その OCSP サーバに直接、問い合わせるか、あるいは、そのハンドシェイクを中止するか、いずれかを行う必要がある(SHOULD)

OCSP nonce リクエスト拡張(id-pkix-ocsp-nonce)の使用は、OCSP レスポンスを再生することを試みる攻撃に対するセキュリティを改善する可能性がある。詳細については、[OCSP] の 4.4.1 節を参照。

7. 国際化についての考慮事項 English

ここに定義されている拡張に、ローカライズの対象となる文字列を直接使うものは無い。DNS(Domain Name System) hostname は、UTF-8 を使って符号化される。将来の拡張がテキストの文字列を使う場合、国際化は、それらの設計において考慮される必要がある。

8. IANA についての考慮事項 English

2.3 節および 5 章は、IANA によって維持管理されるべき ExtensionType 値のレジストリを記述する。ExtensionType 値は、RFC 2434 [IANA] に規定されているように、IETF コンセンサスを通じて割り当てられるべきものである。初期レジストリは、2.3節中の "ExtensionType" の定義に対応する。

MIME type "application/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

Optional parameters: version(デフォルト値は、"1")

符号化についての考慮事項:
この MIME 種別は、下記に定義されているように、ASN.1 type PkiPath を DER で符号化されたものである。:
PkiPath ::= SEQUENCE OF Certificate
PkiPath は、証明書パスを表現するために使われる。この列の中で、証明書の順序は、「最初の証明書の subject は、2 番目の証明書の発行者であり…」というものである。

これは、[X509-4th-TC1] 中に発行されている定義と同一である。「これは、[X509-4th] 中のものとは異なること」に注意。

すべての証明書は、[PKIX] に準拠しなければならない(MUST)。(これは、この種別を使っている PKIX に準拠した証明書のみを符号化するための要件として解釈される必要がある。これは、必ずしも、「PKIX に厳密に準拠していない、すべての証明書は、relying party によって棄却されなければならないこと」を要求しない。ただし、いかなるこのような証明書をも受容することによるセキュリティの結末は、慎重に考慮される必要がある。)

(BER 符号化ではなく)DER 符号化が、使われなければならない(MUST)。この種別が 7 bit 転送(transport)上を送られる場合、base64 符号化が使われる必要がある(SHOULD)

セキュリティについての考慮事項:
[X509-4th] および [PKIX] (もしくは、それらのあらゆる更新版)のセキュリティについての考慮事項が、この種別を使うあらゆるプロトコル(例: TLS)のものと共に適用される。

「この種別は、trusted CA の relying party の既存の設定に関する妥当性(validity)について言明される(assessed)可能性がある証明書チェーンを規定するのみである。その設定についてのいかなる変更を規定するために使われることも、意図されていないこと」に注意。

相互運用可能性についての考慮事項: この種別について、特定の相互運用可能性問題は知られていないが、X.509 証明書に関する推奨事項一般については [PKIX] 参照。

発行されている仕様: RFC 4366 (本書)および [PKIX]。

このメディア種別を使うアプリケーション: TLS。 これは、他のプロトコルによって使われる可能性、あるいは、PKIX 証明書チェーンの一般的な interchange 用に使われる可能性もある。

追加的な情報:
Magic number(s):
DER-encoded ASN.1 は、容易に解釈できる。
Further parsing が、これを他の ASN.1 種別と区別するために要求される。
File extension(s): .pkipath
Macintosh File Type Code(s): 規定されていない。

further 情報のための連絡用
Person & email アドレス:
Magnus Nystrom <magnus@rsasecurity.com>

Intended usage: COMMON

Change controller:
IESG <iesg@ietf.org>

9. 謝辞 English

著者陣は、TLS Working Group および WAP Security Group に感謝したい。本書は、これらのグループ内の検討に基づいている。

10. 規範的参考文献

Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, 1997年 2月.
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月.
Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1998年10月.
Faltstrom, P., Hoffman, P., and A. Costello,"Internationalizing Domain Names in Applications (IDNA)", RFC 3490, 2003年 3月.
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年 3月.
Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 2560, 1999年 6月.
Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, 1999年 5月.
Housley, R., Polk, W., Ford, W., and D. Solo,"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, 2002年 4月.
Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, 1999年 1月.
Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, 2006年 4月.
Berners-Lee, T., Fielding, R., and L. Masinter,"Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 2005年 1月.
Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, 2003年11月.
ITU-T Recommendation X.509 (2000) | ISO/IEC 9594-8:2001, "Information Systems - Open Systems Interconnection - The Directory: Public key and attribute certificate frameworks."
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.

 

11. 参考情報

Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, 2002年 6月.
Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, 1999年10月.
J. Mikkelsen, R. Eberhard, and J. Kistler, "General ClientHello extension mechanism and virtual hosting," ietf-tls mailing list posting, 2000年 8月14日.
Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, 2003年 6月.

 

著者のアドレス

Simon Blake-Wilson
BCI

EMail: sblakewilson@bcisse.com

Magnus Nystrom
RSA Security

EMail: magnus@rsasecurity.com

David Hopwood
Independent Consultant

EMail: david.hopwood@blueyonder.co.uk

Jan Mikkelsen
Transactionware

EMail: janm@transactionware.com

Tim Wright
Vodafone

EMail: timothy.wright@vodafone.com

翻訳者のアドレス

宮川 寧夫
独立行政法人 情報処理推進機構

EMail: miyakawa@go.go.jp

著作権表記全文

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.

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.

知的財産権

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.

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.

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.

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).