HTTP メッセージ署名

本書で使用されるキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", および "OPTIONAL" は、BCP 14（[RFC2119]、 [RFC8174]）に記載されたとおり、大文字で現れる場合に限り解釈されます。

"HTTP message", "HTTP request", "HTTP response", "target URI", "gateway", "header field", "intermediary", "request target", "trailer field", "sender", "method", および "recipient" といった用語は、[HTTP] で定義されているものとして使用します。

便宜上、本書では「署名」という語を、デジタル署名（公開鍵暗号を用いるもの）と鍵付き MAC（対称暗号を用いるもの）の両方を指すために使用します。同様に、動詞 "sign" はデジタル署名または鍵付き MAC の生成のいずれかを指します。特に公開鍵暗号による署名操作の出力を指す場合は「デジタル署名」と明示します。

本書は、データ型を指定するために RFC8941 Section 3 の用語（List, Inner List, Dictionary, Item, String, Integer, Byte Sequence, Boolean）を使用します。

本書は ABNF を用いていくつかの文字列構築を定義し、次の ABNF ルールを使用します：VCHAR, SP, DQUOTE, および LF。また、[STRUCTURED-FIELDS] のルール sf-string, inner-list, parameters、および [HTTP] と [HTTP/1.1] のルール field-content, obs-fold, obs-text を使用します。

HTTP Message Signature:

HTTP メッセージの一部または複数部分をカバーするデジタル署名または鍵付き MAC。単一の HTTP メッセージに複数の HTTP メッセージ署名が含まれることがあります。

Signer:

HTTP メッセージ署名を生成している、または生成したエンティティ。複数のエンティティが署名者として振る舞い、同一メッセージに別個の署名を付与することがあります。

Verifier:

HTTP メッセージに対する署名を検証している、または検証したエンティティ。HTTP メッセージ署名は複数回、潜在的に異なるエンティティによって検証され得ます。

HTTP Message Component:

HTTP メッセージの一部で、HTTP メッセージ署名によってカバー可能なもの。

Derived Component:

指定されたアルゴリズムや処理を用いて HTTP メッセージから導出される HTTP メッセージコンポーネント。詳細は Section 2.2 を参照。

HTTP Message Component Name:

フィールド名や導出コンポーネント名のように、HTTP メッセージコンポーネントの出所を識別する文字列。

HTTP Message Component Identifier:

HTTP メッセージコンポーネント名と任意のパラメータの組み合わせ。これは、特定の HTTP メッセージ署名およびそれが適用される HTTP メッセージに関して特定の HTTP メッセージコンポーネントを一意に識別します。

HTTP Message Component Value:

特定の HTTP メッセージにおける特定のコンポーネント識別子に関連付けられた値。コンポーネント値は HTTP メッセージから導出され、通常は正規化プロセスの対象となります。

Covered Components:

フィールド（Section 2.1）および導出コンポーネント（Section 2.2）に対する順序付けられた識別子の集合で、署名によってカバーされるメッセージコンポーネントの集合を示します。@signature-params 識別子自体は含まれません。この集合の順序は保存され、署名者と検証者の間で署名ベースの再構築を容易にするために伝達されます。

Signature Base:

署名者と検証者がカバーされたコンポーネント集合と HTTP メッセージを用いて生成するバイト列のシーケンス。署名ベースは暗号アルゴリズムによって処理され、HTTP メッセージ署名の生成または検証に用いられます。

HTTP Message Signature Algorithm:

署名と検証のプロセスを記述する暗号アルゴリズムで、HTTP_SIGN および HTTP_VERIFY プリミティブとして Section 3.3 で説明される方法で定義されます。

Key Material:

署名の生成または検証に必要な鍵素材。鍵素材は明示的な key identifier で識別されることが多く、署名者は使用した鍵を検証者に示すことができます。

Creation Time:

署名が生成された時点を署名者が主張するタイムスタンプ。

Expiration Time:

署名が検証者によってもはや受け入れられるべきでない時点を署名者が主張するタイムスタンプ。

Target Message:

HTTP メッセージ署名が適用される対象の HTTP メッセージ。

Signature Context:

HTTP メッセージコンポーネント値が取り出されるデータソース。コンテキストは対象メッセージおよび署名者または検証者が持つ追加情報（例：リクエストの完全なターゲット URI やレスポンスに関連するリクエストメッセージなど）を含み得ます。

"UNIX timestamp" という用語は、[POSIX.1] の Section 4.16 が呼ぶところの "seconds since the Epoch" を指します。

本書には部分的および完全な HTTP メッセージの非規範的な例が含まれます。いくつかの例では長い値の折り返しを示すために単一のトレーリングバックスラッシュ（\）を使用しています（[RFC8792]）。折り返しの行にある \ 文字および先頭の空白は値の一部ではありません。

HTTP は中継者によるメッセージ変換を許容し、場合によっては要求します。これは受信側が送信側のメッセージとビット単位で同一でないメッセージを受け取る結果をもたらす可能性があります。このような場合、受信者は送信者の生データのバイト列に対して完全性保護を検証することができません。なぜならデジタル署名や MAC の検証は、署名者と検証者がまったく同一の署名ベースを持っていることを必要とするからです。したがってメッセージの生バイト列を署名ベースの信頼できる出所として頼ることができない場合、署名者と検証者は各自のバージョンのメッセージから署名ベースを独立に作成する必要があり、そのためにはメッセージの意味を変えない安全な変更に対して回復力のあるメカニズムが必要です。

何が安全な変更であり何が安全でない変更かを厳密に定義するのは様々な理由で実用的でありません。アプリケーションは多様な方法で HTTP を使用し、特定のメッセージ内のある情報（例えばメッセージ内容、メソッド、あるいは特定のヘッダーフィールド）が重要かどうかで意見が分かれ得ます。したがって、汎用的な解決策は署名者が署名するメッセージコンポーネントをある程度制御できることを提供する必要があります。

HTTP アプリケーションは、完全な HTTP メッセージへのアクセスや制御が提供されない環境（例えばブラウザの JavaScript 環境）で動作しているか、あるいはプロトコルの詳細を抽象化するライブラリ（例：Java HTTP Client (HttpClient)）を使用していることがあります。これらのアプリケーションは、HTTP メッセージの完全な情報を持たない場合でも署名の生成と検証ができる必要があります。

• 異なるフィールド名を持つフィールドの順序入れ替え（RFC9110 Section 5.3）。
• 同一フィールド名のフィールドの結合（RFC9110 Section 5.2）。
• Connection ヘッダーに列挙されたフィールドの削除（RFC9110 Section 7.6.1）。
• 制御オプションを示すフィールドの追加（RFC9110 Section 7.6.1）。
• トランスファーコーディングの追加または削除（RFC9110 Section 7.7）。
• Via（RFC9110 Section 7.6.3）や Forwarded（RFC7239 Section 4）のようなフィールドの追加。
• HTTP バージョン間の変換（例：HTTP/1.x と HTTP/2 間の変換）。
• フィールド名、リクエスト URI スキーム、ホストなどの大文字小文字の変化（大文字小文字非区別の要素）。
• リクエストターゲットとオーソリティの変更であって、それらを合わせて適用してもメッセージのターゲット URI が変わらない場合の変更（RFC9110 Section 7.1 の定義に従う）。

• フィールド値の先頭や末尾の空白の使用、追加、または削除。
• フィールド値における obs-fold の使用、追加、または削除（RFC9112 Section 5.2）。

こうした種類の変換は、署名でカバーされたコンポーネントに対して行われても署名検証を妨げるべきではない変換として識別できます。さらに、署名でカバーされていないコンポーネントへのすべての変更は署名検証を妨げるべきではありません。

この種の変換の例とそれらがメッセージ署名に与える影響については、付録 B.4 を参照してください。

一方、カバーされたコンポーネントのフィールド値を解析して再直列化することや導出コンポーネントの値を変更するような変換は、署名がターゲットメッセージに対して有効でなくなる原因となり得ます。本仕様を適用するアプリケーションは、期待される変換がカバーコンポーネントの選択によって十分に扱われることを確保する必要があります。

