メインコンテンツまでスキップ

1.4. Application of HTTP Message Signatures (HTTP メッセージ署名の適用)

1.4. Application of HTTP Message Signatures (HTTP メッセージ署名の適用)​

HTTP メッセージ署名は, 幅広い状況およびアプリケーションに適用可能な汎用ツールとして設計されている. HTTP メッセージ署名を適切かつ安全に適用するために, 本仕様のアプリケーションまたはプロファイルは, 最低限, 次のすべてを指定しなければならない.

  • 被覆コンポーネント一覧に含まれることが期待され必須であるコンポーネント識別子 (セクション 2) および署名パラメータ (セクション 2.3) の集合. 例えば, 認可プロトコルは認可資格情報を保護するために Authorization フィールドの被覆を義務付け, 署名パラメータに created パラメータ (セクション 2.3) の含有を義務付けてもよい. 意味的に関連する HTTP メッセージコンテンツを期待する API は, [DIGEST] で定義される Content-Digest フィールドの存在と被覆を要求し, 保護対象の API に固有の tag パラメータ (セクション 2.3) の値を義務付けてもよい.

  • 必須または期待される被覆コンポーネントのフィールドまたはパラメータについての, 期待される Structured Field 型 [STRUCTURED-FIELDS].

  • 署名の検証に用いる鍵素材 (key material) を取得する手段. アプリケーションは通常, 署名パラメータ (セクション 2.3) の keyid パラメータを用い, そこから鍵を解決する規則を定義するが, 適切な鍵は署名者の鍵の事前登録など他の手段で既知であってもよい.

  • 署名者が用いてよく, 検証者が受け入れる署名アルゴリズムの許容集合.

  • 署名の検証に用いた署名アルゴリズムが, 鍵素材およびメッセージの文脈に適切であると判断する手段. 例えば, 署名パラメータ (セクション 2.3) の alg パラメータでアルゴリズムを明示する, 鍵素材からアルゴリズムを導出する, または署名者と検証者が合意した事前設定のアルゴリズムを用いる, といった過程でよい.

  • 署名に用いた所与の鍵とアルゴリズムがメッセージの文脈に適切であると判断する手段. 例えば, ECDSA 署名のみを期待するサーバは RSA 署名を拒否すべきであることを知っていなければならない. 非対称暗号のみを期待するサーバは対称暗号を拒否すべきであることを知っていなければならない.

  • HTTP メッセージおよびアプリケーション文脈からメッセージ構成要素を導出するためのコンテキストを決定する手段. 通常これはターゲット HTTP メッセージ自身だが, コンテキストには外部ホスト名など設定を通じてアプリケーションが知る追加情報が含まれてもよい.

  • セクション 2.4 が提供する仕組みを用いてリクエストとレスポンスの間の束縛が必要な場合, そのような束縛の特性を提供するために必要となるリクエストメッセージおよびレスポンスメッセージのすべての要素.

  • 署名が無効である, 鍵素材が不適切である, 有効時間窓が仕様外である, コンポーネント値を計算できない, または署名検証過程でその他のエラーが発生したときに, 検証者から署名者に返すエラーメッセージおよびコード. 例えば, 署名を認証機構として用いる場合, HTTP ステータスコード 401 (Unauthorized) または 403 (Forbidden) が適切であってよい. レスポンスが HTTP API からのものである場合, HTTP ステータスコード 400 (Bad Request) などのレスポンスにより, 誤った鍵素材が用いられた旨などの詳細 [RFC7807] [RFC9457] を含めてもよい.

これらのパラメータを選ぶ際, HTTP メッセージ署名のアプリケーションは, 検証者が署名ベースを再現するために必要なすべての情報にアクセスできることを保証しなければならない. 例えば, リバースプロキシの背後のサーバは, 見かけの target URI がリバースプロキシによって変わる場合でも, 派生コンポーネント @target-uri を利用するために元のリクエスト URI を知る必要がある (セクション 7.4.3 も参照). また, レスポンスで署名を用いるアプリケーションは, 署名されたメッセージ部分すべて (サーバが req ("request-response") パラメータ (セクション 2.4) を用いてリクエストの部分に署名した場合はその部分を含む) に, 署名付きレスポンスを受け取るクライアントがアクセスできることを保証する必要がある.

この種のプロファイリングの詳細はアプリケーションの権限に属し本仕様の範囲外であるが, セクション 7 で追加の考慮事項が論じられる. 特に, 必須のコンポーネント識別子集合を選ぶ際には, セクション 7.2.1 および 7.2.8 で論じるとおり, アプリケーションにとってカバレッジが十分であるよう注意しなければならない. 本仕様はアプリケーションの完全なセキュリティシステムの一部のみを定義する. 本ツールに基づく完全なセキュリティシステムを構築する際には, HTTP メッセージ署名がその一部であるシステム全体のセキュリティ分析を実施することが重要である. AWS Signature Version 4 [AWS-SIGv4] のような過去のシステムは, 類似の仕組みをアプリケーションに適用する例や着想を提供し得るが, そのような過去のシステムの検討は, HTTP メッセージ署名のアプリケーションに対するセキュリティ分析の必要性を打ち消さない.

に最終更新