7.2.8. メッセージ本文 (Message Content)
7.2.8. メッセージ本文 (Message Content)
本仕様単体では, リクエストでもレスポンスでも, 署名の下での HTTP メッセージの本文はカバーしない. しかし, [DIGEST] は本文の暗号学的ダイジェストをフィールドで表現できる一組のフィールドを定義する. このフィールドが一度作成されれば, 2.1 節で定義される他のフィールドと同様に含められる.
例えば, 次のレスポンスメッセージでは:
HTTP/1.1 200 OK Content-Type: application/json
{"hello": "world"}
本文のダイジェストを Content-Digest フィールドに次のように追加できる:
NOTE: RFC 8792 に従う '' による行折り返し
HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest:
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
{"hello": "world"}
このフィールドは, 基本的な署名パラメータとともに, 他のフィールドと同様に署名ベースに含められる:
"@status": 200
"content-digest":
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
"@signature-input": ("@status" "content-digest")
ここからは, 署名プロセスは通常どおり進む.
検証時には, 検証者が署名だけでなく Content-Digest フィールドの値を実際に受信した本文に対しても検証することが重要である. この手順を行わない限り, 攻撃者はメッセージ本文を差し替えつつ Content-Digest フィールドの値を触らないままにして署名を通過させうる. 署名で直接カバーされるのはフィールドの値だけであるため, 署名だけを検査しても, そのような差し替え攻撃に対する十分な保護にはならない.
[DIGEST] で論じるとおり, Content-Digest フィールドの値はメッセージの content encoding に依存する. 中間者が content encoding を変更すると, 結果の Content-Digest の値も変わる. それにより署名は無効になる. そのような動作を行う中間者は, 4.3 節で論じるリバースプロキシのユースケースと同様に, 更新された Content-Digest フィールドの値で新しい署名を適用する必要がある.
req パラメータ (2.4 節) を用いるアプリケーションは, この機能の限界にも留意する必要がある. 特に, クライアントがリクエストに Content-Digest のようなヘッダフィールドを含めない場合, サーバーはリクエストの本文をカバーする署名を含められない.