• 期待され、かつカバーコンポーネントリストに含めることが要求されるコンポーネント識別子の集合（Section 2）および署名パラメータ（Section 2.3）。例えば、認可プロトコルは Authorization フィールドをカバーして認可資格情報を保護し、署名パラメータに created パラメータを含めることを要求するかもしれません。一方で、セマンティックに意味のある HTTP メッセージ内容を期待する API は、Content-Digest フィールド（[DIGEST]）の存在とカバーを要求し、さらに API 固有の値を持つ tag パラメータ（Section 2.3）を要求することがあります。
• 必須または期待されるカバーコンポーネントフィールドやパラメータの Structured Field タイプ（[STRUCTURED-FIELDS]）。
• 署名を検証するために使用する鍵素材を取得する手段。アプリケーションは通常、署名パラメータの keyid を使用して鍵を解決する規則を定義しますが、事前登録された署名者鍵など他の手段で適切な鍵が既知であることもあり得ます。
• 署名者が使用することを期待する署名アルゴリズムの集合と、検証者が受け付けるアルゴリズムの集合。
• 署名検証に用いる署名アルゴリズムが鍵素材とメッセージコンテキストに対して適切かどうか判定する手段。例えば、署名パラメータの alg によりアルゴリズムを明示する、鍵素材からアルゴリズムを導出する、あるいは事前設定されたアルゴリズムを使用する方式などが考えられます。
• 署名に用いられた鍵とアルゴリズムがメッセージの文脈に適切であることを判定する手段。例えば ECDSA のみを期待するサーバーは RSA 署名を拒否すべきですし、公開鍵暗号を期待するサーバーは対称暗号を拒否すべきです。
• HTTP メッセージおよびそのアプリケーション文脈からメッセージコンポーネントを導出する際の文脈を決定する手段。通常これは対象の HTTP メッセージ自体ですが、外部ホスト名など設定によって知られる追加情報を含むこともあります。
• Section 2.4 のメカニズムを用いてリクエストとレスポンスの結び付けが必要な場合、その結び付けのプロパティを提供するために必要となるリクエストメッセージとレスポンスメッセージのすべての要素。
• 署名が無効である、鍵素材が不適切である、有効期間が仕様外である、コンポーネント値が計算できない、または検証中にその他のエラーが発生した場合に、検証者が署名者に返すエラーメッセージとコード。例えば、署名が認証メカニズムとして用いられる場合、401（Unauthorized）や 403（Forbidden）といった HTTP ステータスコードが適切なことがあります。HTTP API の応答であれば、400（Bad Request）などのステータスコードに詳細を含めることができ、RFC7807/RFC9457 に従った問題詳細を用いて誤った鍵素材が使用されたことを示すこともできます。

これらのパラメータを選択する際、検証者が署名ベースを再現するために必要なすべての情報にアクセスできることを保証する必要があります。例えば、リバースプロキシの背後にあるサーバーは、導出コンポーネント @target-uri を利用するには元のリクエスト URI を知る必要があります（見かけ上のターゲット URI はリバースプロキシによって変更されるため）。また、レスポンスで署名を使用するアプリケーションは、クライアントが署名された部分（サーバーが req パラメータを使って署名したリクエストの部分を含む）にアクセスできることを確保する必要があります（Section 2.4参照）。

この種のプロファイリングの詳細はアプリケーションの範疇であり本仕様の範囲外ですが、いくつかの追加考慮事項はSection 7で議論されています。特に、必要なコンポーネント識別子の集合を選択する際には、カバレッジがアプリケーションに対して十分であることに注意する必要があります（Section 7.2.1 および Section 7.2.8 を参照）。本仕様はアプリケーション向けの完全なセキュリティシステムの一部のみを定義します。完全なシステムを構築する際にはセキュリティ分析を行うことが重要です。AWS Signature Version 4 [AWS-SIGv4] のような歴史的システムは適用例として参考になりますが、それらを参照したからといって HTTP メッセージ署名を用いるアプリケーションに対するセキュリティ分析の必要性が無くなるわけではありません。

HTTP フィールドのコンポーネント名は、そのフィールド名の小文字化した形式です（Section 5.1 of [HTTP] に定義）。HTTP フィールド名は大文字小文字を区別しませんが、実装はコンポーネント名として小文字化したフィールド名（例：content-type, date, etag）を使用しなければなりません（MUST）。

HTTP フィールドのコンポーネント値は、対象メッセージの指定されたヘッダーフィールドから取られるフィールド値です（Section 5.5 of [HTTP]）。この振る舞いは、以下に示す req や tr フラグ等の追加パラメータと規則によって上書きされない限り適用されます。多くのフィールドについて、フィールド値は [HTTP] が推奨するように ASCII 文字列であり、コンポーネント値はまさにその文字列です。実装によっては他のエンコーディングが存在し得るため、すべての非 ASCII フィールド値は署名ベースに追加される前に ASCII にエンコードされなければなりません（MUST）。問題のあるフィールド値をラップする手段としては、Section 2.1.3 で説明される bs パラメータがあります。

追加のパラメータや規則で上書きされない限り、HTTP フィールド値は Section 5.2 of [HTTP] に定義されたとおり単一の値に結合されなければなりません（MUST）。具体的には、同一フィールド名が複数回送信された場合、フィールド値は単一のカンマと単一の空白（"," + " "）で連結して結合する必要があります。中継者はカンマ間で任意の量の空白を使って値を結合することが許されるため、検証者がこの点を考慮していないと署名は失敗する可能性があります。堅牢性を高めるため、署名されたメッセージはカバーされたフィールドについて可能な限り単一インスタンスのみを含めることがRECOMMENDEDです。特にリストベースのフィールドは下述の厳密アルゴリズムに従って直列化された値を単一インスタンスとして含めると、中継者による変化を避けやすくなります。単一インスタンスで送れない場合は、署名者と検証者が下記の厳密アルゴリズムに基づいてすべての個別フィールド値を取り扱い結合することがRECOMMENDEDです。フィールドが Structured Field の List または Dictionary 型である場合、この効果は Section 2.1.1 に記述される厳密な Structured Field シリアライゼーションを要求することでより直接的に達成できます。

Set-Cookie のように（[COOKIE]）値の結合をこの方法で行えないフィールドもある点に注意してください（複数の入力から結合した出力が一意に解釈できない場合）。コンポーネント値は署名プロセスにより解析されることはなく、署名ベースの一部としてのみ使用されますが、結合値が曖昧になり得るため、こうしたフィールドを署名に含める際は注意が必要です。問題のあるフィールドをラップする手段としては Section 2.1.3 の bs パラメータがあります。この問題に関する詳細は Section 7.5.6 を参照してください。

1. メッセージ内の各インスタンスのフィールド値を、そのメッセージで出現する順序（または出現するであろう順序）で順序付きリストとして作成する。
2. リスト内の各アイテムの先頭および末尾の空白を取り除く。HTTP フィールド値は先頭および末尾の空白を含めてはならないため、準拠実装ではこの操作は無効操作になります。
3. 行内の obsolete line folding を取り除き、単一のスペース（" "）で置き換える（Section 5.2 of [HTTP/1.1] を参照）。この挙動は HTTP/1.1 固有であり、他の HTTP 版では内部折り返しを許容しない点に注意。
4. 各アイテムの間を単一のカンマ（","）と単一のスペース（" "）で連結する。

得られた文字列がそのフィールドのコンポーネント値になります。

中継者が変える可能性のある大文字小文字の違いなど、同等の意味を持つ複数の正当な直列化が存在する HTTP フィールドがある点に注意してください。そのようなフィールドを署名および処理するアプリケーションは、署名者と検証者が同一の値を導出できるように値の扱い方を検討しなければならないことがMUSTです（詳しくは Section 7.5.2 を参照）。

Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT
X-OWS-Header:   Leading and trailing whitespace.
X-Obs-Fold-Header: Obsolete
    line folding.
Cache-Control: max-age=60
Cache-Control:    must-revalidate
Example-Dict:  a=1,    b=2;x=1;y=2,   c=(a   b   c)

"host": www.example.com
"date": Tue, 20 Apr 2021 02:07:56 GMT
"x-ows-header": Leading and trailing whitespace.
"x-obs-fold-header": Obsolete line folding.
"cache-control": max-age=60, must-revalidate
"example-dict": a=1,    b=2;x=1;y=2,   c=(a   b   c)

X-Empty-Header:(SP)

署名ベース生成アルゴリズム（Section 2.5）によって、コロンとコンポーネント識別子の後に追加されるコロンと空白の後には空文字列値が直列化されます。

"x-empty-header":(SP)

sf

Structured Field 値の厳密なエンコードでコンポーネント値が直列化されることを示すブールフラグ（Section 2.1.1）。

key

辞書型 Structured Field から単一のメンバ値を選択するために使われる文字列パラメータ（Section 2.1.2）。

bs

個々のフィールド値が Byte Sequence データ構造でエンコードされてからコンポーネント値に結合されることを示すブールフラグ（Section 2.1.3）。

req

署名されたレスポンスに対して、コンポーネント値がレスポンス自体ではなくこのレスポンスを引き起こしたリクエストから導出されることを示すブールフラグ。なお、このパラメータはリクエストをターゲットとする導出コンポーネント識別子にも適用できます（Section 2.4）。

