ダイジェスト・フィールド

• リクエストおよびレスポンスのヘッダとトレーラフィールドの新しい定義。

  • Section 2 (Content-Digest),
  • Section 3 (Repr-Digest), および
  • Section 4 (Want-Content-Digest と Want-Repr-Digest).

• 表現データ整合性に特有の考慮事項。

  • Section 3.1 (状態変更リクエスト),
  • Section 3.2 (Content-Location),
  • Appendix A にはメッセージ交換における表現データの実例が含まれ、
  • 付録 B と C はメッセージ交換における Repr-Digest および Want-Repr-Digest フィールドの実例を含みます。
• Section 5 ではハッシュアルゴリズムに関する考慮事項を示し、将来のエントリの登録手順を定義します。

本書で定義される HTTP フィールドは HTTP の整合性に使用できます。送信者はハッシュアルゴリズムを選択し、HTTP メッセージに関連する入力からダイジェストを計算します。アルゴリズム識別子とダイジェストは HTTP フィールドで送信されます。受信者は整合性目的でダイジェストを検証できます。ハッシュアルゴリズムは "Hash Algorithms for HTTP Digest Fields" レジストリに登録されます（Section 7.2 を参照）。

ダイジェストを計算するデータの選択は、HTTP メッセージのユースケースによって異なります。本書は HTTP の表現データと HTTP コンテンツのために別々のフィールドを提供します。

単純に HTTP コンテンツのバイト列のダイジェストが必要となるユースケースがあります。その場合、コンテンツのダイジェストをサポートするために Content-Digest のリクエスト・レスポンスのヘッダおよびトレーラフィールドが定義されています（Section 6.4 of [HTTP]）。詳細は Section 2 を参照してください。

より高度なユースケースのために、選択された表現データにハッシュアルゴリズムを適用して計算されるダイジェストを含むリクエスト・レスポンスのヘッダおよびトレーラフィールドとして Repr-Digest が定義されています（Section 3）。選択された表現に基づくことで、メッセージのコンテンツをリソースの表現と見なすために何らかの操作が必要な場合や、範囲リクエストのように部分的な表現を伝達する場合に適用しやすくなります（Section 14 of [HTTP] を参照）。

Content-Digest と Repr-Digest はハッシュアルゴリズムの柔軟性（アジリティ）をサポートします。Want-Content-Digest および Want-Repr-Digest フィールドは、それぞれ Content-Digest と Repr-Digest の受信に対する関心やアルゴリズムの優先を表現するために使用できます。

Content-Digest と Repr-Digest は総称して「Integrity fields（整合性フィールド）」と呼ばれます。Want-Content-Digest と Want-Repr-Digest は総称して「Integrity preference fields（整合性優先フィールド）」と呼ばれます。

整合性フィールドは Content-Encoding および Content-Type ヘッダフィールドに紐づきます。したがって、あるリソースは HTTP 経由で転送される際に複数の異なるダイジェスト値を持つことがあります。

整合性フィールドは HTTP メッセージやフィールド自体には適用されません。ただし、メタデータを保護するデジタル署名のような他のメカニズムと組み合わせることで、HTTP 交換のフェーズ全体や一部を保護することができます。例えば、HTTP Message Signatures [SIGNATURES] は整合性フィールドに署名するために使われ、HTTP コンテンツや表現データのカバレッジを提供できます。

本仕様は認証、認可、プライバシーの手段を定義しません。

[RFC3230] は HTTP の整合性のために Digest および Want-Digest フィールドを定義しました。また、「instance」や「instance manipulation」といった用語を導入し、選択された表現データ（Section 8.1 of [HTTP]）のような概念を説明しました。これらの概念は現在では HTTP セマンティクスとしてより普遍的に定義され実装されています。

実装の経験から、[RFC3230] の実装は「instance」の意味を一貫せず解釈してきたため、相互運用性の問題が生じていることがわかりました。最も一般的な問題は、ダイジェストを計算する際に（現在では）「メッセージコンテンツ」と呼ぶべきものを用いる誤りであり、本来意図されていた「表現データ」を用いるべきであった点に関するものです。興味深いことに、メッセージコンテンツのダイジェストが有益なユースケースもあるため、[RFC3230] に対する非準拠が意図的か非意図的かを判別するのは難しい場合があります。

