ネットワーク WG
Request for Comments: 2817
更新対象: 2616
分類: スタンダードトラック
 

R. Khare
4K Associates / UC Irvine
S. Lawrence
Agranat Systems, Inc.
2000年 5月

English

HTTP/1.1 において TLS に Upgrade する
(Upgrading to TLS Within HTTP/1.1)

 

このメモの位置付け

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

著作権表記

Copyright (C) The Internet Society (2000).  All Rights Reserved.

要旨

このメモは、「既存の TCP コネクション上において、TLS (Transport Layer Security) を開始するための HTTP/1.1 にある Update メカニズムの使い方」を説明する。これにより、セキュア化されていない HTTP と、セキュア化された HTTP のトラフィックが同一の well known ポートを共有できるようになる。(この場合、443番のhttps: ではなく、80番の http: となる。)また、これにより、「バーチャルホスティング」が可能になるので、1台の (HTTP + TLS) サーバーで、1つの IP アドレスを共有する複数のバーチャルホストへのトラフィック処理を特定できるようになる。

最後に、このメモは、公衆用 HTTP 状態コードについての新しい IANA のレジストリを確立するとともに、公衆用もしくは私用の Upgrade 製品トークンについてのレジストリを確立する。

このメモは、現行の'https' URI スキームの定義には影響しない。このスキームは、既に、'http'とは別の名称空間を形成している。(http://example.org/ と https://example.org/ は、同等ではない)。

 

目次

1.  動機

2.  はじめに

2.1 要件の用語法

3.  クライアントからのリクエストによる HTTP over TLS への Upgrade

3.1 オプションとしての Upgrade
3.2 必須な Upgrade
3.3 サーバーにおよる Upgrade リクエストの受容

4.  サーバーからのリクエストによる HTTP over TLS への Upgrade

4.1 オプションとしての公示
4.2 必須な公示

5.  プロキシを踏み越えた Upgrade

5.1 段階的 Upgrade について
5.2 CONNECT でトンネルをリクエストする
5.3 CONNECT でトンネルを確立する

6.  状態コード 4xx(クライアントエラー)の利用についての理論

7.  IANA についての考慮事項

7.1 HTTP 状態コードのレジストリ
7.2 HTTP Upgrade トークンのレジストリ

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

8.1 https: という URI スキームについて
8.2 CONNECT についてのセキュリティ考慮事項

参考文献
著者のアドレス

A.  謝辞
著作権表記全文

 

1. 動機 English

HTTP over SSL3 [3] の採用についてのこれまでの実践において、この組み合わせの場合を固有の URIスキームと TCP ポート番号によってHTTP を単独で使う場合とは区別してきた。'http' のスキームは、80番ポートにおける HTTP プロトコル単独を意味し、一方 'https' は、443番ポートにおける SSL 上のHTTP プロトコルを意味している。同様に、他のアプリケーションプロトコル(例: snews, ftps) のセキュア化された利用とセキュア化されていない利用 を区別するために、それぞれに well-known ポート番号 が要求され(場合によっては、割り当てられ)ている。このアプローチは、利用可能な well known ポート の数を効果的に半減させる。

1997年12月のワシントン DC IETF ミーティングにおいて、アプリケーションエリアのディレクターらと IESG は、 「別途「セキュア」ポート番号を割り当てる実践を止める必要がある」と再度主張した。HTTP/1.1 Upgrade メカニズムは、TLS [6] をオープンな HTTP コネクションに適用できる。

以来、約 2 年間、この提案の背後にある概念が広く受容されてきたが、一般的な Web ブラウザのために 443番ポートを使う方法についての代替法を実装することについて関心は少なかった。実際、このメモ中には、現行の https: URI の解釈に影響を与える事項は無い。しかし、Internet Printing プロトコル [7] のような新しいアプリケーションプロトコルは、HTTP の上に構築されており、IETF 標準化過程において進めるために、ちょうどこのようなメカニズムを求めている。

また、Upgrade メカニズムは、「バーチャルホスティング」問題も解決する。1つのホストに複数の IP アドレスを
割り当てる のではなく、HTTP/1.1 サーバーは、意図する Web サービスを特定するために Host: ヘッダー を使う。HTTP/1.1 利用が普及する に従って、より多くの ISP が名前に基づくバーチャルホスティングを提供するようになっているが、IP アドレス空間の枯渇を遅らせることになる。

TLS (および SSL)は、以前のバージョンの HTTP と同様の制約を引きずっている。: 最初のハンドシェイクは、意図するホスト名を指定せず、IP アドレスのみに頼っている。TLS ハンドシェイクにおける平文 HTTP/1.1 Upgrade: の使用(初期 Host: ヘッダーに基づく証明書の選択)は、ISP が名前に基づく セキュアなバーチャルホスティングも提供できるようにする。

 

2. はじめに English

(SSL (Secure Sockets Layer) としても知られている)TLS は、様々な暗号システムを使ってプライベートな「エンド to エンド」コネクションを確立し、オプションとして強い相互認証を含む。最初に、ハンドシェイク段階では、レコード層を確立し、終端の認証し、パラメータを設定し、エラーを報告するために、3 つのサブプロトコルを使う。次に、 そのコネクションの以降の部分を暗号化・圧縮・再構築する処理を扱う、処理が階層化されたレコードプロトコルがある。 後者は、完全に透過的であることを意図された。例えば、TLS のレコードマーカーかつ/または証明書と、HTTP/1.1 のチャンクされた符号化または認証 の間に、依存関係はない。

クライアントかサーバーのいずれかが「TLS でセキュア化されたコネクションが望まれること/必要不可欠であること」を示すために、HTTP/1.1 [1]  (Section 14.42) の Upgrade メカニズムを使うことができる。このメモは、"TLS/1.0" Upgrade トークンおよび新しい HTTP 状態コード「426 要 Upgrade」を規定する。

3 章4 章は、直接接続されたクライアントとサーバーの操作 を記述している。中間にあるプロキシは、5 章で説明しているように、これらの操作を適用する前に「エンド to エンド」トンネルを確立しなければならない。

2.1 要件の用語法 English

本書中のキーワード"MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" , "MAY"は、RFC 2119 [11] に記述されているように解釈されるべきものである。

 

3. クライアントからのリクエストによる HTTP over TLS への Upgrade English

クライアントが"TLS/1.0"を含む Upgrade ヘッダーフィールドをもつ HTTP/1.1 リクエストを送るとき、クライアントは、 サーバーに対して TLS/1.0 に切り替え後に現在の HTTP/1.1 リクエストを完遂することを要求していることになる。

3.1 オプションとしての Upgrade English

クライアントは、セキュア化されていないレスポンスを受け取り可能なとき、いかなる平文 HTTP リクエストにおいても、セキュア化された動作に切り替えることができる(MAY)。:

GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade

この場合、サーバーは、通常通りのクリアな HTTP 操作に応答するか、あるいは(OR)、(次章において詳細に記述してある)セキュア化された操作に切り替えることができる(MAY)

HTTP/1.1 [1] は、「Upgrade が HTTP/1.1 メッセージ中にあるときは常に、キーワード upgrade は、コネクションヘッダーフィールド(section 14.10)内で提供されなければならない(MUST)」と規定していることに注意。

3.2 必須な Upgrade English

セキュア化されていないレスポンスが許容不能である場合、クライアントは、まず、(可能である場合)TLS/1.0 への切り替えを関するために、OPTIONS リクエストを送らなければならない(MUST)

OPTIONS * HTTP/1.1
Host: example.bank.com
Upgrade: TLS/1.0
Connection: Upgrade

3.3 サーバーによる Upgrade リクエストの受容 English

HTTP/1.1 [1] において仕様とされているように、サーバーが TLS ハンドシェイクを開始する準備ができている場合、サーバーは、過渡的な「101 プロトコル切り替え中」(メッセージ)を送らなければならない(MSUT)とともに、 切り替えるプロトコルスタック のトークンを規定する Upgrade レスポンスヘッダーを含めなければならない(MUST)。:

HTTP/1.1 101 Switching Protocols
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

「101(プロトコル切り替え)レスポンスの Upgrade ヘッダー中に掲載された プロトコルトークンは、順位づけられた「ボトムアップ」スタック を規定すること」に注意。

HTTP/1.1 [1] の 10.1.2 に規定されているように、「サーバーは、101 レスポンス の末尾にある空白行の直後に、プロトコルを レスポンスの Upgrade ヘッダーフィールドによって規定されたものに切り替える」。

一度 TLS ハンドシェイクが成立すると、そのサーバーは、当初のリクエストに対するレスポンスで 続けなければならない(MUST)。いかなる TLS ハンドシェイク失敗も、TLS エラー警告仕様の単位でコネクションを切断するようにしなければならない(MUST)

 

4. サーバーからのリクエストによる HTTP over TLS への Upgrade English

Upgrade レスポンスのヘッダーフィールドは、サーバーが受容できる(MAY)プロトコル Upgrade の候補を公示する。「426(要 Upgrade)」状態コードと併せて、サーバーは、 クライアントがリクエストを完了させるために受容しなければならない(MUST)正確なプロトコル Upgrade を公示できる。

4.1 オプションとしての公示 English

HTTP/1.1 [1] において仕様とされているように、サーバーは、リストされている(組み合わせの)プロトコル に切り替えることを望んでいることを示すために、101 もしくは 426 以外のレスポンス中に Upgrade ヘッダーを含めることができる(MAY)

4.2 必須な公示 English

サーバーは、 「クライアントリクエストは、TLS が 426 状態コード(要 Upgrade)を使わずして完了できないこと」 を示すことができ(MAY)、これは、要求される TLS バージョンのトークンを規定する Upgrade ヘッダーフィールドを含まなければならない(MUST)

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

このサーバーは、426 レスポンスにおいて人間が読むことができる形式でエラーの理由を示すメッセージ本文 を含め、ユーザが利用可能である可能性があるあらゆる代替策を記述する必要がある(SHOULD)

「たとえクライアントが TLS を使うことを望んでいる場合でも、処理のためには、3 章中の操作を行わなければならないこと」に注意。; TLS ハンドシェイクは、426 レスポンス 直後には開始できない。

 

5. プロキシを踏み越えた Upgrade English

段階的なヘッダーであるので、Upgrade は、HTTP の相手同士の各ペア間において交渉される。ユーザエージェントがプロキシ宛に Upgrade ヘッダーをもつリクエストを送る場合、ユーザエージェントは、ユーザエージェントとプロキシの間のプロトコルについての変更を要求しているのであり、「エンド to エンド」の変更ではない。

特に、TLS は、認証を提供し、中間者による攻撃を予防するために「エンド to エンド」な接続を要求するので、このメモは、 プロキシを踏み越えてトンネルを確立するための CONNECT メソッドを規定する。

一度、トンネルが確立したら、3 章中のあらゆる操作が TLS コネクションを確立するために利用可能である。

5.1 段階的 Upgrade について English

発信元サーバーがプロキシから Upgrade ヘッダー を受け取り、101(プロトコル切り替え)レスポンスで応答する場合、プロキシとサーバー自体の間のコネクションのみのプロトコルを切り替えているのである。 同様に、プロキシは、発信元サーバーと通信するのに使っているプロトコルとは独立して、そのクライアント宛にそのコネクション上のプロトコルを変更するために 101 レスポンス を返す可能性がある。

また、これらのシナリオは、426 レスポンスの判定を複雑にする。 Upgrade は段階的なヘッダーであるので、426 を処理できないプロキシは、付随する Upgrade ヘッダーを削除してしまい、クライアントによる要求されたプロトコル への切り替え判定を を行わせない可能性がある。クライアントが Upgrade ヘッダーを伴わない 426 状態コードを受け取った場合、クライアントは、5.2 に記述してあるように、「エンド to エンド」なトンネルコネクションをリクエストする必要があり、要求される Upgrade 情報を得るために、そのリクエストを繰り返す必要がある。

この段階的な Upgrade の仕様は、熟考された選択であった。これによって、プロキシの両側において段階的な採用が可能であり、 カスケード化されたプロキシ間で、変更に関与しなかったプロキシについての知識無しに、プロトコルを最適化できる。

5.2 CONNECT でトンネルをリクエストする English

CONNECT 手法は、 「プロキシが代わりにトンネルコネクションを 確立すること」 を要求する。Request-Line の Request-URI 部分は、URI Generic Syntax [2] によって規定されているように、常に 'authority' である。すなわち、リクエストされたコネクション宛先の ホスト名とポート番号をコロンで区切ったものである。:

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

当然ながら、トンネルが最初に確立されなければならないので、「エンド to エンド」プロトコル Upgrade リクエスト以外であれば他の HTTP メカニズムが通常は CONNECT 手法とともに利用可能である。

例えば、プロキシ認証は、トンネルを作成するためのオーソリティ を確立するために使われる可能性がある。:

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=

いかなる他のパイプライン化された HTTP/1.1 リクエストと同様に、トンネルを通すべきデータを、空白行の直後に送ることができる。通常の警告も適用される。: 最終的なレスポンスが否定的である場合、データを棄却できる。また、複数の TCP セグメントが残っている場合、そのコネクションは、レスポンス無しにリセットできる。

5.3 CONNECT でトンネルを確立する English

CONNECT リクエストに対するいかなる成功レスポンス(2xx)も、 「プロキシがリクエストされたホストとポートに対するコネクションを確立し、現在のコネクションを サーバーコネクション宛にトンネルさせるように切り替えたこと」
を示す。

「プロキシ自体がその他のプロキシを通じてのみ要求した発信元サーバーに到達可能である」ような場合がある。この場合、最初のプロキシは、その次のプロキシの CONNECT リクエストを行い、オーソリティ宛のトンネルを要求する必要がある(SHOULD)。 プロキシは、オーソリティ宛の、直接かトンネルによるいずれかのコネクションが確立されない限り、 いかなる 2xx 状態コードでも応答してはならない(MUST NOT)

自ら宛の CONNECT リクエストを受信した発信元サーバー は、コネクションが確立されたことを示すために 2xx 状態コードで応答することができる(MAY)

ピアのいずれか一方がコネクションを切断する場合、そのピアから来た、あらゆる残っているデータは、他方に転送される。そして、その後、他のコネクションもプロキシ によって終了される。そのピア宛のデータが未配送で残っている場合、 そのデータは、棄却される。

 

6. 状態コード 4xx (クライアントエラー)の使用についての理論 English

Upgrade 機能の信頼できる相互運用可能な交渉においては、明解な失敗の表示が要求される。426(要 Upgrade)状態コードによって、サーバーが一定の資源を提供しなければならないことを示す詳細なプロトコル拡張を明確に表現できるようになる。

一見、 「https: という URI についての古い再指図のやり方に似ていることによって、レスポンスが何らかの再指図(3xx)の一形態である」 ように見える可能性がある。Upgrade: を処理できないユーザエージェントは、これを作成する。

「3xx コードは、『要 Upgrade』について割り当てられてきた」と想定する。; これを処理できなかったユーザエージェント(クライアント)が、これを 300 として扱う。それから、おそらく、クライアントは、レスポンス中の"Location" ヘッダー を探し、そのヘッダーフィールド中の URL に対するリクエストを繰り返すことを試みる。 このユーザエージェントは、 TLS 層上に組み込むよう Upgrade することを知らなかったので、せいぜい、新しい URL でも失敗することであろう。

 

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

IANA は、BCP 26 [10] に記述されているように、2 つの名前空間についてのレジストリを作成するものとする。:

7.1 HTTP 状態コードのレジストリ English

HTTP 状態コードのレジストリは、HTTP レスポンスの Status 行にある Status-Code トークン についての名前空間を規定する。この名前空間についての初期値は、以下のものによって規定されている。:

  1. HTTP/1.1 [1] についてのドラフト標準
  2. Web DAV [[4]] [420-424 を規定]
  3. WebDAV Advanced Collections [5] (作業中)[425 を規定]
  4. 6 章 [426 を規定]

この名前空間に追加されるべき値は、IETF アプリケーションエリアにおけるスタンダードトラック文書の方式で レビューの対象とする必要がある(SHOULD)。あらゆるこのような文書は、

HTTP/1.1 についてのドラフト標準 [1] に対する「廃止(Obsoletes)」か「更新(Updates)」のいずれかの文書ステータスによって、 追跡可能である必要がある(SHOULD)

7.2 HTTP Upgrade トークンのレジストリ English

HTTP Upgrade トークンのレジストリは、Upgrade HTTP ヘッダーフィールド中のプロトコルを識別するために使われる製品トークンについての 名前空間を規定する。登録された各トークンは、1つもしくは一式の仕様と、および、連絡先情報と関連づけられる必要がある。

HTTP/1.1 [1] についてのドラフト標準は、 「トークンは『製品』についての成果に従う」と規定する。:

product         = token ["/" product-version]
product-version = token

登録は、BCP 26 [10] に記述されているように、先入先出法に基づいて許可される必要がある。これらの仕様は、IETF 文書であったり、または、IESG によるレビュー対象とする必要はないが、下記のルールに従う必要がある。:

  1. トークンは、一度登録されると、永遠に登録され続ける。
  2. 登録は、登録についての責任者を記入しなければならない(MUST)
  3. 登録は、連絡先を記入しなければならない(MUST)
  4. 登録は、トークンについて要求される文書を記入できる(MAY)
  5. 責任者は、いつでも登録を変更できる(MAY)。 IANA は、このような変更のすべてを記録し、リクエスト に応じてそれらを利用可能とする。
  6. 「製品」トークンの初期登録についての責任者は、その「製品」トークンの以降の「バージョン」のトークン登録についても、それらが登録される前に承知していなければならない(MUST)
  7. 実際に要求される場合、IESG は、トークンについての責任を再指名できる(MAY)。 これは、通常、責任者に連絡がとれないときにのみ使われる。

この仕様は、プロトコルトークン"TLS/1.0"を TLS プロトコル [6] によって規定されているプロトコルについての識別子として規定する。

「Upgrade トークンを公衆利用可能とするための規定」 は要求されないが、登録についての連絡先情報は、必要(SHOULD)である。

 

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

中間者による(Upgrade ヘッダーを削除する)攻撃についての潜在的可能性は、現状の http/https が混合した実践にあることと同様に残されている。:

さらに、TLS を明示的に呼び出さない クライアントについて、サーバーは、TLS 準拠を示すために 101 もしくは 426 以外のいかなるレスポンスにおいても、Upgrade ヘッダーを使うことができる。TLS 準拠がサーバーの機能であり手元の資源ではないと見なされる必要があるので、1回だけ送信し、クライアントにその事実をキャッシュさせることで十分である。

8.1 https: という URI スキームについて English

このメモ中に 'https' URI スキームの規定に影響を与える事項は無いが、このメカニズムを広くハイパーテキストのコンテンツに採用することによって、セキュアな資源とセキュアでない資源の両方を識別するために、'http' を使うことができるようになる。

「どのようなセキュリティ特性がコネクション上で要求されているか」についての選択は、クライアントとサーバーに委ねられる。これは、この判定を行う際に両者が利用可能なあらゆる情報を使うことができるようにする。例えば、ユーザエージェント (クライアント)は、ユーザパフォーマンス設定や「この LAN 以外のすべての POST 操作に TLS が要求される」というようなネットワークのセキュリティについての情報に依拠できる。あるいは、サーバーは、「このページの FORM は、TLS を使って表示・送信されなければならない」というような資源アクセスルールを適用することができる。

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

一般的な TCP トンネルは、セキュリティリスクにさらされている。まず、そのような認証は、少数の known port に限定される必要がある。ここに規定した Upgrade: メカニズムは、80番ポートにおける前方トンネリングのみを要求する。2番目に、トンネルを通過するデータはプロキシにとっては不透明であるので、他の well-known ポート/予約ポートをトンネルさせることには、追加的なリスクがある。例えば、25番ポートに接続する想定上の HTTP クライアントは、SMTP 経由で spam を中継する可能性がある。

 

参考文献 English

[1]  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月.
 
[2]  Berners-Lee, T., Fielding, R. and L. Masinter,
"URI Generic Syntax",
RFC 2396, 1998年 8月.
 
[3]  Rescorla, E.,
「HTTP オーバー TLS (HTTP Over TLS)」",
RFC 2818, 2000年 5月.
 
[4]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D. Jensen,
"Web Distributed Authoring and Versioning",
RFC 2518, 1999年 2月.
 
[5]  Slein, J., Whitehead, E.J., et al.,
"WebDAV Advanced Collections Protocol", 
作業中。
 
[6]  Dierks, T. and C. Allen,
「TLS プロトコル v1.0 (The TLS Protocol)」,
RFC 2246, 1999年 1月.
 
[7]  Herriot, R., Butler, S., Moore, P. and R. Turner,
"Internet Printing Protocol/1.0: Encoding and Transport",
RFC 2565, 1999年 4月.
 
[8]  Luotonen, A.,
"Tunneling TCP based protocols through Web proxy servers", 
作業中。 
(Also available in: Luotonen, Ari. Web Proxy Servers, Prentice-Hall, 1997 ISBN:0136806120.)
 
[9]  Rose, M.,
「I-D と RFC を XML を使って書く (Writing I-Ds and RFCs using XML)」,
RFC 2629, 1999年 6月.
 
[10] Narten, T. and H. Alvestrand,
「RFC 中の『IANA についてに考慮事項』の章を書くためのガイドライン(Guidelines for Writing an IANA Considerations Section in RFCs)」,
BCP 26
, RFC 2434(English), 1998年10月.
 
[11] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels) 」,
BCP 14
, RFC 2119, 1997年 3月.

 

