TLS Working Group Simon Blake-Wilson, BCI INTERNET-DRAFT Magnus Nystrom, RSA Security July 30, 2002 David Hopwood, Independent Consultant Expires January 30, 2003 Jan Mikkelsen, Transactionware Intended Category: Standards track Tim Wright, Vodafone Transport Layer Security (TLS) の拡張 このメモの位置付け このドキュメントはインターネットドラフトであり、RFC2026の第10章に記載 されているすべての条項に従う。インターネットドラフトは、Internet Engineering Task Force(IETF)とそのエリア、そしてそのワーキンググループ において作成中のドキュメントのことである。その他のグループが、作成中の ドキュメントをインターネットドラフトとして配布することも認められている。 インターネットドラフトは最大6ヶ月間有効で、その後アップデートや置き換え をすることができる。もしくは、他のドキュメントによりいつでも無効にする ことができる。インターネットドラフトを参考文献として引用すること、もし くは "work in progress" 以上の扱いで引用するのは適切ではない。 現在のインターネットドラフトは、次のところからアクセスすることができる。 http://www.ietf.org/ietf/1id-abstracts.txt インターネットドラフトのミラーサイトのリストは、次のところからアクセス することができる。 http://www.ietf.org/shadow.html. 要旨 本ドキュメントでは、TLSに機能追加を行うためのエクステンションについて 記述する。ここでは、TLSハンドシェイクにおけるClientHelloとServerHelloに 適用される汎用拡張メカニズムと、このメカニズムを使用するそれぞれのエクス テンションを規定する。 エクステンションは、TLSクライアントとサーバによって使用される。エクス テンションは下位互換性をもつ。すなわちエクステンションをサポートするTLS 1.0クライアントとサポートしていないTLS1.0サーバとの通信は可能であり、 またその逆も可能である。 本ドキュメントは、TLSワーキンググループとWAPセキュリティグループ内での 議論に基づいている。 本ドキュメントに現れるキーワード"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、 "SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、"OPTIONAL"は、 RFC2119 [KEYWORDS] で示されるように解釈されなければならない。 本ドキュメントに関するコメントは、TLSメーリングリストに投稿下さい。 目次 1. はじめに .................................................. 2 2. 汎用拡張メカニズム ........................................ 4 2.1. 拡張ClientHelloメッセージ ............................... 4 2.2. 拡張ServerHelloメッセージ ............................... 5 2.3. Helloメッセージの拡張 ................................... 6 2.4. ハンドシェイクプロトコルの拡張 .......................... 7 3. エクステンションの詳細 .................................... 7 3.1. サーバ名の提示 .......................................... 8 3.2. 最大フラグメント長のネゴシエーション .................... 9 3.3. クライアントの証明書URL ................................ 11 3.4. 信用しているCAの提示 ................................... 13 3.5. HMACのトランケート ..................................... 14 3.6. 証明書ステータス要求 ................................... 15 4. エラーアラート ........................................... 17 5. 新規エクステンションの定義方法 ........................... 19 6. セキュリティに関する考察 ................................. 20 6.1. server_nameのセキュリティ .............................. 20 6.2. max_fragment_lengthのセキュリティ ...................... 20 6.3. client_certificate_urlのセキュリティ ................... 20 6.4. trusted_ca_keysのセキュリティ .......................... 22 6.5. truncated_hmacのセキュリティ ........................... 22 6.6. status_requestのセキュリティ ........................... 22 7. 国際化に関する考察 ....................................... 22 8. IANAの考慮事項 ........................................... 23 9. 知的所有権 ............................................... 24 10. 謝辞 ..................................................... 24 11. 参考文献 ................................................. 24 12. 参考情報 ................................................. 25 13. 著者のアドレス ........................................... 26 1. はじめに 本ドキュメントでは、TLSに機能追加を行うためのエクステンションについて 記述する。ここでは、TLSハンドシェイクにおけるClientHelloとServerHelloで 使用される汎用拡張メカニズムと、そのメカニズムを使用したエクステンション を規定する。 TLSは現在、その適用範囲が拡大し、さまざまな環境で運用されている。それらの 多くは、TLSの設計基準が決められた時点では予測していなかった環境である。 本ドキュメントで規定するエクステンションは、無線ネットワークなどの新しい 環境において、TLSをできるだけ効果的に運用できるようにするものである。 無線を使用した環境では、有線環境では通常存在しない多くの制限がある場合 が多い。これらの制限としては、帯域幅制限、計算能力の制限、メモリ制限、 そしてバッテリーの寿命に関する制限などがある。 本ドキュメントで記述するエクステンションは、TLSプロトコルメッセージ フォーマットで提供される機能を拡張するものである。例えば新規暗号スイート の追加などの問題については、他のドキュメントに譲る。 特に、このドキュメントで記述されるエクステンションは以下の目的で設計され ている。 - TLSクライアントはTLSサーバに対し、アクセスしようとしているサーバ名を 提供可能とする。この機能は、ある1つのネットワークアドレスにおいて 複数の"仮想"サーバを運用しているサーバに対し、セキュアなコネクション を接続するのに必要とされている。 - TLSクライアントとサーバは、送信するデータの最大フラグメント長を ネゴシエーションすることができる。この機能は、クライアント側で メモリ量制限がある場合や、アクセスするネットワークに帯域幅制限が ある場合に必要とされている。 - TLSクライアントとサーバは、クライアント証明書URLの使用をネゴシエー ションすることができる。この機能は、制約のあるクライアントでのメモリ 使用量の浪費を避けるために必要とされている。 - TLSクライアントはTLSサーバに対し、保持しているCAルート鍵を示すこと ができる。この機能は、メモリ制限のためCAルート鍵を少ししか保持でき ないTLSクライアントにおいて、多数のハンドシェイクエラーの発生を 防ぐために必要とされている。 - TLSクライアントとサーバは、トランケートされたMACの使用に関する ネゴシエーションをすることができる。この機能は、アクセスするネット ワーク帯域幅の浪費を避けるために必要とされている。 - TLSクライアントとサーバは、TLSハンドシェイク中に証明書ステータス情報 (例えば OCSP [OCSP]レスポンスなど)をサーバがクライアントに送信 するか否かに関するネゴシエーションをすることができる。この機能は、 帯域幅制限のあるアクセスネットワーク上でCRLを送信することを避け、 帯域幅の使用量をセーブするために必要とされている。 上記のエクステンションをサポートするために、ClientHelloメッセージと ServerHelloメッセージに適用される汎用拡張メカニズムを導入する。 本ドキュメントで記述するエクステンションは、TLS1.0クライアントとTLS1.0 サーバで使用することができる。エクステンションは、下位互換性をもつように 設計されている。すなわち、エクステンションをサポートするTLS1.0クライ アントは、エクステンションをサポートしないTLS1.0サーバと通信を行うことが 出来る。またその逆も同様である。 下位互換性は主に、以下の2つの考察から実現されている。 - クライアントは通常、第2.1節で記述される拡張ClientHelloメッセージ によりエクステンションを含んだリクエストを送信する。TLS1.0 [TLS] では、サーバは拡張ClientHelloメッセージを"受理"することを要求 している。これは、エクステンションを"理解"出来ない場合にも適用 される。 - ここで記述されるエクステンションでは、クライアントが拡張機能をリク エストしたときに必須となるレスポンスは存在しない。 しかし、下位互換性がサポートされていても、制約のあるクライアントでは、 処理能力の限界から、エクステンションをサポートしていないサーバとの通信 を拒否しなければならなくなるかもしれない。 本ドキュメントは、以下のような構成としている。第2章では、ClientHelloと ServerHelloハンドシェイクメッセージの汎用拡張メカニズムについて記述する。 第3章では、TLS1.0のそれぞれのエクステンションについて記述する。第4章では、 TLSエクステンションで使用される新規エラーアラートについて記述する。最終 章では、IPR、セキュリティに関する考察、application/pkix-pkipathという MIMEタイプの登録、謝辞、そして参考文献について記述する。 2. 汎用拡張メカニズム この章では、TLSハンドシェイクのClientHelloやServerHelloメッセージにおける 汎用拡張メカニズムについて記述する。 これらの汎用拡張メカニズムは、クライアントとサーバが、指定されたエクス テンションを使用するか否か、使用するならばそれらをどのように使用するかに ついてネゴシエーションするために必要となる。ここで記述する拡張フォー マットは、[MAILING LIST]に基づいている。 第2.1節では、拡張ClientHelloメッセージフォーマットを規定する。第2.2節 では、拡張ServerHelloメッセージフォーマットを規定する。第2.3節では、 拡張ClientHelloまたは拡張ServerHelloで使用される実際のエクステンション フォーマットを記述する。 2.1. 拡張ClientHelloメッセージ クライアントは、ClientHelloメッセージフォーマットの代わりに拡張ClientHello メッセージフォーマットを送信することで、サーバに対し拡張機能を要求して もよい(MAY)。拡張ClientHelloメッセージフォーマットは以下である。 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節で定義される。 クライアントが、拡張ClientHelloメッセージを使用して追加機能をリクエスト しているが、その機能をサーバが提供していないときには、クライアントは ハンドシェイクを中断してもよい(MAY)。 [TLS]の第7.4.1.2節では、ClientHelloメッセージに対して追加情報を付加する ことを認めている。それゆえ上記で定義された拡張ClientHelloを使用しても、 現在のTLS 1.0サーバを「破壊する」ことはない。 拡張メカニズムをサポートしているサーバは、オリジナルもしくは拡張された フォーマットのClientHelloメッセージのみを受理しなければならない(MUST)。 そして(他のすべてのメッセージと同様)、メッセージのデータ量はそれらの フォーマットのどちらか一方と正確に一致していることをチェックしなければ ならない(MUST)。そうでない場合には、fatalレベルの"decode_error"アラート を送信しなければならない(MUST)。この仕様は[TLS]における"上位互換性"の項 の記述を更新するものである。 2.2. 拡張ServerHelloメッセージ クライアントが、第2.1節で規定される拡張ClientHelloメッセージを使用して サーバに対し拡張機能をリクエストしているときには、ServerHelloメッセージ の代わりに拡張ServerHelloメッセージフォーマットを送信してもよい(MAY)。 拡張ServerHelloメッセージフォーマットは以下である。 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節で定義される。 拡張ServerHelloメッセージは、拡張ClientHelloメッセージに対するレスポンス としてのみ送信されることに注意。これにより、拡張ServerHelloメッセージが、 現在のTLS1.0クライアントを「破壊する」可能性を防ぐ。 2.3. Helloメッセージの拡張 拡張ClientHelloと拡張ServerHelloにおけるExtensionのフォーマットは以下で ある。 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; すべてのエクステンション型(これは将来定義されるものも含む)では、 ClientHelloメッセージ内にそのエクステンションが含まれていない限り、 それに対応した拡張ServerHelloメッセージにはそのエクステンション型を 含めてはならない(MUST NOT)ことに注意。そのため、クライアントが (拡張)ClientHelloメッセージでリクエストしていないエクステンション型 を拡張ServerHelloメッセージで受信したときには、ハンドシェイクを中断 しなければならない(MUST)。 しかし将来、このフレームワークの範囲内で、"サーバから開始する"エクス テンションが提供されるかもしれない。その場合、クライアントは最初に 空エクステンションを送信することで、そのエクステンションをサポートして いることを示す。 異なった型をもつ複数のエクステンションが、拡張ClientHelloまたは拡張 ServerHelloに含まれているときには、エクステンションはどのような順序で 格納されていてもよいことにも注意。しかし同じ型のエクステンションが複数 含まれていてはならない(MUST NOT)。 本ドキュメントで定義されているすべてのエクステンションは、セションが 初期化されるときのみ関係することに注意。しかし、セションの再利用を要求 するクライアントでは通常、サーバでその再利用リクエストが受理されるか どうかを知らない。そのためセション再利用の際には、クライアントは新規 セション確立を要求する場合と同じ拡張ClientHelloメッセージを送信すべきで ある(SHOULD)。再利用リクエストが拒否されたときには、新規ネゴシエーション としてそれらのエクステンションが正しく処理される。もしそのリクエストが 受理されセションが再利用されたときには、サーバはClientHelloに含まれて いたエクステンションを無視しなければならず(MUST)、エクステンションを 含まないServerHelloメッセージを送信しなければならない(MUST)。この場合、 最初のセションの初期化中にネゴシエーションされたエクステンション機能が 再利用セションにも適用される。 2.4. ハンドシェイクプロトコルの拡張 本ドキュメントでは、2つの新規ハンドシェイクメッセージである"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; /* メッセージのバイト数 */ 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. エクステンションの詳細 この章では、本ドキュメントで規定されるTLSエクステンションの詳細を記述する。 TLSハンドシェイク中に送信される、これらのエクステンションが含まれている すべてのメッセージは、Finishedメッセージに含まれるハッシュ計算に含めな ければならない(MUST)ことに注意。 第3.1節では、クライアントがどのサーバにアクセスしようとしているかを 提示するためのTLSエクステンションを記述する。第3.2節では、最大フラグ メント長をネゴシエーションするためのエクステンションを記述する。 第3.3節では、クライアント証明書URLを提示するためのエクステンションを 記述する。第3.4節では、クライアントがどのCAルート鍵を保持しているかを 提示するためのエクステンションを記述する。第3.5節では、トランケート されたHMACを使用するためのエクステンションを記述する。第3.6節では、 証明書ステータス情報メッセージをTLSハンドシェイクに組み込むための エクステンションを記述する。 3.1. サーバ名の提示 [TLS] には、クライアントがアクセスしようとしているサーバ名をサーバに通知する ためのメカニズムが存在しない。そのためクライアントが、1つのネットワーク アドレス上で動作している複数の「仮想的な」サーバのうちのどのサーバにセキュア なコネクションを接続しようとしているのか、という情報の提供が必要とされている。 サーバ名を提供するために、クライアントは(拡張)ClientHelloメッセージに おいて"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ホスト名である。しかしこれは TLSがDNSに依存しているということを意味するものではなく、将来において 他の名称型を追加してもよい(名称型の追加は、本ドキュメントをアップ デートするRFCによって行われる)。TLSでは、提供されるサーバ名をopaque型 のデータとして処理し、名前と型をそのままアプリケーションに渡してもよい (MAY)。 "HostName"には、クライアントが理解している、サーバの完全修飾DNSホスト名 が格納される。ホスト名はUTF-8エンコーディング[UTF8]を使用したバイト文字列 として表記される。ホスト名の最後には"."が付加されない。(各国の言語を 使用しているホスト名のエンコードにUTF-8を使用するのは、DNSプロトコルに おけるこれらの名前のエンコード方式の選択とは無関係であることに注意。 DNSプロトコルでのエンコード方式選択は、IETFのInternationalized Domain Name Working Group [IDNWG] ではまだ決定していない。 サーバにおいて、ASCII文字以外が含まれているサーバ名とHostNameをマッチング する必要があるならば(すなわち、1つ以上の仮想ホスト名が各国の言語を使用 しているならば)、IDN Working Group で定義される名称マッチングルールの 適用を考慮しなければならない(MUST)。サーバにおいて、ASCII文字のみが含まれ ているサーバ名とHostNameをマッチングする場合には、128以上のバイト値が 含まれるHostNameを、ASCII名とマッチングしてはならず(MUST NOT)、ASCII名の 大文字小文字は区別しないようにしなければならない(MUST)。 IPv4とIPv6アドレスを文字列で表したものは"HostName"の値としては認められない。 クライアントは、サポートしている名称型を使用してサーバを指定するとき には常に、ClientHelloメッセージ内に"server_name"型のエクステンションを 含めることが推奨される(RECOMMENDED)。 "server_name"エクステンションを含んだClientHelloを受信したサーバは、 クライアントに返送する適切な証明書や他のセキュリティポリシーを選択 するためのガイドとして、そのエクステンションに含まれている情報を使用 してもよい(MAY)。このとき、サーバは"server_name"型のエクステンションを (拡張)ServerHelloメッセージに含めるべきである(SHALL)。このエクステン ションの"extension_data"フィールドは空であるべきである(SHALL)。 サーバではClientHelloエクステンションを理解できるものの、受信した サーバ名を識別できないときには、サーバは"unrecognized_name"アラート (これはfatalとしてもよい(MAY))を送信すべきである(SHOULD)。 アプリケーションが、アプリケーションプロトコルを使用してサーバ名を ネゴシエーションし、TLSへアップグレードした後、server_nameエクス テンションを送信したときには、そのエクステンションにはアプリケーション プロトコルでネゴシエーションしたサーバ名と同じものを含むべきである (SHOULD)。TLSセションハンドシェイクにおいてserver_nameが確立された ときには、クライアントはアプリケーション層上にある他のサーバ名をもつ サーバへリクエストしようとすべきではない(SHOULD NOT)。 3.2. 最大フラグメント長のネゴシエーション [TLS]では、平文フラグメント長の最大は2^14バイト固定として規定されている。 しかしリソースの使用に制約のあるクライアントにおいては、メモリ量制限や 帯域幅制限から、より小さいフラグメント長のネゴシエーションが必要と されている。 より小さい最大フラグメント長をネゴシエーションするために、クライアントは (拡張)ClientHelloメッセージに"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"エクステンションを含んだ拡張ClientHelloを受信した サーバは、(拡張)ServerHelloメッセージに"max_fragment_length"型の エクステンションを含めることで、リクエストされた最大フラグメント長 を受理したことを示してもよい(MAY)。このエクステンションの"extension_data" フィールドには、リクエストされた最大フラグメント長と同じ値を含めた "MaxFragmentLength"を含めるべきである(SHALL)。 最大フラグメント長ネゴシエーションにおいて、認められない値が指定された リクエストをサーバが受信したときには、"illegal_parameter"アラートに よりハンドシェイクを中断しなければならない(MUST)。同様に、最大フラグ メント長ネゴシエーションにおいて、リクエストした値とは異なる値が指定 されたレスポンスをクライアントが受信したときには、"illegal_parameter" アラートによりハンドシェイクを中断しなければならない(MUST)。 2^14以外の値をもつ最大フラグメント長のネゴシエーションに成功すると、 クライアントとサーバはすぐに、フラグメント処理されたメッセージ(これには ハンドシェイクメッセージも含む)を開始しなければならない(MUST)。これに よりネゴシエーションされた長さ以上にフラグメントされたメッセージが送信 されないことを確認する。TLSではクライアントとサーバに対し、フラグメント されたハンドシェイクメッセージのサポートをすでに要求していることに注意。 ネゴシエーションされた長さは、セション再利用のケースを含め、セションの 生存期間を通して適用される。 ネゴシエーションされた長さにより、レコード層に対して入力されるデータが、 フラグメントなしで処理される長さ(すなわち、TLSPlaintext.lengthの最大値: [TLS]の第6.2.1節参照)が制限される。レコード層から出力されるデータサイズ はこれより長くなってもよいことに注意。例えば、ネゴシエーションされた長さ が2^9=512であり、また現在定義されている暗号スイート([TLS]、[KERB]、 そして追加予定になっているAES暗号スイート)を使用している場合、そして 圧縮処理としてnullが使用されている場合、レコード層からの出力は最大でも 793バイトである。内訳は、5バイトのヘッダ、512バイトのアプリケーション データ、256バイトのパディング、そして20バイトのMACである。すなわちこの 場合、TLSレコード層メッセージとして793バイトより長いデータを受信した TLSレコード層ピアは、メッセージを復号することなく読み捨て、 "record_overflow"アラートを送信してもよい。 3.3. クライアントの証明書URL [TLS]では、TLSハンドシェイクにおいてクライアント認証を行う際、クライ アントはサーバに対してクライアント証明書を送信することになっている。 しかし制約のあるクライアントでは、証明書の代わりに証明書URLを送信する ことが要求されている。これにより、クライアントは証明書を保持する必要が なく、それゆえメモリを節約することができる。 証明書URLを送信することをサーバとネゴシエーションするために、クライ アントは(拡張)ClientHelloメッセージにおいて、"client_certificate_url" 型のエクステンションを含めてもよい(MAY)。このエクステンションの "extension_data"フィールドは空であるべきである(SHALL)。 (現状のTLS1.0サーバを「破壊」しないために、クライアント証明書URLの ネゴシエーションをする必要があることに注意。) "client_certificate_url"エクステンションを含んだ拡張ClientHelloを受信した サーバは、(拡張)ServerHelloメッセージにおいて"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証明書を使用する場合には、以下の2つのケースが考えられる。 - CertificateURL.typeが"individual_certs"のときは、それぞれのURLには、 DERエンコードされた1つのX.509v3証明書を示す値が含まれる。URLは、 クライアント証明書から順にリストされる。 - CertificateURL.typeが"pkipath"のときには、DERエンコードされた証明書 チェーンを示すURLが1つ含まれる。証明書チェーンは第8章で示される PkiPath型を使用したものである。 他の証明書フォーマットを使用するときには、その仕様書において、証明書 や証明書チェーンのエンコーディングフォーマット、その送信順序制限に ついて定義すべきである。 それぞれのURLに関するハッシュについては、ハッシュを含めないか、または 証明書もしくは証明書チェーン(X.509証明書の場合には、DERエンコードされた 証明書もしくはDERエンコードされたPkiPath)のSHA-1ハッシュを含めるかの どちらかを、クライアントが自由に決定することができる。 X.509証明書のURLリストを含めたときには、それらのURLの格納順序は、TLSの Certificateメッセージでの順序([TLS]の第7.4.2節参照)と同じであるが、 PkiPathでエンコードした証明書の場合とは逆順であることに注意。どちらのケース でも、自己署名されたルート証明書はチェーンから省略してもよい(MAY)。この 場合、サーバはすでにその証明書を保持しており、証明書チェーンを検証すること ができることを仮定している。 "CertificateURL"メッセージを受信したサーバは、URLからクライアントの証明書 チェーンを取得しようとし、そして証明書チェーンを通常通り処理すべきである (SHALL)。URLのコンテンツをキャッシュしたもののコピーを使用してもよい(MAY)。 ただしこれは、そのURLのコンテンツのSHA-1ハッシュ値が提供されており、かつ キャッシュされているもののコピーのハッシュ値がそれと一致した場合である。 このエクステンションをサポートするサーバは、証明書URL用に http: URL スキームをサポートしなければならない(MUST)。さらに他のスキームをサポート してもよい(MAY)。 証明書もしくは証明書チェーンを取得するのに使用するプロトコルが、MIMEで フォーマットされたレスポンス(通常HTTPで行われているものと同様なもの) を返信する場合には、以下のMIME Content-Type を使用すべきである(SHALL)。 1つのX.509v3証明書が返送される場合には、Content-Typeは "application/pkix-cert" [PKIOP] であり、X.509v3証明書チェーンが返送される 場合には、Content-Typeは"application/pkix-pkipath"(第8章参照)である。 URLにSHA-1ハッシュが付加されているときは、サーバは、そのURL(これはMIME Content-Transfer-Encodingのデコードを行った後のもの)の内容をSHA-1ハッシュ した値と、メッセージに含まれていたハッシュ値が一致しているか否かをチェック しなければならない(MUST)。正しいSHA-1ハッシュが含まれていなかった場合 には、サーバはハンドシェイクを中断し、"bad_certificate_hash_value" アラートを送信しなければならない(MUST)。 クライアントは、証明書URLを送信することをネゴシエーションした後、 "Certificate"または"CertificateURL"メッセージのどちらを送信してもよい ことに注意。証明書を送信するという選択肢が含まれているのは、複数の証明書 を保持しているクライアントへの配慮である。 CertificateURLからの証明書取得に不当に長い時間を要した場合には、サーバは タイムアウトし、"certificate_unobtainable"エラーアラートを送信すべきである (SHOULD)。 3.4. 信用しているCAの提示 制約のあるクライアント、例えばメモリ使用量に制限がある、または少数の CAルート鍵のみ保持できるクライアントでは、保持しているルート鍵をサーバに 提示することで、ハンドシェイクエラーを繰り返すことを防ぎたいと考える かもしれない。 どのCAルート鍵を保持しているかを示すために、クライアントは(拡張) ClientHelloメッセージにおいて"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ルート鍵 識別子のリストを含める。それぞれのCAルート鍵は、以下に示す方法のうちの 1つにより特定される。 - "pre_agreed" - CAルート鍵識別子は含まれていない。 - "key_sha1_hash" - CAルート鍵のSHA-1ハッシュが含まれている。 DSAとECDSA鍵では、これは"subjectPublicKey"値のハッシュである。 RSA鍵では、先頭に0値詰めされていないモジュラスをビッグエンディアン 形式のバイト文字列で表した値のハッシュである。(これにより、他の 規定により適用された鍵ハッシュフォーマットもコピーすることになる。) - "x509_name" - X.509で表されたCA証明書のDistinguishedNameをDERエン コードしたもの。 - "cert_sha1_hash" - CAルート鍵が含まれている、DERエンコード形式の 証明書のSHA-1ハッシュ値が含まれている。 クライアントはエクステンションに対し、所有しているCAルート鍵を1つも含め なかったり、そのうちのいくつかを含めたり、もしくはすべてを含めてもよい。 鍵ハッシュ値もしくはDistinguishedNameのみでは、証明書の発行者を特定する 事ができないことにも注意。例えばある1つのCAが複数の鍵ペアを持っている 場合には特定できない。しかしこれはDistinguishedNamesを使用して証明書 発行者を特定しようとする場合である。 CAルート鍵を含めない、というオプションは、あらかじめ定義されたCAルート鍵 セットをクライアントが所有していることを示す。 "trusted_ca_keys"エクステンションを含むClientHelloを受信したサーバは、 クライアントに返送する適切な証明書チェーンを選択するためのガイドとして、 そのエクステンションに含まれている情報を使用してもよい(MAY)。このとき、 サーバは"trusted_ca_keys"型のエクステンションを(拡張)ServerHello メッセージに含めるべきである(SHALL)。このエクステンションの"extension_data" フィールドは空であるべきである(SHALL)。 3.5. HMACのトランケート 現在定義されているTLSの暗号スイートでは、レコード層での通信を認証する ために、MD5またはSHA-1とHMAC [HMAC] の組み合わせを使用したMAC構造を 採用している。TLSでは、このハッシュ関数の出力値のすべてをMACタグとして 使用している。しかし制約条件のある環境においては、帯域幅をセーブする ため、MACタグを計算した際にハッシュ関数の出力値の一部を切り捨てて 80ビットにすることが要望されている。 80ビットにトランケートされたHMAC値を使用する、というネゴシエーションを行う ために、クライアントは拡張ClientHelloメッセージに"truncated_hmac"型の エクステンションを含めてもよい(MAY)。このエクステンションにおける "extension_data"フィールドの値は空であるべきである(SHALL)。 "truncated_hmac"エクステンションを含んだ拡張ClientHelloメッセージを受信した サーバは、拡張ServerHelloメッセージにおいて"truncated_hmac"型のエクス テンションと、空の"extension_data"を含めることで、トランケートされたHMACの 使用に同意してもよい(MAY)。 もし新規暗号スイートが追加され、それらがHMACを使用せず、さらにセションの ネゴシエーションにおいてそれらの暗号スイートの1つが選択されたときには、 このエクステンションには何の効果もないことに注意すべきである。他のMACを 使用するすべての新規暗号スイートでは、整数値で示されたMACサイズを暗号 スイート定義の一部に含め、セキュリティと帯域幅に関する考察を行うことを 強く推奨する。 TLSハンドシェイクにおいて、HMACをトランケートすることが正しくネゴシ エーションされ、ネゴシエーションされた暗号スイートがHMACを使用している ならば、クライアントとサーバは、ネゴシエーションされた他のセキュリティ パラメータと共に、このことをTLSレコード層に通知する。そのセションでは それ以降、クライアントとサーバは [HMAC] で示された方法を使用して計算される HMAC値をトランケートした値を使用しなければならない(MUST)。すなわち、 CipherSpec.hash_sizeは10バイトであり、HMACからの出力の最初の10バイトのみ が送信され、検証される。ただしこのエクステンションは、ハンドシェイク または鍵生成処理におけるPRFの計算には影響しないことに注意すべきである。 ネゴシエーションされたHMACのトランケーションサイズは、セション再利用の 場合も含め、セションの生存期間を通して適用される。 3.6. 証明書ステータス要求 TLS処理に制約のあるクライアントでは、OCSP [OCSP] のような証明書 ステータスプロトコルを使用してサーバ証明書の有効性を検証することで、 CRLの転送を避け、制約のあるネットワークでの帯域使用量をセーブしたいと 考えるかもしれない。ここで示すエクステンションを使用することで、 これらの情報をTLSハンドシェイク中に送信することができ、別リクエスト 処理を避けリソース使用量をセーブすることができる。 クライアントが、証明書ステータス情報を要望していることを示すために、 クライアントは(拡張)ClientHelloメッセージにおいて"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_id_list"の長さがゼロである ときには、例えば以前行った通信などにより、レスポンダの情報はサーバが すでに知っていることを表す特別な意味がある。"Extensions"は、OCSP リクエストエクステンションをDERエンコーディングしたものである。 "ResponderID"と"Extensions"は、[OCSP] で定義されているように、ASN.1を DERエンコードしたものである。"Extensions"は、[PKIX] から導入したもので ある。"request_extensions"の長さがセロであるときには、エクステンションが 存在しないことを意味する(これはASN.1 SEQUENCEとは異なる:こちらは "Extensions"型としては無効なものである)。 "id-pkix-ocsp-nonce" OCSPエクステンションの場合、[OCSP] ではそのエン コーディング方法が規定されていない。これを明確にするために、nonceは OCTET STRINGをDERエンコードしたものでなければならない(MUST)ものとする。 これは他のOCTET STRINGと同様にカプセル化される(現状のOCSPクライアント 実装では、この要求事項に準拠するために値のチェックをすることになる)。 "status_request"エクステンションを含んだClientHelloメッセージを受信した サーバは、自身の証明書と共に、適切な証明書ステータスレスポンスをクライ アントに返送してもよい(MAY)。OCSPが要求されているならば、サーバはOCSP レスポンダの選択の際にはそのレスポンダの情報を使用すべき(SHOULD)であり、 そしてOCSPリクエストにはrequest_extensionsを含めるべきである(SHOULD)。 "Certificate"メッセージの送信直後(かつ"ServerKeyExchange"の前、もしくは "CertificateRequest"メッセージの前)に"CertificateStatus"メッセージを 送信することで、サーバは自身の証明書と共にOCSPレスポンスを返信する。 もしサーバが"CertificateStatus"メッセージを返信する場合、サーバは拡張 ServerHelloメッセージに"status_request"型のエクステンションを含め、 "extension_data"を空としなければならない(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のOCSPResponse型を使用する)が含まれている。 OCSPレスポンスは1回のみ送信されることに注意すべきである。 "CertificateStatus"メッセージは、ハンドシェイクにおける"certificate_status" メッセージを使用して送信される。 サーバは、ClientHelloメッセージにより"status_request"エクステンションを 受信したとしても、"CertificateStatus"メッセージを送信しないことを選択 してもよい(MAY)ことに注意すべきである。 サーバは、ClientHelloメッセージにより"status_request"エクステンションを 受信していない限りは、"CertificateStatus"メッセージを送信してはならない (MUST NOT)ことにも注意すべきである。 OCSPレスポンスを要求し、CertificateStatusメッセージによりOCSPレスポンスを 受信したクライアントは、OCSPレスポンスを検証しなければならず、またその レスポンスが満足いくものでなければハンドシェイクを中断しなければならない (MUST)。 4. エラーアラート この章では、本ドキュメントで定義されるTLSエクステンションで使用する 新規エラーアラートを定義する。 以下の新規エラーアラートが定義される。現存するクライアントとサーバを 「破壊する」ことを避けるために、これらのアラートは、拡張Helloメッセージ を送信したパーティーが、通信相手から拡張Helloメッセージを受信していない 限り、送信してはならない(MUST NOT)。 - "unsupported_extension" - このアラートは、ClientHelloには含まれて いないエクステンションが拡張ServerHelloに含まれていた場合に、クライ アントから送信される(第2.3節を参照)。このメッセージは常にfatalで ある。 - "unrecognized_name" - このアラートは、server_nameエクステンション リクエストを受信したが、そのサーバ名が識別できない場合にサーバ から送信される。このメッセージはfatalとしてもよい(MAY)。 - "certificate_unobtainable" - このアラートは、クライアントから提供 されたURLから証明書チェーンを取得できなかった場合にサーバから送信 される(第3.3節を参照)。このメッセージはfatalとしてもよい(MAY)。 例えば、ハンドシェイクにおいてサーバによりクライアント認証が要求 されているが、そのサーバが証明書チェーンを取得できなかった場合には、 fatalレベルのアラートを送信してもよい。 - "bad_certificate_status_response" - このアラートは、無効な証明書 ステータスレスポンスを受信した場合にクライアントから送信される (第3.6節を参照)。このメッセージは常にfatalである。 - "bad_certificate_hash_value" - このアラートは、証明書のハッシュ値が クライアントが提供したcertificate_hash値と一致しない場合にサーバ から送信される。このメッセージは常にfatalである。 これらのエラーアラートは、以下の構文を使用する。 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. 新規エクステンションの定義方法 インターネットプロトコルでは伝統的に、Internet Assigned Numbers Authority (IANA)において新しい値の割り当て処理を取り扱い、そしてIANAで行われる処理 手順は通常RFCで定義する。しかし、そのプロトコルの現在の機能と新規機能との 間で些細な(時には重要な)相互作用が発生し、その結果として全体的なセキュリ ティレベルの低下を招く可能性がある。 そのため、(エクステンションと新規エラーアラート値の割り当てを含む) 新規エクステンションを定義しようとするときは、IANAへの登録処理だけでなく IETFのTLSワーキンググループにおいても議論されるべきである。 新規エクステンションを設計する際には、以下の点を考慮すべきである。 - 本ドキュメントで定義されるすべてのエクステンションでは、クライアント がエクステンションを送信しサーバがそれを受理した場合は、サーバは 同じ型のエクステンションを返信する、という規定に従っている。 - あるエクステンションの使用をサーバが受理しないというケースや、ある 特定の機能のサポートをサーバが拒否するケースがある。前者の場合は エラーアラートを使用すべきであり、後者の場合はエクステンションに 対するサーバからのレスポンスフィールドを使用する。 - ハンドシェイクメッセージに細工をすることである機能を強制的に使用 させる(または使用させない)、という攻撃を防ぐようなエクステンション の設計を、できる限り行うべきである。その機能がセキュリティ問題を 引き起こす可能性があるないに関わらずこの原則に従うべきである。 エクステンションフィールド値がFinishedメッセージのハッシュ値に含ま れることには問題はないが、ただしそのエクステンションがハンドシェイク フェーズで送信されるメッセージの意味を変更するような場合には、 十分な注意が必要である。設計者と実装者は、ハンドシェイクが認証され るまで、能動的な攻撃者はメッセージを修正してエクステンションを 挿入し、削除し、他のものに変更することができるという事実を理解 すべきである。 - 技術的には、エクステンションによりTLS設計の中心的な機能を変更する ことができる。例えば、暗号スイートネゴシエーションの設計などである。 しかしこれは推奨されない。この場合TLSの新しいバージョンを定義する方 が適切であろう。これは、TLSハンドシェイクアルゴリズムではバージョン 番号に基づくバージョンロールバック攻撃に対する保護を行っており、 またバージョンロールバック攻撃の可能性は、設計変更の際には重要な 考慮事項であるからである。 6. セキュリティに関する考察 前節までは、拡張メカニズムに関するセキュリティの考察と、それぞれのエクス テンションの設計について記述した。以下では、それぞれのエクステンションに 関するセキュリティ分析を行う。 実装者は最新情報をチェックし続け、確認された問題点は公表すべきである。 セキュリティに関するさらなる考察は、TLS1.0のRFC [TLS] で行われている。 6.1. server_nameのセキュリティ ある1つのサーバが複数のドメインを持っている場合、それぞれのドメインの オーナーは、そのサーバがセキュリティニーズを満たしているかを確認する 必要があるのは明らかであろう。またこれとは別に、server_nameを使用する ことにより重要なセキュリティ問題が引き起こされることはないようである。 実装者は、server_nameの長さフィールドがどのような値であっても、バッファ オーバーフローが発生しないよう確認しなければならない(MUST)。 6.2. max_fragment_lengthのセキュリティ 最大フラグメント長はすぐに有効化される。すなわちハンドシェイクメッセージ にも適用される。しかしそれでも、現存のTLSには存在していなかったセキュリ ティ問題が新たに引き起こされることはない。なぜなら[TLS]では、フラグメント されたハンドシェイクメッセージを処理することのできる実装をすでに要求して いるからである。 第3.2節で記述されているように、NULL以外の暗号スイートが選択されたとき には、実際に有効となる最大フラグメント長は、ネゴシエーションされた max_fragment_lengthに加え、その暗号スイートと圧縮方法にも依存する。 これはバッファサイズを決定するときやバッファオーバーフローをチェック する際には考慮に入れておかなければならない。 6.3. client_certificate_urlのセキュリティ このエクステンションの使用に際して最も問題になることは、クライアントが 証明書URLを送信するとき、証明書ハッシュ値を含むべきであるか否かという ことである。 クライアント認証がclient_certificate_urlエクステンション「なし」で 行われるときには、クライアント証明書チェーンはFinishedメッセージ内の ハッシュ値に含まれる。証明書ハッシュ値をFinishedメッセージに含めておき、 補完された証明書チェーンとの比較を行う目的は、このエクステンションが 使用されたとき、クライアントとサーバが同じプロパティを保持していること を確認するためである。すなわちサーバ側で補完された証明書チェーン中の すべての情報は、クライアントが意図しているものと一致していることを確認 するためである。 逆に、証明書ハッシュ値を含めないようにすることで、いくつかの環境で必要 とされている機能が実現される。例えば、クライアントに対し1日1回証明書を 発行してある決まったURLに格納することで、クライアントに証明書を提供する 必要がなくなる、などである。証明書ハッシュ値を含めないことを選択した クライアントは、クライアントが提供しようと意図している証明書とは異なる クライアント鍵に対応する有効な証明書を攻撃者が入手するという攻撃の可能性 があることを知っておくべきである。 また、インターネットではキャッシュを行うHTTPプロキシがよく使用されている が、プロキシの中にはそのオブジェクトが最新バージョンであるかどうかを 正しくチェックしないものがあることに注意。HTTP(またはキャッシュ処理 が行われる他のプロトコル)によるリクエストに対する設定がおかしい、もしくは プロキシがきちんと機能していない場合では、プロキシは古いデータを応答する かもしれない。 TLSではMD5とSHA-1ハッシュを至るところで使用しているが、ここではそこまで 必要ないと考えられる。SHA-1が必要とされるのは、2次的な対抗策のためである。 client_certificate_urlをサポートすることは、同時にサーバが他のプロト コル(通常はHTTPであるが、他のURLスキームの使用も禁止されてはいない) のクライアントとなることも意味する。それゆえ誰でもアクセスが可能なHTTP プロキシサーバに適用されるものと同じセキュリティに関する考察が適用 される。この考察には、攻撃者が他のホストに存在するあるセキュリティ問題 に対する間接攻撃を行うためにサーバを使用する可能性があるということが 含まれる。また、サービス拒否攻撃にさらされることが多くなることも含まれる。 攻撃者は多くの接続を行うことで、サーバはそれぞれの接続に対応するHTTPリク エストを行うことになる。 サーバは、ファイアーウォールの内側またはその他のインターネットから直接的 にはアクセスできないホスト上に存在することがあることに注意。これは他の 方法により外部から隠されている内部ホストの存在を確認することが可能となる ことに加え、上記のセキュリティ問題やサービス拒否問題を悪化させる可能性が ある。 client_certificate_urlエクステンションは、デフォルトで使用可能とする のではなく、サーバ管理者が明示的に指定することで使用可能となるように することが推奨される(RECOMMENDED)。 [URI] で議論されているように、デフォルトポート番号以外のポートを指定 しているURLでは問題が発生する可能性がある。問題が発生するのは非常に 長いURLを使用したときである(ただしこれはバッファオーバーフローバグ を見つけるにも役に立つようではあるが)。 6.4. trusted_ca_keysのセキュリティ どのCAルート鍵をクライアントが保持しているかという情報は、機密情報と 見なすことができる。そのため、CAルート鍵提示エクステンションは十分に 注意して使用しなければならない。 このエクステンションにおいて、証明書のSHA-1ハッシュ値を使用すれば、それ ぞれの証明書は曖昧さなしに指定されたことを確認することが出来る。前記の エクステンションと同様、MD5とSHA-1の両方のハッシュ値を使用する必要は ないと考えられる。 6.5. truncated_hmacのセキュリティ トランケートされたMACは、"トランケートされていない"MACよりも弱い可能性 がある。しかし、MD5またはSHA-1を使用したHMACを80ビットにトランケート したとしても、現在のところ知られているまたは予測されている重要な弱点 は存在しない。MACの出力長は対称暗号鍵長と同じ長さである必要はないことに 注意。これは、MAC値の偽造はオフラインでは実行できないからである。TLS では、片方の通信端でMAC値の検証に失敗すると、TLSセションがすぐに終了 されることになる。 MACアルゴリズムは、Finishedメッセージ内のハッシュ値によりハンドシェイク メッセージの認証が行われた後に有効とされるため、能動的な攻撃者が、 トランケートされたHMACが適用されない箇所でトランケートHMACをネゴシエー ションさせることはできない(ただしハンドシェイクの認証がセキュアである 範囲内である)。それゆえ、トランケートされたHMACにおいて将来セキュリティ 問題が発見され、クライアントまたはサーバがその問題を考慮してセションの アップデートを行ったときには、このエクステンションの使用を拒否することが できる。 6.6. status_requestのセキュリティ クライアントがOCSPレスポンスを要求した場合、漏洩した鍵を利用している 攻撃者のサーバでは、このエクステンションをサポートしていないふりをする ことができる(そしておそらくそのようなふりをするであろう)ことを考慮 しておかなければならない。このような場合、証明書のOCSP検証を要求して いるクライアントは、OCSPサーバに直接アクセスするか、ハンドシェイクを 中断すべきである(SHOULD)。 OCSPのnonceリクエストエクステンション(id-pkix-ocsp-nonce)を使用すれば、 OCSPレスポンスのリプレイ攻撃に対するセキュリティが改善されるであろう。 詳細は [OCSP] の第4.4.1節を参照のこと。 7. 国際化に関する考察 ここで定義されているすべてのエクステンションでは、地域性に影響される ような文字コードを直接的には使用していない。DNSホスト名はUTF-8を使用 してエンコードされている。将来において、テキスト文字を使用するエクス テンションの定義を行う場合には、それらの設計を行う際に国際化に関する 考察を行うべきである。 8. IANAの考慮事項 MIMEタイプ"application/pkix-pkipath"を、以下のテンプレートで登録する。 To: ietf-types@iana.org Subject: MIMEメディアタイプ application/pkix-pkipath の登録について MIMEメディアタイプ名: application MIMEサブタイプ名: pkix-pkipath 必要とされるパラメータ: なし オプショナルパラメータ: version (デフォルト値は "1") エンコーディングに関する考察: このMIMEタイプは、ASN.1のPkiPath型をDERエンコーディングしたもの である。PkiPath型は以下のように定義される。 PkiPath ::= SEQUENCE OF Certificate PkiPathは、証明書パスを示すのに使用される。そのシーケンス内での 証明書の順序は、最初の証明書は次の証明書の発行者であるように するものである。 これは [X509-4th-TC1] で規定された定義と同じである。[X509-4th] とは異なることに注意。 すべての証明書は、[PKIX] に従ったものでなければならない(MUST)。 (これはすなわち、このMIMEタイプを使用するときは、PKIXに準拠した 証明書のみを使用してエンコードすることが要求されていると理解 すべきである。厳密には、PKIX準拠でない証明書を拒否しなければなら ないことを意味しているわけではないが、そのような証明書を受理する ことに関するセキュリティ上の重要性については慎重に考慮すべきで ある。) (BERではなく)DERエンコーディングを使用しなければならない(MUST)。 このタイプを7ビット転送路で送信する際には、base64エンコーディングを 適用すべきである(SHOULD)。 セキュリティに関する考察: [X509-4th] と [PKIX] (もしくはこれらをアップデートしたもの)の セキュリティに関する考察や、このMIMEタイプを使用するプロトコル (例えばTLS)の考察が適用される。 このMIMEタイプは、通信を行っているパーティーが信用しているCAに 関し、有効性を検証することのできる証明書チェーンを規定すること のみを意図しており、信用しているCAの変更を示すという使用目的は 意図していない。 相互運用に関する考察: 相互運用に関する問題は特に知られていない。しかしX.509証明書に関する 一般的な推奨事項が適用される。[PKIX] を参照。 公開されている仕様書: 本メモと [PKIX]。 このメディアタイプを使用するアプリケーション: TLS 他のプロトコルや、PKIX証明書チェーンの一般的な交換で使用してもよい。 備考: マジックナンバー: DERエンコードされたASN.1は容易に認知可能である。 他のASN.1型と区別するにはさらなる解析が必要である。 ファイル拡張子: .pkipath Macintoshのファイル型コード: 規定なし 問い合わせ者とそのメールアドレス: Magnus Nystrom 意図している使用方法: COMMON 著者/変更管理者: Magnus Nystrom 9. 知的所有権 IETFでは、本ドキュメントを実装するために必要となる技術をカバーする著作権、 特許または特許申請、またはその他の知的所有権に関し、これらの権利を持つ パーティーからの情報提供を要請している。情報に関しては、IETFのExecutive Directorに連絡下さい。 10. 謝辞 TLSワーキンググループとWAPセキュリティグループに感謝する。このドキュ メントは、2つのグループ内での議論に基づいている。 11. 参考文献 [HMAC] H. Krawczyk, M. Bellare, and R. Canetti, "HMAC: Keyed-hashing for message authentication," IETF RFC 2104, February 1997. [HTTP] J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1," IETF RFC 2616, June 1999. [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels," IETF RFC 2119, March 1997. [OCSP] M. Myers, R. Ankney, A. Malpani, S. Galperin, and C. Adams, "Internet X.509 Public Key Infrastructure: Online Certificate Status Protocol - OCSP," IETF RFC 2560, June 1999. [PKIOP] R. Housley and P. Hoffman, "Internet X.509 Public Key Infrastructure - Operation Protocols: FTP and HTTP," IETF RFC 2585, May 1999. [PKIX] R. Housley, W. Polk, W. Ford, and D. Solo, "Internet Public Key Infrastructure - Certificate and Certificate Revocation List (CRL) Profile", IETF RFC 3280, April 2002. [TLS] T. Dierks and C. Allen, "The TLS Protocol - Version 1.0," IETF RFC 2246, January 1999. [URI] T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax," IETF RFC 2396, August 1998. [UTF8] F. Yergeau, "UTF-8, a transformation format of ISO 10646," IETF RFC 2279, January 1998. [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. 12. 参考情報 [IDNWG] IETF Internationalized Domain Name Working Group, http://www.i-d-n.net/ [KERB] A. Medvinsky and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)," IETF RFC 2712, October 1999. [MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General ClientHello extension mechanism and virtual hosting," ietf-tls mailing list posting, August 14, 2000. 13. 著者のアドレス Simon Blake-Wilson BCI sblakewilson@bcisse.com Magnus Nystrom RSA Security magnus@rsasecurity.com David Hopwood Independent Consultant david.hopwood@zetnet.co.uk Jan Mikkelsen Transactionware janm@transactionware.com Tim Wright Vodafone timothy.wright@vf.vodafone.co.uk 日本語訳 西原 啓輔 2002年8月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。