Internet Engineering Task Force (IETF)
Request for Comments： 6066
廃止： 4366
分類： スタンダードトラック
ISSN: 2070-1721
 D. Eastlake 3rd
Huawei
2011年1月

English

TLS拡張：拡張定義
(Transport Layer Security (TLS) Extensions: Extension Definitions)

要旨

本書は、既存のTLS拡張についての仕様を提供する。 これは、RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2"の副読本である。 規定されている拡張は、server_name、max_fragment_length、 client_certificate_url、trusted_ca_keys、 truncated_hmacおよびstatus_requestである。

このメモの位置づけ

これはInternet Standards Track文書である。

本書は、IETF (Internet Engineering Task Force)の成果物である。 これは、IETFコミュニティのコンセンサスを表現している。 これは、パブリックレビューを受け、 IESG (Internet Engineering Steering Group)によって発行を承認されたものである。 Internet Standardsについての詳細は、RFC 5741の2章から得られる。

本書の現在の位置づけ(status)についての情報、 あらゆる誤記(errata)および「どのように、 これについてフィードバックを提供するか？」は、 「http://www.rfc-editor.org/info/rfc6066」で入手できる。

著作権表記

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

本書は、本書の発行日において有効なIETF Documents (http://trustee.ietf.org/license-info)に関する BCP 78 およびIETF Trustの法的規制の対象となる。 これらの文書を注意深く読み返していただきたい。 なぜならば、それらは、 本書に関するあなたの権利と制約を記述しているからである。 本書から抽出されたコードComponentsは、Trust Legal Provisionsの4.e節に記述されているようにSimplified BSD License textを含まなければならないし、Simplified BSD Licenseに記述されているように保証なしで提供されなければならない。

本書は、2008年11月10日以前に発行もしくは公開されたIETF文書もしくはIETF Contributionsからの素材を含む可能性がある。 この素材のいくつかにおける著作権を統制する人(々)は、IETF Trustに対して、 このような素材のIETF標準化過程以外における改変を許容する権利を許可していない可能性がある。 このような素材における著作権を統制している人(々)から適切なライセンスを得ること無しに、 本書は、IETF標準化過程以外において改変されてはいけない。 そして、そのderivative worksは、 RFCとしての発行のためにフォーマットを整えること、あるいは、 これを英語以外の言語に翻訳することを除いて、 IETF標準化過程以外で行われてはいけない。

目次

  1. 1. はじめに
    1. 1.1. 対象とする具体的な拡張
    2. 1.2. 本書における用語法
  2. 2. ハンドシェイクプロトコルに対する拡張
  3. 3. サーバ名表示
  4. 4. 最大フラグメント長の交渉
  5. 5. クライアント証明書URL
  6. 6. Trusted CA表示
  7. 7. 切り詰められたHMAC
  8. 8. 証明書状態リクエスト
  9. 9. エラー警告
  10. 10. IANAについての考慮事項
    1. 10.1. pkipath MIME種別の登録
    2. 10.2. TLS警告、TLS HandshakeTypesおよびExtensionTypesへの参照
  11. 11. セキュリティについての考慮事項
    1. 11.1. server_nameについてのセキュリティの考慮事項
    2. 11.2. max_fragment_lengthについてのセキュリティの考慮事項
    3. 11.3. client_certificate_urlについてのセキュリティの考慮事項
    4. 11.4. trusted_ca_keysについてのセキュリティの考慮事項
    5. 11.5. truncated_hmacについてのセキュリティの考慮事項
    6. 11.6. status_requestについてのセキュリティの考慮事項
  12. 12. 規範的参考文献
  13. 13. 参考情報
  14. Appendix A. RFC 4366からの変更点
  15. Appendix B. 謝辞

1. はじめに English

TLS (Transport Layer Security)プロトコルVersion 1.2は、 [RFC5246] に規定されている。 その仕様は、TLSの拡張についてのフレームワーク、 このような拡張を設計する際の考慮事項 ([RFC5246] の7.4.1.4節を参照)、および、 新しい拡張 code pointの割り当て(allocation)についてのIANA考慮事項を含む。 しかし、これは、署名Algorithms以外のいかなる特定の拡張も規定しない ([RFC5246] の7.4.1.4.1節を参照)。 本書は、既存のTLS拡張についての仕様を提供する。 これ(本書)は、 (その大部分は)RFC 4366からの素材を採用して編集したものである。 これ(RFC 4366)は、 TLS 1.0 (RFC 2246)とTLS 1.1 (RFC 4346)についてのTLS拡張を扱っていた。

1.1. 対象とする具体的な拡張 English

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

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

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

具体的には、本書中に記述されている拡張は、：

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

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

「本書中に定義されているすべての拡張は、 あるセッションが開始されるときのみ、関連すること」にも注意。 セッション再開(resumption)を要求するクライアントは、一般に、 「そのサーバがこのrequestを受容するか否か？」を知らない。 それゆえ、それは、 中断を試みるのでないならば送った拡張と同一のものを送る必要がある(SHOULD)。 クライアントがセッション再開をリクエストする過程で、 拡張されたクライアント hello 中に定義された拡張種別のひとつ、 もしくは複数を含むとき：

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

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

2. ハンドシェイクプロトコルに対する拡張 English

本書は、ふたつの新しいハンドシェイクメッセージ("CertificateURL"および"CertificateStatus")の利用を規定する。 これらのメッセージは、この順に5章と8章に記述されている。 それゆえ、新しいハンドシェイクメッセージ構造体は、下記のようになる。： 

enum {
    hello_request(0), client_hello(1), server_hello(2),
    certificate(11), server_key_exchange (12),
    certificate_request(13), server_hello_done(14),
    certificate_verify(15), client_key_exchange(16),
    finished(20), certificate_url(21), certificate_status(22),
    (255)
} HandshakeType;

struct {
    HandshakeType msg_type;    /* handshake type */
    uint24 length;             /* bytes in メッセージ */
    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は、クライアント用に、 サーバ宛にクライアントがコンタクトしようとしているサーバの名前を伝えるためのメカニズムを提供しない。 これは、クライアント用に単一の基盤となっている(underlying)ネットワークアドレスで複数の「バーチャル」サーバをホストするサーバへのセキュアな接続を容易にするために、 この情報を提供するために渇望される可能性がある。

サーバ名を提供するために、クライアントは、 (拡張された)クライアント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;

ServerNameListは、複数のsame name_typeを収めてはならない(MUST NOT)。 サーバがClientHello拡張は解釈できるが、サーバ名を解釈できない場合、 そのサーバは、 (次の)ふたつにひとつのアクションをとる必要がある(SHOULD)。：

fatalレベルのunrecognized_name(112) alertを送ることによって、 そのハンドシェイクを中断するか、あるいは、 そのハンドシェイクを続けるか、のいずれかである。 warningレベルの警告に対するクライアントのふるまいは、 予測不能であるので、 warning-levelのunrecognized_name(112) alertを送ることは、 推奨されない(NOT RECOMMENDED)。 クライアントアプリケーションによって使われるサーバ名と、 そのサーバによって選択されたたクレデンシャルのサーバ名の間に不整合がある場合、 この不整合は、 そのクライアントアプリケーションがサーバendpoint識別(identification)を行うとき、 そのクライアントアプリケーションが「その通信を続けるか否か？」を判断する必要がある時点で明らかになる。 TLS実装には、アプリケーション開発者に向けて、 TLSハンドシェイクにおいて送受信されるwarning-level警告についての情報を入手可能にすることが強く薦められる。 このような情報は、診断(diagnostic)目的のために有用である可能性がある。

注：この仕様の初期の版は、同一name_typeの複数の名前を許容していた。 実際、現在のクライアント実装は、ひとつだけ名前を送り、 そのクライアントは、 必ずしもそのサーバが選択した名前を見つけ出せるとは限らない。 それゆえ、同一name_typeの複数の名前は、今は禁止されている。

現在、サポートされている唯一のサーバ名は、DNS hostnameである。 しかし、これは、いかなるTLSのDNSへの依存性も意味しない。 そして、他の名前種別が、将来、 (本書を更新するRFCによって)追加される可能性がある。 そのhost_name NameTypeと関連づけられるそのデータ構造体は、 16bit長で始まる可変長ベクトルである。 後方互換性(backward compatibility)について、 新しいNameTypesに関連する将来のすべてのdata structuresは、 16bit長のfieldで始まらなければならない(MUAT)。 TLSは、提供されたサーバ名をopaqueデータとして扱い、 その名前と種別をアプリケーションに渡す可能性がある(MAY)。

"HostName"は、クライアントによって理解されているように、 サーバの完全に修飾されたDNSホスト名を納める。 ホスト名は、連結するドット無しでASCII encodingを使ってbyte stringとして表現される。 これは、[RFC5890] に定義されているA-labelsの利用を通じて国際化ドメイン名のサポートを許容する。 DNSホスト名は、大文字／小文字を区別しない(case-insensitive)。 ホスト名を比較するためのアルゴリズムは、 [RFC5890] の2.3.2.4節に記述されている。

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

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

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

そのサーバが「あるセッションを再開するためのリクエストを許容するか否か？」を判断するとき、 server_name拡張の内容が、 そのセッションキャッシュ内のセッションのlookupにおいて使われる可能性がある(MAY)。 そのクライアントは、同一のserver_name拡張を、 そのセッション再開リクエスト中に含む必要がある(SHOULD)。 なぜならば、 それがセッションを確立したfullハンドシェイクにおいて使われたからである。 この拡張を実装するサーバは、 server_name拡張が異なる名前を含んでいる場合、 そのセッションを再開するために、 そのリクエストを受容してはならない(MUST NOT)。 代わりに、それは、 新しいセッションを確立するためにfullハンドシェイクで進める。 あるセッションを再開するとき、そのサーバは、 サーバhello中にserver_name拡張を含んではならない(MUST NOT)。

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

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

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

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

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

この値は、渇望される最大フラグメント長である。 このフィールドについて、許容される値は、 29、210、211および212である。

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

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

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

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

交渉された長さは、 そのレコード層がフラグメンテーション無しに処理できるinputを制限する。 (すなわち、TLSPlaintext.lengthの最大値。 [RFC5246] の6.2.1節を参照。) 「レコード層のoutputは、より大きい可能性があること」に注意。 例えば、交渉された長さが29=512である場合、現在、 定義されているサイファースィート ([RFC5246] と [RFC2712]) およびnull圧縮、そのレコード層のoutputは、 高々805byte (5byteのheader、512byteのapplication data、 256byteのpadding、32byteのMAC)となりうるに過ぎない。 これは、「TLSレコード層ピアが805byteよりも大きいTLS レコード層のメッセージを受け取る際には、 そのメッセージを破棄して、"record_overflow"alertを、 そのメッセージを復号することなしに送らなければならない(MUST)こと」を意味する。 この拡張がDTLS (Datagram Transport Layer Security)と共に使われているとき、実装は、 そのパケットがメッセージ認証(authentication)を渡すのでない限り、 record_overflow 警告を生成してはいけない(SHOULD NOT)。

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

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

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

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

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

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

enum {
    individual_certs(0), pkipath(1), (255)
} CertChainType;

struct {
    CertChainType type;
    URLAndHash url_and_hash_list<1..2^16-1>;
} CertificateURL;

struct {
    opaque url<1..2^16-1>;
    unint8 padding;
    opaque SHA1Hash[20];
} URLAndHash;

ここで、"url_and_hash_list"は、 一連のURLおよびオプションとしてのハッシュを含む。 各"url"は、証明書を取ってくるのに直ちに使え、 [RFC3986] に準拠した完全な(absolute) URI referenceでなければならない(MUST)。

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

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

その「パディング(padding)」バイトは、 0x01でなければならない(MUST)。 これは、そのstructureを下位互換なものにするために提供される。

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

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

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

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

使われているプロトコルがHTTPである場合、そのHTTPサーバは、 Cache-Controlを使うように設定され、「証明書もしくは証明書チェーンは、 キャッシュされる必要があるか否か？」と「どれだけの期間、 キャッシュされる必要があるか？」を規定するために [RFC2616] に記述されているダイレクティブ(directives)を無効にしうる。

そのTLSサーバは、証明書もしくは証明書のチェーンを受け取るとき、 HTTPリダイレクト(redirect)に従ってはならない(MUST NOT)。 この拡張において使われるURLは、 このようなリダイレクト(redirect)に依存することを選択してはならない(MUST NOT)。

そのプロトコルが証明書を取得するために使われる場合、もしくは、 証明書チェーンがHTTPが行うようにMIME-formatted responseを返す場合、 下記のMIME Content-Typesが使われるものとする(SHALL)。： ひとつのX.509v3証明書が返されるとき、そのContent-Typeは、 "application/pkix-cert" [RFC2585] であり、 一連のX.509v3 certificateが返されるとき、そのContent-Typeは、 "application/pkix-pkipath" (10.1節)である。 そのサーバは、 「(あらゆるMIMEコンテンツ転送の符号化をデコードした後に)そのURLから取得したオブジェクトのコンテンツのSHA-1 hashが、 与えられたハッシュと一致すること」をチェックしなければならない(MUST)。 取得されたいかなるオブジェクトも正しいSHA-1ハッシュをもたない場合、 そのサーバは、 そのハンドシェイクをbad_certificate_hash_value(114) alertと共に中断しなければならない(MUST)。 このalertは、常にfatalである。

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

あるサーバが与えられたCertificateURL中の証明書を取得できない場合、 サーバがハンドシェイクを完結させるために証明書を要求するのであれば、 それは、fatal certificate_unobtainable(111) alertを送らなければならない(MUST)。 そのサーバが証明書を要求しない場合、そのサーバは、 そのハンドシェイクを継続する。 そのサーバは、その場合、warning-level alertを送る可能性がある(MAY)。 そのようなalertを受け取るクライアントは、そのalertを記録し、 可能であれば、 そのハンドシェイクで続行する必要がある(SHOULD)。

6. Trusted CA表示 English

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

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

struct {
    TrustedAuthority trusted_authorities_list<0..216-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..216-1>;

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

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

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

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

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

7. 切り詰められたHMAC English

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

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

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

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

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

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

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

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

証明書status情報を受け取るクライアントの渇望を示すために、 クライアントは、(拡張された)クライアント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..216-1>;
    Extensions  request_extensions;
} OCSPStatusRequest;

opaque ResponderID<1..216-1>;
opaque Extensions<0..216-1>;

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

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

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

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

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

struct {
    CertificateStatusType status_type;
    select (status_type) {
        case ocsp: OCSPResponse;
    } response;
} CertificateStatus;

opaque OCSPResponse<1..224-1>;

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

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

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

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

9. エラー警告 English

4つの新しいエラー警告が、 本書中に規定されているTLS拡張についての用法のために定義されている。 既存のクライアントやサーバが"breaking"を避けるために、 これらの警告は、 その送信者が通信相手からextended helloメッセージを受け取ったのでない限り、 送られてはならない(MUST NOT)。 これらのエラー警告は、下記の構文(syntax)を使って運ばれる。 新しい警告は、 エラーalert番号と同じ行上のコメントによって示されているように、 最後の4つである。 

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;

"certificate_unobtainable"は、5章に記述されている。
"unrecognized_name"は、3章に記述されている。
"bad_certificate_status_response"は、8章に記述されている。
"bad_certificate_hash_value"は、5章に記述されている。

10. IANAに関する考慮事項 English

TLS拡張と、registryのcreationについてのIANA考慮事項は、 後述するMIME type application/pkix-pkipathの登録を除いて、 [RFC5246] の12章に網羅されいる。

IANA TLS拡張と、 RFC 4366を参照しているMIME type application/pkix-pkipath registry entriesは、 本書を参照するように更新されている。

10.1. pkipath MIME種別登録 English

MIME media type name： application
MIME subtype name： pkix-pkipath
Required parameters： none

Optional parameters： バージョン(デフォルト値は "1")

Encoding considerations：

Binary; this MIME type is a DER encoding of the ASN.1 type
PkiPath, 下記のように定義される：
　PkiPath ::= SEQUENCE OF Certificate
　PkiPathは、証明書パスを表現するために使われる。 このシーケンス内において、証明書の順序は、 「最初の証明書のサブジェクトは、 2番目の証明書の発行者となり…」というようなものとなる。
これは、[X509-4th-TC1] 中に公表されている定義と同一のものである。 「これは、 [X509-4th]」中のものとは異なること」に注意。

すべての証明書は、[RFC5280] に準拠しなければならない(MUST)。 (これは、 この種別を使うPKIX準拠証明書のみを符号化するための要件として解釈される必要がある。 あらゆるこのような証明書がもたらすセキュリティの結末は、 注意深く考慮される必要があるが、これは、 必ずしも「厳密にはPKIXに準拠していない証明書のすべてが、 依拠当事者(relying party)によって棄却されなければならないこと」までは要求しない。)

DER (as opposed to BER) encodingが使われなければならない(MUST)。 この種別が7bit transport上を送られる場合、 base64 encodingが使われる必要がある(SHOULD)。

Security considerations：

[X509-4th] と [RFC5280] (もしくは、 これらに対するあらゆる更新RFC)の「セキュリティについての考慮事項」が、 この種別(例：TLS)を使うあらゆるプロトコルについてのものと共に適用される。

「この種別は、 署名検証者(relying party)の既存のtrusted CAの設定に関する妥当性(validity)について関連付けられうる証明書チェーンのみを規定すること」、 「これは、 その設定に対するいかなる変更を規定するためにも使われることを意図されていないこと」に注意。

Interoperability considerations：

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

Published specification：本書と [RFC5280]。

Applications that use this media type：

TLS。 これは、他のプロトコルによって、あるいは、 PKIX証明書チェーンの一般的な交換のためも使われる可能性がある。

Additional information：

Magic number(s)：DER-encoded ASN.1は、容易に解釈されうる。
Further parsingが、 これを他のASN.1種別から区別するために要求される。
File extension(s)： .pkipath
Macintosh File Type Code(s)：規定されていない

Person & email address to contact for further information：

Magnus Nystrom

Intended usage：COMMON

Change controller：IESG

10.2. TLS警告、TLS HandshakeTypesおよびExtensionTypesへの参照 English

TLS Alert Registry中の下記の値は、本書を参照するように更新されている。：

111 certificate_unobtainable
112 unrecognized_name
113 bad_certificate_status_response
114 bad_certificate_hash_value

TLS HandshakeType Registry中の記の値は、 本書を参照するように更新されている。：

21 certificate_url
22 certificate_status

下記のExtensionType値は、本書を参照するように更新されている。：

0 server_name
1 max_fragment_length
2 client_certificate_url
3 trusted_ca_keys
4 truncated_hmac
5 status_request

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

TLS拡張についての一般的なセキュリティについての考慮事項は、 [RFC5246] が対応している。 本書において規定されている特定の拡張についてのセキュリティの考慮事項は、 後述される。

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

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

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

あるクライアントが、 そのアプリケーションプロトコルにおいて異なるserver_nameを提示する可能性があるので、 これらの名前が同一であることに依存するアプリケーションサーバの実装は、 「そのクライアントは、 そのアプリケーションプロトコル内で異なる名前を提供しなかったこと」を確保するためにチェックしなければならない(MUST)。

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

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

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

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

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

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

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

この拡張は、(RFC 4366にあるように) SHA-1を使い続け、 アルゴリズムの交換可能性(agility)を提供しない。 この場合、SHA-1に要求された属性は、第二原像攻撃耐性であり、 衝突攻撃耐性ではない。 さらに、たとえ将来、 SHA-1に対する第二原像攻撃が可能とされた(found)場合でも、 client_certificate_urlに対する攻撃は、 サーバによって妥当な証明書として受容されて、 同一の公開鍵を含む第二原像を要求する。

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

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

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

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

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

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

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

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

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

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

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

12. 規範的参考文献

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti,
"HMAC: Keyed-Hashing for Message Authentication",
RFC 2104, 1997年2月.
[RFC2119] Bradner, S.,
"Key words for use in RFCs to Indicate Requirement Levels",
BCP 14, RFC 2119, 1997年3月.
[RFC2560] 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月.
[RFC2585] Housley, R. and P. Hoffman,
"Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, 1999年6月.
[RFC2616] 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月.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax",
STD 66, RFC 3986, 2005年1月.
[RFC5246] Dierks, T. and E. Rescorla,
"The Transport Layer Security (TLS) Protocol Version 1.2",
RFC 5246, 2008年8月.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk,
"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile",
RFC 5280, 2008年5月.
[RFC5890] Klensin, J.,
"Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework",
RFC 5890, 2010年8月.

13. 参考情報

[RFC2712] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)",
RFC 2712, 1999年10月.
[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.

Appendix A. RFC 4366 からの変更点

RFC 4366と本書の間の顕著な変更点が、後述される。

RFC 4366は、(TLSハンドシェイクと、 クライアントhalloおよびサーバhelloについて、)一般的な拡張メカニズムと、 具体的な拡張の両方を記述していた。 RFC 4366は、RFC 4346: TLS 1.1と関連づけられていた。 クライアントとサーバのhello拡張メカニズムは、 RFC 5246: TLS 1.2に移されている。 それゆえ、RFC 5246と関連づけれらている本書は、 ハンドシェイク拡張メカニズムと、RFC 4366からの特定の拡張のみを含む。 RFC 5246は、 「unknown拡張エラーと新しい拡張仕様についての考慮事項」も規定している。 それゆえ、その題材は、本書から削除されている。

サーバ名拡張は、今や、ASCII表記のみを規定しており、UTF-8を排している。 「ServerNameListが、 あらゆる特定のname_typeの複数の名前を含むことができること」がもたらされている。 あるサーバ名が提供されながら解釈できない場合、そのサーバは、 エラー無しにそのハンドシェイクを続けるか、あるいは、 fatalエラーを送るか、のいずれかの必要がある。 warning-levelメッセージを送ることは、 クライアントのふるまいが予測不能(unpredictable)になるので推奨されない。 「あるセッションを再開するか否か？」を判断する際にserver_name拡張を使うユーザについての規定が追加された。 さらに、この拡張は、 そのセッションを確立したフル(full)ハンドシェイク内にあったので、 ひとつのセッション回復(resumption)リクエスト内において同一である必要がある。 このような回復(resumption)リクエストは、 そのserver_name拡張が異なる場合、受容されてはならないが、 代わりに、新しいセッションをできる限り確立するためにフル(full)ハンドシェイクが行われなければならない。

クライアント証明書URL拡張は、 ハッシュの存在を必須とするために変更されている。

DTLSの事例について、 交渉された最長フラグメント長のオーバーフローを報告する要件は、 認証(authentication)を渡す際の条件次第(conditional)とされた。

TLSサーバは、今や、証明書を取得するとき、 HTTPリダイレクトに従うことは、禁止されている。

また、素材は、軽微なやり方で再編されている。 例えば、「どのエラーがfatalであるか？」に関する情報は、 「エラー警告」の節から個々の拡張仕様に移されている。

Appendix B. 謝辞

本書は、RFC 4366からの素材に基づいている。 (これについての著者は、S. Blake-Wilson氏、M. Nystrom氏、 D. Hopwood氏、J. Mikkelsen氏、 そしてT. Wright氏であった。) 他の貢献者には、Joseph Salowey氏、Alexey Melnikov氏、 Peter Saint-Andre氏、そして Adrian Farrel氏が含まれる。

著者のアドレス

Donald Eastlake 3rd
Huawei
155 Beaver Street
Milford, MA 01757 USA

電話： +1-508-333-2270
EMail： d3e3e3＠gmail.com

翻訳者のアドレス

独立行政法人 情報処理推進機構
技術本部 セキュリティセンター
宮川 寧夫

EMail： miyakawa＠ipa.go.jp