著者のアドレス

Rohit Khare
4K Associates / UC Irvine
3207 Palo Verde
Irvine, CA  92612
US

電話: +1 626 806 7574
EMail: rohit@4K-associates.com
URI:   http://www.4K-associates.com/

Scott Lawrence
Agranat Systems, Inc.
5 Clocktower Place
Suite 400
Maynard, MA  01754
US

電話: +1 978 461 0888
EMail: lawrence@agranat.com
URI:   http://www.agranat.com/

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp
URI:   http://www.ipa.go.jp/security/

 


補遺 A. 謝辞 English

CONNECT 手法は、元来、Netscape Communications 社の Ari Luotonen 氏によって、"Tunneling TCP based プロトコルs through Web Proxy Servers" [8] という作業中文書中に記述されていた。これは、広く HTTP プロキシによって実装されていたが、いかなる IETF スタンダードトラック文書の部分とされてこなかった。手法名 CONNECT は、確保されたが、[1] に規定されていない。

ここに提示した規定は、その以前のメモに直接、由来するものであり、 いくつかの編集上の変更と、他の HTTP 仕様において確立されている様式上の慣行への準拠が行われている。

以下の方々にも感謝する。:

 

著作権表記 全文

Copyright (C) The Internet Society (2000).  All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than
 English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

謝辞

RFC 編集者のための資金は現在、Internet Society によって提供されています。