ネットワーク 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月

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

このメモの位置づけ

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

著作権表記

要旨

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

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

1. はじめに English

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

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

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

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

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

TLSクライアントがそのTLSサーバ宛に、問い合わせているそのサーバの名前を提供できるようにする。この機能は、基礎となっている(underlying)単一のネットワークアドレスにおいて複数の「バーチャル」サーバをホストするサーバへのセキュアな接続を容易にするために、渇望されている。
TLSのクライアントおよびサーバが送られるべき最大フラグメント長を交渉できるようにする。この機能は、何らかのクライアントにおけるメモリ制約、および、何らかのアクセスネットワークにおける帯域制約の結果として、渇望されている。
TLSクライアントおよびサーバがクライアント証明書URLの利用を交渉できるようにする。この機能は、制約のあるクライアント上のメモリを節約するために、渇望されている。
TLSクライアントがTLSサーバ宛に「どのCAルート鍵を保持しているか？」を示すことができるようにする。この機能は、メモリ制約に起因して、少数のCAルート鍵しか保管できないTLSクライアントを巻き込む複数のハンドシェイクの失敗を防ぐために、渇望されている。
TLSクライアントおよびサーバが切り詰められたMACの利用を交渉できるようにする。この機能は、制約されたアクセスネットワークにおける帯域を節約する(conserve)ために、渇望されている。
TLSクライアントおよびサーバが「サーバがクライアント証明書状態情報 (例： OCSP (Online Certificate Status Protocol) [OCSP] レスポンス)をTLSハンドシェイクにおいて送ること」を交渉できるようにする。この機能は、CRL (Certificate Revocation List)を制約されたアクセスネットワーク越しに送ることを避け、ひいては帯域を節約するために、渇望されている。

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

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

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

クライアントは、典型的には、 2.1節に記述された拡張されたclient helloメッセージを通じて拡張の利用を要する。 TLSは、サーバに、たとえ、そのサーバがその拡張を「解釈(understand)できない場合でも、拡張されたclient helloメッセージを受容することを要求する。
ここに記述された具体的な拡張について、クライアントが拡張された機能性をリクエストするとき、サーバレスポンスとして必須とされるものは無い。

要するに、下位互換性は、「"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;

ここで：

"extension_type"は、特定の拡張種別を識別する。
"extension_data"は、特定の拡張種別に固有の情報を納める。

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

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中に、ひとつ、もしくは、複数の定義された拡張種別を含むとき：

回復(resumption)リクエストが拒否される場合、その拡張の利用は、通常どおり(as normal)交渉される。
他方、古い方のセッションが中断された場合、そのサーバは、その拡張を無視し、拡張種別を納めないserver helloを送らなければならない(MUST)。この場合、当初のセッション開始において交渉されたこれらの拡張の機能は、その中断されたセッションに適用される。

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¹⁴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⁹、2¹⁰、2¹¹および2¹²である。

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

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

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

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

交渉された長さは、そのレコード層がフラグメンテーション無しに処理できるinputを制限する。 (すなわち、TLSPlaintext.lengthの最大値。 [TLS] 6.2.1節を参照。) 「レコード層のoutputは、より大きい可能性があること」に注意。例えば、交渉された長さが2⁹=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証明書が使われるとき、ふたつの可能性がある。：

CertificateURL.typeが"individual_certs"である場合、各URLは、まず、そのクライアントの証明書のURLをもつ単一のDERで符号化されたX.509v3証明書を参照する。
CertificateURL.typeが"pkipath"である場合、その一覧は、 8章に記述されている種別PkiPathを使ってDERで符号化された証明書チェーンを参照する単一のURLを納める。

あらゆる他の証明書フォーマットが使われるとき、 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ルート鍵は、下記のいずれかを通じて識別される。：

"pre_agreed"：: CAルート鍵アイデンティティは、提供されなかった。
"key_sha1_hash"：: これは、CAルート鍵のSHA-1ハッシュを含む。 DSA (Digital Signature Algorithm)およびECDSA (Elliptic Curve Digital Signature Algorithm)の鍵については、これは、 "subjectPublicKey"値のハッシュである。 RSA鍵について、そのハッシュは、いかなる初期ゼロ値バイトをももたない法(modulus)のビッグエンディアンbyte string表現である。 (これは、他の環境に配備された鍵ハッシュフォーマットをコピーする。)
"x509_name"：: これは、そのCAのDERで符号化されたX.509 DistinguishedNameを含む。
"cert_sha1_hash"：: これは、そのCAルート鍵を格納するDERで符号化された証明書のSHA-1ハッシュを含む。

「クライアントは、この拡張中にクライアントが保持する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)。

"unsupported_extension"：: この警告は、「対応するclient hello (2.3節を参照) を入れていない」という拡張を納めている拡張されたserver helloを受け取るクライアントによって送られる。このメッセージは、常にfatalである。
"unrecognized_name"：: この警告は、 server_name拡張リクエストを受け取るサーバによって送られるが、そのサーバ名を認識しない(の意)。このメッセージは、fatalである可能性がある(MAY)。
"certificate_unobtainable"：: この警告は、証明書チェーンをクライアントによってサポートされたURL (3.3節を参照) から取得できないサーバによって送られる。このメッセージは、fatalである可能性がある(MAY)。例えば、クライアント認証がハンドシェイクを継続するためにサーバによって要求されており、かつ、そのサーバがその証明書チェーンを取得できない場合、サーバは、fatal警告を送る可能性がある。
"bad_certificate_status_response"：: この警告は、不正な(invalid)証明書状態レスポンス(3.6節を参照)を受け取るクライアントによって送られる。このメッセージは、常にfatalである。
"bad_certificate_hash_value"：: この警告は、証明書ハッシュがクライアントが提供したcertificate_hashと一致しないとき、サーバによって送られる。このメッセージは、常にfatalである。

これらのエラー警告は、下記の構文(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)な攻撃者は、メッセージを改変し、拡張を挿入、削除もしくは置換できる」という事実を認識しておく必要がある。
拡張をTLSの設計の主要な見地(aspect)を変更するために使うことは、技術的には可能である。 (例：サイファースィート交渉の設計) これは、推奨されない。新しいバージョンのTLSを定義することが、より適切である。特段の理由は、「TLSハンドシェイクアルゴリズムは、バージョンロールバック攻撃に対して、そのバージョン番号に基づく特定の防護をもつから」である。バージョンロールバックの可能性は、あらゆる主要な設計変更において、顕著な考慮事項のひとつである必要がある。

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. 規範的参考文献

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

11. 参考情報

[AESSUITES]	Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, 2002年6月.
[KERB]	Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)", RFC 2712, 1999年10月.
[MAILINGLIST]	J. Mikkelsen, R. Eberhard, and J. Kistler, "General ClientHello extension mechanism and virtual hosting," ietf-tls mailing list posting, 2000年 8月14日.
[RFC3546]	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

著作権表記全文

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).

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