この文書は、 J. Mogul, A. Van Hoff: Instance Digests in HTTP (RFC 3230), January 2002. を 橋本英彦 が日本語訳した物です。 この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。
Network Working Group Request for Comments: 3230 Category: Standards Track
J. Mogul
Compaq WRL
A. Van Hoff
Marimba
January 2002
この文書は、インターネットコミュニティにおけるインターネット標準化過程プロトコルを規定し、改良のために議論と提案を求めるものである。 このプロトコルの標準化状態と状況については、"Internet Official ProtocolStandards" (STD 1) の最新版を参照していただきたい。 この文書の配布に制限は無い。
Copyright © The Internet Society (2002). All Rights Reserved.
HTTP/1.1 では、サーバがレスポンスボディのダイジェストを含む事ができる Content-MD5 ヘッダを定義している。 しかし、これは仕様上、完全なファイルの内容ではなく、実際のメッセージのボディを範囲とすると定義されている (レスポンスが Content-Range だったり、差分エンコーディングを使用していた場合、これらは全く異なるであろう)。 また、Content-MD5 は一つの特定のダイジェストアルゴリズムに限定されている; ある場面では、例えば SHA-1 (Secure Hash Standard) のような他のアルゴリズムがより適切かもしれない。 最後に、 HTTP/1.1 ではクライアントがダイジェストを要求できるような明示的なメカニズムが提供されていない。 この文書では、これらの問題を解決する HTTP の拡張を提案する。
HTTP は典型的に、例えば TCP のように、信頼できる輸送プロトコルの上に層をなすが、これは送信者から受信者への信頼できる情報の輸送を保証するものではない。 検出されない転送エラー、プログラム上のエラー、保存されるデータの退廃、悪意の介入等の様々な問題が転送される情報のエラーの原因となり得る。
HTTP のような、ネットワークプロトコルや分散システムにおけるデータ完全性の問題への一般的なアプローチには、ダイジェストやチェックサム、あるいはハッシュ値の使用がある。 送信者はダイジェストを計算し、それをデータと共に送る; 受信者は受信したデータのダイジェストを計算し、そのダイジェストを比較する事によってこのデータの完全性を検証する。
チェックサムは、IP スタックの全ての層で仮想的に使用される。 しかし、保護されているデータのサイズや性質が変わったり、データの完全性を脅かす可能性が変わったりするので、計算コストという理由から、それぞれの層で異なるダイジェストアルゴリズムが使用されるかもしれない。 例えば、Ethernet では 巡回冗長検査 (CRC:Cyclic Redundancy Check) を使用する。 IPv4 プロトコルは、IP ヘッダ上で 1 の補数のチェックサム{ones-complement checksum} を使用する (しかしパケットの残り部分では使用しない)。 TCP は、TCP ヘッダとデータにおいて 1 の補数のチェックサムを使用し、特定の種類のプログラム上のエラーを検出するための "疑似ヘッダ" を含んでいる。
HTTP/1.1 [4] は、メッセージの完全性を保証するためのメカニズムとして、Content-MD5 ヘッダを含む。 このヘッダは実際には、MIME に適合するメッセージのために独立した仕様書 [10] にて定義されている。 HTTP/1.1 仕様書によれば、
Content-MD5 エンティティヘッダフィールドは [...] エンティティボディのメッセージ状態チェック{message integrity check} (MIC) をエンティトゥエンドで提供するという目的を持つエンティティボディの MD5 ダイジェストである。
HTTP/1.1 は、MIME メッセージ (例えば、電子メールメッセージ) と HTTPメッセージ (HTTP サーバへのリクエスト、あるいはそこからのレスポンス)との類似性に基づき、MIME の世界から Content-MD5 を借りてきた。
section 3 にてより詳しく議論されるように、この MIME メッセージと HTTPメッセージの類似性はいくつかの混乱を招いている。 特に、MIME メッセージは自己完結的{self-contained} であるが、HTTP メッセージはリソースの現在の状態の完全な表現を含んでいないかもしれない。 (より正確には、HTTPレスポンスは完全なる "インスタンス" を含んでいないかもしれない; この用語の定義については section 3 参照。)
この違いが問題となる状況は少なくとも二つある:
我々は、これら二種類の変形を、我々が "インスタンス操作" と呼ぶ潜在的に広がるカテゴリに含む。
これらの場合のそれぞれにおいて、サーバはレスポンスメッセージの完全性を保護するために Content-MD5 ヘッダを使う事ができる。 しかし、Content-MD5 ヘッダフィールド中の MIC は、そのメッセージ中のエンティティのみに適用され、再構成されるインスタンス全体に適用されるのではないので、(例えば、キャッシュエントリの) データの退廃によるエラー、(例えば、部分内容や差分の不適切な適用のような) プログラム上のエラー、特定の悪意のある攻撃 [9] 、あるいは転送における HTTP ヘッダの退廃等から保護する事はできない。
従って、Content-MD5 ヘッダは、多くの場合には有用でありまた十分であるが、HTTP の全ての使用においてインスタンスの完全性を検証するためには十分ではない。
ダイジェスト認証メカニズム [5] は、それがあるヘッダフィールドを含んでいる事以外は、(その他の目標に加えて) Content-MD5 と同様の message-digest 関数を提供している。 Content-MD5 のように、これは特定のメッセージをその範囲とし、インスタンス全体を範囲とはしない。
チェックサムは無料ではない。 ダイジェストを計算するには CPU リソースを使うし、メッセージの生成に遅れが生じるかもしれない。 (これらのコストのいくらかは送信者側で注意深くキャッシュする事によって回避する事ができるが、多くの場合そのようなキャッシュは有効なヒット率は持っていないであろう。 ) ダイジェストの転送は、HTTP ヘッダ空間を消費する (また、それ故に遅れや必要なネットワーク帯域が増える)。 もしメッセージ受信者がダイジェストの使用を意図しない場合、何故メッセージ送信者がそれを計算したり送信するためにリソースを消費する必要があるのか?
もちろん、Content-MD5 ヘッダは暗黙的に MD5 アルゴリズムの使用する。 しかし、ある目的では他のアルゴリズムのほうがより適切かもしれない。 これらには SHA-1 アルゴリズム [12] や、様々な "指紋" アルゴリズム [7] を含む。 HTTP では現在、これらのアルゴリズムの使用についての標準的にサポートされるものを提供しない。
HTTP/1.1 では、明らかにダイジェストの生成の選択は送信者の責任であるように想定されており、チェックサムが有用かどうか、あるいはどのチェックサムアルゴリズムを理解できるかを受信者が示すためのメカニズムを提供していない。
この提案の目標は以下の通りである:
目標には以下のものは含まれない:
ダイジェストアクセス認証メカニズム [5] は、いくつかの HTTP ヘッダの完全性を提供する事ができ、認証を提供する。
HTTP/1.1 [4] は以下の語を定義する:
"entity" の辞書による定義は、"その存在や対象、あるいは概念的現実が他と明確に区別されるもの" である [8]。 不幸にも、HTTP/1.1 中の "entity"の定義は、MIME [6] 中で使用されるそれに似ており、MIME と HTTP との誤った類推に基づくものである。
MIME では、電子メールはメッセージとは区別されるものを持っている。 MIMEは "エンティティ" を"特に MIME にて定義されたヘッダフィールドと、あるメッセージかマルチパートメッセージのボディ中の一部分のいずれかの内容を参照する" ようなものとして定義している。
しかし HTTP では、GET へのレスポンスはメッセージとは区別されるものを持ってはいない。 むしろ、それはリソース (あるいはある制約のセットに従うようなバリアント) の現状を表現ている。 HTTP/1.1 仕様書では、"現時点において特定されたリソースの選択されたバリアントについて GET リクエストへのレスポンスとして返される値" について記述するための用語はない。 これは、この概念が必要な場所において HTTP/1.1 仕様書中で不適切な表現に通じる。
HTTP/1.1 仕様書の用語上の失敗を修正するにはもう遅すぎるので、代わりにこの文書で使用するためる新しい用語を定義する:
HTTP/1.1 では、エンティティよりも、インスタンスに関係しているので、エンティティタグについて考える事は便利である。 すなわち、与えられたリソースについて、二つの異なるレスポンスメッセージが同じエンティティタグを持っているかもしれないが、リソースの二つの異なるインスンスは決して同じ (強い) エンティティタグに対応すべきではない。
また、以下の用語も定義する:
この仕様書において、"MUST", "MUST NOT", "SHOULD", "SHOULD NOT", "MAY"各キーワードは RFC 2119 [2] に記述されるように解釈される。
ダイジェストアルゴリズムは、特定のダイジェスト計算法を示すために使用される。 アルゴリズムによっては、一つ以上の引数を与えるかもしれない。
digest-algorithm = token
"parameter" の BNF は、RFC 2616 [4] にて使用される通りである。 全てのdigest-algorithm 値は大文字・小文字を区別しない。
Internet Assigned Numbers Authority (IANA) は、digest-algorithm 値のレジストリの役割を果たす。 最初に、レジストリは以下のトークンを含む:
もし他の digest-algorithm 値が定義される場合、関連付けられるエンコーディングは、引用文字列として表されなければならない。 あるいはエンコーディングに用いられる文字セット中に ";" か "," を含んでいてはならない。
インスタンスダイジェストは、使用されるアルゴリズムの指標 (と任意の引数) と、ダイジェストアルゴリズムの出力を一緒に表したものである。
instance-digest = digest-algorithm "=" <エンコードされたダイジェストの出力>
ダイジェストは、メッセージに関連付けられたインスタンス全体について計算される。 インスタンスは、インスタンス操作や転送コーディングを適用する前のリソースの断片である (section 3 参照)。 ダイジェストを計算するのに使用されるバイトオーダーは、インスタンスの content-type において定義される転送バイトオーダーである。
注: ダイジェストはインスタンス操作の適用の前に計算される。 もし範囲や差分コーディング [9] 使用する場合、範囲や差分を計算した後にダイジェストを計算しても、再構成されたインスタンスの完全性を検査するための有用な要約は提供されない。
エンコードされたダイジェストの出力は、特定の digest-algorithm にて定義されたエンコーディングフォーマットを使用する。 例えば、digest-algorithm が "MD5" ならば、そのエンコーディングは base64 である; また、digest-algorithm が "UNIXsum" ならば、そのエンコーディングは十進数の ASCII 文字列である。
例:
MD5=HUXZLQLMuI/KZ5KDcJPcOA== sha=thvDyvhfIqlvFe+A9MYgxAfm1q5= UNIXsum=30637
以下のヘッダを定義する。
Want-Digest メッセージヘッダフィールドは、Request-URI に関連付けられたメッセージに関するインスタンスダイジェストを受信したいという送信者の希望を示すものである。
Want-Digest = "Want-Digest" ":"
#(digest-algorithm [ ";" "q" "=" qvalue])
digest-algorithm に qvalue が伴っていなければ、それに関連付けられたqvalue は 1.0 であるように扱われる。
メッセージの Want-Digest ヘッダフィールドに digest-algorithm が列挙されており、その qvalue が 0 でない場合、送信者はそれを受け入れるであろう。
複数の受け入れ可能な digest-algorithm 値が与えられた場合、送信者が望む digest-algorithm は、最高の qvalue をもつ物である。
例:
Want-Digest: md5 Want-Digest: MD5;q=0.3, sha;q=1
Digest メッセージヘッダフィールドは、そのメッセージが表すインスタンスのメッセージダイジェストを提供する。
Digest = "Digest" ":" #(instance-digest)
メッセージによって表されるインスタンスは、message-body に完全に含まれているかもしれないし、message-body に部分的に含まれているかもしれないし、 message-body に全く含まれていないかもしれない。 インスタンスは、Request-URI とメッセージに含まれる任意のキャッシュバリディタによって指定される。
Digest ヘッダフィールドは、複数の instance-digest 値を含む事ができる。 これは、例えば異なるブラウザのユーザによって共有されるキャッシュ中に存在すると期待されるレスポンスに対しては有用であろう。
受信者は、Digest ヘッダフィールドの instance-digest の一部または全部を無視してもよい。
送信者は、受信者がその digest-algorithm をサポートしているかどうか知らない、あるいは受信者がそれを無視するであろうという事を知っているいた場合でも、digest-algorithm を使用した instance-digest を送る事ができる。
例:
Digest: md5=HUXZLQLMuI/KZ5KDcJPcOA== Digest: SHA=thvDyvhfIqlvFe+A9MYgxAfm1q5=,unixsum=30637
HTTP/1.1 では Content-MD5 ヘッダフィールドを提供しているが、この使用 (または不使用) を要求するためのメカニズムは提供していない。 この文書で定義される Want-Digest ヘッダフィールドは、そのようなメカニズムの基本を提供する。
初めに、(section 4.1.1 の) digest-algorithm 値のセットにトークン "contentMD5" を加えるが、この digest-algorithm は Digest ヘッダフィールドにて使用してはならない。
Want-Digest ヘッダフィールドに 0 でない qvalue の "contentMD5" という digest-algorithm があれば、送信者は Request-URI に関連付けられたメッセージで Content-MD5 ヘッダを受信したいという事を示す。
Want-Digest ヘッダフィールドに 0 の qvalue の "contentMD5" という digest-algorithm があれば、送信者は Request-URI に関連付けられたメッセージで Content-MD5 ヘッダを無視するであろうという事を示す。
Internet Assigned Numbers Authority (IANA) は、digest-algorithm 値についての名前空間を管理する。 値とその意味は、独立した実装間での相互運用が可能なように、RFC あるいは他のよく検討された{peer-reviewed}、永続的で容易に利用可能な参照の中で、詳細に文書化されなければならない。 このような制約に従うので、名前の割り当ては早い者勝ちである (RFC 2434[11] 参照)。
この文書は、ある種の偶発的な変形から、HTTP インスタンスデータを守るというデータ完全性メカニズムを詳述するものであり、HTTP エンティティヘッダを守るためのものではない。 また、このメカニズムは最低一つのなりすまし攻撃 [9] を検出するために有用である。 しかし、HTTP メッセージへの悪意のある改ざんに対しての一般的な保護は意図されていない。
HTTP ダイジェストアクセス認証メカニズムでは、悪意のある改ざんからの保護をいくつか提供している。
範囲や差分を使用する時に Content-MD5 ヘッダフィールドではデータ完全性を提供するには十分ではないという事に誰が最初に気づいたのかは明らかではない。
Laurent Demailly は、HTTP におけるアルゴリズムに依存しないチェックサムヘッダを最初に提案した人物であるだろう [3]。 Dave Raggett は、用語"チェックサム" の代わりに "ダイジェスト" の使用を提案した [14]。
Jeffrey C. Mogul Western Research Laboratory Compaq Computer Corporation 250 University Avenue Palo Alto, California, 94305, U.S.A. EMail: JeffMogul@acm.org Phone: 1 650 617 3304 (email preferred) Arthur van Hoff Marimba, Inc. 440 Clyde Avenue Mountain View, CA 94043 EMail: avh@marimba.com Phone: 1 (650) 930 5283
Copyright © The Internet Society (2002). All Rights Reserved.
この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。 しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。
上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。
この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。
RFC Editer 機構の資金は、現在インターネット学会から提供されている。