そのような不一致や曖昧さに対処するため、本書は [RFC3230] を廃止します。本書で定義される Integrity フィールド（Section 2 および Section 3）および Integrity 優先フィールド（Section 4）は、現在の HTTP セマンティクスとより整合し、意図された用途を明確に表す名前になっています。

本書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、すべて大文字で表示されるときに限り BCP 14 ([RFC2119] および [RFC8174]) に記述されたとおりに解釈されます。

本書は拡張 ABNF（[RFC5234]）およびそれを更新する文献（[RFC7405]）を使用します。これには CR、LF、および CRLF の規則が含まれます。

本書は構文と解析の指定のために Section 3 of [STRUCTURED-FIELDS] からの用語（Boolean, Byte Sequence, Dictionary, Integer, List）を使用します。

本書中の "representation", "selected representation", "representation data", "representation metadata", "user agent", および "content" の定義は [HTTP] に従って解釈されます。

本書は長い行の折り畳み戦略として [FOLDING] を使用します。

ハッシュアルゴリズム名はその定義文書で用いられる大文字小文字を尊重します（例: SHA-1, CRC32c）。

HTTP メッセージはアルゴリズムを Algorithm Key（algorithms）で示します。本文で Algorithm Key に言及する場合、それは引用符で囲まれます（例: "sha", "crc32c"）。

"checksum" という用語はバイト列にアルゴリズムを適用した出力を表し、"digest" はフィールド内に含まれる値にのみ用います。

"Integrity fields" は Content-Digest と Repr-Digest の総称です。

"Integrity preference fields" は Want-Repr-Digest と Want-Content-Digest の総称です。

状態変更リクエストに含まれる表現がターゲットリソースを記述していない場合、表現ダイジェストは表現データに対して計算されることが MUST です。表現ダイジェストは完全な表現メタデータを必要とするため（Section 3 を参照）、これが唯一の選択になります。

レスポンスにおいて、

• 表現がリクエストのステータスを記述する場合、Repr-Digest は同梱された表現に対して計算されることが MUST です（Appendix B.8 を参照）；
• 参照されたリソースがある場合、Repr-Digest は参照されたリソースの選択された表現に対して計算されることが MUST です。これは同梱された表現とは異なる場合があり得ます。

後者の場合は、http のメソッドのセマンティクスに従って行われます。例えば Content-Location ヘッダフィールドを使用することがあります（Section 8.7 of [HTTP] を参照）。対照的に、Location ヘッダフィールドは表現メタデータではないため Repr-Digest に影響を与えません。

例えば PATCH リクエストでは、表現メタデータがパッチ文書を示すため、表現ダイジェストはパッチ文書に対して計算されます（Section 2 of [PATCH] を参照）。一方、レスポンスではパッチされたリソースの選択された表現に対して表現ダイジェストが計算されます。

状態変更メソッドが Content-Location ヘッダフィールドを返す場合、同梱の表現はその値で識別されるリソースを参照し、Repr-Digest はそれに応じて計算されます。例は Appendix B.7 に示されています。

本書は HTTP の表現データまたはコンテンツのデータ整合性を保護する仕組みを規定しますが、HTTP のヘッダやトレーラフィールド全体を保護するものではありません。

整合性フィールドは HTTP メッセージに対する悪意ある改ざんに対する一般的な保護を意図したものではありません。追加のセキュリティメカニズムがない場合、経路上の悪意ある行為者はダイジェスト値を完全に削除するか、改変した表現データやコンテンツに対して新しいダイジェスト値を計算して置き換えることができます。この攻撃は、TLS やデジタル署名（例えば HTTP Message Signatures [SIGNATURES]）と組み合わせることで軽減できます。