tr

メッセージのトレーラから値が取られることを示すブールフラグ（Section 6.5 of [HTTP] に定義）。このフラグがない場合、フィールド値はヘッダーフィールドから取られます（Section 6.3 of [HTTP]、および Section 2.1.4 を参照）。

複数のパラメータを同時に指定することはMAYですが、冗長または互換性のない組み合わせもあります。例えば、key パラメータは Dictionary アイテムに対して厳密な直列化を要求するため、sf の機能は key によって既にカバーされます。生のバイトを必要とする bs パラメータは、結合後の解析されたデータ構造を必要とする sf や key と互換性がありません。

追加のパラメータは Section 6.5 で設立された "HTTP Signature Component Parameters" レジストリで定義できます。

HTTP フィールドに加えて、制御データ、署名コンテキスト、または署名される HTTP メッセージのその他の側面から導出できるさまざまなコンポーネントがあります。そのような導出コンポーネントは、コンポーネント名、可能なパラメータ、メッセージターゲット、およびそのコンポーネント値の導出方法を定義することで署名ベースに含められます。

導出コンポーネント名は @ 文字で始まらなければならないことがMUSTです。これにより導出コンポーネント名は HTTP フィールド名（Section 5.1 に従い @ を含められない）と区別されます。HTTP メッセージ署名のプロセッサは導出コンポーネント名をフィールド名とは別に扱わなければなりません（Section 7.5.1 を参照）。

@method

リクエストで使用されたメソッド（Section 2.2.1）。

@target-uri

リクエストの完全なターゲット URI（Section 2.2.2）。

@authority

リクエストのターゲット URI のオーソリティ（Section 2.2.3）。

@scheme

リクエストのターゲット URI のスキーム（Section 2.2.4）。

@request-target

リクエストターゲット（Section 2.2.5）。

@path

リクエストのターゲット URI の絶対パス部分（Section 2.2.6）。

@query

リクエストのターゲット URI のクエリ部分（Section 2.2.7）。

@query-param

リクエストのターゲット URI の解析およびエンコードされたクエリパラメータ（Section 2.2.8）。

@status

レスポンスのステータスコード（Section 2.2.9）。

追加の導出コンポーネント名は "HTTP Signature Derived Component Names" レジストリ（Section 6.4）で定義されます。

導出コンポーネント値は署名の対象メッセージのコンテキストから取られます。このコンテキストにはメッセージ自体に関する情報（制御データなど）や、署名者や検証者が保持する追加の状態やコンテキストが含まれます。特に、レスポンスに署名する際には、署名者は req パラメータを使用して元のリクエストから導出された任意の導出コンポーネントを含めることができます（Section 2.4）。

request:

HTTP リクエストメッセージから導出された値およびその結果。Section 3.4 of [HTTP] を参照。ターゲットメッセージがレスポンスである場合、Section 2.4 で定義された req パラメータを用いることでリクエストをターゲットとする導出コンポーネントを含められる。

response:

HTTP レスポンスメッセージから導出された値およびその結果（Section 3.4 を参照）。

request, response:

リクエストメッセージまたはレスポンスメッセージのいずれから導出された値。

導出コンポーネント定義は適用可能なすべてのターゲットメッセージ型を定義しなければなりません（MUST）。

導出コンポーネント値は印刷可能文字とスペースに限定され、改行文字を含んではならないことがMUSTです。導出コンポーネント値は先頭または末尾に空白文字を持ってはなりません（MUST NOT）。

HTTP メッセージ署名には、カバーされたコンポーネントの順序付けられた集合や、署名作成のタイムスタンプ、検証鍵素材の識別子、およびその他のユーティリティを含む順序付けられたパラメータ集合など、署名の生成と検証に関するメタデータプロパティがあります。このメタデータは署名ベース内の特別なメッセージコンポーネントによって表され、他のメッセージコンポーネントとは若干異なる扱いを受けます。具体的には、署名パラメータのメッセージコンポーネントは署名ベースの最後の行として含めることがREQUIREDであり（Section 2.5）、このコンポーネント識別子自体を含めてどの署名でもカバーコンポーネントの集合内で列挙してはなりません（MUST NOT）。

署名パラメータのコンポーネント名は @signature-params です。

created:

作成時刻を UNIX タイムスタンプの Integer 型で示します。小数秒精度はサポートされません。このパラメータの包含はRECOMMENDEDです。

expires:

有効期限時刻を UNIX タイムスタンプの Integer 型で示します。小数秒精度はサポートされません。

nonce:

この署名のために生成されたランダムで一意な文字列値。

alg:

"HTTP Signature Algorithms" レジストリからの HTTP メッセージ署名アルゴリズムを String 値として示します。

keyid:

鍵素材の識別子を String 値として示します。

tag:

アプリケーション固有の署名タグを String 値として示します。これは特定のアプリケーションやプロトコルに関連する署名を識別するのに用いられます。

追加のパラメータは "HTTP Signature Metadata Parameters" レジストリ（Section 6.3）で定義できます。パラメータ群には一般的な順序はありませんが、一度特定のパラメータ集合に順序を選択するとその順序は署名パラメータ値を変更せずには変えられません。

1. 出力を空文字列とする。
2. @signature-params コンポーネント識別子自体を除いた、カバーされたコンポーネントのコンポーネント識別子の順序を決定する。いったん選択された順序は変更できません。この順序は署名ベースの作成に使用した順序と同一でなければなりません（MUST）。
3. カバーされたコンポーネントのコンポーネント識別子（すべてのパラメータを含む）を、String 値の順序付き Inner List として Section 4.1.1.1 の規則に従って直列化し、これを出力に追加する。コンポーネント識別子は自身のパラメータを含むことができ、これらのパラメータは順序付けられた集合である。あるコンポーネントのパラメータの順序が一度選択されると、その順序は変更できない。
4. 署名パラメータの順序を決定する。一度選択された順序は変更できない。
5. 利用可能な、またはこのメッセージ署名に使用されるパラメータを Section 4.1.1.2 の規則に従って Inner List に順序付けて追加する。
6. 出力が署名パラメータコンポーネント値を含む。

ここで Section 4.1.1.1 の Inner List の直列化をカバーコンポーネント値に使用するのは、Section 4.1 で議論される Signature-Input フィールドへの並列性を促進するためです。

NOTE: '\' line wrapping per RFC 8792

("@target-uri" "@authority" "date" "cache-control")\
  ;keyid="test-key-rsa-pss";alg="rsa-pss-sha512";\
  created=1618884475;expires=1618884775

HTTP メッセージは複数の署名を含み得ます（Section 4.3 を参照）が、単一の署名に使われる署名パラメータのみが各署名パラメータエントリに含まれる点に注意してください。

リクエストメッセージが署名されたレスポンスメッセージを生じさせる場合、署名者はコンポーネント識別子に req パラメータを追加することでリクエストメッセージの一部を署名ベースに含めることができます。

req

このコンポーネント値が署名対象のレスポンスメッセージではなく、このレスポンスを引き起こしたリクエストから導出されることを示すブールフラグ。

このパラメータは HTTP フィールドとリクエストをターゲットとする導出コンポーネントの両方に適用でき、同じ意味を持ちます。このパラメータを用いるメッセージコンポーネントのコンポーネント値は通常どおり計算されますが、データは署名が適用される対象のレスポンスメッセージの代わりにリクエストメッセージから引き出されます。

同じコンポーネント名は req パラメータの有無にかかわらず同一署名ベース内に含められてもよく（MAY）、それはリクエストメッセージとレスポンスメッセージの同名コンポーネントをそれぞれ示すことになります。

req パラメータはコンポーネント識別子に対して他のパラメータと組み合わせて用いることがMAYです（例えば Dictionary フィールドの key パラメータなど）。

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:

{"busy": true, "message": "Your call is very important to us"}

サーバーはレスポンスに対して自身の鍵で署名し、このアプリケーションにとって妥当な量のレスポンスをカバーするためにステータスコードやいくつかのヘッダーフィールドをカバーコンポーネントに含めます。加えて、サーバーはこのレスポンスを引き起こした元のリクエストメッセージから導出されたいくつかのコンポーネントをレスポンスのカバーコンポーネントに含めます。この例ではサーバーはリクエストのメソッド、オーソリティ、パス、および Content-Digest をレスポンス署名に含めています。リクエストとレスポンスの両方の Content-Digest がレスポンス署名に含まれています。この例のアプリケーションではクエリはレスポンスに関連がないと見なされ、カバーには含められていません。アプリケーションに応じて別の判断が行われるでしょう（Section 1.4 を参照）。

NOTE: '\' line wrapping per RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "content-digest";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:dMT/A/76ehrdBTD/2Xx8QuKV6FoyzEP/I9hdzKN8LQJLNgzU\
  4W767HK05rx1i8meNQQgQPgQp8wq2ive3tV5Ag==:

{"busy": true, "message": "Your call is very important to us"}

ここで使われている ECDSA 署名アルゴリズムは非決定論的であり、アルゴリズムを実行するたびに異なる署名値が生成されることに注意してください。提示された署名値は与えられた鍵に対して検証可能ですが、新たに生成された署名値が例と一致することは期待されません。詳細は Section 7.3.5 を参照してください。

リクエストからのコンポーネント値がレスポンスに繰り返されない場合、要求者はレスポンスがこれらのコンポーネント識別子パラメータを使って署名されている場合に検証できるよう、元のメッセージコンポーネント値を十分な期間保持しておくことがMUSTです。多くの場合、署名者がリクエストの任意の部分をレスポンスに含める可能性があるため、要求者は元のリクエストメッセージ自体を保持する必要があります。中継者がリクエストをサーバー処理前に変更できる可能性があるため、アプリケーションはそのように変更された値に署名してはならず、クライアントが結果の署名を検証できないようなことがないよう注意する必要があります。

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Type: application/json
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" "@query" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-rsa-pss"
Signature: sig1=:e8UJ5wMiRaonlth5ERtE8GIiEH7Akcr493nQ07VPNo6y3qvjdK\
  t0fo8VHO8xXDjmtYoatGYBGJVlMfIp06eVMEyNW2I4vN7XDAz7m5v1108vGzaDljr\
  d0H8+SJ28g7bzn6h2xeL/8q+qUwahWA/JmC8aOC9iVnwbOKCc0WSrLgWQwTY6VLp4\
  2Qt7jjhYT5W7/wCvfK9A1VmHH1lJXsV873Z6hpxesd50PSmO+xaNeYvDLvVdZlhtw\
  5PCtUYzKjHqwmaQ6DEuM8udRjYsoNqp2xZKcuCO1nKc0V3RjpqMZLuuyVbHDAbCzr\
  0pg2d2VM/OC33JAU7meEjjaNz+d7LWPg==:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

"@status": 503
"content-digest": sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObf\
  wnHJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
"content-type": application/json
"@authority";req: example.com
"@method";req: POST
"@path";req: /foo
"@query";req: ?param=Value&Pet=dog
"content-digest";req: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A\
  2svX+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type";req: application/json