整合性フィールドは、実装上の誤り、望ましくない「変換プロキシ」（RFC 9110 セクション 7.7 を参照）、またはデータが複数のホップやシステム境界を通過する際に行われるその他の操作による表現データやコンテンツの改変を検出するのに役立ちます。単純なエンドツーエンドの表現データ整合性の仕組みでも、ユーザエージェントがリソース取得の成功を検証してから HTML パーサやビデオプレーヤー等に渡すことができる点で有用です。

これらのメカニズムのみを使用しても、複数ホップにわたる HTTP メッセージのメタデータが任意の段階で改変され得るため、完全なエンドツーエンドの整合性は提供されないことに注意してください。メタデータを保護する方法については セクション 6.3 を参照してください。

デジタル署名はチェックサムと組み合わせてメッセージの発信元の特定を確実にするために広く用いられます（[FIPS186-5]）。そのような署名は一つまたは複数の HTTP フィールドを保護できますが、整合性フィールドを含める場合には追加の考慮事項があります。

整合性フィールドと組み合わせるデジタル署名の型や形式には制限はありません。ひとつの方法として、HTTP Message Signatures [SIGNATURES] と組み合わせることが考えられます。

ダイジェストは明示的に「表現メタデータ」（例: Content-Type, Content-Encoding 等）の影響を受けます。整合性フィールドを保護する署名が他の「表現メタデータ」を保護していない場合、通信は改ざんに晒される可能性があります。例えば、攻撃者が Content-Type の値を操作して受信者でのダイジェスト検証を失敗させ、アプリケーションが表現にアクセスできないようにすることが考えられます。このような攻撃は両端のリソースを消費します。詳しくは セクション 3.2 も参照してください。

署名は整合性フィールドを適用する際に敵対的な環境と見なされることが多いでしょう（セクション 5 を参照）。Repr-Digest は署名と組み合わせた場合に興味深い可能性を提供します。例えば、送信するコンテンツがない場合に空文字列のダイジェストをメッセージに含め、それを署名すれば、受信者はコンテンツが事故や意図的な操作で追加されたかどうかを検出できます。逆のシナリオもサポートされます。コンテンツのための整合性フィールドを含めてそれに署名することにより、受信者はコンテンツが削除された箇所を検出できます。

整合性フィールドの任意の改変は署名検証に影響を与える可能性があります。改変の例としては、ダイジェストの重複除去や異なるフィールド値の結合などがあります（RFC 9110 セクション 5.2 を参照）。

整合性フィールドをトレーラセクションで送信する前に、送信者は仲介者がトレーラを削除することが明示的に許されている点を考慮すべきです（RFC 9110 セクション 6.5.2 を参照）。

整合性フィールドがトレーラセクションで使用される場合、フィールド値はコンテンツの後に受信されます。トレーラ前にコンテンツを先行処理するとダイジェスト検証ができず、無効なデータを処理してしまう可能性があります。

トレーラで整合性フィールドを使う利点の一つは、送信中にバイトをハッシュできる点です。しかし、コンテンツを処理する方法によってはこの利点が無効化されるアルゴリズムを設計することも可能です。例えば、Merkle Integrity Content Encoding [MICE] はコンテンツを逆順で処理することを要求します。これは完全なデータが利用可能でなければならないことを意味し、ヘッダに整合性フィールドを含める場合とトレーラに含める場合で処理差がほとんどなくなります。

コンテンツ符号化の仕組みはさまざまなエンコーディングパラメータをサポートすることがあり、同じ入力コンテンツが異なる出力を生むことがあります。例えば GZIP は複数の圧縮レベルをサポートします。こうしたエンコーディングパラメータは一般に表現メタデータとして伝達されません。例えば異なる圧縮レベルはすべて同じ "Content-Encoding: gzip" フィールドを使用します。ほかの例として、nonce やタイムスタンプに依存するエンコーディング（RFC 8188 の aes128gcm 等）があります。

コンテンツ符号化内に変動が存在し得るため、整合性フィールドが示すチェックサムは、全コンテンツを保存しない限り「保存時（at rest）」の整合性の証明として使用することはできません。

ハッシュアルゴリズムのセキュリティ特性は固定的ではありません。アルゴリズムの柔軟性（agility）は、実装が IANA の "Hash Algorithms for HTTP Digest Fields" レジストリからハッシュアルゴリズムを選択できる柔軟性を提供することで達成されます（セクション 7.2 を参照）。

弱いアルゴリズムからの移行は、Want-Content-Digest や Want-Repr-Digest を使ったハッシュアルゴリズムのネゴシエーション（セクション 4 を参照）や、送信側が複数のダイジェストを送信して受信側が選択する方法によってサポートされます。ダイジェストをセキュリティ目的で依存する受信者は、受け入れる最も弱いアルゴリズムの脆弱性に対して脆弱になります。複数の値を送信することは受信者がそれらを無視した場合にリソースを消費することになるため注意が必要です（セクション 3 を参照）。

アルゴリズムの柔軟性は強力なアルゴリズムへの移行を可能にしますが、弱いアルゴリズムの使用を防ぐものではありません。整合性フィールドはハッシュアルゴリズムのダウングレードや置換攻撃に対する緩和策を提供しません（RFC 6211 セクション 1 を参照）。そのような攻撃から守るために、エンドポイントはサポートするアルゴリズム集合を強いものに制限し、TLS やデジタル署名でフィールドの値を保護することが考えられます。

整合性フィールドの検証は計算資源を消費します。リソース枯渇を避けるため、実装はアルゴリズム種別、検証回数、コンテンツサイズの制限を設けることができます。そのような場合、検証を完全にスキップするか、より優先度の高いアルゴリズムの検証失敗を無視することでダウングレード攻撃の可能性が残ります（セクション 6.6 を参照）。

IANA は新しい "Hash Algorithms for HTTP Digest Fields" レジストリを <https://www.iana.org/assignments/http-digest-hash-alg/> に作成し、表 2 のエントリで初期 populated を行いました。新規登録の手順は セクション 5 に記載されています。

このレジストリは廃止されています。なぜなら本レジストリは Digest および Want-Digest フィールドと共に使用可能なアルゴリズムを列挙しており、これらは [RFC3230] によって定義されていましたが、RFC 9530 によって廃止されたためです。登録は閉じられていませんが、新規登録は代わりに Hash Algorithms for HTTP Digest Fields レジストリの使用が推奨されます。

この例では、メッセージコンテンツが完全な表現データを伝えます。したがってレスポンスでは、Content-Digest と Repr-Digest の両方が JSON オブジェクト {"hello": "world"}（LF に続く）に対して計算され、同じ値になります。

この例では、HEAD リクエストを使ってリソースのチェックサムを取得します。

レスポンスの Content-Digest フィールド値は空のコンテンツに対して計算されています。Repr-Digest は JSON オブジェクト {"hello": "world"}（LF に続く）に対して計算されていますが、コンテンツがないため表示されていません。

この例では、クライアントがレンジリクエストを行い、サーバが部分コンテンツで応答します。

NOTE: '\' line wrapping per RFC 8792

Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg=:

NOTE: '\' line wrapping per RFC 8792

Content-Digest: \
  sha-256=:jjcgBDWNAtbYUXI37CVG3gRuGOAjaaDRGpIUFsdyepQ=:

リクエストには同梱表現に対して計算された Repr-Digest フィールド値が含まれています。また、クライアントは Brotli 符号化をサポートすることを示す Accept-Encoding: br ヘッダーフィールドを含めています。

レスポンスには選択された表現が Brotli で符号化されていることを示す Content-Encoding: br が含まれます。したがって、Repr-Digest のフィールド値はリクエストと異なります。

表示の都合上、レスポンスボディは非表示文字を含むため 16 進エンコードされたバイト列として表示されています。

リクエストの Repr-Digest フィールド値は、同梱コンテンツ（LF に続く JSON オブジェクト {"hello": "world"}）に対して計算されています。

レスポンスの Repr-Digest フィールド値は、レスポンスにコンテンツが含まれない場合でも Content-Encoding: br を含む表現メタデータに依存します。

NOTE: '\' line wrapping per RFC 8792

PUT /items/123 HTTP/1.1
Host: foo.example
Content-Type: application/json
Content-Length: 19
Accept-Encoding: br
Repr-Digest: \
  sha-256=:RK/0qy18MlBSVnWgjwz6lZEWjP/lF5HF9bvEF8FabDg==:

{"hello": "world"}

レスポンスは異なるアルゴリズムを使った二つのダイジェスト値を含みます。

表示の都合上、レスポンスボディは非表示文字を含むため 16 進エンコードされたバイト列として表示されています。

リクエストの Repr-Digest フィールド値は同梱表現（LF に続く JSON オブジェクト {"title": "New Title"}）に対して計算されます（セクション 3.1 を参照）。

レスポンスに同梱された表現は複数行の JSON オブジェクト（LF に続く）で、Content-Location によって識別されるリソースを参照します（RFC 9110 セクション 6.4.2 を参照）。したがって、アプリケーションは Repr-Digest を Content-Location によって参照されるリソースと関連付けて使用できます。

リクエストの Repr-Digest フィールド値は同梱表現（LF に続く JSON オブジェクト {"title": "New Title"}）に対して計算されています（セクション 3.1 を参照）。

レスポンスに同梱された表現はリクエストの状態を記述しており、したがって Repr-Digest はその同梱表現に対して計算されます。これは複数行の JSON オブジェクト（LF に続く）です。

レスポンスの Repr-Digest は Location によって参照されるリソースと明示的な関係を持ちません。

このケースは、ターゲットリソースがターゲット URI を反映する POST リクエストに類似しています。

PATCH リクエストは application/merge-patch+json メディアタイプを使用します（RFC7396 を参照）。Repr-Digest はパッチ文書に対応するコンテンツ（LF に続く JSON オブジェクト {"title": "New Title"}）に対して計算されます。

レスポンスの Repr-Digest フィールド値は、パッチされたリソースの完全な表現に対して計算されます。これは複数行の JSON オブジェクト（LF に続く）です。

同じ Repr-Digest フィールド値を持ちコンテンツがない 204 No Content のレスポンスも妥当であったことに注意してください。その場合、Content-Digest は空コンテンツに対して計算されます。

エラーレスポンスでは、表現データは必ずしもターゲットリソースを参照するわけではありません。代わりにエラーの表現を参照します。

以下の例では、クライアントは図 26（PATCH リクエスト）の同じリクエストを /books/123 に送信してリソースをパッチしようとしました。しかし、リソースが存在しないためサーバは 404 を生成し、RFC9457 に従ってエラーを記述する本文を返します。

レスポンスの Repr-Digest フィールド値はこの同梱表現に対して計算されています。これは複数行の JSON オブジェクト（LF に続く）です。

オリジンサーバはストリーミング中にダイジェスト値を計算できるように、Repr-Digest をトレーラーフィールドとして送信することがあります。 これによりリソース消費を軽減できます。Repr-Digest のフィールド値は 付録 B.1 のものと同一です。Repr-Digest は一つ以上の転送符号化の使用と無関係となるよう設計されているためです（参照: セクション 3）。

以下の応答コンテンツでは、文字列 "\r\n" が CRLF バイトを表します。

クライアントはダイジェストを要求し "sha" を好むと示します。サーバはそれでも "sha-256" で応答して構いません。

クライアントはサポートする唯一のアルゴリズムとして "sha" を要求します。サーバは必ずしも "sha" を含む応答を返す義務はなく、別のアルゴリズムを使用します。

付録 C.2 はサーバがクライアントの優先ダイジェストアルゴリズムを無視する例です。代わりにサーバはリクエストを拒否して 4xx や 5xx のようなエラーステータスコードで応答することもできます。本仕様はステータスコード選択に関する要件を定めませんが、以下は一例を示しています。

この例ではクライアントは "sha" の Repr-Digest を要求し、サーバは問題の詳細（RFC9457）を含むエラーを返します。問題の詳細にはサーバがサポートするハッシュアルゴリズムの一覧が含まれます。これはあくまで例であり、本仕様はそのようなコンテンツの形式や要件を定義しません。