"content-length";req: 18
"@signature-params": ("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 503 Service Unavailable
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 62
Content-Digest: sha-512=:0Y6iCBzGg5rZtoXS95Ijz03mslf6KAMCloESHObfwn\
  HJDbkkWWQz6PhhU9kxsTbARtY2PTBOzq24uJFpHsMuAg==:
Signature-Input: reqres=("@status" "content-digest" "content-type" \
  "@authority";req "@method";req "@path";req "@query";req \
  "content-digest";req "content-type";req "content-length";req)\
  ;created=1618884479;keyid="test-key-ecc-p256"
Signature: reqres=:C73J41GVKc+TYXbSobvZf0CmNcptRiWN+NY1Or0A36ISg6ym\
  dRN6ZgR2QfrtopFNzqAyv+CeWrMsNbcV2Ojsgg==:

{"busy": true, "message": "Your call is very important to us"}

ここでも ECDSA 署名アルゴリズムは非決定論的であるため、アルゴリズムを実行するたびに異なる署名値が生成されます。提示された署名値は与えられた鍵で検証できますが、新しく生成された署名値が例と一致することは期待されません。詳細は Section 7.3.5 を参照してください。

署名済みリクエストに対してレスポンスを署名するアプリケーションは、署名がカバーするコンポーネントのすべてを署名することにより、衝突攻撃の一部に対する十分なカバレッジと保護を提供することがSHOULD推奨されます（Section 7.3.7 を参照）。この例のサーバーはクライアントのリクエスト署名の Signature-Input フィールドに列挙されたすべてのコンポーネントをレスポンス署名に含めています。

リクエストメッセージの Signature と Signature-Input フィールドをレスポンスの署名コンポーネントに含めることは構文的には可能ですが、この慣行はNOT RECOMMENDEDです。署名の署名は期待されるような覆い下の遷移的カバレッジを提供せず、Section 7.3.7 で議論されるいくつかの攻撃に対して脆弱だからです。署名の処理成功や受領を安全に示す必要があるアプリケーションは、そのような信号を安全に送るための代替メカニズムを慎重に指定する必要があります。

このフラグを用いる場合、レスポンス署名はリクエストメッセージに含まれるものだけをカバーできることに注意してください。したがって、アプリケーションがリクエストのメッセージ内容をレスポンスの署名に含める必要がある場合、クライアントは Content-Digest フィールドのようなコンテンツをカバーする手段を含める必要があります。詳細は Section 7.2.8 を参照してください。

req パラメータはリクエストをターゲットとする署名に対しては使用してはなりません（MUST NOT）。

署名ベースは、署名でカバーされる正規化された HTTP メッセージコンポーネントを含む ASCII 文字列 [ASCII] です。署名ベース作成アルゴリズムへの入力は、順序付けられたカバーされたコンポーネント識別子の集合とそれらに関連付けられた値、および Section 2.3 で述べる追加の署名パラメータです。

コンポーネント識別子は、[STRUCTURED-FIELDS] の Section 4 で定義された厳密な直列化規則を用いて直列化されます。コンポーネント識別子はコンポーネント名を持ち、これは sf-string ABNF ルールで直列化された String Item 値です。コンポーネント識別子は定義されたパラメータを含むことがMAYあり、これらは parameters ABNF ルールで直列化されます。Section 2.3 で定義された署名パラメータ行も同様のパターンに従いますが、コンポーネント識別子は固定値の String Item でパラメータを持たず、コンポーネント値は常にオプションのパラメータを持つ Inner List になります。

つまり、コンポーネント名自体の直列化は二重引用符で囲まれ、その後にセミコロンで区切られたパラメータリストが続く形になることに注意してください。例: "cache-control"、"@authority"、"@signature-params"、または "example-dictionary";key="foo" のようになります。

signature-base = *( signature-base-line LF ) signature-params-line
signature-base-line = component-identifier ":" SP
    ( derived-component-value / *field-content )
    ; no obs-fold nor obs-text
component-identifier = component-name parameters
component-name = sf-string
derived-component-value = *( VCHAR / SP )
signature-params-line = DQUOTE "@signature-params" DQUOTE
     ":" SP inner-list

署名ベースを作成するために、署名者または検証者は署名のカバーされたコンポーネントそれぞれのコンポーネント識別子（およびそのパラメータ）に対するエントリを次のアルゴリズムに従って連結します。ここで説明されるすべてのエラーは、署名ベースを出力することなくただちにアルゴリズムを失敗させることがMUSTです。

1. 出力を空の文字列とする。

2. カバーされたコンポーネント集合内の各メッセージコンポーネント項目について（順に）:

   11.

   コンポーネント識別子（そのパラメータを含む）が既に署名ベースに追加されている場合、エラーを出す。

   12.

   該当するカバーコンポーネントのコンポーネント識別子を component-identifier ABNF ルールに従って直列化して追加する。注: この直列化はコンポーネント名を二重引用符で囲み、パラメータは引用符の外に追加する。

   13.

   単一のコロン（:）を追加する。

   14.

   単一の空白（" "）を追加する。

   15.

   コンポーネント識別子のためのコンポーネント値を決定する。

   • コンポーネント識別子に理解されないパラメータがある場合、エラーを出す。
   • bs と sf のように互いに矛盾するパラメータを含む場合、エラーを出す。
   • コンポーネント識別子に req パラメータが含まれ、かつターゲットメッセージがリクエストである場合、エラーを出す。
   • コンポーネント識別子に req パラメータが含まれ、かつターゲットメッセージがレスポンスである場合、コンポーネント値のコンテキストはそのレスポンスメッセージに関連するリクエストメッセージである。さもなければ、コンポーネント値のコンテキストはターゲットメッセージである。
   • コンポーネント名が "at" (@) で始まる場合、導出コンポーネントとして定義された特定の規則に従ってメッセージから値を導出する（Section 2.2 を参照）。既知の有効なパラメータがあればそれらを処理する。導出コンポーネント名が不明であるか、値が導出できない場合、エラーを出す。
   • コンポーネント名が "at" (@) で始まらない場合、Section 2.1 に記述されたとおり HTTP フィールド値を正規化し、既知の有効なパラメータを処理する。フィールドがメッセージ内で見つからない、またはコンテキスト内で値が取得できない場合、エラーを出す。

   16.

   カバーされたコンポーネントの正規化済みコンポーネント値を追加する。

   17.

   単一の改行（\n）を追加する。

3. 次に、Section 2.3 に従って署名パラメータコンポーネントを signature-params-line ルールに従って追加する:

   11.

   署名パラメータのコンポーネント識別子を component-identifier ルールに従って直列化して追加する。すなわち正確な値 "@signature-params"（二重引用符を含む）を追加する。

   12.

   単一のコロン（:）を追加する。

   13.

   単一の空白（" "）を追加する。

   14.

   Section 2.3 で定義されたとおり、署名パラメータの正規化済みコンポーネント値（パラメータを持つ Inner List Structured Field 値）を追加する。

4. 出力文字列に非 ASCII 文字が含まれている場合、エラーを出す [ASCII]。
5. 出力文字列を返す。

• 署名者または検証者が導出コンポーネント名を理解していない。
• コンポーネント名がメッセージに存在しないフィールドを指している、またはその値が不正である。
• コンポーネント識別子に不明なパラメータが含まれている、またはその識別子に適用できないパラメータが含まれている。
• コンポーネント識別子が Structured Field の直列化を示す（sf パラメータ経由）にもかかわらず、そのフィールドが Structured Field でない、または Structured Field の型が実装で不明である。
• コンポーネント識別子が Dictionary メンバー識別子であり、そのフィールドがメッセージに存在しない、Dictionary Structured Field でない、またはその値が不正である。
• コンポーネント識別子が Dictionary メンバー識別子や名前付きクエリパラメータ識別子であって、参照されるメンバーがコンポーネント値に存在しないか、その値が不正である。例えば識別子が "example-dict";key="c" であり、Example-Dict ヘッダの値が a=1, b=2 で c が存在しない場合など。

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18

{"hello": "world"}

上の例の署名ベースには表示を終えるための最後の改行は含まれておらず、本仕様の他の例の署名ベースにも同様である点に注意してください。

HTTP メッセージ署名の作成は、署名コンテキスト（ターゲットメッセージを含む）とアプリケーションの要件を入力として取り、出力として署名値と署名パラメータの集合を生成し、それらをメッセージに追加して検証者に伝達できるようにするプロセスです。

1. 署名者は、利用可能な署名アルゴリズムの集合から HTTP 署名アルゴリズムと鍵素材を選択する。利用可能なアルゴリズムの集合はアプリケーションにより決定され、本書の対象外である。署名者はアルゴリズムに適した鍵素材を選び、鍵サイズや形式などアルゴリズムで定義される要件に従わなければならない（MUST）。鍵とアルゴリズムの選択機構は本書の範囲外である。
2. 署名者は署名の作成時刻を現在時刻に設定する。
3. 該当する場合、署名者は署名の有効期限プロパティを署名が失効する時刻に設定する。期限は検証者へのヒントであり、署名者がその時刻以降署名に対する保証を行わないことを表す。適切な有効期限の長さやこのパラメータの処理要件はアプリケーション固有である。

4. 署名者は、署名でカバーするメッセージコンポーネントを表すコンポーネント識別子の順序付けられた集合を作成し、この集合に署名メタデータパラメータを付与する。この集合の直列化された値は、後に Section 4.1 で説明される Signature-Input フィールドの値として使用される。

   • 一度カバーコンポーネントの順序が決定されたら、その順序は署名の寿命の間変更してはならない（MUST NOT）。
   • 各カバーコンポーネント識別子は、署名コンテキスト内で（1）HTTP フィールド（Section 2.1）であるか、（2）Section 2.2 または "HTTP Signature Derived Component Names" レジストリに列挙された導出コンポーネントでなければならない（MUST）。
   • リクエストの署名者は、@method、@authority、@target-uri などのメッセージ制御データをカバーコンポーネントに含めることを SHOULD する。
   • 署名者は署名作成時刻を示すために created 署名メタデータパラメータを含めることを SHOULD する。
   • @signature-params 導出コンポーネント識別子はカバーコンポーネント識別子の一覧に存在してはならない（MUST NOT）。この導出コンポーネントは常に署名ベースの最後の行である必要があり、署名が常に自身のメタデータをカバーし、メタデータを置換できないことを保証する。
   • この集合に何を含め、どの順序にするかについての追加の指針は本書の範囲外である。
5. 署名者はこれらのパラメータと署名ベース作成アルゴリズム（Section 2.5）を用いて署名ベースを作成する。
6. 署名者は選択した署名アルゴリズムと選択した鍵素材を用いて HTTP_SIGN プリミティブ関数で署名ベースに署名する。HTTP_SIGN プリミティブおよび署名アルゴリズムの具体的な適用は Section 3.3 で定義される。
7. 署名関数のバイト配列出力が、Section 4.2 で定義される Signature フィールドに含める HTTP メッセージ署名出力値となる。

ここで使用されている RSA-PSS アルゴリズムは非決定論的であり、アルゴリズムを実行するたびに異なる署名値が生成されることに注意してください。提示された署名値は与えられた鍵に対して検証可能ですが、新たに生成された署名値が例と一致することは期待されません。詳細は Section 7.3.5 を参照してください。

HTTP メッセージ署名の検証は、署名コンテキスト（ターゲットメッセージ、特にその Signature および Signature-Input フィールドを含む）とアプリケーションの要件を入力として取り、出力として正の検証結果またはエラーを返すプロセスです。

1. Signature および Signature-Input フィールドを Sections 4.1 および 4.2 に従って解析し、検証すべき署名とそのラベルを抽出する。

   11.

   複数の署名値が存在する場合、このメッセージに対してどの署名を処理すべきかを検証者のポリシーと構成に基づいて決定する。適用可能な署名が見つからない場合、エラーを出す。

   12.

   選択した Signature フィールド値に対応する Signature-Input フィールド値（同じラベルを持つもの）がない場合、エラーを出す。

2. 選択した Signature-Input フィールドの値を parameterized Inner List として解析し、カバーされたコンポーネントの順序付けられたリストと署名パラメータを取得する。
3. 対応する Signature フィールドの値を解析して、検証すべき署名のバイト配列値を取得する。
4. 署名パラメータを調べ、本書およびアプリケーションが定義する追加要件（例えばどのメッセージコンポーネントが署名されるべきか）を満たしているか確認する（Section 3.2.1）。
5. この署名に対する検証鍵素材を決定する。鍵素材が静的設定や外部プロトコル交渉などの外部手段で既知である場合、検証者はその外部知識から鍵素材を取得する手法を用いる。もし署名パラメータで鍵が識別されている場合、検証者は鍵識別子を参照して適切な鍵素材を取得する。検証者は、そのコンテキストで鍵素材が信頼に足るかどうか判断しなければならない。検証者が知らないか信頼できない鍵、またはこの要求に対して一致しない鍵が識別された場合、検証はMUST失敗する。

6. 検証に適用するアルゴリズムを決定する:

   11.

   アプリケーションが既知とする許容アルゴリズムの集合から開始する。以下のいずれかの手順で選択されたアルゴリズムがこの集合に含まれない場合、署名検証は失敗する。

   12.

   アルゴリズムが静的設定や外部プロトコル交渉など外部手段で既知である場合、検証者はそのアルゴリズムを使用する。

   13.

   鍵素材からアルゴリズムが決定できる場合（例えば鍵値自体にアルゴリズムフィールドがある場合）、検証者はそのアルゴリズムを使用する。

   14.

   署名パラメータで "HTTP Signature Algorithms" レジストリの値を用いてアルゴリズムが明示されている場合、検証者は参照されたアルゴリズムを使用する。

   15.

   アルゴリズムが複数の場所で指定されている場合（例えば静的設定、署名パラメータの alg、鍵素材自身の組合せ）、解決されたアルゴリズムは同一でなければならない（MUST）。一致しない場合、検証者は検証を失敗させる（MUST）。

7. 受信した HTTP メッセージと解析した署名パラメータを用いて、Section 2.5 に定義されたアルゴリズムを使用して署名ベースを再作成する。@signature-params の入力値は、この署名のための Signature-Input フィールドの値を Section 2.3 に記述された規則に従って直列化したものになることに注意する。なお、これは Signature-Input フィールドのラベルを含まない。
8. 鍵素材がアルゴリズムに適切であれば、再計算した署名ベース、鍵素材、および署名値に対して適切な HTTP_VERIFY 暗号検証アルゴリズムを適用する。HTTP_VERIFY プリミティブおよびいくつかの具体的アルゴリズムは Section 3.3 に定義される。
9. 検証アルゴリズム関数の結果が暗号検証の最終結果となる。

上記のいずれかのステップが失敗またはエラーを出した場合、署名検証は失敗する。

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-length" "content-type")\
  ;created=1618884473;keyid="test-key-rsa-pss"
Signature: sig1=:HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrl\
  FrCGUDih47vAxi4L2YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxH\
  LMCy8uqK488o+9jrptQ+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSf\
  SvzPuBCh+ARHBmWuNo1UzVVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y\
  9TP5FsZYzHvDqbInkTNigBcE9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7\
  aXq6Am6sfOrpIC49yXjj3ae6HRalVc/g==:

{"hello": "world"}

さらに、少なくとも method、authority、path、content-digest、content-length、および content-type のエントリが署名されていること、並びに署名作成タイムスタンプが検証時に十分に新しいことという追加要件があると、検証は成功する。

HTTP メッセージ署名は、鍵素材、環境、および署名者と検証者のニーズに適した暗号デジタル署名または MAC 方法を使用しなければなりません（MUST）。本仕様は利用可能な署名アルゴリズムを厳密に制限するものではなく、これらの基本要件を満たす任意の署名アルゴリズムは HTTP メッセージ署名のアプリケーションで使用できる（MAY）ことに注意してください。

HTTP_SIGN (M, Ks)  ->  S

HTTP_VERIFY (M, Kv, S) -> V

以下の節では、いくつかの一般的な署名アルゴリズムを示し、これらの暗号プリミティブが上記の HTTP_SIGN および HTTP_VERIFY 定義にどのように対応するかを説明します。使用する方法は、明示的なアルゴリズム（alg）署名パラメータ（Section 2.3）で伝えるか、鍵素材への参照、または署名者と検証者の間の合意によって決定できます。alg パラメータで選択された署名アルゴリズムは、"HTTP Signature Algorithms" レジストリ（Section 6.2）の値を使用しなければなりません（MUST）。

NOTE: '\' line wrapping per RFC 8792

Signature-Input: sig1=("@method" "@target-uri" "@authority" \
  "content-digest" "cache-control");\
  created=1618884475;keyid="test-key-rsa-pss"

署名検証を容易にするため、Signature-Input フィールド値は署名ベースの @signature-params 値を生成する際に使用された直列化済みの値と同一であることがMUSTです（Section 2.3 を参照）。Structured Field 値ではリストの順序およびパラメータの順序が保持される必要があることに注意してください。

署名者は署名処理が完了した後にメッセージのコンテンツを署名するために Signature-Input フィールドをトレーラとして含めることがMAYです。しかし中継者はトレーラを削除することが許されるため（[HTTP]）、署名がメッセージから意図せず取り除かれるのを避けるために、Signature-Input フィールドはヘッダーフィールドとしてのみ含めることがRECOMMENDEDされます。

単一の HTTP メッセージに複数の Signature-Input フィールドを含めることがMAYです。署名ラベルはすべてのフィールド値にわたって一意でなければなりません（MUST）。

NOTE: '\' line wrapping per RFC 8792

Signature: sig1=:P0wLUszWQjoi54udOtydf9IWTfNhy+r53jGFj9XZuP4uKwxyJo\
  1RSHi+oEF1FuX6O29d+lbxwwBao1BAgadijW+7O/PyezlTnqAOVPWx9GlyntiCiHz\
  C87qmSQjvu1CFyFuWSjdGa3qLYYlNm7pVaJFalQiKWnUaqfT4LyttaXyoyZW84jS8\
  gyarxAiWI97mPXU+OVM64+HVBHmnEsS+lTeIsEQo36T3NFf2CujWARPQg53r58Rmp\
  Z+J9eKR2CD6IJQvacn5A4Ix5BUAVGqlyp8JYm+S/CWJi31PNUjRRCusCVRj05NrxA\
  BNFv3r5S9IXf2fYJK+eyW4AiGVMvMcOg==:

署名者は署名処理が完了した後に Signature フィールドをトレーラとして含めることがMAYです。しかし中継者はトレーラを削除することが許されるため（[HTTP]）、署名がメッセージから意図せず取り除かれるのを避けるために、Signature フィールドはヘッダーフィールドとしてのみ含めることがRECOMMENDEDされます。

単一の HTTP メッセージに複数の Signature フィールドを含めることがMAYです。署名ラベルはすべてのフィールド値にわたって一意でなければなりません（MUST）。

複数の異なる署名を単一のメッセージに含めることがMAYです。各異なる署名は一意のラベルを持たなければなりません（MUST）。これらの複数署名は同一の署名者によって追加されることも、複数の異なる署名者から来ることもあります。例えば、異なる検証者の能力をサポートするために同じメッセージコンポーネントに対して異なる鍵やアルゴリズムで複数署名を含めることや、リバースプロキシがクライアントの元の署名値に関する情報を転送時にフィールドに含める（クライアントの署名値に対する署名を含める）などが考えられます。

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
  +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length")\
  ;created=1618884475;keyid="test-key-ecc-p256"
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
  +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

"@method": POST
"@authority": origin.host.internal.example
"@path": /foo
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
  +TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-type": application/json
"content-length": 18
"forwarded": for=192.0.2.123;host=example.com;proto=https
"@signature-params": ("@method" "@authority" "@path" \
  "content-digest" "content-type" "content-length" "forwarded")\
  ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
  ;expires=1618884540

NOTE: '\' line wrapping per RFC 8792

S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+JH+8XY1I6+8Cy\
+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49GwiyUpZ10KHgOEe11s\
x3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7LB5YAv0RAGhB8tmpv7sFn\
Im9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtflzvZdXAsD3LH2TwevU+/PBPv0\
B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbLVdp770I6VHR6WfgS9ddzirrswsE1w\
5o0LV/g==

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: origin.host.internal.example
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Length: 18
Forwarded: for=192.0.2.123;host=example.com;proto=https
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Signature-Input: sig1=("@method" "@authority" "@path" \
    "content-digest" "content-type" "content-length")\
    ;created=1618884475;keyid="test-key-ecc-p256", \
  proxy_sig=("@method" "@authority" "@path" "content-digest" \
    "content-type" "content-length" "forwarded")\
    ;created=1618884480;keyid="test-key-rsa";alg="rsa-v1_5-sha256"\
    ;expires=1618884540
Signature: sig1=:X5spyd6CFnAG5QnDyHfqoSNICd+BUP4LYMz2Q0JXlb//4Ijpzp\
    +kve2w4NIyqeAuM7jTDX+sNalzA8ESSaHD3A==:, \
  proxy_sig=:S6ZzPXSdAMOPjN/6KXfXWNO/f7V6cHm7BXYUh3YD/fRad4BCaRZxP+\
    JH+8XY1I6+8Cy+CM5g92iHgxtRPz+MjniOaYmdkDcnL9cCpXJleXsOckpURl49G\
    wiyUpZ10KHgOEe11sx3G2gxI8S0jnxQB+Pu68U9vVcasqOWAEObtNKKZd8tSFu7\
    LB5YAv0RAGhB8tmpv7sFnIm9y+7X5kXQfi8NMaZaA8i2ZHwpBdg7a6CMfwnnrtf\
    lzvZdXAsD3LH2TwevU+/PBPv0B6NMNk93wUs/vfJvye+YuI87HU38lZHowtznbL\
    Vdp770I6VHR6WfgS9ddzirrswsE1w5o0LV/g==:

{"hello": "world"}

プロキシが元のメッセージからクライアントの Signature フィールド値や Signature-Input フィールドを新しい署名のカバーコンポーネントに含めることは可能ですが、署名値を署名することには既知の弱点があるためこれはNOT RECOMMENDEDです（詳しくは Section 7.3.7 を参照）。プロキシはクライアントの署名を検証できる立場にあり、プロキシが行うメッセージ変更はオリジンサーバーが見ると既存の署名を無効にします。この例では、オリジンサーバーが権限の変更を考慮するための追加情報を署名コンテキストに持っている可能性がありますが、この慣行には追加の設定と注意が必要です（Section 7.4.4 を参照）。別のアプリケーションでは、オリジンサーバーは元の署名自体を検証できないかもしれませんが、それでもプロキシがクライアントの署名を適切に検証したことを確認したい場合があります。署名の処理成功や受領を示す必要があるアプリケーションは、そのような信号を安全に送るための代替メカニズムを慎重に指定する必要があります。

Accept-Signature フィールドは Dictionary Structured Field（Section 3.2 of [STRUCTURED-FIELDS]）であり、ターゲット HTTP メッセージのメッセージコンポーネントから生成される 1 つ以上の要求されたメッセージ署名のメタデータを含みます。各メンバーは単一のメッセージ署名を記述します。メンバーのキーは、ターゲット HTTP メッセージのコンテキスト内で要求されたメッセージ署名を一意に識別するラベルです。

NOTE: '\' line wrapping per RFC 8792

Accept-Signature: sig1=("@method" "@target-uri" "@authority" \
  "content-digest" "cache-control");\
  keyid="test-key-rsa-pss";created;tag="app-123"

コンポーネント識別子のリストは、要求された署名に含まれるコンポーネント識別子の正確な集合（適用されるすべてのコンポーネントパラメータを含む）を示します。

created:

署名者に作成時刻を生成して含めることを要求します。このパラメータは署名要求として送信されるときは値を伴いません。

expires:

署名者に有効期限時刻を生成して含めることを要求します。このパラメータは署名要求として送信されるときは値を伴いません。

nonce:

署名者に、このパラメータの値をターゲット署名の nonce として含めることを要求します。

alg:

署名者に "HTTP Signature Algorithms" レジストリから示された署名アルゴリズムを使用してターゲット署名を作成することを要求します。

keyid:

署名者に示された鍵素材を使用してターゲット署名を作成することを要求します。

tag:

署名者にこのパラメータの値をターゲット署名の tag として含めることを要求します。

1. フィールド値を Dictionary として解析する。

2. Dictionary の各メンバーについて：

   11.

   キーは Section 4.1 に指定されているように、出力署名のラベルとして扱われます。

   12.

   メンバーの値を解析して、カバーされたコンポーネント識別子の集合を取得する。

   13.

   カバーされたコンポーネントがターゲットメッセージに適用可能であることを判定する。適用できない場合、処理は失敗しエラーを返す。

   14.

   要求されたパラメータ（署名アルゴリズムや鍵素材など）を処理する。要求されたパラメータが満たせないか、ターゲットメッセージに適切であると見なされるものと矛盾する場合、処理は失敗しエラーを返す。

   15.

   署名を完了するために必要な追加のパラメータを選択および生成する。

   16.

   ターゲットメッセージに対して HTTP メッセージ署名を作成する。

   17.

   Signature-Input および Signature フィールド値を作成し、それらをラベルに関連付ける。

3. 必要に応じて、Accept-Signature フィールドに見つからない一意のラベルを持つ追加の Signature-Input および Signature フィールド値を作成することができる。
4. すべてのラベル付き Signature-Input および Signature フィールド値を結合し、両方のフィールドをターゲットメッセージに付加する。

このプロセスにより、ターゲットメッセージに適用された署名は同一のラベルを持ち、同一のカバーコンポーネント集合を含み、要求されたすべてのパラメータを処理し、追加のパラメータを持つことがMAYあり得ます（ただし必須ではありません）。

Accept-Signature フィールドの受信者は、アプリケーションのパラメータに合致しない署名要求を無視してもよいことがMAYです。

ターゲットメッセージは、Accept-Signature フィールドで指定されていない追加の署名を含めることがMAYです。例えば、追加のメッセージコンポーネントをカバーするために、署名者は要求された署名の出力を含む追加コンポーネントを含む二番目の署名を作成することができます。

本書は HTTP 署名アルゴリズムを定義しており、IANA は "HTTP Signature Algorithms" という新しいレジストリを作成し管理します。初期値は Section 6.2.2 に示されています。将来の割り当てや既存割り当ての変更は Specification Required 登録ポリシー ([RFC8126]) を通じて行われます。

このレジストリに記載されたアルゴリズムは、この仕様のアプリケーションで使用可能な暗号アルゴリズムの一部を識別しますが、可能なアルゴリズムの網羅的リストを示すものでも、特定の用途に対する適合性を示すものでもありません。アプリケーションは、署名者と検証者が安全かつ決定論的にアルゴリズムのパラメータに合意できる限り、自分たちのニーズに合う任意のアルゴリズムを実装できます。アプリケーションがランタイムで特定のアルゴリズムを alg 署名パラメータで指示する必要がある場合、このレジストリはそのパラメータ値と特定のアルゴリズムとの対応を提供します。ただし、アルゴリズムの混同や置換攻撃を避けるために alg パラメータの使用には注意が必要です（Section 7 を参照）。

Status 値は標準化状況および IETF やセキュリティ関連の標準化団体（SDO）などの関連利害関係者の広い意見を反映すべきです。アルゴリズムが初めて登録される際、Designated Expert (DE) はアルゴリズムが一般的に安全であるとのコンセンサスがある場合に Status フィールドを "Active" に設定し、コンセンサスが得られていない実験的アルゴリズムなどの場合は "Provisional" に設定すべきです。将来登録されたアルゴリズムに欠陥が見つかった場合、レジストリ項目は更新され "Deprecated" とされることがあります。DE は登録に対する Status 値の説明と参照を含めることができ、特に非推奨となったアルゴリズムに対して重要です。

• 登録されたアルゴリズムが参照するアルゴリズムについて、すべてのパラメータ（例: ソルト、ハッシュ、必要な鍵長）が定義文書で固定されていることを確認する。
• アルゴリズム定義が HTTP_SIGN および HTTP_VERIFY プリミティブ関数を完全に特定し、すべての入力と出力が基礎となる暗号アルゴリズムにどのようにマッピングされるかを明確にすることを確認する。
• 既存の登録のエイリアスである登録は拒否する。
• すべての登録が Section 6.2.1 に示されたテンプレートに従うことを確認する。これには名前の長さが過度でないことを確認しつつ、固有で認識可能であることを含む。

本仕様は、アルゴリズム名に主要なパラメータを含めることで開発者にとって識別しやすくする識別子を作成します。しかし、このレジストリ内のアルゴリズム識別子は文字列全体として解釈され、部分ごとに分解してパラメータを決定するものではありません。例えば rsa-pss-sha512 を、ハッシュやマスク、ソルト値が定義文書で定められた特定のアルゴリズムを指すものとして理解することが期待されています。

本書は署名パラメータ構造（Section 2.3）を定義します。IANA は "HTTP Signature Metadata Parameters" という新しいレジストリを作成し、署名パラメータ構造のメンバー値で使用されるパラメータを記録・管理します。初期値は Section 6.3.2 に示されています。将来の割り当てや変更は Expert Review 登録ポリシー ([RFC8126]) を通じて行われます。

• 名前が Section 6.3.1 に示されたテンプレートに従うことを確認する（長さが過度でないこと、一意かつ認識可能であることを含む）。
• 定義された機能が明確であり他の登録済みパラメータと矛盾しないことを確認する。
• メタデータパラメータの定義が、通常の署名プロセスで使用される場合と Accept-Signature フィールドで使用される場合の両方における振る舞いを含むことを確認する。

本書は HTTP メッセージコンポーネントを正規化する方法を定義しており、HTTP フィールド外のコンテキストから導出できるコンポーネントも含みます。これらの導出コンポーネントはコンポーネント名という一意の文字列で識別されます。導出コンポーネント名は常に "at"（@）記号で始まり、HTTP フィールド名と区別されます。IANA は "HTTP Signature Derived Component Names" という新しいレジストリを作成し、非フィールドのコンポーネント名とそれらに関連するコンポーネント値を生成する方法を記録・管理します。初期値は Section 6.4.2 に示されています。将来の割り当てや変更は Expert Review 登録ポリシー ([RFC8126]) を通じて行われます。

• Section 6.4.1 に示されたテンプレートに従うことを確認する（長さが過度でないこと、一意かつ認識可能であることを含む）。
• 登録要求が示すコンポーネント値がターゲット HTTP メッセージから決定論的に導出可能であることを確認する。
• 登録要求のために定義されたパラメータがそれらのコンポーネント値に与える影響を明確に文書化することを確認する。

DE は、登録が既存の導出コンポーネント定義と十分に区別されていることを確認すべきです。

登録項目のステータスを "Deprecated" に設定する際、DE は非推奨の理由と非推奨機能から移行するための指示を文書化するべきです。

本書は複数の種類のコンポーネント識別子を定義しており、そのうちいくつかは特定の状況でパラメータ化され、固有の修正された振る舞いを提供することができます。IANA は "HTTP Signature Component Parameters" という新しいレジストリを作成し、現在これを維持しており、パラメータ名、それらが関連付けられるコンポーネント識別子、およびこれらのパラメータがコンポーネント値に対して行う変更を記録・管理します。パラメータの定義は、適用対象（特定のフィールド型、導出コンポーネント、またはコンテキストなど）を定義しなければなりません（MUST）。このレジストリの初期値は Section 6.5.2 に示されています。将来の割り当ておよび既存の割り当ての修正は Expert Review 登録ポリシーに従って行われます（[RFC8126]）。

• 名前が Section 6.5.1 に示されたテンプレートに従っていることを確認する。これは、名前の長さが過度にならない一方で、その定義された機能に対して一意で認識可能であることを確保することを含みます。
• 登録要求時に既知の他のパラメータとの相互作用や非互換性を定義が十分に規定していることを確認する。
• パラメータがコンポーネント値を変更する場合、そのパラメータを適用したコンポーネント識別子によって定義されるコンポーネント値が、ターゲットの HTTP メッセージから決定論的に導出可能であることを確認する。

もし署名者が複数の検証者に対して同じ鍵を使用するか、単一の検証者に対して時間を通じて同じ鍵を使用する場合、その鍵の継続的な使用によって署名者は検証者の集合全体にわたって追跡され得ます。暗号鍵は機能的に一意であることが意図されているため、同じ鍵を長期間使用することは複数のメッセージに同一の当事者が署名している強い指標になります。

多くのアプリケーションではこれは望ましい特性であり、HTTP メッセージ署名を署名者を検証者に対して認証する一部として使用できることを可能にします。しかしながら、署名者が気付かない意図しない追跡につながる可能性もあります。この種の追跡に対抗するため、署名者は通信している各検証者ごとに異なる鍵を使用するか、あるいは与えられた検証者にメッセージを送る際に鍵をローテーションすることができます。これらの方法は他の反トラッキング技術の必要性を否定するものではありません。

HTTP メッセージ署名は、署名によって保護される情報に対して機密性を提供しません。HTTP メッセージの内容、すべてのフィールドの値、および署名値自体は、メッセージにアクセスできる任意の当事者に平文で提示されます。

輸送レベルでの機密性を提供するためには、Section 7.1.2 で述べられているように TLS または同等の手段を使用できます。

エラー条件に関して開発者に有用なフィードバックを提供する必要性と、攻撃者に追加情報を与えないようにする必要性のバランスを取ることが重要です。例えば、無邪気で役立つサーバ実装がリソース要求に必要な鍵識別子を示そうとするかもしれません。もし誰かがその鍵を誰が管理しているかを知れば、リソースの存在と鍵で識別される当事者の間に相関関係を作ることができます。そのような情報へのアクセスは攻撃者が正当なリソース所有者をさらなる攻撃の標的にするために利用することができます。

本仕様の中核的設計理念は、署名でカバーされるすべてのメッセージコンポーネントが、検証者が署名ベースを再作成し署名を検証するために利用可能である必要があるということです。その結果、本仕様の適用が特定のフィールドの署名を要求する場合、検証者はそのフィールドの値にアクセスする必要があります。

例えば、仲介プロセッサを含む複雑なシステムでは、署名を壊すことを恐れて仲介者がプライバシーに敏感な情報をメッセージから削除できなくなるような驚くべき挙動を引き起こす可能性があります。この特定の状況を緩和する一つの方法は、仲介者自身が署名を検証し、その後メッセージを変更してプライバシーに敏感な情報を削除することです。仲介者はこの時点で自身の署名を追加して、次の宛先に対して受信した署名が検証されたことを示すことができます。これは Section 4.3 の例に示されています。

この節では、文書内の例示署名で参照される暗号鍵を示します。これらの鍵はテスト以外の目的で使用してはなりません（MUST NOT）。

各鍵の鍵識別子は本仕様の例全体で使用されます。これらの例において、署名者と検証者はここで使用されるすべての鍵識別子を一意に参照でき、使用される鍵とアルゴリズムが署名が提示される文脈に適していることが前提とされています。

openssl pkey -text

このコマンドは OpenSSL バージョン 1.1.1m ですべての例示鍵でテストされました。いくつかのシステムではこれらの鍵を直接生成または使用できない場合があり、追加の処理が必要になることがあります。すべての鍵は JWK 形式でも利用可能です。

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Digest: sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX+T\
  aPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
Content-Length: 18

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

HTTP/1.1 200 OK
Date: Tue, 20 Apr 2021 02:07:56 GMT
Content-Type: application/json
Content-Digest: sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ41Q\
  JgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==:
Content-Length: 23

{"message": "good dog"}

この例では、リソースの前に TLS 終端を持つリバースプロキシが存在します。クライアントはリクエストに署名せず、代わりに相互 TLS を使って呼び出します。終端プロキシは TLS ストリームを検証し、[CLIENT-CERT] に従って Client-Cert ヘッダーフィールドを注入し、その後このフィールドに署名を適用します。このヘッダーフィールドに署名することで、リバースプロキシは初期リクエストの TLS パラメータを自ら検証したことを示すだけでなく、クライアントの動作とは独立してバックエンドシステムに対して自身を認証することができます。

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: example.com
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
  BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
  AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\
  wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\
  C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\
  R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\
  8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\
  4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\
  bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

"@path": /foo
"@query": ?param=Value&Pet=dog
"@method": POST
"@authority": service.internal.example
"client-cert": :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQ\
  KDBJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBD\
  QTAeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDM\
  FkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXm\
  ckC8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQY\
  DVR0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8B\
  Af8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQ\
  GV4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0\
  Q6bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
"@signature-params": ("@path" "@query" "@method" "@authority" \
  "client-cert");created=1618884473;keyid="test-key-ecc-p256"

NOTE: '\' line wrapping per RFC 8792

xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6Mce9315T6xoklyy0y\
zhD9ah4JHRwMLOgmizw==

NOTE: '\' line wrapping per RFC 8792

POST /foo?param=Value&Pet=dog HTTP/1.1
Host: service.internal.example
Date: Tue, 20 Apr 2021 02:07:55 GMT
Content-Type: application/json
Content-Length: 18
Client-Cert: :MIIBqDCCAU6gAwIBAgIBBzAKBggqhkjOPQQDAjA6MRswGQYDVQQKD\
  BJMZXQncyBBdXRoZW50aWNhdGUxGzAZBgNVBAMMEkxBIEludGVybWVkaWF0ZSBDQT\
  AeFw0yMDAxMTQyMjU1MzNaFw0yMTAxMjMyMjU1MzNaMA0xCzAJBgNVBAMMAkJDMFk\
  wEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE8YnXXfaUgmnMtOXU/IncWalRhebrXmck\
  C8vdgJ1p5Be5F/3YC8OthxM4+k1M6aEAEFcGzkJiNy6J84y7uzo9M6NyMHAwCQYDV\
  R0TBAIwADAfBgNVHSMEGDAWgBRm3WjLa38lbEYCuiCPct0ZaSED2DAOBgNVHQ8BAf\
  8EBAMCBsAwEwYDVR0lBAwwCgYIKwYBBQUHAwIwHQYDVR0RAQH/BBMwEYEPYmRjQGV\
  4YW1wbGUuY29tMAoGCCqGSM49BAMCA0gAMEUCIBHda/r1vaL6G3VliL4/Di6YK0Q6\
  bMjeSkC3dFCOOB8TAiEAx/kHSB4urmiZ0NX5r5XarmPk0wmuydBVoU4hBVZ1yhk=:
Signature-Input: ttrp=("@path" "@query" "@method" "@authority" \
  "client-cert");created=1618884473;keyid="test-key-ecc-p256"
Signature: ttrp=:xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6\
  Mce9315T6xoklyy0yzhD9ah4JHRwMLOgmizw==:

{"hello": "world"}

内部サービスはプロキシの署名を検証できるため、クライアントの証明書が適切に処理されたことを信頼できます。

HTTP は仲介者やアプリケーションがメッセージの意味を変えずに HTTP メッセージを変換することを許容します。HTTP メッセージ署名は、さまざまな状況でこれらの変換に対して堅牢になるよう設計されています。

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

"@method": GET
"@path": /demo
"@authority": example.org
"accept": application/json, */*
"@signature-params": ("@method" "@path" "@authority" "accept")\
  ;created=1618884473;keyid="test-key-ed25519"

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2&param=added HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Accept-Language: en-US,en;q=0.5
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Referer: https://developer.example.org/demo
Accept: application/json, */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Accept: application/json
Accept: */*
Date: Fri, 15 Jul 2022 14:24:55 GMT
Host: example.org
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

POST /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.com
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: application/json
Accept: */*
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:

NOTE: '\' line wrapping per RFC 8792

GET /demo?name1=Value1&Name2=value2 HTTP/1.1
Host: example.org
Date: Fri, 15 Jul 2022 14:24:55 GMT
Accept: */*
Accept: application/json
Signature-Input: transform=("@method" "@path" "@authority" \
  "accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
  Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==: