[要約] この文書は、HTTPメッセージの一部に対してデジタル署名やメッセージ認証コードを作成、エンコード、検証する仕組みを説明しています。この仕組みは、署名者が完全なHTTPメッセージを知らない場合や、メッセージが検証者に到達する前に変換される場合などの使用ケースをサポートします。また、この文書は、進行中のHTTP通信で後続のHTTPメッセージに署名が適用されるよう要求する手段についても説明しています。
Internet Engineering Task Force (IETF) A. Backman, Ed.
Request for Comments: 9421 Amazon
Category: Standards Track J. Richer, Ed.
ISSN: 2070-1721 Bespoke Engineering
M. Sporny
Digital Bazaar
February 2024
This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.
このドキュメントでは、HTTPメッセージのコンポーネントを介したデジタル署名またはメッセージ認証コードを作成、エンコード、および検証するメカニズムについて説明します。このメカニズムは、完全なHTTPメッセージが署名者に知られていない可能性があり、検証者に到達する前にメッセージが（例えば仲介者によって）変換される可能性のあるユースケースをサポートします。このドキュメントでは、進行中のHTTP交換で署名をその後のHTTPメッセージに適用するよう要求する手段についても説明しています。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9421.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9421で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Conventions and Terminology
1.2. Requirements
1.3. HTTP Message Transformations
1.4. Application of HTTP Message Signatures
2. HTTP Message Components
2.1. HTTP Fields
2.1.1. Strict Serialization of HTTP Structured Fields
2.1.2. Dictionary Structured Field Members
2.1.3. Binary-Wrapped HTTP Fields
2.1.4. Trailer Fields
2.2. Derived Components
2.2.1. Method
2.2.2. Target URI
2.2.3. Authority
2.2.4. Scheme
2.2.5. Request Target
2.2.6. Path
2.2.7. Query
2.2.8. Query Parameters
2.2.9. Status Code
2.3. Signature Parameters
2.4. Signing Request Components in a Response Message
2.5. Creating the Signature Base
3. HTTP Message Signatures
3.1. Creating a Signature
3.2. Verifying a Signature
3.2.1. Enforcing Application Requirements
3.3. Signature Algorithms
3.3.1. RSASSA-PSS Using SHA-512
3.3.2. RSASSA-PKCS1-v1_5 Using SHA-256
3.3.3. HMAC Using SHA-256
3.3.4. ECDSA Using Curve P-256 DSS and SHA-256
3.3.5. ECDSA Using Curve P-384 DSS and SHA-384
3.3.6. EdDSA Using Curve edwards25519
3.3.7. JSON Web Signature (JWS) Algorithms
4. Including a Message Signature in a Message
4.1. The Signature-Input HTTP Field
4.2. The Signature HTTP Field
4.3. Multiple Signatures
5. Requesting Signatures
5.1. The Accept-Signature Field
5.2. Processing an Accept-Signature
6. IANA Considerations
6.1. HTTP Field Name Registration
6.2. HTTP Signature Algorithms Registry
6.2.1. Registration Template
6.2.2. Initial Contents
6.3. HTTP Signature Metadata Parameters Registry
6.3.1. Registration Template
6.3.2. Initial Contents
6.4. HTTP Signature Derived Component Names Registry
6.4.1. Registration Template
6.4.2. Initial Contents
6.5. HTTP Signature Component Parameters Registry
6.5.1. Registration Template
6.5.2. Initial Contents
7. Security Considerations
7.1. General Considerations
7.1.1. Skipping Signature Verification
7.1.2. Use of TLS
7.2. Message Processing and Selection
7.2.1. Insufficient Coverage
7.2.2. Signature Replay
7.2.3. Choosing Message Components
7.2.4. Choosing Signature Parameters and Derived Components
over HTTP Fields
7.2.5. Signature Labels
7.2.6. Multiple Signature Confusion
7.2.7. Collision of Application-Specific Signature Tag
7.2.8. Message Content
7.3. Cryptographic Considerations
7.3.1. Cryptography and Signature Collision
7.3.2. Key Theft
7.3.3. Symmetric Cryptography
7.3.4. Key Specification Mixup
7.3.5. Non-deterministic Signature Primitives
7.3.6. Key and Algorithm Specification Downgrades
7.3.7. Signing Signature Values
7.4. Matching Signature Parameters to the Target Message
7.4.1. Modification of Required Message Parameters
7.4.2. Matching Values of Covered Components to Values in the
Target Message
7.4.3. Message Component Source and Context
7.4.4. Multiple Message Component Contexts
7.5. HTTP Processing
7.5.1. Processing Invalid HTTP Field Names as Derived
Component Names
7.5.2. Semantically Equivalent Field Values
7.5.3. Parsing Structured Field Values
7.5.4. HTTP Versions and Component Ambiguity
7.5.5. Canonicalization Attacks
7.5.6. Non-List Field Values
7.5.7. Padding Attacks with Multiple Field Values
7.5.8. Ambiguous Handling of Query Elements
8. Privacy Considerations
8.1. Identification through Keys
8.2. Signatures do not provide confidentiality
8.3. Oracles
8.4. Required Content
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Detecting HTTP Message Signatures
Appendix B. Examples
B.1. Example Keys
B.1.1. Example RSA Key
B.1.2. Example RSA-PSS Key
B.1.3. Example ECC P-256 Test Key
B.1.4. Example Ed25519 Test Key
B.1.5. Example Shared Secret
B.2. Test Cases
B.2.1. Minimal Signature Using rsa-pss-sha512
B.2.2. Selective Covered Components Using rsa-pss-sha512
B.2.3. Full Coverage Using rsa-pss-sha512
B.2.4. Signing a Response Using ecdsa-p256-sha256
B.2.5. Signing a Request Using hmac-sha256
B.2.6. Signing a Request Using ed25519
B.3. TLS-Terminating Proxies
B.4. HTTP Message Transformations
Acknowledgements
Authors' Addresses
Message integrity and authenticity are security properties that are critical to the secure operation of many HTTP applications. Application developers typically rely on the transport layer to provide these properties, by operating their application over TLS [TLS]. However, TLS only guarantees these properties over a single TLS connection, and the path between the client and application may be composed of multiple independent TLS connections (for example, if the application is hosted behind a TLS-terminating gateway or if the client is behind a TLS Inspection appliance). In such cases, TLS cannot guarantee end-to-end message integrity or authenticity between the client and application. Additionally, some operating environments present obstacles that make it impractical to use TLS (such as the presentation of client certificates from a browser) or to use features necessary to provide message authenticity. Furthermore, some applications require the binding of a higher-level application-specific key to the HTTP message, separate from any TLS certificates in use. Consequently, while TLS can meet message integrity and authenticity needs for many HTTP-based applications, it is not a universal solution.
メッセージの整合性と信頼性は、多くのHTTPアプリケーションの安全な動作に重要なセキュリティプロパティです。アプリケーション開発者は通常、TLS [TLS]を介してアプリケーションを操作することにより、これらのプロパティを提供するために輸送層に依存しています。ただし、TLSは単一のTLS接続でこれらのプロパティのみを保証し、クライアントとアプリケーションの間のパスは複数の独立したTLS接続で構成されている場合があります（たとえば、アプリケーションがTLS終了ゲートウェイの背後にホストされている場合、またはクライアントが遅れている場合TLS検査アプライアンス）。そのような場合、TLSは、クライアントとアプリケーションの間のエンドツーエンドのメッセージの完全性または信頼性を保証することはできません。さらに、一部の運用環境は、TLS（ブラウザからのクライアント証明書の表示など）を使用したり、メッセージの信頼性を提供するために必要な機能を使用することを非現実的にする障害を提示します。さらに、一部のアプリケーションでは、使用中のTLS証明書とは別に、HTTPメッセージへの高レベルのアプリケーション固有のキーを拘束する必要があります。その結果、TLSは多くのHTTPベースのアプリケーションのメッセージの整合性と信頼性のニーズを満たすことができますが、それは普遍的なソリューションではありません。
Additionally, many applications need to be able to generate and verify signatures despite incomplete knowledge of the HTTP message as seen on the wire, due to the use of libraries, proxies, or application frameworks that alter or hide portions of the message from the application at the time of signing or verification. These applications need a means to protect the parts of the message that are most relevant to the application without having to violate layering and abstraction.
さらに、ライブラリ、プロキシ、またはアプリケーションからの部分を変更または非表示にするアプリケーションフレームワークの使用により、ワイヤーに見られるように、HTTPメッセージの不完全な知識にもかかわらず、多くのアプリケーションが署名を生成および検証できる必要があります。署名または検証の時間。これらのアプリケーションには、レイヤー化と抽象化に違反することなく、アプリケーションに最も関連するメッセージの部分を保護する手段が必要です。
Finally, object-based signature mechanisms such as JSON Web Signature [JWS] require the intact conveyance of the exact information that was signed. When applying such technologies to an HTTP message, elements of the HTTP message need to be duplicated in the object payload either directly or through the inclusion of a hash. This practice introduces complexity, since the repeated information needs to be carefully checked for consistency when the signature is verified.
最後に、JSON Web署名[JWS]などのオブジェクトベースの署名メカニズムには、署名された正確な情報の無傷の伝達が必要です。そのようなテクノロジーをHTTPメッセージに適用する場合、HTTPメッセージの要素を直接またはハッシュを含めることにより、オブジェクトペイロードで複製する必要があります。この慣行は複雑さを導入します。これは、署名が検証されたときに繰り返される情報の一貫性を慎重にチェックする必要があるためです。
This document defines a mechanism for providing end-to-end integrity and authenticity for components of an HTTP message by using a detached signature on HTTP messages. The mechanism allows applications to create digital signatures or message authentication codes (MACs) over only the components of the message that are meaningful and appropriate for the application. Strict canonicalization rules ensure that the verifier can verify the signature even if the message has been transformed in many of the ways permitted by HTTP.
このドキュメントは、HTTPメッセージにデタッチされた署名を使用して、HTTPメッセージのコンポーネントにエンドツーエンドの完全性と信頼性を提供するメカニズムを定義します。このメカニズムにより、アプリケーションは、アプリケーションに有意義で適切なメッセージのコンポーネントのみを介してデジタル署名またはメッセージ認証コード（Mac）を作成できます。厳格な標準化規則は、メッセージがHTTPによって許可されている多くの方法で変換された場合でも、検証者が署名を検証できることを保証します。
The signing mechanism described in this document consists of three parts:
このドキュメントで説明されている署名メカニズムは、3つの部分で構成されています。
* A common nomenclature and canonicalization rule set for the different protocol elements and other components of HTTP messages, used to create the signature base (Section 2).
* 署名ベースを作成するために使用される、異なるプロトコル要素およびHTTPメッセージのその他のコンポーネントに合わせて、一般的な命名法および標準化ルールが設定されています（セクション2）。
* Algorithms for generating and verifying signatures over HTTP message components using this signature base through the application of cryptographic primitives (Section 3).
* 暗号化プリミティブの適用により、この署名ベースを使用してHTTPメッセージコンポーネント上の署名を生成および検証するためのアルゴリズム（セクション3）。
* A mechanism for attaching a signature and related metadata to an HTTP message and for parsing attached signatures and metadata from HTTP messages. To facilitate this, this document defines the "Signature-Input" and "Signature" fields (Section 4).
* 署名および関連するメタデータをHTTPメッセージに添付し、HTTPメッセージから添付の署名とメタデータを解析するメカニズム。これを容易にするために、このドキュメントは「署名入力」および「署名」フィールド（セクション4）を定義します。
This document also provides a mechanism for negotiating the use of signatures in one or more subsequent messages via the "Accept-Signature" field (Section 5). This optional negotiation mechanism can be used along with opportunistic or application-driven message signatures by either party.
このドキュメントは、「受け入れ署名」フィールド（セクション5）を介して、1つ以上の後続のメッセージで署名の使用を交渉するメカニズムも提供します。このオプションの交渉メカニズムは、いずれかの当事者による日和見的またはアプリケーション主導のメッセージ署名とともに使用できます。
The mechanisms defined in this document are important tools that can be used to build an overall security mechanism for an application. This toolkit provides some powerful capabilities but is not sufficient in creating an overall security story. In particular, the requirements listed in Section 1.4 and the security considerations discussed in Section 7 are of high importance to all implementors of this specification. For example, this specification does not define a means to directly cover HTTP message content (defined in Section 6.4 of [HTTP]); rather, it relies on the Digest specification [DIGEST] to provide a hash of the message content, as discussed in Section 7.2.8.
このドキュメントで定義されているメカニズムは、アプリケーションの全体的なセキュリティメカニズムを構築するために使用できる重要なツールです。このツールキットはいくつかの強力な機能を提供しますが、全体的なセキュリティストーリーを作成するのに十分ではありません。特に、セクション1.4にリストされている要件とセクション7で説明されているセキュリティ上の考慮事項は、この仕様のすべての実装者にとって非常に重要です。たとえば、この仕様では、HTTPメッセージコンテンツを直接カバーする手段を定義するものではありません（[http]のセクション6.4で定義）。むしろ、セクション7.2.8で説明したように、メッセージコンテンツのハッシュを提供するために、ダイジェスト仕様[ダイジェスト]に依存しています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The terms "HTTP message", "HTTP request", "HTTP response", "target URI", "gateway", "header field", "intermediary", "request target", "trailer field", "sender", "method", and "recipient" are used as defined in [HTTP].
「HTTPメッセージ」、「HTTP要求」、「HTTP応答」、「ターゲットURI」、「ゲートウェイ」、「ヘッダーフィールド」、「仲介者」、「リクエストターゲット」、「トレーラーフィールド」、「送信者」、「送信者」という用語という用語メソッド」、および「受信者」は[http]で定義されているように使用されます。
For brevity, the term "signature" on its own is used in this document to refer to both digital signatures (which use asymmetric cryptography) and keyed MACs (which use symmetric cryptography). Similarly, the verb "sign" refers to the generation of either a digital signature or keyed MAC over a given signature base. The qualified term "digital signature" refers specifically to the output of an asymmetric cryptographic signing operation.
簡潔にするために、このドキュメントで「署名」という用語は、デジタル署名（非対称暗号化を使用）とキー付きMac（対称暗号化を使用）の両方を参照するために使用されます。同様に、動詞の「符号」とは、特定の署名ベースにわたるデジタル署名またはキー付きMacの生成を指します。適格な用語「デジタル署名」とは、非対称暗号化署名操作の出力を特に指します。
This document uses the following terminology from Section 3 of [STRUCTURED-FIELDS] to specify data types: List, Inner List, Dictionary, Item, String, Integer, Byte Sequence, and Boolean.
このドキュメントでは、[構造化場]のセクション3の次の用語を使用して、リスト、内側リスト、辞書、アイテム、文字列、整数、バイトシーケンス、ブール波のデータ型を指定します。
This document defines several string constructions using ABNF [ABNF] and uses the following ABNF rules: VCHAR, SP, DQUOTE, and LF. This document uses the following ABNF rules from [STRUCTURED-FIELDS]: sf-string, inner-list, and parameters. This document uses the following ABNF rules from [HTTP] and [HTTP/1.1]: field-content, obs-fold, and obs-text.
このドキュメントは、ABNF [ABNF]を使用していくつかの文字列構成を定義し、次のABNFルールを使用します：VCHAR、SP、DQUOTE、およびLF。このドキュメントでは、[構造化場]の次のABNFルールを使用しています：SFストリング、内リスト、およびパラメーター。このドキュメントでは、[http]および[http/1.1]の次のABNFルールを使用します。フィールドコンテンツ、obs倍、およびobs-textです。
In addition to those listed above, this document uses the following terms:
上記のものに加えて、このドキュメントは次の用語を使用しています。
HTTP Message Signature:
HTTPメッセージ署名：
A digital signature or keyed MAC that covers one or more portions of an HTTP message. Note that a given HTTP message can contain multiple HTTP message signatures.
HTTPメッセージの一部または複数の部分をカバーするデジタル署名またはキー付きMac。特定のHTTPメッセージには、複数のHTTPメッセージ署名が含まれることに注意してください。
Signer:
歌手：
The entity that is generating or has generated an HTTP message signature. Note that multiple entities can act as signers and apply separate HTTP message signatures to a given HTTP message.
HTTPメッセージの署名を生成または生成しているエンティティ。複数のエンティティが署名者として機能し、特定のHTTPメッセージに個別のHTTPメッセージ署名を適用できることに注意してください。
Verifier:
Verifier：
An entity that is verifying or has verified an HTTP message signature against an HTTP message. Note that an HTTP message signature may be verified multiple times, potentially by different entities.
HTTPメッセージに対してHTTPメッセージ署名を検証または確認しているエンティティ。HTTPメッセージ署名は、潜在的に異なるエンティティによって複数回検証される場合があることに注意してください。
HTTP Message Component:
HTTPメッセージコンポーネント：
A portion of an HTTP message that is capable of being covered by an HTTP message signature.
HTTPメッセージの署名でカバーできるHTTPメッセージの一部。
Derived Component:
派生コンポーネント：
An HTTP message component derived from the HTTP message through the use of a specified algorithm or process. See Section 2.2.
指定されたアルゴリズムまたはプロセスを使用して、HTTPメッセージから派生したHTTPメッセージコンポーネント。セクション2.2を参照してください。
HTTP Message Component Name:
HTTPメッセージコンポーネント名：
A String that identifies an HTTP message component's source, such as a field name or derived component name.
フィールド名や派生コンポーネント名など、HTTPメッセージコンポーネントのソースを識別する文字列。
HTTP Message Component Identifier:
HTTPメッセージコンポーネント識別子：
The combination of an HTTP message component name and any parameters. This combination uniquely identifies a specific HTTP message component with respect to a particular HTTP message signature and the HTTP message it applies to.
HTTPメッセージコンポーネント名とパラメーターの組み合わせ。この組み合わせは、特定のHTTPメッセージ署名と適用されるHTTPメッセージに関して、特定のHTTPメッセージコンポーネントを一意に識別します。
HTTP Message Component Value:
HTTPメッセージコンポーネント値：
The value associated with a given component identifier within the context of a particular HTTP message. Component values are derived from the HTTP message and are usually subject to a canonicalization process.
特定のHTTPメッセージのコンテキスト内で、特定のコンポーネント識別子に関連付けられた値。コンポーネント値はHTTPメッセージから導出され、通常は標準化プロセスの対象となります。
Covered Components:
対象コンポーネント：
An ordered set of HTTP message component identifiers for fields (Section 2.1) and derived components (Section 2.2) that indicates the set of message components covered by the signature, never including the @signature-params identifier itself. The order of this set is preserved and communicated between the signer and verifier to facilitate reconstruction of the signature base.
フィールド（セクション2.1）および派生コンポーネント（セクション2.2）のHTTPメッセージコンポーネント識別子の順序付けられたセット。このセットの順序は保存され、署名者と検証者の間で通信され、署名ベースの再構築を促進します。
Signature Base:
署名ベース：
The sequence of bytes generated by the signer and verifier using the covered components set and the HTTP message. The signature base is processed by the cryptographic algorithm to produce or verify the HTTP message signature.
対象コンポーネントセットとHTTPメッセージを使用して、署名者と検証者によって生成されたバイトのシーケンス。署名ベースは、HTTPメッセージ署名を作成または検証するために、暗号化アルゴリズムによって処理されます。
HTTP Message Signature Algorithm:
HTTPメッセージ署名アルゴリズム：
A cryptographic algorithm that describes the signing and verification process for the signature, defined in terms of the HTTP_SIGN and HTTP_VERIFY primitives described in Section 3.3.
セクション3.3で説明されているhttp_signおよびhttp_verifyプリミティブに関して定義された署名の署名と検証プロセスを説明する暗号化アルゴリズム。
Key Material:
重要な資料：
The key material required to create or verify the signature. The key material is often identified with an explicit key identifier, allowing the signer to indicate to the verifier which key was used.
署名を作成または検証するために必要な重要な資料。キー資料は、明示的なキー識別子でしばしば識別され、署名者がどのキーが使用されたかを検証剤に示すことができます。
Creation Time:
作成時間：
A timestamp representing the point in time that the signature was generated, as asserted by the signer.
署名者によって主張されているように、署名が生成された時点を表すタイムスタンプ。
Expiration Time:
有効期限：
A timestamp representing the point in time after which the signature should no longer be accepted by the verifier, as asserted by the signer.
署名者によって主張されているように、署名が検証者によって受け入れられなくなった後の時点を表すタイムスタンプ。
Target Message:
ターゲットメッセージ：
The HTTP message to which an HTTP message signature is applied.
HTTPメッセージ署名が適用されるHTTPメッセージ。
Signature Context:
署名コンテキスト：
The data source from which the HTTP message component values are drawn. The context includes the target message and any additional information the signer or verifier might have, such as the full target URI of a request or the related request message for a response.
HTTPメッセージコンポーネント値が描画されるデータソース。コンテキストには、ターゲットメッセージと、リクエストの完全なターゲットURIや応答の関連リクエストメッセージなど、署名者または検証者が持つ可能性のある追加情報が含まれます。
The term "UNIX timestamp" refers to what Section 4.16 of [POSIX.1] calls "seconds since the Epoch".
「UNIXタイムスタンプ」という用語は、[POSIX.1]のセクション4.16が「エポック以来の秒」と呼ぶものを指します。
This document contains non-normative examples of partial and complete HTTP messages. Some examples use a single trailing backslash (\) to indicate line wrapping for long values, as per [RFC8792]. The \ character and leading spaces on wrapped lines are not part of the value.
このドキュメントには、部分的および完全なHTTPメッセージの非規範的な例が含まれています。いくつかの例は、単一の後続のバックスラッシュ（\）を使用して、[RFC8792]に従って、長い値のラインラッピングを示しています。ラップラインの\文字と先行スペースは、値の一部ではありません。
HTTP permits, and sometimes requires, intermediaries to transform messages in a variety of ways. This can result in a recipient receiving a message that is not bitwise-equivalent to the message that was originally sent. In such a case, the recipient will be unable to verify integrity protections over the raw bytes of the sender's HTTP message, as verifying digital signatures or MACs requires both signer and verifier to have the exact same signature base. Since the exact raw bytes of the message cannot be relied upon as a reliable source for a signature base, the signer and verifier have to independently create the signature base from their respective versions of the message, via a mechanism that is resilient to safe changes that do not alter the meaning of the message.
HTTPは、仲介者がさまざまな方法でメッセージを変換することを許可し、時には要求します。これにより、受信者は、元々送信されたメッセージに少し等しくないメッセージを受信する可能性があります。そのような場合、受信者は、送信者のHTTPメッセージの生のバイトを介して整合性保護を検証することができません。これは、デジタル署名またはMacを検証するには、署名者と検証者の両方がまったく同じ署名ベースを持たせる必要があるためです。メッセージの正確な生のバイトは、署名ベースの信頼できるソースとして依存できないため、署名者と検証者は、それぞれのバージョンのメッセージの署名ベースを、安全な変更に復活させるメカニズムを介して独立して作成する必要があります。メッセージの意味を変更しないでください。
For a variety of reasons, it is impractical to strictly define what constitutes a safe change versus an unsafe one. Applications use HTTP in a wide variety of ways and may disagree on whether a particular piece of information in a message (e.g., the message content, the method, or a particular header field) is relevant. Thus, a general-purpose solution needs to provide signers with some degree of control over which message components are signed.
さまざまな理由から、安全な変化と危険な変化と比較して、何が安全かを構成するものを厳密に定義することは非現実的です。アプリケーションはさまざまな方法でHTTPを使用しており、メッセージ内の特定の情報（メッセージコンテンツ、メソッド、または特定のヘッダーフィールドなど）が関連するかどうかに同意しない場合があります。したがって、汎用ソリューションは、署名者にどのメッセージコンポーネントが署名されているかについてある程度の制御を提供する必要があります。
HTTP applications may be running in environments that do not provide complete access to or control over HTTP messages (such as a web browser's JavaScript environment) or may be using libraries that abstract away the details of the protocol (such as the Java HTTP Client (HttpClient) library (https://openjdk.java.net/groups/net/httpclient/intro.html)). These applications need to be able to generate and verify signatures despite incomplete knowledge of the HTTP message.
HTTPアプリケーションは、HTTPメッセージ（WebブラウザーのJavaScript環境など）への完全なアクセスまたは制御を提供しない環境で実行されている場合があります。）ライブラリ（https://openjdk.java.net/groups/net/httpclient/intro.html））。これらのアプリケーションは、HTTPメッセージの知識が不完全にもかかわらず署名を生成および検証できる必要があります。
As mentioned earlier, HTTP explicitly permits, and in some cases requires, implementations to transform messages in a variety of ways. Implementations are required to tolerate many of these transformations. What follows is a non-normative and non-exhaustive list of transformations that could occur under HTTP, provided as context:
前述のように、HTTPは明示的に許可されており、場合によっては、さまざまな方法でメッセージを変換するための実装が必要になります。これらの変換の多くを許容するには、実装が必要です。以下は、コンテキストとして提供されるHTTPで発生する可能性のある変換の非規範的で非網羅的なリストです。
* Reordering of fields with different field names (Section 5.3 of [HTTP]).
* 異なるフィールド名を持つフィールドの並べ替え（[http]のセクション5.3）。
* Combination of fields with the same field name (Section 5.2 of [HTTP]).
* フィールドと同じフィールド名（[HTTP]のセクション5.2）の組み合わせ。
* Removal of fields listed in the Connection header field (Section 7.6.1 of [HTTP]).
* 接続ヘッダーフィールドにリストされているフィールドの削除（[http]のセクション7.6.1）。
* Addition of fields that indicate control options (Section 7.6.1 of [HTTP]).
* 制御オプションを示すフィールドの追加（[http]のセクション7.6.1）。
* Addition or removal of a transfer coding (Section 7.7 of [HTTP]).
* 転送コーディングの追加または削除（[http]のセクション7.7）。
* Addition of fields such as Via (Section 7.6.3 of [HTTP]) and Forwarded (Section 4 of [RFC7239]).
* via（[http]のセクション7.6.3）や転送（[RFC7239]のセクション4）などのフィールドの添加。
* Conversion between different versions of HTTP (e.g., HTTP/1.x to HTTP/2, or vice versa).
* HTTPの異なるバージョン間の変換（たとえば、HTTP/1.xからHTTP/2、またはその逆）。
* Changes in case (e.g., "Origin" to "origin") of any case-insensitive components such as field names, request URI scheme, or host.
* フィールド名、リクエストURIスキーム、またはホストなどのケースに依存しないコンポーネントのケース（例：「起源」から「起源」など）の変更。
* Changes to the request target and authority that, when applied together, do not result in a change to the message's target URI, as defined in Section 7.1 of [HTTP].
* [HTTP]のセクション7.1で定義されているように、ターゲットと権限の変更と権限の変更
Additionally, there are some transformations that are either deprecated or otherwise not allowed but that could still occur in the wild. These transformations can still be handled without breaking the signature; they include such actions as:
さらに、非推奨または許可されていないものの、いくつかの変換がありますが、野生ではまだ発生する可能性があります。これらの変換は、署名を破ることなく処理できます。次のようなアクションが含まれます。
* Use, addition, or removal of leading or trailing whitespace in a field value.
* フィールド値での先頭または後続の白文学の使用、追加、または除去。
* Use, addition, or removal of obs-fold in field values (Section 5.2 of [HTTP/1.1]).
* フィールド値での倍数の使用、追加、または除去（[http/1.1]のセクション5.2）。
We can identify these types of transformations as transformations that should not prevent signature verification, even when performed on message components covered by the signature. Additionally, all changes to components not covered by the signature should not prevent signature verification.
これらのタイプの変換は、署名の検証を妨げるべきではない変換として識別できます。さらに、署名でカバーされていないコンポーネントのすべての変更は、署名の検証を防ぐべきではありません。
Some examples of these kinds of transformations, and the effect they have on the message signature, are found in Appendix B.4.
これらの種類の変換の例と、メッセージ署名に対する効果のいくつかの例は、付録B.4にあります。
Other transformations, such as parsing and reserializing the field values of a covered component or changing the value of a derived component, can cause a signature to no longer validate against a target message. Applications of this specification need to take care to ensure that the transformations expected by the application are adequately handled by the choice of covered components.
カバーされたコンポーネントのフィールド値を解析して再選択したり、派生コンポーネントの値を変更したりするなど、その他の変換により、署名がターゲットメッセージに対して検証されなくなる可能性があります。この仕様のアプリケーションは、アプリケーションで予想される変換が対象コンポーネントの選択によって適切に処理されるように注意する必要があります。
HTTP message signatures are designed to be a general-purpose tool applicable in a wide variety of circumstances and applications. In order to properly and safely apply HTTP message signatures, an application or profile of this specification MUST specify, at a minimum, all of the following items:
HTTPメッセージ署名は、さまざまな状況とアプリケーションで適用可能な汎用ツールになるように設計されています。HTTPメッセージ署名を適切かつ安全に適用するには、この仕様のアプリケーションまたはプロファイルを少なくともすべての項目を指定する必要があります。
* The set of component identifiers (Section 2) and signature parameters (Section 2.3) that are expected and required to be included in the covered components list. For example, an authorization protocol could mandate that the Authorization field be covered to protect the authorization credentials and mandate that the signature parameters contain a created parameter (Section 2.3), while an API expecting semantically relevant HTTP message content could require the Content-Digest field defined in [DIGEST] to be present and covered as well as mandate a value for the tag parameter (Section 2.3) that is specific to the API being protected.
* コンポーネント識別子のセット（セクション2）と署名パラメーター（セクション2.3）は、対象コンポーネントリストに含まれることが予想され、必要です。たとえば、承認プロトコルは、認証資格を保護するために認可フィールドをカバーし、署名パラメーターに作成されたパラメーターが含まれていることを義務付けていることが義務付けられています（セクション2.3）。[ダイジェスト]で定義され、存在してカバーされ、保護されているAPIに固有のタグパラメーター（セクション2.3）の値を義務付けます。
* The expected Structured Field types [STRUCTURED-FIELDS] of any required or expected covered component fields or parameters.
* 必要なまたは予想されるカバーされたコンポーネントフィールドまたはパラメーターの予想される構造化場[構造化場]。
* A means of retrieving the key material used to verify the signature. An application will usually use the keyid parameter of the signature parameters (Section 2.3) and define rules for resolving a key from there, though the appropriate key could be known from other means such as preregistration of a signer's key.
* 署名の検証に使用される重要な資料を取得する手段。アプリケーションは通常、署名パラメーターのKeyIDパラメーターを使用し（セクション2.3）、そこからキーを解決するためのルールを定義しますが、適切なキーは、署名者のキーの前提条件などの他の手段からわかることができます。
* The set of allowable signature algorithms to be used by signers and accepted by verifiers.
* 署名者によって使用され、検証剤によって受け入れられる許容署名アルゴリズムのセット。
* A means of determining that the signature algorithm used to verify the signature is appropriate for the key material and context of the message. For example, the process could use the alg parameter of the signature parameters (Section 2.3) to state the algorithm explicitly, derive the algorithm from the key material, or use some preconfigured algorithm agreed upon by the signer and verifier.
* 署名を検証するために使用される署名アルゴリズムが、メッセージの主要な資料とコンテキストに適していると判断する手段。たとえば、このプロセスは、署名パラメーターのアルグパラメーターを使用して（セクション2.3）、アルゴリズムを明示的に述べたり、キーマテリアルからアルゴリズムを導出したり、署名者と検証者によって合意された事前に設定されたアルゴリズムを使用したりすることができます。
* A means of determining that a given key and algorithm used for a signature are appropriate for the context of the message. For example, a server expecting only ECDSA signatures should know to reject any RSA signatures, or a server expecting asymmetric cryptography should know to reject any symmetric cryptography.
* 署名に使用される特定のキーとアルゴリズムがメッセージのコンテキストに適していると判断する手段。たとえば、ECDSAの署名のみを期待するサーバーは、RSAの署名を拒否することを知っている必要があります。または、非対称の暗号化を期待するサーバーは、対称的な暗号化を拒否することを知っている必要があります。
* A means of determining the context for derivation of message components from an HTTP message and its application context. While this is normally the target HTTP message itself, the context could include additional information known to the application through configuration, such as an external hostname.
* HTTPメッセージとそのアプリケーションコンテキストからメッセージコンポーネントを導出するためのコンテキストを決定する手段。これは通常、ターゲットHTTPメッセージ自体ですが、コンテキストには、外部ホスト名などの構成を介してアプリケーションに知られている追加情報を含めることができます。
* If binding between a request and response is needed using the mechanism provided in Section 2.4, all elements of the request message and the response message that would be required to provide properties of such a binding.
* セクション2.4で提供されているメカニズムを使用して、要求と応答の間にバインディングが必要な場合、リクエストメッセージのすべての要素と、そのようなバインディングのプロパティを提供するために必要な応答メッセージが必要です。
* The error messages and codes that are returned from the verifier to the signer when the signature is invalid, the key material is inappropriate, the validity time window is out of specification, a component value cannot be calculated, or any other errors occur during the signature verification process. For example, if a signature is being used as an authentication mechanism, an HTTP status code of 401 (Unauthorized) or 403 (Forbidden) could be appropriate. If the response is from an HTTP API, a response with an HTTP status code such as 400 (Bad Request) could include more details [RFC7807] [RFC9457], such as an indicator that the wrong key material was used.
* 署名が無効である場合、主要な資料が不適切である場合、有効性の時間ウィンドウが仕様から外れている、コンポーネント値を計算できない、または署名中にその他のエラーが発生する場合、検証者から署名者に返されるエラーメッセージとコードが署名者に返されます。検証プロセス。たとえば、署名が認証メカニズムとして使用されている場合、401（不正）または403（禁止）のHTTPステータスコードが適切である可能性があります。応答がHTTP APIからのものである場合、400（悪い要求）などのHTTPステータスコードを含む応答には、詳細を含めることができます[RFC7807] [RFC9457]。
When choosing these parameters, an application of HTTP message signatures has to ensure that the verifier will have access to all required information needed to recreate the signature base. For example, a server behind a reverse proxy would need to know the original request URI to make use of the derived component @target-uri, even though the apparent target URI would be changed by the reverse proxy (see also Section 7.4.3). Additionally, an application using signatures in responses would need to ensure that clients receiving signed responses have access to all the signed portions of the message, including any portions of the request that were signed by the server using the req ("request-response") parameter (Section 2.4).
これらのパラメーターを選択するとき、HTTPメッセージ署名のアプリケーションは、検証者が署名ベースを再現するために必要なすべての必要な情報にアクセスできるようにする必要があります。たとえば、逆プロキシの背後にあるサーバーは、派生したターゲットURIが逆プロキシによって変更されますが、派生コンポーネント @ターゲットウリを使用するために元のリクエストURIを知る必要があります（セクション7.4.3も参照）。さらに、応答に署名を使用するアプリケーションは、署名された応答を受信するクライアントが、REQを使用してサーバーによって署名された要求の部分を含む、メッセージのすべての署名された部分にアクセスできるようにする必要があります（「リクエスト応答」）パラメーター（セクション2.4）。
Details regarding this kind of profiling are within the purview of the application and outside the scope of this specification; however, some additional considerations are discussed in Section 7. In particular, when choosing the required set of component identifiers, care has to be taken to make sure that the coverage is sufficient for the application, as discussed in Sections 7.2.1 and 7.2.8. This specification defines only part of a full security system for an application. When building a complete security system based on this tool, it is important to perform a security analysis of the entire system, of which HTTP message signatures is a part. Historical systems, such as AWS Signature Version 4 [AWS-SIGv4], can provide inspiration and examples of how to apply similar mechanisms to an application, though review of such historical systems does not negate the need for a security analysis of an application of HTTP message signatures.
この種のプロファイリングに関する詳細は、アプリケーションの範囲内およびこの仕様の範囲外です。ただし、セクション7でいくつかの追加の考慮事項について説明します。特に、コンポーネント識別子の必要なセットを選択する際には、セクション7.2.1および7.2で説明するように、適用に十分であることを確認するために注意する必要があります。8。この仕様は、アプリケーションの完全なセキュリティシステムの一部のみを定義します。このツールに基づいて完全なセキュリティシステムを構築する場合、システム全体のセキュリティ分析を実行することが重要です。このセキュリティは、HTTPメッセージ署名が一部です。AWS署名バージョン4 [AWS-SIGV4]などの履歴システムは、同様のメカニズムをアプリケーションに適用する方法のインスピレーションと例を提供できますが、このような履歴システムのレビューはHTTPのアプリケーションのセキュリティ分析の必要性を否定しません。メッセージ署名。
In order to allow signers and verifiers to establish which components are covered by a signature, this document defines component identifiers for components covered by an HTTP message signature, a set of rules for deriving and canonicalizing the values associated with these component identifiers from the HTTP message, and the means for combining these canonicalized values into a signature base.
署名者と検証者がどのコンポーネントが署名でカバーされているかを確立できるようにするために、このドキュメントは、HTTPメッセージからのこれらのコンポーネント識別子に関連付けられた値を導き出しおよび正規化するためのルールのセットであるHTTPメッセージ署名でカバーされているコンポーネントのコンポーネント識別子を定義します。、およびこれらの正規化された値を署名ベースに結合する手段。
The signature context for deriving these values MUST be accessible to both the signer and the verifier of the message. The context MUST be the same across all components in a given signature. For example, it would be an error to use the raw query string for the @query derived component but combined query and form parameters for the @query-param derived component. For more considerations regarding the message component context, see Section 7.4.3.
これらの値を導き出すための署名コンテキストは、メッセージの署名者と検証者の両方がアクセスできる必要があります。コンテキストは、特定の署名のすべてのコンポーネントで同じでなければなりません。たとえば、@Query派生コンポーネントにRAWクエリ文字列を使用するのはエラーになりますが、 @Query-Param派生コンポーネントのクエリとフォームパラメーターを組み合わせて使用します。メッセージコンポーネントのコンテキストに関する詳細については、セクション7.4.3を参照してください。
A component identifier is composed of a component name and any parameters associated with that name. Each component name is either an HTTP field name (Section 2.1) or a registered derived component name (Section 2.2). The possible parameters for a component identifier are dependent on the component identifier. The "HTTP Signature Component Parameters" registry, which catalogs all possible parameters, is defined in Section 6.5.
コンポーネント識別子は、コンポーネント名とその名前に関連付けられたパラメーターで構成されています。各コンポーネント名は、HTTPフィールド名（セクション2.1）または登録された派生コンポーネント名（セクション2.2）のいずれかです。コンポーネント識別子の可能なパラメーターは、コンポーネント識別子に依存します。すべての可能なパラメーターをカタログ化する「HTTP署名コンポーネントパラメーター」レジストリは、セクション6.5で定義されています。
Within a single list of covered components, each component identifier MUST occur only once. One component identifier is distinct from another if the component name differs or if any of the parameters differ for the same component name. Multiple component identifiers having the same component name MAY be included if they have parameters that make them distinct, such as "foo";bar and "foo";baz. The order of parameters MUST be preserved when processing a component identifier (such as when parsing during verification), but the order of parameters is not significant when comparing two component identifiers for equality checks. That is to say, "foo";bar;baz cannot be in the same message as "foo";baz;bar, since these two component identifiers are equivalent, but a system processing one form is not allowed to transform it into the other form.
対象コンポーネントの単一のリスト内で、各コンポーネント識別子は1回だけ発生する必要があります。コンポーネント名が異なる場合、または同じコンポーネント名でパラメーターのいずれかが異なる場合、1つのコンポーネント識別子は別のコンポーネント識別子とは異なります。「foo」; barや "foo"; bazなど、それらを明確にするパラメーターがある場合、同じコンポーネント名を持つ複数のコンポーネント識別子が含まれる場合があります。パラメーターの順序は、コンポーネント識別子を処理するときに保存する必要があります（検証中に解析するときなど）が、平等チェックの2つのコンポーネント識別子を比較する場合はパラメーターの順序は重要ではありません。つまり、「foo」; bar; bazは「foo」と同じメッセージに載ることはできません; baz; bar。形状。
The component value associated with a component identifier is defined by the identifier itself. Component values MUST NOT contain newline (\n) characters. Some HTTP message components can undergo transformations that change the bitwise value without altering the meaning of the component's value (for example, when combining field values). Message component values therefore need to be canonicalized before they are signed, to ensure that a signature can be verified despite such intermediary transformations. This document defines rules for each component identifier that transform the identifier's associated component value into such a canonical form.
コンポーネント識別子に関連付けられたコンポーネント値は、識別子自体によって定義されます。コンポーネント値には、NewLine（\ n）文字を含めてはなりません。一部のHTTPメッセージコンポーネントは、コンポーネントの値の意味を変更せずにビットワイズ値を変更する変換を受ける可能性があります（たとえば、フィールド値を組み合わせるとき）。したがって、メッセージコンポーネントの値は、署名する前に正規化する必要があり、そのような仲介者の変換にもかかわらず署名を検証できるようにする必要があります。このドキュメントは、識別子の関連コンポーネント値をそのような標準形式に変換する各コンポーネント識別子のルールを定義します。
The following sections define component identifier names, their parameters, their associated values, and the canonicalization rules for their values. The method for combining message components into the signature base is defined in Section 2.5.
次のセクションでは、コンポーネント識別子名、そのパラメーター、関連する値、およびその値の標準化ルールを定義します。メッセージコンポーネントを署名ベースに結合する方法は、セクション2.5で定義されています。
The component name for an HTTP field is the lowercased form of its field name as defined in Section 5.1 of [HTTP]. While HTTP field names are case insensitive, implementations MUST use lowercased field names (e.g., content-type, date, etag) when using them as component names.
HTTPフィールドのコンポーネント名は、[HTTP]のセクション5.1で定義されているように、そのフィールド名の低い形式です。HTTPフィールド名はケースではありませんが、実装はコンポーネント名として使用する場合、より低いフィールド名（コンテンツタイプ、日付、ETAGなど）を使用する必要があります。
The component value for an HTTP field is the field value for the named field as defined in Section 5.5 of [HTTP]. The field value MUST be taken from the named header field of the target message unless this behavior is overridden by additional parameters and rules, such as the req and tr flags, below. For most fields, the field value is an ASCII string as recommended by [HTTP], and the component value is exactly that string. Other encodings could exist in some implementations, and all non-ASCII field values MUST be encoded to ASCII before being added to the signature base. The bs parameter, as described in Section 2.1.3, provides a method for wrapping such problematic field values.
HTTPフィールドのコンポーネント値は、[http]のセクション5.5で定義されている指名されたフィールドのフィールド値です。この動作が以下のREQやTRフラグなどの追加のパラメーターとルールによってオーバーライドされない限り、ターゲットメッセージの名前付きヘッダーフィールドからフィールド値を取得する必要があります。ほとんどのフィールドでは、[http]で推奨されるASCII文字列であり、コンポーネント値はまさにその文字列です。他のエンコーディングはいくつかの実装に存在する可能性があり、すべての非ASCIIフィールド値は、署名ベースに追加する前にASCIIにエンコードする必要があります。セクション2.1.3で説明されているように、BSパラメーターは、このような問題のあるフィールド値をラップする方法を提供します。
Unless overridden by additional parameters and rules, HTTP field values MUST be combined into a single value as defined in Section 5.2 of [HTTP] to create the component value. Specifically, HTTP fields sent as multiple fields MUST be combined by concatenating the values using a single comma and a single space as a separator ("," + " "). Note that intermediaries are allowed to combine values of HTTP fields with any amount of whitespace between the commas, and if this behavior is not accounted for by the verifier, the signature can fail, since the signer and verifier will see a different component value in their respective signature bases. For robustness, it is RECOMMENDED that signed messages include only a single instance of any field covered under the signature, particularly with the value for any list-based fields serialized using the algorithm below. This approach increases the chances of the field value remaining untouched through intermediaries. Where that approach is not possible and multiple instances of a field need to be sent separately, it is RECOMMENDED that signers and verifiers process any list-based fields taking all individual field values and combining them based on the strict algorithm below, to counter possible intermediary behavior. When the field in question is a Structured Field of type List or Dictionary, this effect can be accomplished more directly by requiring the strict Structured Field serialization of the field value, as described in Section 2.1.1.
追加のパラメーターとルールによってオーバーライドされない限り、[http]のセクション5.2で定義されているように、HTTPフィールド値を単一の値に結合してコンポーネント値を作成する必要があります。具体的には、複数のフィールドとして送信されたHTTPフィールドは、単一のコンマとセパレーター（ "、" ""）として単一のスペースを使用して値を連結することにより組み合わせる必要があります。仲介業者は、HTTPフィールドの値とコンマの間の任意の量のホワイトスペースを組み合わせることが許可されていることに注意してください。この動作が検証剤によって説明されない場合、署名者と検証者には異なるコンポーネント値が表示されるため、署名が失敗する可能性があります。それぞれの署名ベース。堅牢性のために、署名されたメッセージには、特に以下のアルゴリズムを使用してシリアル化されたリストベースのフィールドの値を使用して、署名の下でカバーされているフィールドの単一インスタンスのみを含めることをお勧めします。このアプローチは、仲介者を通じて触れられないままのフィールド値の可能性を高めます。そのアプローチが不可能で、フィールドの複数のインスタンスを個別に送信する必要がある場合、署名者と検証剤は、すべての個々のフィールド値を取得し、以下の厳格なアルゴリズムに基づいてそれらを組み合わせて、可能な仲介者に対抗するリストベースのフィールドを処理することをお勧めします行動。問題のフィールドがタイプリストまたは辞書の構造化されたフィールドである場合、セクション2.1.1で説明されているように、この効果は、フィールド値の厳密な構造化されたフィールドシリアル化を要求することにより、より直接的に達成できます。
Note that some HTTP fields, such as Set-Cookie [COOKIE], do not follow a syntax that allows for the combination of field values in this manner (such that the combined output is unambiguous from multiple inputs). Even though the component value is never parsed by the message signature process and is used only as part of the signature base (Section 2.5), caution needs to be taken when including such fields in signatures, since the combined value could be ambiguous. The bs parameter, as described in Section 2.1.3, provides a method for wrapping such problematic fields. See Section 7.5.6 for more discussion regarding this issue.
Set-Cookie [Cookie]などの一部のHTTPフィールドは、この方法でフィールド値の組み合わせを可能にする構文に従わないことに注意してください（複数の出力が複数の入力から明確になるように）。コンポーネントの値はメッセージ署名プロセスによって解析されることはなく、署名ベースの一部としてのみ使用されます（セクション2.5）、そのようなフィールドを署名に含める場合は注意が必要です。セクション2.1.3で説明されているように、BSパラメーターは、このような問題のあるフィールドをラッピングする方法を提供します。この問題に関する詳細については、セクション7.5.6を参照してください。
If the correctly combined value is not directly available for a given field by an implementation, the following algorithm will produce canonicalized results for list-based fields:
実装によって特定のフィールドで正しく組み合わされた値が直接使用できない場合、次のアルゴリズムはリストベースのフィールドに正規化された結果を生成します。
1. Create an ordered list of the field values of each instance of the field in the message, in the order they occur (or will occur) in the message.
1. メッセージ内の順序で、メッセージ内のフィールドの各インスタンスのフィールド値の順序付けられたリストを作成します。
2. Strip leading and trailing whitespace from each item in the list. Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this would be a no-op in a compliant implementation.
2. リスト内の各アイテムから先頭および後続の白人をストリップします。HTTPフィールド値には、先頭および末尾の空白を含めることは許可されていないため、これは準拠の実装においてノーオプになることに注意してください。
3. Remove any obsolete line folding within the line, and replace it with a single space (" "), as discussed in Section 5.2 of [HTTP/1.1]. Note that this behavior is specific to HTTP/1.1 and does not apply to other versions of the HTTP specification, which do not allow internal line folding.
3. [HTTP/1.1]のセクション5.2で説明しているように、ライン内の折りたたみ折りたたみを削除し、単一のスペース（ ""）に置き換えます。この動作はHTTP/1.1に固有であり、内部線の折りたたみを許可しないHTTP仕様の他のバージョンには適用されないことに注意してください。
4. Concatenate the list of values with a single comma (",") and a single space (" ") between each item.
4. 各アイテム間の単一のコンマ（ "、"）と単一のスペース（ ""）を使用して、値のリストを連結します。
The resulting string is the component value for the field.
結果の文字列は、フィールドのコンポーネント値です。
Note that some HTTP fields have values with multiple valid serializations that have equivalent semantics, such as allowing case-insensitive values that intermediaries could change. Applications signing and processing such fields MUST consider how to handle the values of such fields to ensure that the signer and verifier can derive the same value, as discussed in Section 7.5.2.
一部のHTTPフィールドには、仲介者が変化する可能性のあるケース非感受性値を許可するなど、同等のセマンティクスを持つ複数の有効なシリアル化を持つ値があることに注意してください。このようなフィールドに署名および処理するアプリケーションは、セクション7.5.2で説明したように、署名者と検証者が同じ値を導き出すことができるように、そのようなフィールドの値を処理する方法を検討する必要があります。
The following are non-normative examples of component values for header fields, given the following example HTTP message fragment:
以下は、次の例を考慮して、ヘッダーフィールドのコンポーネント値の非規範的な例です。
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)
The following example shows the component values for these example header fields, presented using the signature base format defined in Section 2.5:
次の例は、セクション2.5で定義されている署名ベース形式を使用して提示された、これらの例ヘッダーフィールドのコンポーネント値を示しています。
"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)
Empty HTTP fields can also be signed when present in a message. The canonicalized value is the empty string. This means that the following empty header field, with (SP) indicating a single trailing space character before the empty field value:
空のHTTPフィールドは、メッセージに存在するときに署名することもできます。標準化された値は空の文字列です。これは、次の空のヘッダーフィールドで、（sp）は、空のフィールド値の前に単一のトレイルスペース文字を示していることを意味します。
X-Empty-Header:(SP)
is serialized by the signature base generation algorithm (Section 2.5) with an empty string value following the colon and space added after the component identifier.
シグネチャーベース生成アルゴリズム（セクション2.5）によってシリアル化されています。コンポーネント識別子の後に追加されたコロンとスペースが追加された空の文字列値があります。
"x-empty-header":(SP)
Any HTTP field component identifiers MAY have the following parameters in specific circumstances, each described in detail in their own sections:
HTTPフィールドコンポーネント識別子は、特定の状況で次のパラメーターを持っている場合があります。それぞれが独自のセクションで詳細に説明されています。
sf
SF
A Boolean flag indicating that the component value is serialized using strict encoding of the Structured Field value (Section 2.1.1).
構造化されたフィールド値の厳密なエンコードを使用してコンポーネント値がシリアル化されていることを示すブールフラグ（セクション2.1.1）。
key
鍵キー基幹秘訣手がかり手掛かり調子急所解法虎の巻虎巻キー入力
A String parameter used to select a single member value from a Dictionary Structured Field (Section 2.1.2).
辞書構造化されたフィールドから単一のメンバー値を選択するために使用される文字列パラメーター（セクション2.1.2）。
bs
BS
A Boolean flag indicating that individual field values are encoded using Byte Sequence data structures before being combined into the component value (Section 2.1.3).
ブールフラグは、個々のフィールド値がバイトシーケンスデータ構造を使用してエンコードされ、コンポーネント値に結合されることを示すブールフラグ（セクション2.1.3）。
req
req
A Boolean flag for signed responses indicating that the component value is derived from the request that triggered this response message and not from the response message directly. Note that this parameter can also be applied to any derived component identifiers that target the request (Section 2.4).
コンポーネント値が、直接応答メッセージではなく、この応答メッセージをトリガーした要求から派生していることを示す署名された応答のブールフラグ。このパラメーターは、要求をターゲットにする派生コンポーネント識別子にも適用できることに注意してください（セクション2.4）。
tr
tr
A Boolean flag indicating that the field value is taken from the trailers of the message as defined in Section 6.5 of [HTTP]. If this flag is absent, the field value is taken from the header fields of the message as defined in Section 6.3 of [HTTP] (Section 2.1.4).
[HTTP]のセクション6.5で定義されているように、メッセージのトレーラーからフィールド値が取得されることを示すブールフラグ。このフラグがない場合、[HTTP]（セクション2.1.4）のセクション6.3で定義されているように、メッセージのヘッダーフィールドからフィールド値が取得されます。
Multiple parameters MAY be specified together, though some combinations are redundant or incompatible. For example, the sf parameter's functionality is already covered when the key parameter is used on a Dictionary item, since key requires strict serialization of the value. The bs parameter, which requires the raw bytes of the field values from the message, is not compatible with the use of the sf or key parameters, which require the parsed data structures of the field values after combination.
いくつかの組み合わせは冗長または互換性がありますが、複数のパラメーターを一緒に指定できます。たとえば、Keyには値の厳密なシリアル化が必要なため、SFパラメーターの機能は辞書項目でキーパラメーターが使用されるときに既にカバーされています。メッセージからのフィールド値の生のバイトを必要とするBSパラメーターは、組み合わせ後にフィールド値の解析されたデータ構造を必要とするSFまたはキーパラメーターの使用と互換性がありません。
Additional parameters can be defined in the "HTTP Signature Component Parameters" registry established in Section 6.5.
追加のパラメーターは、セクション6.5で確立された「HTTP署名コンポーネントパラメーター」レジストリで定義できます。
If the value of an HTTP field is known by the application to be a Structured Field type (as defined in [STRUCTURED-FIELDS] or its extensions or updates) and the expected type of the Structured Field is known, the signer MAY include the sf parameter in the component identifier. If this parameter is included with a component identifier, the HTTP field value MUST be serialized using the formal serialization rules specified in Section 4 of [STRUCTURED-FIELDS] (or the applicable formal serialization section of its extensions or updates) applicable to the type of the HTTP field. Note that this process will replace any optional internal whitespace with a single space character, among other potential transformations of the value.
HTTPフィールドの値は、アプリケーションによって構造化されたフィールドタイプ（[構造化場]またはその拡張または更新で定義されている）と構造化されたフィールドの予想タイプがわかっていることがわかっている場合、署名者にはSFが含まれる場合があります。コンポーネント識別子のパラメーター。このパラメーターがコンポーネント識別子に含まれている場合、[構造化場]のセクション4（またはその拡張または更新の該当する正式なシリアル化セクション）で指定された正式なシリアル化ルールを使用して、HTTPフィールド値をシリアル化する必要があります。HTTPフィールド。このプロセスは、オプションの内部空白を、値の潜在的な変換の中でも、単一のスペース文字に置き換えることに注意してください。
If multiple field values occur within a message, these values MUST be combined into a single List or Dictionary structure before serialization.
メッセージ内で複数のフィールド値が発生する場合、これらの値は、シリアル化前に単一のリストまたは辞書構造に結合する必要があります。
If the application does not know the type of the field or does not know how to serialize the type of the field, the use of this flag will produce an error. As a consequence, the signer can only reliably sign fields using this flag when the verifier's system knows the type as well.
アプリケーションがフィールドのタイプを知らない場合、またはフィールドのタイプをシリアル化する方法がわからない場合、このフラグを使用するとエラーが発生します。結果として、署名者は、Verifierのシステムが同様にタイプを知っている場合にのみ、このフラグを使用してフィールドを確実に署名できます。
For example, the following Dictionary field is a valid serialization:
たとえば、次の辞書フィールドは有効なシリアル化です。
Example-Dict: a=1, b=2;x=1;y=2, c=(a b c)
If included in the signature base without parameters, its value would be:
パラメーターのない署名ベースに含まれる場合、その値は次のとおりです。
"example-dict": a=1, b=2;x=1;y=2, c=(a b c)
However, if the sf parameter is added, the value is reserialized as follows:
ただし、SFパラメーターが追加されている場合、値は次のように再参照されます。
"example-dict";sf: a=1, b=2;x=1;y=2, c=(a b c)
The resulting string is used as the component value; see Section 2.1.
結果の文字列は、コンポーネント値として使用されます。セクション2.1を参照してください。
If a given field is known by the application to be a Dictionary Structured Field, an individual member in the value of that Dictionary is identified by using the parameter key and the Dictionary member key as a String value.
特定のフィールドがアプリケーションによって辞書構造化されたフィールドであることがわかっている場合、その辞書の値の個々のメンバーは、パラメーターキーと辞書メンバーキーを文字列値として使用して識別されます。
If multiple field values occur within a message, these values MUST be combined into a single Dictionary structure before serialization.
メッセージ内で複数のフィールド値が発生する場合、これらの値は、シリアル化前に単一の辞書構造に結合する必要があります。
An individual member value of a Dictionary Structured Field is canonicalized by applying the serialization algorithm described in Section 4.1.2 of [STRUCTURED-FIELDS] on the member_value and its parameters, not including the Dictionary key itself. Specifically, the value is serialized as an Item or Inner List (the two possible values of a Dictionary member), with all parameters and possible subfields serialized using the strict serialization rules defined in Section 4 of [STRUCTURED-FIELDS] (or the applicable section of its extensions or updates).
辞書構造化されたフィールドの個々のメンバー値は、辞書キー自体を含まない[構造化場]のセクション4.1.2で説明されているシリアル化アルゴリズムとそのパラメーターを適用することにより、正規化されます。具体的には、値はアイテムまたは内部リスト（辞書メンバーの2つの可能な値）としてシリアル化され、すべてのパラメーターと可能なサブフィールドが[構造化場]のセクション4で定義された厳密なシリアル化ルールを使用してシリアル化されています（または該当するセクションその拡張または更新の）。
Each parameterized key for a given field MUST NOT appear more than once in the signature base. Parameterized keys MAY appear in any order in the signature base, regardless of the order they occur in the source Dictionary.
特定のフィールドの各パラメーター化されたキーは、署名ベースに複数回表示されてはなりません。パラメーター化されたキーは、ソース辞書で発生する順序に関係なく、署名ベースの任意の順序で表示される場合があります。
If a Dictionary key is named as a covered component but it does not occur in the Dictionary, this MUST cause an error in the signature base generation.
辞書キーがカバーコンポーネントとして名前が付けられているが、辞書では発生しない場合、これは署名ベース生成にエラーを引き起こす必要があります。
The following are non-normative examples of canonicalized values for Dictionary Structured Field members, given the following example header field, whose value is known by the application to be a Dictionary:
以下は、次の例のヘッダーフィールドを考慮して、辞書の例を考慮して、辞書の標準化された値の非規範的な例であり、その値はアプリケーションで辞書であることが知られています。
Example-Dict: a=1, b=2;x=1;y=2, c=(a b c), d
The following example shows canonicalized values for different component identifiers of this field, presented using the signature base format discussed in Section 2.5:
次の例は、セクション2.5で説明されている署名ベース形式を使用して提示された、このフィールドのさまざまなコンポーネント識別子の正規化された値を示しています。
"example-dict";key="a": 1
"example-dict";key="d": ?1
"example-dict";key="b": 2;x=1;y=2
"example-dict";key="c": (a b c)
Note that the value for key="c" has been reserialized according to the strict member_value algorithm, and the value for key="d" has been serialized as a Boolean value.
key = "c"の値は、Strict Member_valueアルゴリズムに従って再選択されており、key = "d"の値はブール値としてシリアル化されていることに注意してください。
If the value of the HTTP field in question is known by the application to cause problems with serialization, particularly with the combination of multiple values into a single line as discussed in Section 7.5.6, the signer SHOULD include the bs parameter in a component identifier to indicate that the values of the field need to be wrapped as binary structures before being combined.
問題のHTTPフィールドの値が、特にセクション7.5.6で説明されているように、特に複数の値を単一行に組み合わせてシリアル化の問題を引き起こすためのアプリケーションで知られている場合、署名者はコンポーネント識別子にBSパラメーターを含める必要があります。組み合わせる前に、フィールドの値をバイナリ構造として包む必要があることを示すため。
If this parameter is included with a component identifier, the component value MUST be calculated using the following algorithm:
このパラメーターがコンポーネント識別子に含まれている場合、次のアルゴリズムを使用してコンポーネント値を計算する必要があります。
1. Let the input be the ordered set of values for a field, in the order they appear in the message.
1. 入力を、メッセージに表示される順序で、フィールドの順序付けられた値のセットとします。
2. Create an empty List for accumulating processed field values.
2. 処理されたフィールド値を蓄積するための空のリストを作成します。
3. For each field value in the set:
3. セット内の各フィールド値について：
3.1. Strip leading and trailing whitespace from the field value. Note that since HTTP field values are not allowed to contain leading and trailing whitespace, this would be a no-op in a compliant implementation.
3.1. フィールド値から先頭および後続の白い師をストリップします。HTTPフィールド値には、先頭および末尾の空白を含めることは許可されていないため、これは準拠の実装においてノーオプになることに注意してください。
3.2. Remove any obsolete line folding within the line, and replace it with a single space (" "), as discussed in Section 5.2 of [HTTP/1.1]. Note that this behavior is specific to [HTTP/1.1] and does not apply to other versions of the HTTP specification.
3.2. [HTTP/1.1]のセクション5.2で説明しているように、ライン内の折りたたみ折りたたみを削除し、単一のスペース（ ""）に置き換えます。この動作は[HTTP/1.1]に固有であり、HTTP仕様の他のバージョンには適用されないことに注意してください。
3.3. Encode the bytes of the resulting field value as a Byte Sequence. Note that most fields are restricted to ASCII characters, but other octets could be included in the value in some implementations.
3.3. 結果のフィールド値のバイトをバイトシーケンスとしてエンコードします。ほとんどのフィールドはASCII文字に制限されていますが、他のオクテットはいくつかの実装の値に含めることができることに注意してください。
3.4. Add the Byte Sequence to the List accumulator.
3.4. リストアキュムレータにバイトシーケンスを追加します。
4. The intermediate result is a List of Byte Sequence values.
4. 中間結果は、バイトシーケンス値のリストです。
5. Follow the strict serialization of a List as described in Section 4.1.1 of [STRUCTURED-FIELDS], and return this output.
5. [構造化場]のセクション4.1.1で説明されているリストの厳密なシリアル化に従い、この出力を返します。
For example, the following field with internal commas prevents the distinct field values from being safely combined:
たとえば、内部コンマを備えた次のフィールドは、明確なフィールド値が安全に組み合わされるのを防ぎます。
Example-Header: value, with, lots
Example-Header: of, commas
In our example, the same field can be sent with a semantically different single value:
この例では、同じフィールドを意味的に異なる単一値で送信できます。
Example-Header: value, with, lots, of, commas
Both of these versions are treated differently by the application. However, if included in the signature base without parameters, the component value would be the same in both cases:
これらのバージョンは両方とも、アプリケーションによって異なって扱われます。ただし、パラメーターのない署名ベースに含まれる場合、両方の場合にコンポーネント値が同じになります。
"example-header": value, with, lots, of, commas
However, if the bs parameter is added, the two separate instances are encoded and serialized as follows:
ただし、BSパラメーターが追加されている場合、2つの別々のインスタンスがエンコードされ、次のようにシリアル化されます。
"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHM=:, :b2YsIGNvbW1hcw==:
For the single-instance field above, the encoding with the bs parameter is:
上記のシングルインスタンスフィールドの場合、BSパラメーターを使用したエンコードは次のとおりです。
"example-header";bs: :dmFsdWUsIHdpdGgsIGxvdHMsIG9mLCBjb21tYXM=:
This component value is distinct from the multiple-instance field above, preventing a collision that could potentially be exploited.
このコンポーネント値は、上記の複数インスタンスフィールドとは異なり、潜在的に悪用される可能性のある衝突を防ぎます。
If the signer wants to include a trailer field in the signature, the signer MUST include the tr Boolean parameter to indicate that the value MUST be taken from the trailer fields and not from the header fields.
署名者が署名にトレーラーフィールドを含めることを望む場合、署名者は、ヘッダーフィールドからではなく、トレーラーフィールドから値を取得する必要があることを示すために、TRブールパラメーターを含める必要があります。
For example, given the following message:
たとえば、次のメッセージが与えられます。
HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked
Trailer: Expires
4
HTTP
7
Message
a
Signatures
0
Expires: Wed, 9 Nov 2022 07:28:00 GMT
The signer decides to add both the Trailer header field and the Expires trailer field to the signature base, along with the status code derived component:
署名者は、トレーラーヘッダーフィールドと有効期限の両方のトレーラーフィールドの両方を署名ベースに追加することを決定し、ステータスコード派生コンポーネントとともに：
"@status": 200
"trailer": Expires
"expires";tr: Wed, 9 Nov 2022 07:28:00 GMT
If a field is available as both a header and a trailer in a message, both values MAY be signed, but the values MUST be signed separately. The values of header fields and trailer fields of the same name MUST NOT be combined for purposes of the signature.
フィールドがメッセージ内のヘッダーとトレーラーの両方として利用可能である場合、両方の値に署名することができますが、値は別々に署名する必要があります。同じ名前のヘッダーフィールドとトレーラーフィールドの値は、署名の目的のために組み合わせる必要はありません。
Since trailer fields could be merged into the header fields or dropped entirely by intermediaries as per Section 6.5.1 of [HTTP], it is NOT RECOMMENDED to include trailers in the signature unless the signer knows that the verifier will have access to the values of the trailers as sent.
トレーラーフィールドは、[http]のセクション6.5.1に従って、ヘッダーフィールドにマージされたり、仲介者によって完全にドロップされたりする可能性があるため、署名者が検証者がVerifierの値にアクセスできることを知らない限り、トレーラーを署名に含めることはお勧めしません。送信されたトレーラー。
In addition to HTTP fields, there are a number of different components that can be derived from the control data, signature context, or other aspects of the HTTP message being signed. Such derived components can be included in the signature base by defining a component name, possible parameters, message targets, and the derivation method for its component value.
HTTPフィールドに加えて、署名されているHTTPメッセージの制御データ、署名コンテキスト、またはその他の側面から導出できるさまざまなコンポーネントがいくつかあります。このような派生コンポーネントは、コンポーネント名、可能なパラメーター、メッセージターゲット、およびそのコンポーネント値の派生方法を定義することにより、署名ベースに含めることができます。
Derived component names MUST start with the "at" (@) character. This differentiates derived component names from HTTP field names, which cannot contain the @ character as per Section 5.1 of [HTTP]. Processors of HTTP message signatures MUST treat derived component names separately from field names, as discussed in Section 7.5.1.
派生コンポーネント名は、「at」（@）文字から開始する必要があります。これにより、派生したコンポーネント名がHTTPフィールド名を区別します。これは、[http]のセクション5.1に従って @文字を含めることはできません。HTTPメッセージ署名のプロセッサは、セクション7.5.1で説明したように、フィールド名とは別に派生コンポーネント名を扱う必要があります。
This specification defines the following derived components:
この仕様は、次の派生コンポーネントを定義します。
@method
@方法
The method used for a request (Section 2.2.1).
リクエストに使用される方法（セクション2.2.1）。
@target-uri
@Target-Uri
The full target URI for a request (Section 2.2.2).
リクエストの完全なターゲットURI（セクション2.2.2）。
@authority
@権限
The authority of the target URI for a request (Section 2.2.3).
リクエストに対するターゲットURIの権限（セクション2.2.3）。
@scheme
@スキーム
The scheme of the target URI for a request (Section 2.2.4).
リクエストのターゲットURIのスキーム（セクション2.2.4）。
@request-target
@request-target
The request target (Section 2.2.5).
リクエストターゲット（セクション2.2.5）。
@path
@パス
The absolute path portion of the target URI for a request (Section 2.2.6).
リクエストのターゲットURIの絶対パス部分（セクション2.2.6）。
@query
@query
The query portion of the target URI for a request (Section 2.2.7).
リクエストのターゲットURIのクエリ部分（セクション2.2.7）。
@query-param
@query-param
A parsed and encoded query parameter of the target URI for a request (Section 2.2.8).
リクエストのターゲットURIの解析およびエンコードされたクエリパラメーター（セクション2.2.8）。
@status
@状態
The status code for a response (Section 2.2.9).
応答のステータスコード（セクション2.2.9）。
Additional derived component names are defined in the "HTTP Signature Derived Component Names" registry (Section 6.4).
追加の派生コンポーネント名は、「HTTP署名派生コンポーネント名」レジストリ（セクション6.4）で定義されています。
Derived component values are taken from the context of the target message for the signature. This context includes information about the message itself, such as its control data, as well as any additional state and context held by the signer or verifier. In particular, when signing a response, the signer can include any derived components from the originating request by using the req parameter (Section 2.4).
派生コンポーネント値は、署名のターゲットメッセージのコンテキストから取得されます。このコンテキストには、コントロールデータなどのメッセージ自体に関する情報、および署名者または検証者が保有する追加の状態とコンテキストが含まれます。特に、応答に署名する場合、署名者は、REQパラメーター（セクション2.4）を使用して、発信元の要求から派生コンポーネントを含めることができます。
request:
リクエスト：
Values derived from, and results applied to, an HTTP request message as described in Section 3.4 of [HTTP]. If the target message of the signature is a response, derived components that target request messages can be included by using the req parameter as defined in Section 2.4.
[HTTP]のセクション3.4で説明されているように、HTTP要求メッセージから派生した値と結果。署名のターゲットメッセージが応答である場合、セクション2.4で定義されているREQパラメーターを使用して、ターゲットリクエストメッセージを含めることができる派生コンポーネント。
response:
応答：
Values derived from, and results applied to, an HTTP response message as described in Section 3.4 of [HTTP].
[HTTP]のセクション3.4で説明されているHTTP応答メッセージから導き出された値と結果。
request, response:
リクエスト、応答：
Values derived from, and results applied to, either a request message or a response message.
リクエストメッセージまたは応答メッセージから派生した値と結果が適用されます。
A derived component definition MUST define all target message types to which it can be applied.
派生コンポーネント定義は、適用できるすべてのターゲットメッセージタイプを定義する必要があります。
Derived component values MUST be limited to printable characters and spaces and MUST NOT contain any newline characters. Derived component values MUST NOT start or end with whitespace characters.
派生コンポーネントの値は、印刷可能な文字とスペースに限定されている必要があり、新しいライン文字を含めてはなりません。派生コンポーネント値は、Whitespace文字で起動または終了してはなりません。
The @method derived component refers to the HTTP method of a request message. The component value is canonicalized by taking the value of the method as a string. Note that the method name is case sensitive as per [HTTP], Section 9.1. While conventionally standardized method names are uppercase [ASCII], no transformation to the input method value's case is performed.
@method派生コンポーネントは、リクエストメッセージのHTTPメソッドを指します。コンポーネント値は、メソッドの値を文字列として取得することにより標準化されます。メソッド名は[http]、セクション9.1に従ってケースに敏感であることに注意してください。従来の標準化されたメソッド名は大文字です[ASCII]が、入力メソッド値のケースへの変換は実行されません。
For example, the following request message:
たとえば、次の要求メッセージ：
POST /path?param=value HTTP/1.1
Host: www.example.com
would result in the following @method component value:
次の@methodコンポーネント値が得られます。
POST
and the following signature base line:
次の署名ベースライン：
"@method": POST
The @target-uri derived component refers to the target URI of a request message. The component value is the target URI of the request ([HTTP], Section 7.1), assembled from all available URI components, including the authority.
@Target-URI派生コンポーネントは、リクエストメッセージのターゲットURIを指します。コンポーネント値は、当局を含む利用可能なすべてのURIコンポーネントから組み立てられた要求のターゲットURI（[HTTP]、セクション7.1）です。
For example, the following message sent over HTTPS:
たとえば、次のメッセージはhttpsを介して送信されました。
POST /path?param=value HTTP/1.1
Host: www.example.com
would result in the following @target-uri component value:
次の @Target-URIコンポーネント値が得られます。
https://www.example.com/path?param=value
and the following signature base line:
次の署名ベースライン：
"@target-uri": https://www.example.com/path?param=value
The @authority derived component refers to the authority component of the target URI of the HTTP request message, as defined in [HTTP], Section 7.2. In HTTP/1.1, this is usually conveyed using the Host header field, while in HTTP/2 and HTTP/3 it is conveyed using the :authority pseudo-header. The value is the fully qualified authority component of the request, comprised of the host and, optionally, port of the request target, as a string. The component value MUST be normalized according to the rules provided in [HTTP], Section 4.2.3. Namely, the hostname is normalized to lowercase, and the default port is omitted.
@Authority派生コンポーネントは、[HTTP]、セクション7.2で定義されているように、HTTP要求メッセージのターゲットURIの権限コンポーネントを指します。HTTP/1.1では、これは通常、ホストヘッダーフィールドを使用して伝達されますが、HTTP/2およびHTTP/3では、Authority Pseudo-Headerを使用して伝えられます。値は、ホストの完全に適格な権限コンポーネントであり、ホスト、およびオプションでは、リクエストターゲットのポートが文字列として構成されています。コンポーネント値は、[http]、セクション4.2.3で提供されるルールに従って正規化する必要があります。つまり、ホスト名は小文字に正規化され、デフォルトのポートは省略されています。
For example, the following request message:
たとえば、次の要求メッセージ：
POST /path?param=value HTTP/1.1
Host: www.example.com
would result in the following @authority component value:
次の@Authorityコンポーネント値が得られます。
www.example.com
and the following signature base line:
次の署名ベースライン：
"@authority": www.example.com
The @authority derived component SHOULD be used instead of signing the Host header field directly. See Section 7.2.4.
ホストヘッダーフィールドに直接署名する代わりに、@Authority派生コンポーネントを使用する必要があります。セクション7.2.4を参照してください。
The @scheme derived component refers to the scheme of the target URL of the HTTP request message. The component value is the scheme as a lowercase string as defined in [HTTP], Section 4.2. While the scheme itself is case insensitive, it MUST be normalized to lowercase for inclusion in the signature base.
@scheme派生コンポーネントは、HTTP要求メッセージのターゲットURLのスキームを指します。コンポーネント値は、[http]、セクション4.2で定義されている小文字の文字列としてのスキームです。スキーム自体は症例ではありませんが、署名ベースに含めるために小文字に正規化する必要があります。
For example, the following request message sent over plain HTTP:
たとえば、Plain HTTPを介して送信された次のリクエストメッセージ：
POST /path?param=value HTTP/1.1
Host: www.example.com
would result in the following @scheme component value:
次の@schemeコンポーネント値が得られます。
http
and the following signature base line:
次の署名ベースライン：
"@scheme": http
The @request-target derived component refers to the full request target of the HTTP request message, as defined in [HTTP], Section 7.1. The component value of the request target can take different forms, depending on the type of request, as described below.
@request-target派生コンポーネントは、[http]、セクション7.1で定義されているように、HTTP要求メッセージの完全な要求ターゲットを指します。要求ターゲットのコンポーネント値は、以下に説明するように、リクエストのタイプに応じて異なるフォームをとることができます。
For HTTP/1.1, the component value is equivalent to the request target portion of the request line. However, this value is more difficult to reliably construct in other versions of HTTP. Therefore, it is NOT RECOMMENDED that this component be used when versions of HTTP other than 1.1 might be in use.
HTTP/1.1の場合、コンポーネント値はリクエスト行のリクエストターゲット部分と同等です。ただし、この値は、HTTPの他のバージョンで確実に構築することがより困難です。したがって、1.1以外のHTTPのバージョンが使用されている場合は、このコンポーネントを使用することはお勧めしません。
The origin form value is a combination of the absolute path and query components of the request URL.
Origin Form値は、リクエストURLの絶対パスとクエリコンポーネントの組み合わせです。
For example, the following request message:
たとえば、次の要求メッセージ：
POST /path?param=value HTTP/1.1
Host: www.example.com
would result in the following @request-target component value:
次の @リクエストターゲットコンポーネント値が得られます。
/path?param=value
and the following signature base line:
次の署名ベースライン：
"@request-target": /path?param=value
The following request to an HTTP proxy with the absolute-form value, containing the fully qualified target URI:
完全に適格なターゲットURIを含む絶対形式の値を持つHTTPプロキシへの以下のリクエスト：
GET https://www.example.com/path?param=value HTTP/1.1
would result in the following @request-target component value:
次の @リクエストターゲットコンポーネント値が得られます。
https://www.example.com/path?param=value
and the following signature base line:
次の署名ベースライン：
"@request-target": https://www.example.com/path?param=value
The following CONNECT request with an authority-form value, containing the host and port of the target:
ターゲットのホストとポートを含む権限形式の値を持つ次の接続要求：
CONNECT www.example.com:80 HTTP/1.1
Host: www.example.com
would result in the following @request-target component value:
次の @リクエストターゲットコンポーネント値が得られます。
www.example.com:80
and the following signature base line:
次の署名ベースライン：
"@request-target": www.example.com:80
The following OPTIONS request message with the asterisk-form value, containing a single asterisk (*) character:
次のオプションでは、単一のアスタリスク（*）文字を含むアスタリスク形式の値でメッセージを要求します。
OPTIONS * HTTP/1.1
Host: www.example.com
would result in the following @request-target component value:
次の @リクエストターゲットコンポーネント値が得られます。
*
and the following signature base line:
次の署名ベースライン：
"@request-target": *
The @path derived component refers to the target path of the HTTP request message. The component value is the absolute path of the request target defined by [URI], with no query component and no trailing question mark (?) character. The value is normalized according to the rules provided in [HTTP], Section 4.2.3. Namely, an empty path string is normalized as a single slash (/) character. Path components are represented by their values before decoding any percent-encoded octets, as described in the simple string comparison rules provided in Section 6.2.1 of [URI].
@Path派生コンポーネントは、HTTP要求メッセージのターゲットパスを指します。コンポーネント値は、[URI]で定義された要求ターゲットの絶対パスであり、クエリコンポーネントも後続の疑問符（？）文字もありません。値は、[http]、セクション4.2.3で提供されるルールに従って正規化されます。つまり、空のパス文字列は、単一のスラッシュ（/）文字として正規化されます。パスコンポーネントは、[URI]のセクション6.2.1で提供されている単純な文字列比較ルールで説明されているように、パーセントエンコードされたオクテットをデコードする前に、その値で表されます。
For example, the following request message:
たとえば、次の要求メッセージ：
GET /path?param=value HTTP/1.1
Host: www.example.com
would result in the following @path component value:
次の @pathコンポーネント値が得られます。
/path
and the following signature base line:
次の署名ベースライン：
"@path": /path
The @query derived component refers to the query component of the HTTP request message. The component value is the entire normalized query string defined by [URI], including the leading ? character. The value is read using the simple string comparison rules provided in Section 6.2.1 of [URI]. Namely, percent-encoded octets are not decoded.
@Query派生コンポーネントは、HTTPリクエストメッセージのクエリコンポーネントを指します。コンポーネント値は、[URI]で定義されている正規化クエリ文字列全体が、主要なものを含めていますか？キャラクター。値は、[URI]のセクション6.2.1で提供される単純な文字列比較ルールを使用して読み取られます。つまり、パーセントエンコードされたオクテットはデコードされていません。
For example, the following request message:
たとえば、次の要求メッセージ：
GET /path?param=value&foo=bar&baz=bat%2Dman HTTP/1.1
Host: www.example.com
would result in the following @query component value:
次の@Queryコンポーネント値が得られます。
?param=value&foo=bar&baz=bat%2Dman
and the following signature base line:
次の署名ベースライン：
"@query": ?param=value&foo=bar&baz=bat%2Dman
The following request message:
次のリクエストメッセージ：
POST /path?queryString HTTP/1.1
Host: www.example.com
would result in the following @query component value:
次の@Queryコンポーネント値が得られます。
?queryString
and the following signature base line:
次の署名ベースライン：
"@query": ?queryString
Just like including an empty path component, the signer can include an empty query component to indicate that this component is not used in the message. If the query string is absent from the request message, the component value is the leading ? character alone:
空のパスコンポーネントを含めるのと同じように、署名者には空のクエリコンポーネントを含めることができ、このコンポーネントがメッセージで使用されていないことを示します。クエリ文字列がリクエストメッセージに存在しない場合、コンポーネント値はリーディングですか？キャラクターだけ：
?
resulting in the following signature base line:
次の署名ベースラインになります。
"@query": ?
If the query portion of a request target URI uses HTML form parameters in the format defined in Section 5 ("application/ x-www-form-urlencoded") of [HTMLURL], the @query-param derived component allows addressing of these individual query parameters. The query parameters MUST be parsed according to Section 5.1 ("application/x-www-form-urlencoded parsing") of [HTMLURL], resulting in a list of (nameString, valueString) tuples. The REQUIRED name parameter of each component identifier contains the encoded nameString of a single query parameter as a String value. The component value of a single named parameter is the encoded valueString of that single query parameter. Several different named query parameters MAY be included in the covered components. Single named parameters MAY occur in any order in the covered components, regardless of the order they occur in the query string.
[htmlurl]のセクション5（ "application/ x-www-form-urlencoded"）で定義されている形式でuriがHTMLフォームパラメーターを使用している場合、 @query-param派生コンポーネントは、これらの個々の個々のコンポーネントにアドレスを与えることができます。クエリパラメーター。クエリパラメーターは、[htmlurl]のセクション5.1（ "アプリケーション/x-www-form-urlencoded parsing"）に従って解析する必要があります。各コンポーネント識別子の必要な名前パラメーターには、文字列値として単一クエリパラメーターのエンコードされた名前が含まれています。単一の名前のパラメーターのコンポーネント値は、その単一クエリパラメーターのエンコードされた値を付けられています。いくつかの異なる名前のクエリパラメーターをカバーされたコンポーネントに含めることができます。単一の名前付きパラメーターは、クエリ文字列で発生する順序に関係なく、カバーされたコンポーネントの任意の順序で発生する場合があります。
The value of the name parameter and the component value of a single named parameter are calculated via the following process:
名前パラメーターの値と単一の名前のパラメーターのコンポーネント値は、次のプロセスで計算されます。
1. Parse the nameString or valueString of the named query parameter defined by Section 5.1 ("application/x-www-form-urlencoded parsing") of [HTMLURL]; this is the value after percent-encoded octets are decoded.
1. [htmlurl]のセクション5.1（ "Application/x-www-form-urlencoded parsing"）で定義された名前付きクエリパラメーターのnamestringまたはvaluestringを解析します。これは、割合でエンコードされたオクテットがデコードされた後の値です。
2. Encode the nameString or valueString using the "percent-encode after encoding" process defined by Section 5.2 ("application/ x-www-form-urlencoded serializing") of [HTMLURL]; this results in an ASCII string [ASCII].
2. [htmlurl]のセクション5.2（ "application/ x-www-form-urlencoded serializing"）で定義された「エンコード後の」プロセスを使用して、namestringまたはvaluestringをエンコードします。これにより、ASCII文字列[ASCII]が生成されます。
3. Output the ASCII string.
3. ASCII文字列を出力します。
Note that the component value does not include any leading question mark (?) characters, equals sign (=) characters, or separating ampersand (&) characters. Named query parameters with an empty valueString have an empty string as the component value. Note that due to inconsistencies in implementations, some query parameter parsing libraries drop such empty values.
コンポーネント値には、主要な質問マーク（？）文字、標識（=）文字、またはAmperSand（＆）文字の分離は含まれていないことに注意してください。空のValueStringを使用した名前のクエリパラメーターには、コンポーネント値として空の文字列があります。実装の矛盾により、一部のクエリパラメーター解析ライブラリはそのような空の値を落とすことに注意してください。
If a query parameter is named as a covered component but it does not occur in the query parameters, this MUST cause an error in the signature base generation.
クエリパラメーターがカバーコンポーネントとして命名されているが、クエリパラメーターで発生しない場合、これは署名ベース生成にエラーを引き起こす必要があります。
For example, for the following request:
たとえば、次のリクエストに対して：
GET /path?param=value&foo=bar&baz=batman&qux= HTTP/1.1
Host: www.example.com
Indicating the baz, qux, and param named query parameters would result in the following @query-param component values:
BAZ、QUX、およびPARAMという名前のクエリパラメーターを示すと、次の @Query-Paramコンポーネント値が得られます。
_baz_: batman
_BAZ_：バットマン
_qux_: an empty string
_Qux_：空の文字列
_param_: value
_PARAM_：値
and the following signature base lines, with (SP) indicating a single trailing space character before the empty component value:
次の署名ベースライン。（SP）は、空のコンポーネント値の前に単一のトレーリングスペース文字を示しています。
"@query-param";name="baz": batman
"@query-param";name="qux":(SP)
"@query-param";name="param": value
This derived component has some limitations. Specifically, the algorithms provided in Section 5 ("application/ x-www-form-urlencoded") of [HTMLURL] only support query parameters using percent-escaped UTF-8 encoding. Other encodings are not supported. Additionally, multiple instances of a named parameter are not reliably supported in the wild. If a parameter name occurs multiple times in a request, the named query parameter MUST NOT be included. If multiple parameters are common within an application, it is RECOMMENDED to sign the entire query string using the @query component identifier defined in Section 2.2.7.
この派生コンポーネントにはいくつかの制限があります。具体的には、[htmlurl]のセクション5（ "アプリケーション/ x-www-form-urlencoded"）で提供されているアルゴリズムは、パーセントエスケープUTF-8エンコーディングを使用してクエリパラメーターのみをサポートしています。他のエンコーディングはサポートされていません。さらに、名前付きパラメーターの複数のインスタンスは、野生では確実にサポートされていません。リクエストでパラメーター名が複数回発生した場合、名前付きクエリパラメーターを含める必要はありません。アプリケーション内で複数のパラメーターが一般的である場合、セクション2.2.7で定義された@Queryコンポーネント識別子を使用してクエリ文字列全体に署名することをお勧めします。
The encoding process allows query parameters that include newlines or other problematic characters in their values, or with alternative encodings such as using the plus (+) character to represent spaces. For the query parameters in this message:
エンコーディングプロセスでは、値にnewlinesまたはその他の問題のある文字を含むクエリパラメーター、またはPlus（）文字を使用してスペースを表すなどの代替エンコーディングを使用できます。このメッセージのクエリパラメーターの場合：
NOTE: '\' line wrapping per RFC 8792
GET /parameters?var=this%20is%20a%20big%0Amultiline%20value&\
bar=with+plus+whitespace&fa%C3%A7ade%22%3A%20=something HTTP/1.1
Host: www.example.com
Date: Tue, 20 Apr 2021 02:07:56 GMT
The resulting values are encoded as follows:
結果の値は次のようにエンコードされます。
"@query-param";name="var": this%20is%20a%20big%0Amultiline%20value
"@query-param";name="bar": with%20plus%20whitespace
"@query-param";name="fa%C3%A7ade%22%3A%20": something
If the encoding were not applied, the resultant values would be:
エンコーディングが適用されていない場合、結果の値は次のとおりです。
"@query-param";name="var": this is a big
multiline value
"@query-param";name="bar": with plus whitespace
"@query-param";name="façade\": ": something
This base string contains characters that violate the constraints on component names and values and is therefore invalid.
このベース文字列には、コンポーネント名と値の制約に違反する文字が含まれているため、無効です。
The @status derived component refers to the three-digit numeric HTTP status code of a response message as defined in [HTTP], Section 15. The component value is the serialized three-digit integer of the HTTP status code, with no descriptive text.
@Status派生コンポーネントは、[HTTP]、セクション15で定義されている応答メッセージの3桁の数値HTTPステータスコードを指します。コンポーネント値は、HTTPステータスコードのシリアル化された3桁の整数です。
For example, the following response message:
たとえば、次の応答メッセージ：
HTTP/1.1 200 OK
Date: Fri, 26 Mar 2010 00:05:00 GMT
would result in the following @status component value:
次の@Statusコンポーネント値が得られます。
200
and the following signature base line:
次の署名ベースライン：
"@status": 200
The @status component identifier MUST NOT be used in a request message.
@Statusコンポーネント識別子は、リクエストメッセージで使用してはなりません。
HTTP message signatures have metadata properties that provide information regarding the signature's generation and verification, consisting of the ordered set of covered components and the ordered set of parameters, where the parameters include a timestamp of signature creation, identifiers for verification key material, and other utilities. This metadata is represented by a special message component in the signature base for signature parameters; this special message component is treated slightly differently from other message components. Specifically, the signature parameters message component is REQUIRED as the last line of the signature base (Section 2.5), and the component identifier MUST NOT be enumerated within the set of covered components for any signature, including itself.
HTTPメッセージ署名には、署名の生成と検証に関する情報を提供するメタデータプロパティがあります。これには、カバーされたコンポーネントの順序付けられたセットとパラメーターの順序付けられたセットで構成されます。ここでは、署名作成のタイムスタンプ、検証キー資料の識別子、およびその他のユーティリティが含まれます。このメタデータは、署名パラメーターの署名ベースの特別なメッセージコンポーネントで表されます。この特別なメッセージコンポーネントは、他のメッセージコンポーネントとはわずかに異なって扱われます。具体的には、署名ベースの最後の行（セクション2.5）として署名パラメーターメッセージコンポーネントが必要であり、コンポーネント識別子は、それ自体を含む任意の署名のためにカバーコンポーネントのセット内に列挙されてはなりません。
The signature parameters component name is @signature-params.
署名パラメータコンポーネント名は @Signature-Paramsです。
The signature parameters component value is the serialization of the signature parameters for this signature, including the covered components ordered set with all associated parameters. These parameters include any of the following:
署名パラメーターコンポーネント値は、すべての関連するパラメーターで並べられたセットを並べ替えた対象コンポーネントを含む、この署名の署名パラメーターのシリアル化です。これらのパラメーターには、次のいずれかが含まれます。
created:
作成した：
Creation time as a UNIX timestamp value of type Integer. Sub-second precision is not supported. The inclusion of this parameter is RECOMMENDED.
タイプ整数のUNIXタイムスタンプ値としての作成時間。サブ秒の精度はサポートされていません。このパラメーターを含めることをお勧めします。
expires:
期限切れ：
Expiration time as a UNIX timestamp value of type Integer. Sub-second precision is not supported.
タイプ整数のUNIXタイムスタンプ値としての有効期限。サブ秒の精度はサポートされていません。
nonce:
ノンセ：
A random unique value generated for this signature as a String value.
文字列値としてこの署名に対して生成されたランダムな一意の値。
alg:
アルグ：
The HTTP message signature algorithm from the "HTTP Signature Algorithms" registry, as a String value.
文字列値として、「HTTP署名アルゴリズム」レジストリからのHTTPメッセージ署名アルゴリズム。
keyid:
KeyID：
The identifier for the key material as a String value.
文字列値としてキーマテリアルの識別子。
tag:
鬼ごっこ：
An application-specific tag for the signature as a String value. This value is used by applications to help identify signatures relevant for specific applications or protocols.
文字列値としての署名のアプリケーション固有のタグ。この値は、特定のアプリケーションまたはプロトコルに関連する署名を特定するのに役立つアプリケーションで使用されます。
Additional parameters can be defined in the "HTTP Signature Metadata Parameters" registry (Section 6.3). Note that the parameters are not in any general order, but once an ordering is chosen for a given set of parameters, it cannot be changed without altering the signature parameters value.
追加のパラメーターは、「HTTP署名メタデータパラメーター」レジストリ（セクション6.3）で定義できます。パラメーターは一般的な順序ではありませんが、特定のパラメーターセットの順序付けが選択されると、署名パラメーター値を変更せずに変更できないことに注意してください。
The signature parameters component value is serialized as a parameterized Inner List using the rules provided in Section 4 of [STRUCTURED-FIELDS] as follows:
署名パラメーターコンポーネント値は、[構造化場]のセクション4で提供されているルールを使用して、次のように次のようにパラメーター化された内部リストとしてシリアル化されます。
1. Let the output be an empty string.
1. 出力を空の文字列にします。
2. Determine an order for the component identifiers of the covered components, not including the @signature-params component identifier itself. Once this order is chosen, it cannot be changed. This order MUST be the same order as that used in creating the signature base (Section 2.5).
2. @Signature-Paramsコンポーネント識別子自体を含まない、対象コンポーネントのコンポーネント識別子の注文を決定します。この注文が選択されると、変更することはできません。この順序は、署名ベースの作成に使用される順序と同じ順序でなければなりません（セクション2.5）。
3. Serialize the component identifiers of the covered components, including all parameters, as an ordered Inner List of String values according to Section 4.1.1.1 of [STRUCTURED-FIELDS]; then, append this to the output. Note that the component identifiers can include their own parameters, and these parameters are ordered sets. Once an order is chosen for a component's parameters, the order cannot be changed.
3. [構造化場]のセクション4.1.1.1に従って、文字列値の順序付けられた内部リストとして、すべてのパラメーターを含む、対象コンポーネントのコンポーネント識別子をシリアル化します。次に、これを出力に追加します。コンポーネント識別子には独自のパラメーターを含めることができ、これらのパラメーターは並べ替えられたセットです。コンポーネントのパラメーターの注文が選択されると、注文を変更することはできません。
4. Determine an order for any signature parameters. Once this order is chosen, it cannot be changed.
4. 署名パラメーターの注文を決定します。この注文が選択されると、変更することはできません。
5. Append the parameters to the Inner List in order according to Section 4.1.1.2 of [STRUCTURED-FIELDS], skipping parameters that are not available or not used for this message signature.
5. [構造化場]のセクション4.1.1.2に従って、パラメーターを内側リストに追加し、このメッセージ署名に使用できないか、使用していないパラメーターをスキップします。
6. The output contains the signature parameters component value.
6. 出力には、署名パラメータコンポーネント値が含まれています。
Note that the Inner List serialization from Section 4.1.1.1 of [STRUCTURED-FIELDS] is used for the covered component value instead of the List serialization from Section 4.1.1 of [STRUCTURED-FIELDS] in order to facilitate parallelism with this value's inclusion in the Signature-Input field, as discussed in Section 4.1.
[構造化場]のセクション4.1.1.1からの内側リストのシリアル化は、[構造化場]のセクション4.1.1からのリストのシリアル化の代わりに、カバーされたコンポーネント値に使用されていることに注意して、この値との並列性を促進します。セクション4.1で説明したように、署名入力フィールド。
This example shows the serialized component value for the parameters of an example message signature:
この例は、メッセージメッセージ署名のパラメーターのシリアル化されたコンポーネント値を示しています。
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
Note that an HTTP message could contain multiple signatures (Section 4.3), but only the signature parameters used for a single signature are included in a given signature parameters entry.
HTTPメッセージには複数の署名（セクション4.3）が含まれる可能性がありますが、単一の署名に使用される署名パラメーターのみが特定の署名パラメーターエントリに含まれています。
When a request message results in a signed response message, the signer can include portions of the request message in the signature base by adding the req parameter to the component identifier.
リクエストメッセージが署名された応答メッセージを作成する場合、署名者は、reqパラメーターをコンポーネント識別子に追加することにより、署名ベースにリクエストメッセージの一部を含めることができます。
req
req
A Boolean flag indicating that the component value is derived from the request that triggered this response message and not from the response message directly.
コンポーネント値が、直接応答メッセージではなく、この応答メッセージをトリガーした要求から派生していることを示すブールフラグ。
This parameter can be applied to both HTTP fields and derived components that target the request, with the same semantics. The component value for a message component using this parameter is calculated in the same manner as it is normally, but data is pulled from the request message instead of the target response message to which the signature is applied.
このパラメーターは、同じセマンティクスを使用して、リクエストをターゲットにするHTTPフィールドと派生コンポーネントの両方に適用できます。このパラメーターを使用したメッセージコンポーネントのコンポーネント値は、通常と同じ方法で計算されますが、データは署名が適用されるターゲット応答メッセージの代わりにリクエストメッセージから引き出されます。
Note that the same component name MAY be included with and without the req parameter in a single signature base, indicating the same named component from both the request message and the response message.
同じコンポーネント名が、単一の署名ベースにREQパラメーターの有無にかかわらず含まれる場合があり、要求メッセージと応答メッセージの両方から同じ名前のコンポーネントを示していることに注意してください。
The req parameter MAY be combined with other parameters as appropriate for the component identifier, such as the key parameter for a Dictionary field.
REQパラメーターは、辞書フィールドの重要なパラメーターなど、コンポーネント識別子に適した場合に、他のパラメーターと組み合わせることができます。
For example, when serving a response for this request:
たとえば、このリクエストの応答を提供する場合：
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"}
This would result in the following unsigned response message:
これにより、次の署名されていない応答メッセージが表示されます。
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"}
The server signs the response with its own key, including the @status code and several header fields in the covered components. While this covers a reasonable amount of the response for this application, the server additionally includes several components derived from the original request message that triggered this response. In this example, the server includes the method, authority, path, and content digest from the request in the covered components of the response. The Content-Digest for both the request and the response is included under the response signature. For the application in this example, the query is deemed not to be relevant to the response and is therefore not covered. Other applications would make different decisions based on application needs, as discussed in Section 1.4.
サーバーは、@Statusコードや対象コンポーネントのいくつかのヘッダーフィールドなど、独自のキーで応答に署名します。これはこのアプリケーションの合理的な量の応答をカバーしていますが、サーバーには、この応答をトリガーした元のリクエストメッセージから派生したいくつかのコンポーネントが追加されています。この例では、サーバーには、応答の対象コンポーネントのリクエストからメソッド、権限、パス、およびコンテンツが消化します。リクエストと応答の両方のコンテンツダイエストは、応答署名の下に含まれています。この例のアプリケーションの場合、クエリは応答に関連していないとみなされるため、カバーされません。セクション1.4で説明したように、他のアプリケーションはアプリケーションのニーズに基づいて異なる決定を下します。
The signature base for this example is:
この例の署名ベースは次のとおりです。
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"
The signed response message is:
署名された応答メッセージは次のとおりです。
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"}
Note that the ECDSA signature algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.
ここで使用されているECDSA署名アルゴリズムは非決定的であることに注意してください。つまり、アルゴリズムが実行されるたびに異なる署名値が作成されることを意味します。ここで提供される署名値は、指定されたキーに対して検証できますが、新しく生成された署名値は、例と一致するとは期待されていません。セクション7.3.5を参照してください。
Since the component values from the request are not repeated in the response message, the requester MUST keep the original message component values around long enough to validate the signature of the response that uses this component identifier parameter. In most cases, this means the requester needs to keep the original request message around, since the signer could choose to include any portions of the request in its response, according to the needs of the application. Since it is possible for an intermediary to alter a request message before it is processed by the server, applications need to take care not to sign such altered values, as the client would not be able to validate the resulting signature.
リクエストからのコンポーネント値は応答メッセージで繰り返されないため、リクエスタは、このコンポーネント識別子パラメーターを使用する応答の署名を検証するのに十分な長さの元のメッセージコンポーネント値を維持する必要があります。ほとんどの場合、これは、申請のニーズに応じて、署名者がリクエストの一部をその応答に含めることを選択できるため、リクエスタは元のリクエストメッセージを維持する必要があることを意味します。クライアントが結果の署名を検証できないため、仲介者がサーバーによって処理される前にリクエストメッセージを変更することが可能であるため、アプリケーションはそのような変更された値に署名しないように注意する必要があります。
It is also possible for a server to create a signed response in response to a signed request. For this example of a signed request:
また、サーバーが署名された要求に応じて署名された応答を作成することもできます。署名されたリクエストのこの例については：
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"}
The server could choose to sign portions of this response, including several portions of the request, resulting in this signature base:
サーバーは、リクエストのいくつかの部分を含め、この応答の一部に署名することを選択できます。この署名ベースになります。
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"
and the following signed response:
そして、次の署名された応答：
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"}
Note that the ECDSA signature algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.
ここで使用されているECDSA署名アルゴリズムは非決定的であることに注意してください。つまり、アルゴリズムが実行されるたびに異なる署名値が作成されることを意味します。ここで提供される署名値は、指定されたキーに対して検証できますが、新しく生成された署名値は、例と一致するとは期待されていません。セクション7.3.5を参照してください。
Applications signing a response to a signed request SHOULD sign all of the components of the request signature value to provide sufficient coverage and protection against a class of collision attacks, as discussed in Section 7.3.7. The server in this example has included all components listed in the Signature-Input field of the client's signature on the request in the response signature, in addition to components of the response.
署名された要求への応答に署名するアプリケーションは、セクション7.3.7で説明したように、衝突攻撃のクラスに対する十分なカバレッジと保護を提供するために、リクエスト署名値のすべてのコンポーネントに署名する必要があります。この例のサーバーには、応答のコンポーネントに加えて、応答署名のリクエスト上のクライアントの署名の署名入力フィールドにリストされているすべてのコンポーネントが含まれています。
While it is syntactically possible to include the Signature and Signature-Input fields of the request message in the signature components of a response to a message using this mechanism, this practice is NOT RECOMMENDED. This is because signatures of signatures do not provide transitive coverage of covered components as one might expect, and the practice is susceptible to several attacks as discussed in Section 7.3.7. An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely.
このメカニズムを使用してメッセージへの応答の署名コンポーネントにリクエストメッセージの署名と署名入力フィールドを含めることは構文的に可能ですが、このプラクティスは推奨されません。これは、署名の署名が予想されるように対象コンポーネントの推移的なカバレッジを提供しないためであり、セクション7.3.7で説明されているように、実践はいくつかの攻撃の影響を受けやすいためです。署名の成功した処理または受領を信号する必要があるアプリケーションは、そのような信号を安全に送信するための代替メカニズムを慎重に指定する必要があります。
The response signature can only ever cover what is included in the request message when using this flag. Consequently, if an application needs to include the message content of the request under the signature of its response, the client needs to include a means for covering that content, such as a Content-Digest field. See the discussion in Section 7.2.8 for more information.
応答署名は、このフラグを使用するときにリクエストメッセージに含まれるもののみをカバーできます。その結果、アプリケーションが応答の署名に基づいてリクエストのメッセージコンテンツを含める必要がある場合、クライアントは、コンテンツダイジェストフィールドなどのコンテンツをカバーするための手段を含める必要があります。詳細については、セクション7.2.8の説明を参照してください。
The req parameter MUST NOT be used for any component in a signature that targets a request message.
REQパラメーターは、要求メッセージをターゲットにする署名のコンポーネントに使用しないでください。
The signature base is an ASCII string [ASCII] containing the canonicalized HTTP message components covered by the signature. The input to the signature base creation algorithm is the ordered set of covered component identifiers and their associated values, along with any additional signature parameters discussed in Section 2.3.
署名ベースは、署名で覆われた標準化されたHTTPメッセージコンポーネントを含むASCII文字列[ASCII]です。署名ベース作成アルゴリズムへの入力は、セクション2.3で説明されている追加の署名パラメーターとともに、対象コンポーネント識別子の順序付けセットとそれに関連する値です。
Component identifiers are serialized using the strict serialization rules defined by [STRUCTURED-FIELDS], Section 4. The component identifier has a component name, which is a String Item value serialized using the sf-string ABNF rule. The component identifier MAY also include defined parameters that are serialized using the parameters ABNF rule. The signature parameters line defined in Section 2.3 follows this same pattern, but the component identifier is a String Item with a fixed value and no parameters, and the component value is always an Inner List with optional parameters.
コンポーネント識別子は、[構造化場]、セクション4で定義された厳密なシリアル化ルールを使用してシリアル化されます。コンポーネント識別子にはコンポーネント名があります。これは、SFストリングABNFルールを使用してシリアル化された文字列項目値です。コンポーネント識別子には、パラメーターABNFルールを使用してシリアル化された定義されたパラメーターを含めることもできます。セクション2.3で定義されている署名パラメーター行は、この同じパターンに従いますが、コンポーネント識別子は固定値とパラメーターがない文字列アイテムであり、コンポーネント値は常にオプションのパラメーターを持つ内部リストです。
Note that this means the serialization of the component name itself is encased in double quotes, with parameters following as a semicolon-separated list, such as "cache-control", "@authority", "@signature-params", or "example-dictionary";key="foo".
これは、コンポーネント名自体のシリアル化が二重引用符で囲まれていることを意味し、パラメーターは「キャッシュコントロール」、「@authority」、「@signature-params」、または「例」などのセミコロン分離リストとしてフォローしています。-dictionary "; key =" foo "。
The output is the ordered set of bytes that form the signature base, which conforms to the following ABNF:
出力は、署名ベースを形成する順序付けられたバイトセットであり、次のABNFに適合します。
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
To create the signature base, the signer or verifier concatenates entries for each component identifier in the signature's covered components (including their parameters) using the following algorithm. All errors produced as described MUST fail the algorithm immediately, without outputting a signature base.
署名ベースを作成するために、署名者または検証剤は、次のアルゴリズムを使用して、署名の対象コンポーネント（パラメーターを含む）の各コンポーネント識別子のエントリを連結します。記載されているように生成されたすべてのエラーは、署名ベースを出力せずに、すぐにアルゴリズムを失敗させる必要があります。
1. Let the output be an empty string.
1. 出力を空の文字列にします。
2. For each message component item in the covered components set (in order):
2. [順番に）設定されているcapedコンポーネントの各メッセージコンポーネント項目について：
2.1. If the component identifier (including its parameters) has already been added to the signature base, produce an error.
2.1. コンポーネント識別子（そのパラメーターを含む）がすでに署名ベースに追加されている場合、エラーが発生します。
2.2. Append the component identifier for the covered component serialized according to the component-identifier ABNF rule. Note that this serialization places the component name in double quotes and appends any parameters outside of the quotes.
2.2. コンポーネント-Identifier ABNFルールに従ってシリアル化されたカバーされたコンポーネントのコンポーネント識別子を追加します。このシリアル化は、コンポーネント名を二重引用符で掲載し、引用符以外のパラメーターを追加することに注意してください。
2.3. Append a single colon (:).
2.3. 単一のコロン（:)を追加します。
2.4. Append a single space (" ").
2.4. 単一のスペース（ ""）を追加します。
2.5. Determine the component value for the component identifier.
2.5. コンポーネント識別子のコンポーネント値を決定します。
* If the component identifier has a parameter that is not understood, produce an error.
* コンポーネント識別子に理解されていないパラメーターがある場合、エラーが発生します。
* If the component identifier has parameters that are mutually incompatible with one another, such as bs and sf, produce an error.
* コンポーネント識別子に、BSやSFなどの相互に互換性のないパラメーターがある場合、エラーが発生します。
* If the component identifier contains the req parameter and the target message is a request, produce an error.
* コンポーネント識別子にREQパラメーターが含まれ、ターゲットメッセージがリクエストである場合、エラーが発生します。
* If the component identifier contains the req parameter and the target message is a response, the context for the component value is the related request message of the target response message. Otherwise, the context for the component value is the target message.
* コンポーネント識別子にREQパラメーターが含まれ、ターゲットメッセージが応答である場合、コンポーネント値のコンテキストはターゲット応答メッセージの関連要求メッセージです。それ以外の場合、コンポーネント値のコンテキストはターゲットメッセージです。
* If the component name starts with an "at" (@) character, derive the component's value from the message according to the specific rules defined for the derived component, as provided in Section 2.2, including processing of any known valid parameters. If the derived component name is unknown or the value cannot be derived, produce an error.
* コンポーネント名が「at」（@）文字で始まる場合、既知の有効なパラメーターの処理を含むセクション2.2で規定されているように、派生コンポーネントに対して定義された特定のルールに従って、メッセージからコンポーネントの値を導き出します。派生コンポーネント名が不明な場合、または値を導出できない場合、エラーが発生します。
* If the component name does not start with an "at" (@) character, canonicalize the HTTP field value as described in Section 2.1, including processing of any known valid parameters. If the field cannot be found in the message or the value cannot be obtained in the context, produce an error.
* コンポーネント名が「at」（@）文字で始まらない場合、既知の有効なパラメーターの処理を含むセクション2.1で説明されているように、HTTPフィールド値を正規化します。メッセージにフィールドが見つからない場合、またはコンテキストで値を取得できない場合、エラーが発生します。
2.6. Append the covered component's canonicalized component value.
2.6. 対象のコンポーネントの標準化されたコンポーネント値を追加します。
2.7. Append a single newline (\n).
2.7. 単一の新しいライン（\ n）を追加します。
3. Append the signature parameters component (Section 2.3) according to the signature-params-line rule as follows:
3. 次のように、署名パラムラインルールに従って署名パラメーターコンポーネント（セクション2.3）を追加します。
3.1. Append the component identifier for the signature parameters serialized according to the component-identifier rule, i.e., the exact value "@signature-params" (including double quotes).
3.1. コンポーネント-Identifierルール、つまり正確な値「@Signature-Params」（二重引用符を含む）に従ってシリアル化された署名パラメーターのコンポーネント識別子を追加します。
3.2. Append a single colon (:).
3.2. 単一のコロン（:)を追加します。
3.3. Append a single space (" ").
3.3. 単一のスペース（ ""）を追加します。
3.4. Append the signature parameters' canonicalized component values as defined in Section 2.3, i.e., Inner List Structured Field values with parameters.
3.4. セクション2.3で定義されているように、署名パラメーターの標準化されたコンポーネント値を追加します。
4. Produce an error if the output string contains any non-ASCII characters [ASCII].
4. 出力文字列に非ASCII文字[ASCII]が含まれている場合、エラーを生成します。
5. Return the output string.
5. 出力文字列を返します。
If covered components reference a component identifier that cannot be resolved to a component value in the message, the implementation MUST produce an error and not create a signature base. Such situations include, but are not limited to, the following:
対象コンポーネントがメッセージ内のコンポーネント値に解決できないコンポーネント識別子を参照する場合、実装はエラーを生成し、署名ベースを作成する必要はありません。このような状況には、以下が含まれますが、これらに限定されません。
* The signer or verifier does not understand the derived component name.
* 署名者または検証者は、派生コンポーネント名を理解していません。
* The component name identifies a field that is not present in the message or whose value is malformed.
* コンポーネント名は、メッセージに存在しない、またはその値が奇形であるフィールドを識別します。
* The component identifier includes a parameter that is unknown or does not apply to the component identifier to which it is attached.
* コンポーネント識別子には、添付されているコンポーネント識別子に不明または適用されないパラメーターが含まれます。
* The component identifier indicates that a Structured Field serialization is used (via the sf parameter), but the field in question is known to not be a Structured Field or the type of Structured Field is not known to the implementation.
* コンポーネント識別子は、構造化されたフィールドシリアル化が（SFパラメーターを介して）使用されていることを示しますが、問題のフィールドは構造化されたフィールドではないことが知られているか、構造化されたフィールドのタイプが実装に知られていません。
* The component identifier is a Dictionary member identifier that references a field that is not present in the message, that is not a Dictionary Structured Field, or whose value is malformed.
* コンポーネント識別子は、メッセージに存在しないフィールド、辞書構造化されたフィールドではない、またはその値が奇形であるフィールドを参照する辞書メンバー識別子です。
* The component identifier is a Dictionary member identifier or a named query parameter identifier that references a member that is not present in the component value or whose value is malformed. For example, the identifier is "example-dict";key="c", and the value of the Example-Dict header field is a=1, b=2, which does not have the c value.
* コンポーネント識別子は、辞書メンバー識別子またはコンポーネント値に存在しないか、値が奇形であるメンバーを参照する名前のクエリパラメーター識別子です。たとえば、識別子は「example-dict」; key = "c"であり、例命令ヘッダーフィールドの値はa = 1、b = 2であり、C値はありません。
In the following non-normative example, the HTTP message being signed is the following request:
次の非規範的な例では、署名されているHTTPメッセージは次のリクエストです。
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"}
The covered components consist of the @method, @authority, and @path derived components followed by the Content-Digest, Content-Length, and Content-Type HTTP header fields, in order. The signature parameters consist of a creation timestamp of 1618884473 and a key identifier of test-key-rsa-pss. Note that no explicit alg parameter is given here, since the verifier is known by the application to use the RSA-PSS algorithm based on the identified key. The signature base for this message with these parameters is:
対象のコンポーネントは、@method、 @authority、および @path派生コンポーネントで構成され、その後、コンテンツダイジスト、コンテンツレングス、およびコンテンツタイプのHTTPヘッダーフィールドが順番に行われます。署名パラメーターは、1618884473の作成タイムスタンプと、Test-Key-RSA-PSSの重要な識別子で構成されています。特定されたキーに基づいてRSA-PSSアルゴリズムを使用するために検証剤がアプリケーションで知られているため、明示的なアルグパラメーターはここに示されていないことに注意してください。これらのパラメーターを使用したこのメッセージの署名ベースは次のとおりです。
NOTE: '\' line wrapping per RFC 8792
"@method": POST
"@authority": example.com
"@path": /foo
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-length": 18
"content-type": application/json
"@signature-params": ("@method" "@authority" "@path" \
"content-digest" "content-length" "content-type")\
;created=1618884473;keyid="test-key-rsa-pss"
Figure 1: Non-normative Example Signature Base
図1：非規範的な例の署名ベース
Note that the example signature base above does not include the final newline that ends the displayed example, nor do other example signature bases displayed elsewhere in this specification.
上記の例の署名ベースには、表示された例を終了する最終的な新しいラインは含まれておらず、この仕様の他の場所に表示される他の例の署名ベースも含まれていないことに注意してください。
An HTTP message signature is a signature over a string generated from a subset of the components of an HTTP message in addition to metadata about the signature itself. When successfully verified against an HTTP message, an HTTP message signature provides cryptographic proof that the message is semantically equivalent to the message for which the signature was generated, with respect to the subset of message components that was signed.
HTTPメッセージ署名は、署名自体に関するメタデータに加えて、HTTPメッセージのコンポーネントのサブセットから生成された文字列を介した署名です。HTTPメッセージに対して正常に検証された場合、HTTPメッセージの署名は、署名されたメッセージコンポーネントのサブセットに関して、メッセージが署名が生成されたメッセージと意味的に同等であるという暗号化された証明を提供します。
Creation of an HTTP message signature is a process that takes as its input the signature context (including the target message) and the requirements for the application. The output is a signature value and set of signature parameters that can be communicated to the verifier by adding them to the message.
HTTPメッセージの署名の作成は、署名コンテキスト（ターゲットメッセージを含む）とアプリケーションの要件を入力するときに実行するプロセスです。出力は、メッセージに追加することで検証者に伝達できる署名値と署名パラメーターのセットです。
In order to create a signature, a signer MUST apply the following algorithm:
署名を作成するには、署名者は次のアルゴリズムを適用する必要があります。
1. The signer chooses an HTTP signature algorithm and key material for signing from the set of potential signing algorithms. The set of potential algorithms is determined by the application and is out of scope for this document. The signer MUST choose key material that is appropriate for the signature's algorithm and that conforms to any requirements defined by the algorithm, such as key size or format. The mechanism by which the signer chooses the algorithm and key material is out of scope for this document.
1. 署名者は、潜在的な署名アルゴリズムのセットから署名するためのHTTP署名アルゴリズムと重要な資料を選択します。潜在的なアルゴリズムのセットは、アプリケーションによって決定され、このドキュメントの範囲外です。署名者は、署名のアルゴリズムに適しており、キーサイズや形式などのアルゴリズムによって定義された要件に準拠するキー資料を選択する必要があります。署名者がアルゴリズムとキー資料を選択するメカニズムは、このドキュメントの範囲外です。
2. The signer sets the signature's creation time to the current time.
2. 署名者は、署名の作成時間を現在まで設定します。
3. If applicable, the signer sets the signature's expiration time property to the time at which the signature is to expire. The expiration is a hint to the verifier, expressing the time at which the signer is no longer willing to vouch for the signature. An appropriate expiration length, and the processing requirements of this parameter, are application specific.
3. 該当する場合、署名者は署名の有効期限のある時間プロパティを署名の期限が切れる時間に設定します。有効期限は、署名者がもはや署名を保証する意思がない時間を表現する検証者のヒントです。適切な有効期限、およびこのパラメーターの処理要件は、アプリケーション固有です。
4. The signer creates an ordered set of component identifiers representing the message components to be covered by the signature and attaches signature metadata parameters to this set. The serialized value of this set is later used as the value of the Signature-Input field as described in Section 4.1.
4. 署名者は、署名でカバーするメッセージコンポーネントを表す順序付けられたコンポーネント識別子セットを作成し、このセットに署名メタデータパラメーターを添付します。このセットのシリアル化値は、セクション4.1で説明されているように、署名入力フィールドの値として後に使用されます。
* Once an order of covered components is chosen, the order MUST NOT change for the life of the signature.
* カバーされたコンポーネントの順序が選択されたら、署名の寿命のために注文が変更されてはなりません。
* Each covered component identifier MUST be either (1) an HTTP field (Section 2.1) in the signature context or (2) a derived component listed in Section 2.2 or in the "HTTP Signature Derived Component Names" registry.
* 対象コンポーネントの各識別子は、（1）署名コンテキストのHTTPフィールド（セクション2.1）、または（2）セクション2.2または「HTTP署名派生コンポーネント名」レジストリにリストされている派生コンポーネントのいずれかでなければなりません。
* Signers of a request SHOULD include some or all of the message control data in the covered components, such as the @method, @authority, @target-uri, or some combination thereof.
* リクエストの署名者には、 @method、 @authority、 @target-uri、またはその組み合わせなど、対象コンポーネントのメッセージ制御データの一部またはすべてを含める必要があります。
* Signers SHOULD include the created signature metadata parameter to indicate when the signature was created.
* 署名者は、作成された署名メタデータパラメーターを含めて、署名がいつ作成されたかを示す必要があります。
* The @signature-params derived component identifier MUST NOT be present in the list of covered component identifiers. The derived component is required to always be the last line in the signature base, ensuring that a signature always covers its own metadata and the metadata cannot be substituted.
* @signature-params派生コンポーネント識別子は、対象コンポーネント識別子のリストに存在しないでください。導出されたコンポーネントは、常に署名ベースの最後の行であるために必要であり、署名が常に独自のメタデータを覆い、メタデータを置き換えることができないことを保証します。
* Further guidance on what to include in this set and in what order is out of scope for this document.
* このセットに何を含めるか、およびこのドキュメントの範囲外の順序に関するさらなるガイダンス。
5. The signer creates the signature base using these parameters and the signature base creation algorithm (Section 2.5).
5. 署名者は、これらのパラメーターと署名ベース作成アルゴリズムを使用して署名ベースを作成します（セクション2.5）。
6. The signer uses the HTTP_SIGN primitive function to sign the signature base with the chosen signing algorithm using the key material chosen by the signer. The HTTP_SIGN primitive and several concrete applications of signing algorithms are defined in Section 3.3.
6. 署名者は、http_signプリミティブ関数を使用して、署名者が選択したキーマテリアルを使用して、選択した署名アルゴリズムで署名ベースに署名します。http_signプリミティブおよび署名アルゴリズムのいくつかのコンクリートアプリケーションは、セクション3.3で定義されています。
7. The byte array output of the signature function is the HTTP message signature output value to be included in the Signature field as defined in Section 4.2.
7. 署名関数のバイト配列出力は、セクション4.2で定義されているように、署名フィールドに含まれるHTTPメッセージ署名出力値です。
For example, given the HTTP message and signature parameters in the example in Section 2.5, the example signature base is signed with the test-key-rsa-pss key (see Appendix B.1.2) and the RSASSA-PSS algorithm described in Section 3.3.1, giving the following message signature output value, encoded in Base64:
たとえば、セクション2.5の例のHTTPメッセージと署名パラメーターを考慮して、署名ベースの例は、テストキー-RSA-PSSキー（付録B.1.2を参照）とセクション3.3で説明したRSASSA-PSSアルゴリズムで署名されています。.1、Base64でエンコードされた次のメッセージ署名出力値を与える：
NOTE: '\' line wrapping per RFC 8792
HIbjHC5rS0BYaa9v4QfD4193TORw7u9edguPh0AW3dMq9WImrlFrCGUDih47vAxi4L2\
YRZ3XMJc1uOKk/J0ZmZ+wcta4nKIgBkKq0rM9hs3CQyxXGxHLMCy8uqK488o+9jrptQ\
+xFPHK7a9sRL1IXNaagCNN3ZxJsYapFj+JXbmaI5rtAdSfSvzPuBCh+ARHBmWuNo1Uz\
VVdHXrl8ePL4cccqlazIJdC4QEjrF+Sn4IxBQzTZsL9y9TP5FsZYzHvDqbInkTNigBc\
E9cKOYNFCn4D/WM7F6TNuZO9EgtzepLWcjTymlHzK7aXq6Am6sfOrpIC49yXjj3ae6H\
RalVc/g==
Figure 2: Non-normative Example Signature Value
図2：非通常の例の署名値
Note that the RSA-PSS algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.
ここで使用されているRSA-PSSアルゴリズムは非決定的であることに注意してください。つまり、アルゴリズムが実行されるたびに異なる署名値が作成されることを意味します。ここで提供される署名値は、指定されたキーに対して検証できますが、新しく生成された署名値は、例と一致するとは期待されていません。セクション7.3.5を参照してください。
Verification of an HTTP message signature is a process that takes as its input the signature context (including the target message, particularly its Signature and Signature-Input fields) and the requirements for the application. The output of the verification is either a positive verification or an error.
HTTPメッセージの署名の検証は、署名コンテキスト（ターゲットメッセージ、特に署名および署名入力フィールドを含む）とアプリケーションの要件を入力すると、プロセスです。検証の出力は、肯定的な検証またはエラーのいずれかです。
In order to verify a signature, a verifier MUST apply the following algorithm:
署名を検証するには、検証者は次のアルゴリズムを適用する必要があります。
1. Parse the Signature and Signature-Input fields as described in Sections 4.1 and 4.2, and extract the signatures to be verified and their labels.
1. セクション4.1および4.2で説明されているように、署名および署名入力フィールドを解析し、検証する署名とラベルを抽出します。
1.1. If there is more than one signature value present, determine which signature should be processed for this message based on the policy and configuration of the verifier. If an applicable signature is not found, produce an error.
1.1. 複数の署名値が存在する場合は、検証器のポリシーと構成に基づいて、このメッセージの署名を処理する必要があるかを決定します。該当する署名が見つからない場合は、エラーを生成します。
1.2. If the chosen Signature field value does not have a corresponding Signature-Input field value (i.e., one with the same label), produce an error.
1.2. 選択した署名フィールド値に対応する署名入力フィールド値（つまり、同じラベルのあるもの）がない場合、エラーが発生します。
2. Parse the values of the chosen Signature-Input field as a parameterized Inner List to get the ordered list of covered components and the signature parameters for the signature to be verified.
2. 選択した署名入力フィールドの値をパラメーター化された内部リストとして解析して、検証される署名の署名パラメーターと署名パラメーターを取得します。
3. Parse the value of the corresponding Signature field to get the byte array value of the signature to be verified.
3. 対応する署名フィールドの値を解析して、検証する署名のバイト配列値を取得します。
4. Examine the signature parameters to confirm that the signature meets the requirements described in this document, as well as any additional requirements defined by the application such as which message components are required to be covered by the signature (Section 3.2.1).
4. 署名パラメーターを調べて、署名がこのドキュメントに記載されている要件を満たしていることを確認します。また、どのメッセージコンポーネントを署名でカバーする必要があるなどのアプリケーションで定義された追加要件（セクション3.2.1）。
5. Determine the verification key material for this signature. If the key material is known through external means such as static configuration or external protocol negotiation, the verifier will use the applicable technique to obtain the key material from this external knowledge. If the key is identified in the signature parameters, the verifier will dereference the key identifier to appropriate key material to use with the signature. The verifier has to determine the trustworthiness of the key material for the context in which the signature is presented. If a key is identified that the verifier does not know or trust for this request or that does not match something preconfigured, the verification MUST fail.
5. この署名の検証キー資料を決定します。重要な資料が静的構成や外部プロトコル交渉などの外部手段を通じて知られている場合、検証者は該当する手法を使用して、この外部知識から重要な資料を取得します。キーが署名パラメーターで識別されている場合、検証剤は、署名で使用する適切なキー資料のキー識別子を再参照します。検証者は、署名が提示されているコンテキストの重要な資料の信頼性を判断する必要があります。検証者がこの要求を知らない、または信頼していないこと、またはそれが事前に設定されたものと一致しないというキーが特定されている場合、検証は失敗する必要があります。
6. Determine the algorithm to apply for verification:
6. 検証に応募するアルゴリズムを決定します。
6.1. Start with the set of allowable algorithms known to the application. If any of the following steps select an algorithm that is not in this set, the signature validation fails.
6.1. アプリケーションに既知の許容アルゴリズムのセットから始めます。次の手順のいずれかがこのセットにないアルゴリズムを選択すると、署名検証は失敗します。
6.2. If the algorithm is known through external means such as static configuration or external protocol negotiation, the verifier will use that algorithm.
6.2. アルゴリズムが静的構成や外部プロトコル交渉などの外部平均を通じて既知である場合、検証者はそのアルゴリズムを使用します。
6.3. If the algorithm can be determined from the keying material, such as through an algorithm field on the key value itself, the verifier will use that algorithm.
6.3. キー値自体のアルゴリズムフィールドなど、キーイング材料からアルゴリズムを決定できる場合、検証者はそのアルゴリズムを使用します。
6.4. If the algorithm is explicitly stated in the signature parameters using a value from the "HTTP Signature Algorithms" registry, the verifier will use the referenced algorithm.
6.4. アルゴリズムが「HTTP署名アルゴリズム」レジストリの値を使用して署名パラメーターで明示的に記載されている場合、検証者は参照されるアルゴリズムを使用します。
6.5. If the algorithm is specified in more than one location (e.g., a combination of static configuration, the algorithm signature parameter, and the key material itself), the resolved algorithms MUST be the same. If the algorithms are not the same, the verifier MUST fail the verification.
6.5. アルゴリズムが複数の場所で指定されている場合（たとえば、静的構成、アルゴリズムの署名パラメーター、およびキーマテリアル自体の組み合わせ）、解決されたアルゴリズムは同じでなければなりません。アルゴリズムが同じでない場合、検証者は検証に失敗する必要があります。
7. Use the received HTTP message and the parsed signature parameters to recreate the signature base, using the algorithm defined in Section 2.5. The value of the @signature-params input is the value of the Signature-Input field for this signature serialized according to the rules described in Section 2.3. Note that this does not include the signature's label from the Signature-Input field.
7. セクション2.5で定義されているアルゴリズムを使用して、受信したHTTPメッセージと解析された署名パラメーターを使用して、署名ベースを再現します。@Signature-Params入力の値は、セクション2.3で説明されているルールに従ってシリアル化されたこの署名の署名入力フィールドの値です。これには、署名入力フィールドの署名ラベルは含まれていないことに注意してください。
8. If the key material is appropriate for the algorithm, apply the appropriate HTTP_VERIFY cryptographic verification algorithm to the signature, recalculated signature base, key material, and signature value. The HTTP_VERIFY primitive and several concrete algorithms are defined in Section 3.3.
8. キー資料がアルゴリズムに適している場合は、適切なhttp_verify暗号化検証アルゴリズムを署名、再計算された署名ベース、キーマテリアル、および署名値に適用します。http_verifyプリミティブといくつかのコンクリートアルゴリズムは、セクション3.3で定義されています。
9. The results of the verification algorithm function are the final results of the cryptographic verification function.
9. 検証アルゴリズム関数の結果は、暗号化検証関数の最終結果です。
If any of the above steps fail or produce an error, the signature validation fails.
上記の手順のいずれかが失敗またはエラーが発生した場合、署名検証は失敗します。
For example, verifying the signature with the label sig1 of the following message with the test-key-rsa-pss key (see Appendix B.1.2) and the RSASSA-PSS algorithm described in Section 3.3.1:
たとえば、次のメッセージのラベルSig1を使用して署名を検証し、テストキーRSA-PSSキー（付録B.1.2を参照）およびセクション3.3.1で説明したRSassa-PSSアルゴリズムを確認します。
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"}
With the additional requirements that at least the method, authority, path, content-digest, content-length, and content-type entries be signed, and that the signature creation timestamp be recent enough at the time of verification, the verification passes.
少なくともメソッド、権限、パス、コンテンツダイジスト、コンテンツレングス、およびコンテンツタイプのエントリが署名され、署名作成タイムスタンプが検証時に十分に最近であることを確認する追加の要件があるため、検証は通過します。
The verification requirements specified in this document are intended as a baseline set of restrictions that are generally applicable to all use cases. Applications using HTTP message signatures MAY impose requirements above and beyond those specified by this document, as appropriate for their use case.
このドキュメントで指定されている検証要件は、すべてのユースケースに一般的に適用される制限のベースラインセットとして意図されています。HTTPメッセージ署名を使用したアプリケーションは、ユースケースに適しているように、このドキュメントで指定されたものを超えて要件を課す場合があります。
Some non-normative examples of additional requirements an application might define are:
アプリケーションが定義する可能性のある追加要件のいくつかの非規範的な例は次のとおりです。
* Requiring a specific set of header fields to be signed (e.g., Authorization, Content-Digest).
* 特定の一連のヘッダーフィールドに署名する必要があります（たとえば、承認、コンテンツダイジスト）。
* Enforcing a maximum signature age from the time of the created timestamp.
* 作成されたタイムスタンプの時代から最大署名年齢を実施します。
* Rejecting signatures past the expiration time in the expires timestamp. Note that the expiration time is a hint from the signer and that a verifier can always reject a signature ahead of its expiration time.
* 期限切れの期限を過ぎて署名を拒否するタイムスタンプ。有効期限は署名者からのヒントであり、検証者は有効期限に先立って常に署名を拒否できることに注意してください。
* Prohibiting certain signature metadata parameters, such as runtime algorithm signaling with the alg parameter when the algorithm is determined from the key information.
* アルゴリズムが主要な情報から決定された場合のランタイムアルゴリズムシグナル伝達などの特定の署名メタデータパラメーターを禁止します。
* Ensuring successful dereferencing of the keyid parameter to valid and appropriate key material.
* keyIDパラメーターの有効かつ適切なキー資料への委任状の成功を保証します。
* Prohibiting the use of certain algorithms or mandating the use of a specific algorithm.
* 特定のアルゴリズムの使用を禁止するか、特定のアルゴリズムの使用を義務付けます。
* Requiring keys to be of a certain size (e.g., 2048 bits vs. 1024 bits).
* 特定のサイズのキーを必要とする（たとえば、2048ビット対1024ビット）。
* Enforcing uniqueness of the nonce parameter.
* NONCEパラメーターの独自性を強制します。
* Requiring an application-specific value for the tag parameter.
* タグパラメーターにアプリケーション固有の値が必要です。
Application-specific requirements are expected and encouraged. When an application defines additional requirements, it MUST enforce them during the signature verification process, and signature verification MUST fail if the signature does not conform to the application's requirements.
アプリケーション固有の要件が予想され、奨励されています。アプリケーションが追加の要件を定義する場合、署名検証プロセス中にそれらを実施する必要があり、署名が署名がアプリケーションの要件に準拠していない場合、署名検証が失敗する必要があります。
Applications MUST enforce the requirements defined in this document. Regardless of use case, applications MUST NOT accept signatures that do not conform to these requirements.
アプリケーションは、このドキュメントで定義されている要件を実施する必要があります。ユースケースに関係なく、アプリケーションはこれらの要件に準拠していない署名を受け入れてはなりません。
An HTTP message signature MUST use a cryptographic digital signature or MAC method that is appropriate for the key material, environment, and needs of the signer and verifier. This specification does not strictly limit the available signature algorithms, and any signature algorithm that meets these basic requirements MAY be used by an application of HTTP message signatures.
HTTPメッセージ署名は、署名者と検証者の主要な素材、環境、ニーズに適した暗号化デジタル署名またはMACメソッドを使用する必要があります。この仕様は、利用可能な署名アルゴリズムを厳密に制限するものではなく、これらの基本要件を満たす署名アルゴリズムは、HTTPメッセージ署名のアプリケーションによって使用される場合があります。
For each signing method, HTTP_SIGN takes as its input the signature base defined in Section 2.5 as a byte array (M) and the signing key material (Ks), and outputs the resultant signature as a byte array (S):
各署名方法について、http_signは、セクション2.5でバイト配列（M）および署名キーマテリアル（ks）として定義されている署名ベースを入力として取得し、結果の署名をバイト配列として出力します。
HTTP_SIGN (M, Ks) -> S
For each verification method, HTTP_VERIFY takes as its input the regenerated signature base defined in Section 2.5 as a byte array (M), the verification key material (Kv), and the presented signature to be verified as a byte array (S), and outputs the verification result (V) as a Boolean:
各検証方法について、http_verifyは、セクション2.5でバイト配列（m）、検証キーマテリアル（kv）、およびバイト配列として検証される提示された署名として定義された再生署名ベースを入力として取得します。検証結果（v）をブール値として出力します。
HTTP_VERIFY (M, Kv, S) -> V
The following sections contain several common signature algorithms and demonstrate how these cryptographic primitives map to the HTTP_SIGN and HTTP_VERIFY definitions above. Which method to use can be communicated through the explicit algorithm (alg) signature parameter (Section 2.3), by reference to the key material, or through mutual agreement between the signer and verifier. Signature algorithms selected using the alg parameter MUST use values from the "HTTP Signature Algorithms" registry (Section 6.2).
次のセクションには、いくつかの一般的な署名アルゴリズムが含まれており、これらの暗号化プリミティブが上記のhttp_signおよびhttp_verify定義にどのようにマッピングされるかを示します。使用する方法は、明示的なアルゴリズム（ALG）署名パラメーター（セクション2.3）、主要な資料を参照すること、または署名者と検証者の間の相互合意を通じて伝達できます。ALGパラメーターを使用して選択された署名アルゴリズムは、「HTTP署名アルゴリズム」レジストリ（セクション6.2）から値を使用する必要があります。
To sign using this algorithm, the signer applies the RSASSA-PSS-SIGN (K, M) function defined in [RFC8017] with the signer's private signing key (K) and the signature base (M) (Section 2.5). The mask generation function is MGF1 as specified in [RFC8017] with a hash function of SHA-512 [RFC6234]. The salt length (sLen) is 64 bytes. The hash function (Hash) SHA-512 [RFC6234] is applied to the signature base to create the digest content to which the digital signature is applied. The resulting signed content byte array (S) is the HTTP message signature output used in Section 3.1.
このアルゴリズムを使用して署名するために、署名者は[RFC8017]で定義されたRSASSA-PSS-SIGN（K、M）関数を署名者のプライベート署名キー（k）と署名ベース（M）（M）に適用します（セクション2.5）。マスク生成関数は、[RFC8017]で指定されているようにMGF1であり、SHA-512 [RFC6234]のハッシュ関数です。塩の長さ（スレン）は64バイトです。ハッシュ関数（ハッシュ）SHA-512 [RFC6234]が署名ベースに適用され、デジタル署名が適用されるダイジェストコンテンツを作成します。結果の署名されたコンテンツバイト配列は、セクション3.1で使用されるHTTPメッセージ署名出力です。
To verify using this algorithm, the verifier applies the RSASSA-PSS-VERIFY ((n, e), M, S) function [RFC8017] using the public key portion of the verification key material (n, e) and the signature base (M) recreated as described in Section 3.2. The mask generation function is MGF1 as specified in [RFC8017] with a hash function of SHA-512 [RFC6234]. The salt length (sLen) is 64 bytes. The hash function (Hash) SHA-512 [RFC6234] is applied to the signature base to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified (S) as described in Section 3.2. The results of the verification function indicate whether the signature presented is valid.
このアルゴリズムを使用して検証するために、検証剤は、検証キーマテリアル（n、e）の公開部分（n、e）（署名ベース）を使用して、rsassa-pss-verify（（n、e）、m、s）関数[rfc8017]を適用します。m）セクション3.2で説明されているように再作成されました。マスク生成関数は、[RFC8017]で指定されているようにMGF1であり、SHA-512 [RFC6234]のハッシュ関数です。塩の長さ（スレン）は64バイトです。ハッシュ関数（ハッシュ）SHA-512 [RFC6234]が署名ベースに適用され、検証関数が適用されるダイジェスト含有量が作成されます。検証器は、セクション3.2で説明されているように、検証するHTTPメッセージ署名を抽出します。検証関数の結果は、提示された署名が有効かどうかを示します。
Note that the output of the RSASSA-PSS algorithm is non-deterministic; therefore, it is not correct to recalculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See Section 7.3.5.
RSASSA-PSSアルゴリズムの出力は非決定的であることに注意してください。したがって、署名ベースの新しい署名を再計算し、結果を既存の署名と比較することは正しくありません。代わりに、ここで定義されている検証アルゴリズムを使用する必要があります。セクション7.3.5を参照してください。
The use of this algorithm can be indicated at runtime using the rsa-pss-sha512 value for the alg signature parameter.
このアルゴリズムの使用は、ALG署名パラメーターのRSA-PSS-SHA512値を使用して実行時に示すことができます。
To sign using this algorithm, the signer applies the RSASSA-PKCS1-V1_5-SIGN (K, M) function defined in [RFC8017] with the signer's private signing key (K) and the signature base (M) (Section 2.5). The hash SHA-256 [RFC6234] is applied to the signature base to create the digest content to which the digital signature is applied. The resulting signed content byte array (S) is the HTTP message signature output used in Section 3.1.
このアルゴリズムを使用して署名するために、署名者は[RFC8017]で定義されたRSASSA-PKCS1-V1_5-SIGN（K、M）関数を署名者のプライベート署名キー（K）と署名ベース（M）に適用します（セクション2.5）。ハッシュSHA-256 [RFC6234]が署名ベースに適用され、デジタル署名が適用されるダイジェストコンテンツを作成します。結果の署名されたコンテンツバイト配列は、セクション3.1で使用されるHTTPメッセージ署名出力です。
To verify using this algorithm, the verifier applies the RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S) function [RFC8017] using the public key portion of the verification key material (n, e) and the signature base (M) recreated as described in Section 3.2. The hash function SHA-256 [RFC6234] is applied to the signature base to create the digest content to which the verification function is applied. The verifier extracts the HTTP message signature to be verified (S) as described in Section 3.2. The results of the verification function indicate whether the signature presented is valid.
このアルゴリズムを使用して検証するために、検証剤は、検証キーマテリアル（N、E）の公開部分と署名の公開部分を使用して、RSASSA-PKCS1-V1_5-Verify（（n、e）、m、s）関数[rfc8017]を適用します。セクション3.2で説明されているように、ベース（M）再作成されました。ハッシュ関数SHA-256 [RFC6234]が署名ベースに適用され、検証関数が適用されるダイジェスト含有量が作成されます。検証器は、セクション3.2で説明されているように、検証するHTTPメッセージ署名を抽出します。検証関数の結果は、提示された署名が有効かどうかを示します。
The use of this algorithm can be indicated at runtime using the rsa-v1_5-sha256 value for the alg signature parameter.
このアルゴリズムの使用は、ALG署名パラメーターのRSA-V1_5-SHA256値を使用して実行時に示すことができます。
To sign and verify using this algorithm, the signer applies the HMAC function [RFC2104] with the shared signing key (K) and the signature base (text) (Section 2.5). The hash function SHA-256 [RFC6234] is applied to the signature base to create the digest content to which the HMAC is applied, giving the signature result.
このアルゴリズムを使用して署名して検証するには、署名者はHMAC関数[RFC2104]を共有署名キー（k）と署名ベース（テキスト）（セクション2.5）に適用します。ハッシュ関数SHA-256 [RFC6234]が署名ベースに適用され、HMACが適用されるダイジェストコンテンツを作成し、署名結果が得られます。
For signing, the resulting value is the HTTP message signature output used in Section 3.1.
署名の場合、結果の値は、セクション3.1で使用されるHTTPメッセージ署名出力です。
For verification, the verifier extracts the HTTP message signature to be verified (S) as described in Section 3.2. The output of the HMAC function is compared bytewise to the value of the HTTP message signature, and the results of the comparison determine the validity of the signature presented.
検証のために、検証剤は、セクション3.2で説明されているように、検証するHTTPメッセージ署名を抽出します。HMAC関数の出力は、bytewiseをHTTPメッセージ署名の値と比較し、比較の結果は提示された署名の有効性を決定します。
The use of this algorithm can be indicated at runtime using the hmac-sha256 value for the alg signature parameter.
このアルゴリズムの使用は、ALG署名パラメーターのHMAC-SHA256値を使用して実行時に示すことができます。
To sign using this algorithm, the signer applies the ECDSA signature algorithm defined in [FIPS186-5] using curve P-256 with the signer's private signing key and the signature base (Section 2.5). The hash SHA-256 [RFC6234] is applied to the signature base to create the digest content to which the digital signature is applied (M). The signature algorithm returns two integer values: r and s. These are both encoded as big-endian unsigned integers, zero-padded to 32 octets each. These encoded values are concatenated into a single 64-octet array consisting of the encoded value of r followed by the encoded value of s. The resulting concatenation of (r, s) is a byte array of the HTTP message signature output used in Section 3.1.
このアルゴリズムを使用して署名するために、署名者は、[FIPS186-5]で定義されたECDSA署名アルゴリズムを、署名者のプライベート署名キーと署名ベース（セクション2.5）を使用して、[FIPS186-5]を使用して適用します。ハッシュSHA-256 [RFC6234]が署名ベースに適用され、デジタル署名が適用されるダイジェストコンテンツ（M）を作成します。署名アルゴリズムは、rとsの2つの整数値を返します。これらはどちらも、それぞれ32オクテットにゼロパッドされたビッグエンディアンの符号なし整数としてエンコードされています。これらのエンコードされた値は、rのエンコードされた値で構成される単一の64-OCTETアレイに連結され、その後にsのエンコードされた値が続きます。結果の（r、s）の連結は、セクション3.1で使用されるHTTPメッセージ署名出力のバイト配列です。
To verify using this algorithm, the verifier applies the ECDSA signature algorithm defined in [FIPS186-5] using the public key portion of the verification key material and the signature base recreated as described in Section 3.2. The hash function SHA-256 [RFC6234] is applied to the signature base to create the digest content to which the signature verification function is applied (M). The verifier extracts the HTTP message signature to be verified (S) as described in Section 3.2. This value is a 64-octet array consisting of the encoded values of r and s concatenated in order. These are both encoded as big-endian unsigned integers, zero-padded to 32 octets each. The resulting signature value (r, s) is used as input to the signature verification function. The results of the verification function indicate whether the signature presented is valid.
このアルゴリズムを使用して検証するために、検証者は、[FIPS186-5]で定義されたECDSA署名アルゴリズムを、検証キーマテリアルの公開キー部分とセクション3.2で説明したように再現された署名ベースを使用して適用します。ハッシュ関数SHA-256 [RFC6234]が署名ベースに適用され、署名検証関数が適用されるダイジェストコンテンツ（M）を作成します。検証器は、セクション3.2で説明されているように、検証するHTTPメッセージ署名を抽出します。この値は、順に連結されたrとsのエンコードされた値で構成される64オクタート配列です。これらはどちらも、それぞれ32オクテットにゼロパッドされたビッグエンディアンの符号なし整数としてエンコードされています。結果の署名値（r、s）は、署名検証関数への入力として使用されます。検証関数の結果は、提示された署名が有効かどうかを示します。
Note that the output of ECDSA signature algorithms is non-deterministic; therefore, it is not correct to recalculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See Section 7.3.5.
ECDSA署名アルゴリズムの出力は非決定的であることに注意してください。したがって、署名ベースの新しい署名を再計算し、結果を既存の署名と比較することは正しくありません。代わりに、ここで定義されている検証アルゴリズムを使用する必要があります。セクション7.3.5を参照してください。
The use of this algorithm can be indicated at runtime using the ecdsa-p256-sha256 value for the alg signature parameter.
このアルゴリズムの使用は、ALG署名パラメーターのECDSA-P256-SHA256値を使用して実行時に示すことができます。
To sign using this algorithm, the signer applies the ECDSA signature algorithm defined in [FIPS186-5] using curve P-384 with the signer's private signing key and the signature base (Section 2.5). The hash SHA-384 [RFC6234] is applied to the signature base to create the digest content to which the digital signature is applied (M). The signature algorithm returns two integer values: r and s. These are both encoded as big-endian unsigned integers, zero-padded to 48 octets each. These encoded values are concatenated into a single 96-octet array consisting of the encoded value of r followed by the encoded value of s. The resulting concatenation of (r, s) is a byte array of the HTTP message signature output used in Section 3.1.
このアルゴリズムを使用して署名するために、署名者は、[FIPS186-5]で定義されたECDSA署名アルゴリズムを、署名者のプライベート署名キーと署名ベース（セクション2.5）を使用して、[FIPS186-5]を使用して適用します。ハッシュSHA-384 [RFC6234]が署名ベースに適用され、デジタル署名が適用されるダイジェストコンテンツ（M）を作成します。署名アルゴリズムは、rとsの2つの整数値を返します。これらはどちらも、それぞれ48オクテットにゼロパッドされたビッグエンディアンの符号なし整数としてエンコードされています。これらのエンコードされた値は、rのエンコードされた値で構成される単一の96-OCTETアレイに連結され、その後にsのエンコードされた値が続きます。結果の（r、s）の連結は、セクション3.1で使用されるHTTPメッセージ署名出力のバイト配列です。
To verify using this algorithm, the verifier applies the ECDSA signature algorithm defined in [FIPS186-5] using the public key portion of the verification key material and the signature base recreated as described in Section 3.2. The hash function SHA-384 [RFC6234] is applied to the signature base to create the digest content to which the signature verification function is applied (M). The verifier extracts the HTTP message signature to be verified (S) as described in Section 3.2. This value is a 96-octet array consisting of the encoded values of r and s concatenated in order. These are both encoded as big-endian unsigned integers, zero-padded to 48 octets each. The resulting signature value (r, s) is used as input to the signature verification function. The results of the verification function indicate whether the signature presented is valid.
このアルゴリズムを使用して検証するために、検証者は、[FIPS186-5]で定義されたECDSA署名アルゴリズムを、検証キーマテリアルの公開キー部分とセクション3.2で説明したように再現された署名ベースを使用して適用します。ハッシュ関数SHA-384 [RFC6234]が署名ベースに適用され、署名検証関数が適用されるダイジェストコンテンツ（M）を作成します。検証器は、セクション3.2で説明されているように、検証するHTTPメッセージ署名を抽出します。この値は、順に連結されたrとsのエンコードされた値で構成される96オクタート配列です。これらはどちらも、それぞれ48オクテットにゼロパッドされたビッグエンディアンの符号なし整数としてエンコードされています。結果の署名値（r、s）は、署名検証関数への入力として使用されます。検証関数の結果は、提示された署名が有効かどうかを示します。
Note that the output of ECDSA signature algorithms is non-deterministic; therefore, it is not correct to recalculate a new signature on the signature base and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See Section 7.3.5.
ECDSA署名アルゴリズムの出力は非決定的であることに注意してください。したがって、署名ベースの新しい署名を再計算し、結果を既存の署名と比較することは正しくありません。代わりに、ここで定義されている検証アルゴリズムを使用する必要があります。セクション7.3.5を参照してください。
The use of this algorithm can be indicated at runtime using the ecdsa-p384-sha384 value for the alg signature parameter.
このアルゴリズムの使用は、ALG署名パラメーターのECDSA-P384-SHA384値を使用して実行時に示すことができます。
To sign using this algorithm, the signer applies the Ed25519 algorithm defined in Section 5.1.6 of [RFC8032] with the signer's private signing key and the signature base (Section 2.5). The signature base is taken as the input message (M) with no prehash function. The signature is a 64-octet concatenation of R and S as specified in Section 5.1.6 of [RFC8032], and this is taken as a byte array for the HTTP message signature output used in Section 3.1.
このアルゴリズムを使用して署名するために、署名者は[RFC8032]のセクション5.1.6で定義されたED25519アルゴリズムを、署名者のプライベート署名キーと署名ベース（セクション2.5）に適用します。署名ベースは、プレハッシュ関数のない入力メッセージ（m）と見なされます。署名は、[RFC8032]のセクション5.1.6で指定されているRとSの64オクテットの連結であり、これはセクション3.1で使用されるHTTPメッセージ署名出力のバイト配列として使用されます。
To verify using this algorithm, the signer applies the Ed25519 algorithm defined in Section 5.1.7 of [RFC8032] using the public key portion of the verification key material (A) and the signature base recreated as described in Section 3.2. The signature base is taken as the input message (M) with no prehash function. The signature to be verified is processed as the 64-octet concatenation of R and S as specified in Section 5.1.7 of [RFC8032]. The results of the verification function indicate whether the signature presented is valid.
このアルゴリズムを使用して検証するために、署名者は、[RFC8032]のセクション5.1.7で定義されているED25519アルゴリズムを、検証キーマテリアル（a）の公開部分（a）とセクション3.2で説明したように再現された署名ベースを使用して適用します。署名ベースは、プレハッシュ関数のない入力メッセージ（m）と見なされます。検証される署名は、[RFC8032]のセクション5.1.7で指定されているRとSの64オクテットの連結として処理されます。検証関数の結果は、提示された署名が有効かどうかを示します。
The use of this algorithm can be indicated at runtime using the ed25519 value for the alg signature parameter.
このアルゴリズムの使用は、ALG署名パラメーターのED25519値を使用して実行時に示すことができます。
If the signing algorithm is a JSON Object Signing and Encryption (JOSE) signing algorithm from the "JSON Web Signature and Encryption Algorithms" registry established by [RFC7518], the JWS algorithm definition determines the signature and hashing algorithms to apply for both signing and verification.
署名アルゴリズムが「JSON Web Signature and Encryption Algorithms」レジストリから[RFC7518]によって確立されたJSONオブジェクトの署名および暗号化（Jose）の署名アルゴリズムである場合、JWSアルゴリズム定義は、署名とハッシュアルゴリズムの両方に適用される署名とハッシュアルゴリズムを決定します。。
For both signing and verification, the HTTP message's signature base (Section 2.5) is used as the entire "JWS Signing Input". The JOSE Header [JWS] [RFC7517] is not used, and the signature base is not first encoded in Base64 before applying the algorithm. The output of the JWS Signature is taken as a byte array prior to the Base64url encoding used in JOSE.
署名と検証の両方で、HTTPメッセージの署名ベース（セクション2.5）は、「JWS署名入力」全体として使用されます。ホセヘッダー[JWS] [RFC7517]は使用されておらず、アルゴリズムを適用する前に署名ベースはBase64で最初にエンコードされません。JWS署名の出力は、ホセで使用されるbase64urlエンコードの前にバイト配列として使用されます。
The JWS algorithm MUST NOT be "none" and MUST NOT be any algorithm with a JOSE Implementation Requirement of "Prohibited".
JWSアルゴリズムは「なし」であってはならず、「禁止」というホセの実装要件を持つアルゴリズムであってはなりません。
JSON Web Algorithm (JWA) values from the "JSON Web Signature and Encryption Algorithms" registry are not included as signature parameters. Typically, the JWS algorithm can be signaled using JSON Web Keys (JWKs) or other mechanisms common to JOSE implementations. In fact, JWA values are not registered in the "HTTP Signature Algorithms" registry (Section 6.2), and so the explicit alg signature parameter is not used at all when using JOSE signing algorithms.
「JSON Web署名および暗号化アルゴリズム」レジストリのJSON Webアルゴリズム（JWA）値は、署名パラメーターとして含まれていません。通常、JWSアルゴリズムは、JSON Webキー（JWK）またはホセの実装に共通するその他のメカニズムを使用してシグナルを受けることができます。実際、JWA値は「HTTP署名アルゴリズム」レジストリ（セクション6.2）に登録されていないため、Jose Sing Singly Algorithmsを使用する場合は明示的なアルグ署名パラメーターをまったく使用しません。
HTTP message signatures can be included within an HTTP message via the Signature-Input and Signature fields, both defined within this specification.
HTTPメッセージ署名は、この仕様内で定義されている署名入力および署名フィールドを介してHTTPメッセージに含めることができます。
The Signature-Input field identifies the covered components and parameters that describe how the signature was generated, while the Signature field contains the signature value. Each field MAY contain multiple labeled values.
署名入力フィールドは、署名フィールドに署名値が含まれている一方で、署名の生成方法を説明するカバーされたコンポーネントとパラメーターを識別します。各フィールドには、複数のラベル付き値が含まれる場合があります。
An HTTP message signature is identified by a label within an HTTP message. This label MUST be unique within a given HTTP message and MUST be used in both the Signature-Input field and the Signature field. The label is chosen by the signer, except where a specific label is dictated by protocol negotiations such as those described in Section 5.
HTTPメッセージの署名は、HTTPメッセージ内のラベルによって識別されます。このラベルは、特定のHTTPメッセージ内で一意でなければならず、署名入力フィールドと署名フィールドの両方で使用する必要があります。ラベルは、セクション5に記載されているようなプロトコル交渉によって特定のラベルが決定される場合を除き、署名者によって選択されます。
An HTTP message signature MUST use both the Signature-Input field and the Signature field, and each field MUST contain the same labels. The presence of a label in one field but not the other is an error.
HTTPメッセージの署名は、署名入力フィールドと署名フィールドの両方を使用する必要があり、各フィールドには同じラベルが含まれている必要があります。1つのフィールドにラベルが存在するが、もう1つのフィールドではなく、エラーです。
The Signature-Input field is a Dictionary Structured Field (defined in Section 3.2 of [STRUCTURED-FIELDS]) containing the metadata for one or more message signatures generated from components within the HTTP message. Each member describes a single message signature. The member's key is the label that uniquely identifies the message signature within the HTTP message. The member's value is the covered components ordered set serialized as an Inner List, including all signature metadata parameters identified by the label:
署名入力フィールドは、HTTPメッセージ内のコンポーネントから生成された1つ以上のメッセージ署名のメタデータを含む辞書構造化場（[構造化場]のセクション3.2で定義）です。各メンバーは、単一のメッセージ署名について説明します。メンバーのキーは、HTTPメッセージ内のメッセージ署名を一意に識別するラベルです。メンバーの値は、ラベルによって識別されたすべての署名メタデータパラメーターを含む、内部リストとしてシリアル化された順序付けされたコンポーネントである対象コンポーネントです。
NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig1=("@method" "@target-uri" "@authority" \
"content-digest" "cache-control");\
created=1618884475;keyid="test-key-rsa-pss"
To facilitate signature validation, the Signature-Input field value MUST contain the same serialized value used in generating the signature base's @signature-params value defined in Section 2.3. Note that in a Structured Field value, list order and parameter order have to be preserved.
署名検証を容易にするために、署名入力フィールド値には、セクション2.3で定義された署名ベースの @署名パラム値を生成する際に使用される同じシリアル化値を含める必要があります。構造化されたフィールド値では、リストの順序とパラメーターの順序を保存する必要があることに注意してください。
The signer MAY include the Signature-Input field as a trailer to facilitate signing a message after its content has been processed by the signer. However, since intermediaries are allowed to drop trailers as per [HTTP], it is RECOMMENDED that the Signature-Input field be included only as a header field to avoid signatures being inadvertently stripped from a message.
署名者は、コンテンツが署名者によって処理された後にメッセージに署名することを促進するための予告編として署名入力フィールドを含めることができます。ただし、仲介者は[http]に従ってトレーラーをドロップすることが許可されているため、署名フィールドをヘッダーフィールドとしてのみ含めることをお勧めします。
Multiple Signature-Input fields MAY be included in a single HTTP message. The signature labels MUST be unique across all field values.
複数の署名入力フィールドを単一のHTTPメッセージに含めることができます。署名ラベルは、すべてのフィールド値にわたって一意でなければなりません。
The Signature field is a Dictionary Structured Field (defined in Section 3.2 of [STRUCTURED-FIELDS]) containing one or more message signatures generated from the signature context of the target message. The member's key is the label that uniquely identifies the message signature within the HTTP message. The member's value is a Byte Sequence containing the signature value for the message signature identified by the label:
署名フィールドは、ターゲットメッセージの署名コンテキストから生成された1つ以上のメッセージ署名を含む辞書構造化フィールド（[構造化場]のセクション3.2で定義）です。メンバーのキーは、HTTPメッセージ内のメッセージ署名を一意に識別するラベルです。メンバーの値は、ラベルによって識別されたメッセージ署名の署名値を含むバイトシーケンスです。
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==:
The signer MAY include the Signature field as a trailer to facilitate signing a message after its content has been processed by the signer. However, since intermediaries are allowed to drop trailers as per [HTTP], it is RECOMMENDED that the Signature field be included only as a header field to avoid signatures being inadvertently stripped from a message.
署名者は、署名者によってコンテンツが処理された後にメッセージに署名することを促進するための予告編として署名フィールドを含めることができます。ただし、仲介者は[http]に従ってトレーラーをドロップすることが許可されているため、署名フィールドは、メッセージから誤って剥がされないようにヘッダーフィールドとしてのみ含めることをお勧めします。
Multiple Signature fields MAY be included in a single HTTP message. The signature labels MUST be unique across all field values.
複数の署名フィールドを単一のHTTPメッセージに含めることができます。署名ラベルは、すべてのフィールド値にわたって一意でなければなりません。
Multiple distinct signatures MAY be included in a single message. Each distinct signature MUST have a unique label. These multiple signatures could all be added by the same signer, or they could come from several different signers. For example, a signer may include multiple signatures signing the same message components with different keys or algorithms to support verifiers with different capabilities, or a reverse proxy may include information about the client in fields when forwarding the request to a service host, including a signature over the client's original signature values.
複数の異なる署名が単一のメッセージに含まれる場合があります。それぞれの異なる署名には、一意のラベルが必要です。これらの複数の署名はすべて同じ署名者によって追加されるか、いくつかの異なる署名者から来ることがあります。たとえば、署名者には、異なるキーまたはアルゴリズムを持つ同じメッセージコンポーネントに署名する複数の署名が含まれる場合があります。異なる機能を持つ検証者をサポートするため、またはリバースプロキシには、リクエストをサービスホストを含むサービスホストに転送する際にフィールド内のクライアントに関する情報を含めることができます。クライアントの元の署名値について。
The following non-normative example starts with a signed request from the client. A reverse proxy takes this request and validates the client's signature:
次の非規範的な例は、クライアントからの署名された要求から始まります。リバースプロキシはこのリクエストを受け取り、クライアントの署名を検証します。
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"}
The proxy then alters the message before forwarding it on to the origin server, changing the target host and adding the Forwarded header field defined in [RFC7239]:
次に、プロキシはメッセージを変更してからOrigin Serverに転送し、ターゲットホストを変更し、[RFC7239]で定義されている転送ヘッダーフィールドを追加します。
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"}
The proxy is in a position to validate the incoming client's signature and make its own statement to the origin server about the nature of the request that it is forwarding by adding its own signature over the new message before passing it along to the origin server. The proxy also includes all the elements from the original message that are relevant to the origin server's processing. In many cases, the proxy will want to cover all the same components that were covered by the client's signature, which is the case in the following example. Note that in this example, the proxy is signing over the new authority value, which it has changed. The proxy also adds the Forwarded header field to its own signature value. The proxy identifies its own key and algorithm and, in this example, includes an expiration for the signature to indicate to downstream systems that the proxy will not vouch for this signed message past this short time window. This results in a signature base of:
プロキシは、着信クライアントの署名を検証し、Origin Serverに渡す前に新しいメッセージに独自の署名を追加することにより、転送されるというリクエストの性質についてOrigin Serverに独自のステートメントを作成します。プロキシには、Origin Serverの処理に関連する元のメッセージのすべての要素も含まれています。多くの場合、プロキシは、クライアントの署名でカバーされているすべてのコンポーネントをすべてカバーしたいと考えています。これは、次の例で当てはまります。この例では、プロキシは新しい当局の値に署名しており、それが変更されたことに注意してください。また、プロキシは、転送されたヘッダーフィールドを独自の署名値に追加します。プロキシは独自のキーとアルゴリズムを識別し、この例では、この短い時間枠を超えてプロキシがこの署名されたメッセージを保証しないことを下流システムに示すための署名の有効期限が含まれています。これにより、次の署名ベースが得られます。
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
and a signature output value of:
およびの署名出力値：
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==
These values are added to the HTTP request message by the proxy. The original signature is included under the label sig1, and the reverse proxy's signature is included under the label proxy_sig. The proxy uses the key test-key-rsa to create its signature using the rsa-v1_5-sha256 signature algorithm, while the client's original signature was made using the key test-key-rsa-pss and an RSA-PSS signature algorithm:
これらの値は、プロキシによってHTTP要求メッセージに追加されます。元の署名はラベルSig1の下に含まれており、逆プロキシの署名はラベルproxy_sigに含まれています。プロキシは、キーテストキーRSAを使用してRSA-V1_5-SHA256署名アルゴリズムを使用して署名を作成し、クライアントの元の署名は、キーテスト-Key-RSA-PSSとRSA-PSS署名アルゴリズムを使用して作成されました。
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"}
While the proxy could additionally include the client's Signature field value and Signature-Input fields from the original message in the new signature's covered components, this practice is NOT RECOMMENDED due to known weaknesses in signing signature values as discussed in Section 7.3.7. The proxy is in a position to validate the client's signature; the changes the proxy makes to the message will invalidate the existing signature when the message is seen by the origin server. In this example, it is possible for the origin server to have additional information in its signature context to account for the change in authority, though this practice requires additional configuration and extra care as discussed in Section 7.4.4. In other applications, the origin server will not be able to verify the original signature itself but will still want to verify that the proxy has done the appropriate validation of the client's signature. An application that needs to signal successful processing or receipt of a signature would need to carefully specify alternative mechanisms for sending such a signal securely.
プロキシには、新しい署名の対象コンポーネントの元のメッセージからのクライアントの署名フィールド値と署名入力フィールドをさらに含めることができますが、セクション7.3.7で説明したように、署名値に署名する既知の弱点があるため、このプラクティスは推奨されません。プロキシは、クライアントの署名を検証する立場にあります。メッセージにプロキシが行う変更は、メッセージがOrigin Serverによって表示されると、既存の署名を無効にします。この例では、Origin Serverが署名コンテキストに追加情報を作成して権限の変更を説明することができますが、セクション7.4.4で説明したように、追加の構成と追加の注意が必要です。他のアプリケーションでは、Origin Serverは元の署名自体を確認することはできませんが、プロキシがクライアントの署名の適切な検証を行ったことを確認する必要があります。署名の成功した処理または受領を信号する必要があるアプリケーションは、そのような信号を安全に送信するための代替メカニズムを慎重に指定する必要があります。
While a signer is free to attach a signature to a request or response without prompting, it is often desirable for a potential verifier to signal that it expects a signature from a potential signer using the Accept-Signature field.
署名者は、プロンプトなしでリクエストまたは応答に署名を自由に添付できますが、潜在的な検証者が受け入れ署名フィールドを使用して潜在的な署名者から署名を期待することを示すことが望ましいことがよくあります。
When the Accept-Signature field is sent in an HTTP request message, the field indicates that the client desires the server to sign the response using the identified parameters, and the target message is the response to this request. All responses from resources that support such signature negotiation SHOULD either be uncacheable or contain a Vary header field that lists Accept-Signature, in order to prevent a cache from returning a response with a signature intended for a different request.
Accept-SignatureフィールドがHTTP要求メッセージで送信されると、フィールドは、クライアントが識別されたパラメーターを使用して応答に署名することをクライアントに希望することを示し、ターゲットメッセージはこのリクエストに対する応答です。このような署名交渉をサポートするリソースからのすべての応答は、別のリクエストを目的とした署名を使用してキャッシュが応答を返すことを防ぐために、受け取ることができないか、受容署名をリストするさまざまなヘッダーフィールドを含める必要があります。
When the Accept-Signature field is used in an HTTP response message, the field indicates that the server desires the client to sign its next request to the server with the identified parameters, and the target message is the client's next request. The client can choose to also continue signing future requests to the same server in the same way.
Accept-SignatureフィールドがHTTP応答メッセージで使用される場合、フィールドは、サーバーが識別されたパラメーターでサーバーに次の要求に署名することをクライアントに希望することを示し、ターゲットメッセージはクライアントの次のリクエストです。クライアントは、同じ方法で同じサーバーへの将来のリクエストに署名を続けることもできます。
The target message of an Accept-Signature field MUST include all labeled signatures indicated in the Accept-Signature field, each covering the same identified components of the Accept-Signature field.
Accept-Signatureフィールドのターゲットメッセージには、Accept-Signatureフィールドに示されているすべてのラベル付きシグネチャを含める必要があります。
The sender of an Accept-Signature field MUST include only identifiers that are appropriate for the type of the target message. For example, if the target message is a request, the covered components cannot include the @status component identifier.
Accept-Signatureフィールドの送信者には、ターゲットメッセージのタイプに適した識別子のみを含める必要があります。たとえば、ターゲットメッセージがリクエストの場合、対象コンポーネントには@Statusコンポーネント識別子を含めることはできません。
The Accept-Signature field is a Dictionary Structured Field (defined in Section 3.2 of [STRUCTURED-FIELDS]) containing the metadata for one or more requested message signatures to be generated from message components of the target HTTP message. Each member describes a single message signature. The member's key is the label that uniquely identifies the requested message signature within the context of the target HTTP message.
Accept-Signatureフィールドは、ターゲットHTTPメッセージのメッセージコンポーネントから生成される1つ以上の要求されたメッセージ署名のメタデータを含む辞書構造化場（[構造化場]のセクション3.2で定義）です。各メンバーは、単一のメッセージ署名について説明します。メンバーのキーは、ターゲットHTTPメッセージのコンテキスト内で要求されたメッセージ署名を一意に識別するラベルです。
The member's value is the serialization of the desired covered components of the target message, including any allowed component metadata parameters, using the serialization process defined in Section 2.3:
メンバーの値は、セクション2.3で定義されているシリアル化プロセスを使用して、許可されたコンポーネントメタデータパラメーターを含む、ターゲットメッセージの目的のカバーコンポーネントのシリアル化です。
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"
The list of component identifiers indicates the exact set of component identifiers to be included in the requested signature, including all applicable component parameters.
コンポーネント識別子のリストは、該当するすべてのコンポーネントパラメーターを含む、要求された署名に含まれるコンポーネント識別子の正確なセットを示します。
The signature request MAY include signature metadata parameters that indicate desired behavior for the signer. The following behavior is defined by this specification:
署名リクエストには、署名者の希望の動作を示す署名メタデータパラメーターが含まれる場合があります。次の動作は、この仕様によって定義されます。
created:
作成した：
The signer is requested to generate and include a creation time. This parameter has no associated value when sent as a signature request.
署名者は、作成時間を生成して含めるように要求されます。このパラメーターには、署名リクエストとして送信された場合、関連する値はありません。
expires:
期限切れ：
The signer is requested to generate and include an expiration time. This parameter has no associated value when sent as a signature request.
署名者は、有効期限を生成して含めるように要求されます。このパラメーターには、署名リクエストとして送信された場合、関連する値はありません。
nonce:
ノンセ：
The signer is requested to include the value of this parameter as the signature nonce in the target signature.
署名者は、ターゲット署名の署名ノンセとしてこのパラメーターの値を含めるように要求されます。
alg:
アルグ：
The signer is requested to use the indicated signature algorithm from the "HTTP Signature Algorithms" registry to create the target signature.
署名者は、「HTTP署名アルゴリズム」レジストリから指定された署名アルゴリズムを使用して、ターゲット署名を作成するように要求されます。
keyid:
KeyID：
The signer is requested to use the indicated key material to create the target signature.
署名者は、指定されたキー資料を使用してターゲット署名を作成するように要求されます。
tag:
鬼ごっこ：
The signer is requested to include the value of this parameter as the signature tag in the target signature.
署名者は、このパラメーターの値をターゲット署名の署名タグとして含めるように要求されます。
The receiver of an Accept-Signature field fulfills that header as follows:
Accept-Signatureフィールドの受信者は、次のようにそのヘッダーを満たします。
1. Parse the field value as a Dictionary.
1. フィールド値を辞書として解析します。
2. For each member of the Dictionary:
2. 辞書の各メンバーについて：
2.1. The key is taken as the label of the output signature as specified in Section 4.1.
2.1. キーは、セクション4.1で指定されているように、出力署名のラベルと見なされます。
2.2. Parse the value of the member to obtain the set of covered component identifiers.
2.2. メンバーの値を解析して、カバーされたコンポーネント識別子のセットを取得します。
2.3. Determine that the covered components are applicable to the target message. If not, the process fails and returns an error.
2.3. 対象コンポーネントがターゲットメッセージに適用できることを決定します。そうでない場合、プロセスが失敗し、エラーが返されます。
2.4. Process the requested parameters, such as the signing algorithm and key material. If any requested parameters cannot be fulfilled or if the requested parameters conflict with those deemed appropriate to the target message, the process fails and returns an error.
2.4. 署名アルゴリズムやキー資料など、要求されたパラメーターを処理します。要求されたパラメーターを満たせない場合、または要求されたパラメーターがターゲットメッセージに適切とみなされるものと競合する場合、プロセスは失敗し、エラーを返します。
2.5. Select and generate any additional parameters necessary for completing the signature.
2.5. 署名を完了するために必要な追加のパラメーターを選択して生成します。
2.6. Create the HTTP message signature over the target message.
2.6. ターゲットメッセージにHTTPメッセージ署名を作成します。
2.7. Create the Signature-Input and Signature field values, and associate them with the label.
2.7. 署名入力と署名のフィールド値を作成し、それらをラベルに関連付けます。
3. Optionally create any additional Signature-Input and Signature field values, with unique labels not found in the Accept-Signature field.
3. オプションで、accept署名フィールドには一意のラベルが見つからない追加の署名入力および署名フィールド値を作成します。
4. Combine all labeled Signature-Input and Signature field values, and attach both fields to the target message.
4. ラベル付きのすべての署名入力と署名フィールド値を組み合わせて、両方のフィールドをターゲットメッセージに接続します。
By this process, a signature applied to a target message MUST have the same label, MUST include the same set of covered components, MUST process all requested parameters, and MAY have additional parameters.
このプロセスにより、ターゲットメッセージに適用される署名には同じラベルが必要であり、覆われたコンポーネントの同じセットを含める必要があり、要求されたすべてのパラメーターを処理する必要があり、追加のパラメーターがある場合があります。
The receiver of an Accept-Signature field MAY ignore any signature request that does not fit application parameters.
Accept-Signatureフィールドの受信者は、アプリケーションパラメーターに適合しない署名要求を無視する場合があります。
The target message MAY include additional signatures not specified by the Accept-Signature field. For example, to cover additional message components, the signer can create a second signature that includes the additional components as well as the signature output of the requested signature.
ターゲットメッセージには、Accept-Signatureフィールドによって指定されていない追加の署名が含まれます。たとえば、追加のメッセージコンポーネントをカバーするために、署名者は、要求された署名の署名出力だけでなく、追加のコンポーネントを含む2番目の署名を作成できます。
IANA has updated one registry and created four new registries, according to the following sections.
次のセクションによると、IANAは1つのレジストリを更新し、4つの新しいレジストリを作成しました。
IANA has updated the entries in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" as follows:
IANAは、次のように「ハイパーテキスト転送プロトコル（HTTP）フィールド名レジストリ」のエントリを更新しました。
+==================+===========+=========================+
| Field Name | Status | Reference |
+==================+===========+=========================+
| Signature-Input | permanent | Section 4.1 of RFC 9421 |
+------------------+-----------+-------------------------+
| Signature | permanent | Section 4.2 of RFC 9421 |
+------------------+-----------+-------------------------+
| Accept-Signature | permanent | Section 5.1 of RFC 9421 |
+------------------+-----------+-------------------------+
Table 1: Updates to the Hypertext Transfer Protocol (HTTP) Field Name Registry
表1：ハイパーテキスト転送プロトコル（HTTP）フィールド名レジストリの更新
This document defines HTTP signature algorithms, for which IANA has created and now maintains a new registry titled "HTTP Signature Algorithms". Initial values for this registry are given in Section 6.2.2. Future assignments and modifications to existing assignments are to be made through the Specification Required registration policy [RFC8126].
このドキュメントは、IANAが作成したHTTP署名アルゴリズムを定義し、「HTTP Signature Algorithms」というタイトルの新しいレジストリを維持しています。このレジストリの初期値は、セクション6.2.2に記載されています。既存の割り当てに対する将来の割り当てと変更は、仕様が必要な登録ポリシー[RFC8126]を通じて行われます。
The algorithms listed in this registry identify some possible cryptographic algorithms for applications to use with this specification, but the entries neither represent an exhaustive list of possible algorithms nor indicate fitness for purpose with any particular application of this specification. An application is free to implement any algorithm that suits its needs, provided the signer and verifier can agree to the parameters of that algorithm in a secure and deterministic fashion. When an application needs to signal the use of a particular algorithm at runtime using the alg signature parameter, this registry provides a mapping between the value of that parameter and a particular algorithm. However, the use of the alg parameter needs to be treated with caution to avoid various forms of algorithm confusion and substitution attacks, as discussed in Section 7.
このレジストリにリストされているアルゴリズムは、この仕様で使用するアプリケーションの可能な暗号化アルゴリズムを識別しますが、エントリは、可能なアルゴリズムの徹底的なリストを表したり、この仕様の特定のアプリケーションで目的の適合性を示したりすることはありません。アプリケーションは、署名者と検証者が安全で決定論的な方法でそのアルゴリズムのパラメーターに同意できる場合、そのニーズに合ったすべてのアルゴリズムを無料で実装できます。アプリケーションがアルグ署名パラメーターを使用して実行時に特定のアルゴリズムの使用を信号する必要がある場合、このレジストリはそのパラメーターの値と特定のアルゴリズムのマッピングを提供します。ただし、セクション7で説明したように、さまざまな形式のアルゴリズムの混乱と置換攻撃を避けるために、ALGパラメーターの使用を注意して処理する必要があります。
The Status value should reflect standardization status and the broad opinion of relevant interest groups such as the IETF or security-related Standards Development Organizations (SDOs). When an algorithm is first registered, the designated expert (DE) should set the Status field to "Active" if there is consensus for the algorithm to be generally recommended as secure or "Provisional" if the algorithm has not reached that consensus, e.g., for an experimental algorithm. A status of "Provisional" does not mean that the algorithm is known to be insecure but instead indicates that the algorithm has not reached consensus regarding its properties. If at a future time the algorithm as registered is found to have flaws, the registry entry can be updated and the algorithm can be marked as "Deprecated" to indicate that the algorithm has been found to have problems. This status does not preclude an application from using a particular algorithm; rather, it serves to provide a warning regarding possible known issues with an algorithm that need to be considered by the application. The DE can further ensure that the registration includes an explanation and reference for the Status value; this is particularly important for deprecated algorithms.
ステータス値は、IETFやセキュリティ関連標準開発組織（SDO）などの関連する利益団体の標準化ステータスと幅広い意見を反映する必要があります。アルゴリズムが最初に登録されている場合、指定されたエキスパート（DE）は、アルゴリズムが一般的にセキュアーとして推奨されるか、アルゴリズムがそのコンセンサスに達していない場合は「暫定」として推奨されることを一般的に推奨する場合、ステータスフィールドを「アクティブ」に設定する必要があります。実験アルゴリズムの場合。「暫定」のステータスは、アルゴリズムが不安定であることが知られていることを意味するのではなく、その代わりにアルゴリズムがその特性に関するコンセンサスに達していないことを示します。将来、登録されているアルゴリズムに欠陥があることがわかった場合、レジストリエントリを更新し、アルゴリズムにアルゴリズムに問題があることがわかっていることを示すために「非推奨」としてマークを付けることができます。このステータスは、アプリケーションが特定のアルゴリズムの使用を妨げるものではありません。むしろ、アプリケーションで考慮する必要があるアルゴリズムを使用して、既知の可能性に関する警告を提供するのに役立ちます。DEは、登録にステータス値の説明と参照が含まれることをさらに保証できます。これは、非推奨アルゴリズムにとって特に重要です。
The DE is expected to do the following:
DEは次のことを行うことが期待されています。
* Ensure that the algorithms referenced by a registered algorithm identifier are fully defined with all parameters (e.g., salt, hash, required key length) fixed by the defining text.
* 登録されたアルゴリズム識別子によって参照されるアルゴリズムが、定義テキストによって固定されたすべてのパラメーター（塩、ハッシュ、必要なキー長）で完全に定義されていることを確認してください。
* Ensure that the algorithm definition fully specifies the HTTP_SIGN and HTTP_VERIFY primitive functions, including how all defined inputs and outputs map to the underlying cryptographic algorithm.
* アルゴリズムの定義が、すべての定義された入力と出力が基礎となる暗号アルゴリズムにマッピングする方法を含む、http_signおよびhttp_verifyプリミティブ関数を完全に指定していることを確認してください。
* Reject any registrations that are aliases of existing registrations.
* 既存の登録のエイリアスである登録を拒否します。
* Ensure that all registrations follow the template presented in Section 6.2.1; this includes ensuring that the length of the name is not excessive while still being unique and recognizable.
* すべての登録がセクション6.2.1に示されているテンプレートに従っていることを確認してください。これには、ユニークで認識可能である間に、名前の長さが過度ではないことを保証することが含まれます。
This specification creates algorithm identifiers by including major parameters in the identifier String in order to make the algorithm name unique and recognizable by developers. However, algorithm identifiers in this registry are to be interpreted as whole String values and not as a combination of parts. That is to say, it is expected that implementors understand rsa-pss-sha512 as referring to one specific algorithm with its hash, mask, and salt values set as defined in the defining text that establishes the identifier in question. Implementors do not parse out the rsa, pss, and sha512 portions of the identifier to determine parameters of the signing algorithm from the String, and the registration of one combination of parameters does not imply the registration of other combinations.
この仕様は、アルゴリズム名を開発者が一意で認識できるようにするために、識別子文字列に主要なパラメーターを含めることにより、アルゴリズム識別子を作成します。ただし、このレジストリのアルゴリズム識別子は、パーツの組み合わせではなく、文字列値全体として解釈されることになります。つまり、実装者は、問題の識別子を確立する定義テキストで定義されているハッシュ、マスク、および塩値を使用して、1つの特定のアルゴリズム、および塩値を使用して1つの特定のアルゴリズムを参照することをRSA-PSS-SHA512を理解していることが予想されます。実装者は、識別子のRSA、PSS、およびSHA512部分を解析して、文字列から署名アルゴリズムのパラメーターを決定することはなく、パラメーターの1つの組み合わせの登録は、他の組み合わせの登録を意味しません。
Algorithm Name:
アルゴリズム名：
An identifier for the HTTP signature algorithm. The name MUST be an ASCII string that conforms to the sf-string ABNF rule in Section 3.3.3 of [STRUCTURED-FIELDS] and SHOULD NOT exceed 20 characters in length. The identifier MUST be unique within the context of the registry.
HTTP署名アルゴリズムの識別子。名前は、[構造化場]のセクション3.3.3のSF弦ABNFルールに準拠するASCII文字列でなければならず、長さ20文字を超えてはなりません。識別子は、レジストリのコンテキスト内で一意でなければなりません。
Description:
説明：
A brief description of the algorithm used to sign the signature base.
署名ベースに署名するために使用されるアルゴリズムの簡単な説明。
Status:
状態：
The status of the algorithm. MUST start with one of the following values and MAY contain additional explanatory text. The options are:
アルゴリズムのステータス。次の値のいずれかから開始する必要があり、追加の説明テキストが含まれている場合があります。オプションは次のとおりです。
"Active":
"アクティブ"：
For algorithms without known problems. The signature algorithm is fully specified, and its security properties are understood.
既知の問題のないアルゴリズムの場合。署名アルゴリズムは完全に指定されており、そのセキュリティプロパティが理解されています。
"Provisional":
"仮"：
For unproven algorithms. The signature algorithm is fully specified, but its security properties are not known or proven.
証明されていないアルゴリズム用。署名アルゴリズムは完全に指定されていますが、そのセキュリティプロパティは不明または証明されていません。
"Deprecated":
「非推奨」：
For algorithms with known security issues. The signature algorithm is no longer recommended for general use and might be insecure or unsafe in some known circumstances.
既知のセキュリティ問題を抱えるアルゴリズムの場合。署名アルゴリズムは、一般的な使用には推奨されなくなり、一部の既知の状況では不安または安全でない場合があります。
Reference:
参照：
Reference to the document or documents that specify the algorithm, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
アルゴリズムを指定するドキュメントまたはドキュメントへの参照、できればドキュメントのコピーを取得するために使用できるURIを含む。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
The table below contains the initial contents of the "HTTP Signature Algorithms" registry.
以下の表には、「HTTP署名アルゴリズム」レジストリの初期内容が含まれています。
+===================+===================+========+===============+
| Algorithm Name | Description | Status | Reference |
+===================+===================+========+===============+
| rsa-pss-sha512 | RSASSA-PSS using | Active | Section 3.3.1 |
| | SHA-512 | | of RFC 9421 |
+-------------------+-------------------+--------+---------------+
| rsa-v1_5-sha256 | RSASSA-PKCS1-v1_5 | Active | Section 3.3.2 |
| | using SHA-256 | | of RFC 9421 |
+-------------------+-------------------+--------+---------------+
| hmac-sha256 | HMAC using | Active | Section 3.3.3 |
| | SHA-256 | | of RFC 9421 |
+-------------------+-------------------+--------+---------------+
| ecdsa-p256-sha256 | ECDSA using curve | Active | Section 3.3.4 |
| | P-256 DSS and | | of RFC 9421 |
| | SHA-256 | | |
+-------------------+-------------------+--------+---------------+
| ecdsa-p384-sha384 | ECDSA using curve | Active | Section 3.3.5 |
| | P-384 DSS and | | of RFC 9421 |
| | SHA-384 | | |
+-------------------+-------------------+--------+---------------+
| ed25519 | EdDSA using curve | Active | Section 3.3.6 |
| | edwards25519 | | of RFC 9421 |
+-------------------+-------------------+--------+---------------+
Table 2: Initial Contents of the HTTP Signature Algorithms Registry
表2：HTTP署名アルゴリズムレジストリの初期内容
This document defines the signature parameters structure (Section 2.3), which may have parameters containing metadata about a message signature. IANA has created and now maintains a new registry titled "HTTP Signature Metadata Parameters" to record and maintain the set of parameters defined for use with member values in the signature parameters structure. Initial values for this registry are given in Section 6.3.2. Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy [RFC8126].
このドキュメントでは、メッセージ署名に関するメタデータを含むパラメーターがある場合がある署名パラメーター構造（セクション2.3）を定義します。IANAは、署名パラメーター構造のメンバー値で使用するために定義されたパラメーターのセットを記録および維持するために、「HTTP署名メタデータパラメーター」というタイトルの新しいレジストリを作成し、維持しています。このレジストリの初期値は、セクション6.3.2に記載されています。既存の課題に対する将来の割り当てと変更は、専門家のレビュー登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to do the following:
DEは次のことを行うことが期待されています。
* Ensure that the name follows the template presented in Section 6.3.1; this includes ensuring that the length of the name is not excessive while still being unique and recognizable for its defined function.
* 名前がセクション6.3.1に示されているテンプレートに従うことを確認してください。これには、名前の長さが過度ではなく、定義された機能に対してユニークで認識できるようにすることが含まれます。
* Ensure that the defined functionality is clear and does not conflict with other registered parameters.
* 定義された機能が明確であり、他の登録パラメーターと競合しないことを確認してください。
* Ensure that the definition of the metadata parameter includes its behavior when used as part of the normal signature process as well as when used in an Accept-Signature field.
* メタデータパラメーターの定義には、通常の署名プロセスの一部として使用された場合、および受け入れ署名フィールドで使用された場合の動作が含まれていることを確認してください。
Name:
名前：
An identifier for the HTTP signature metadata parameter. The name MUST be an ASCII string that conforms to the key ABNF rule defined in Section 3.1.2 of [STRUCTURED-FIELDS] and SHOULD NOT exceed 20 characters in length. The identifier MUST be unique within the context of the registry.
HTTP署名メタデータパラメーターの識別子。名前は、[構造化場]のセクション3.1.2で定義されているキーABNFルールに準拠するASCII文字列でなければならず、長さ20文字を超えてはなりません。識別子は、レジストリのコンテキスト内で一意でなければなりません。
Description:
説明：
A brief description of the metadata parameter and what it represents.
メタデータパラメーターとそれが表す内容の簡単な説明。
Reference:
参照：
Reference to the document or documents that specify the parameter, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
パラメーターを指定するドキュメントまたはドキュメントへの参照、できればドキュメントのコピーを取得するために使用できるURIを含むことが望ましい。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
The table below contains the initial contents of the "HTTP Signature Metadata Parameters" registry. Each row in the table represents a distinct entry in the registry.
以下の表には、「HTTP署名メタデータパラメーター」レジストリの初期内容が含まれています。テーブル内の各行は、レジストリ内の明確なエントリを表します。
+=========+===============================+=============+
| Name | Description | Reference |
+=========+===============================+=============+
| alg | Explicitly declared signature | Section 2.3 |
| | algorithm | of RFC 9421 |
+---------+-------------------------------+-------------+
| created | Timestamp of signature | Section 2.3 |
| | creation | of RFC 9421 |
+---------+-------------------------------+-------------+
| expires | Timestamp of proposed | Section 2.3 |
| | signature expiration | of RFC 9421 |
+---------+-------------------------------+-------------+
| keyid | Key identifier for the | Section 2.3 |
| | signing and verification keys | of RFC 9421 |
| | used to create this signature | |
+---------+-------------------------------+-------------+
| nonce | A single-use nonce value | Section 2.3 |
| | | of RFC 9421 |
+---------+-------------------------------+-------------+
| tag | An application-specific tag | Section 2.3 |
| | for a signature | of RFC 9421 |
+---------+-------------------------------+-------------+
Table 3: Initial Contents of the HTTP Signature Metadata Parameters Registry
表3：HTTP署名メタデータパラメータレジストリの初期内容
This document defines a method for canonicalizing HTTP message components, including components that can be derived from the context of the target message outside of the HTTP fields. These derived components are identified by a unique String, known as the component name. Component names for derived components always start with the "at" (@) symbol to distinguish them from HTTP field names. IANA has created and now maintains a new registry titled "HTTP Signature Derived Component Names" to record and maintain the set of non-field component names and the methods used to produce their associated component values. Initial values for this registry are given in Section 6.4.2. Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy [RFC8126].
このドキュメントでは、HTTPフィールドの外側のターゲットメッセージのコンテキストから導出できるコンポーネントを含む、HTTPメッセージコンポーネントを正規化する方法を定義します。これらの派生コンポーネントは、コンポーネント名として知られる一意の文字列によって識別されます。派生コンポーネントのコンポーネント名は常に「at」（@）シンボルから始まり、HTTPフィールド名と区別します。IANAは、非フィールドコンポーネント名のセットと関連するコンポーネント値の作成に使用される方法を記録および維持するために、「HTTP署名派生コンポーネント名」というタイトルの新しいレジストリを作成し、維持しています。このレジストリの初期値は、セクション6.4.2に記載されています。既存の課題に対する将来の割り当てと変更は、専門家のレビュー登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to do the following:
DEは次のことを行うことが期待されています。
* Ensure that the name follows the template presented in Section 6.4.1; this includes ensuring that the length of the name is not excessive while still being unique and recognizable for its defined function.
* 名前がセクション6.4.1に示されているテンプレートに従っていることを確認してください。これには、名前の長さが過度ではなく、定義された機能に対してユニークで認識できるようにすることが含まれます。
* Ensure that the component value represented by the registration request can be deterministically derived from the target HTTP message.
* 登録要求で表されるコンポーネント値が、ターゲットHTTPメッセージから決定的に導き出されることを確認してください。
* Ensure that any parameters defined for the registration request are clearly documented, along with their effects on the component value.
* 登録要求に定義されたパラメーターが、コンポーネント値への影響とともに明確に文書化されていることを確認してください。
The DE should ensure that a registration is sufficiently distinct from existing derived component definitions to warrant its registration.
DEは、登録が既存の派生コンポーネント定義と十分に異なることを確認する必要があります。
When setting a registered item's status to "Deprecated", the DE should ensure that a reason for the deprecation is documented, along with instructions for moving away from the deprecated functionality.
登録されたアイテムのステータスを「非推奨」に設定する場合、DEは、非推奨の理由と、非推奨機能から離れるための指示とともに、非推奨の理由が文書化されるようにする必要があります。
Name:
名前：
A name for the HTTP derived component. The name MUST begin with the "at" (@) character followed by an ASCII string consisting only of lowercase characters ("a"-"z"), digits ("0"-"9"), and hyphens ("-"), and SHOULD NOT exceed 20 characters in length. The name MUST be unique within the context of the registry.
HTTP派生コンポーネントの名前。名前は、「at」（@）文字に続いて、低いキャラクター（ "a" - "z"）、桁（ "0" - "9"）、およびハイフン（ " - "で構成されるASCII文字列が続く必要があります。）、長さ20文字を超えてはなりません。名前は、レジストリのコンテキスト内で一意でなければなりません。
Description:
説明：
A description of the derived component.
派生コンポーネントの説明。
Status:
状態：
A brief text description of the status of the algorithm. The description MUST begin with one of "Active" or "Deprecated" and MAY provide further context or explanation as to the reason for the status. A value of "Deprecated" indicates that the derived component name is no longer recommended for use.
アルゴリズムのステータスの簡単なテキスト説明。説明は、「アクティブ」または「非推奨」のいずれかで開始する必要があり、ステータスの理由についてさらなるコンテキストまたは説明を提供する場合があります。「非推奨」の値は、派生コンポーネント名が使用することを推奨しなくなったことを示します。
Target:
目標：
The valid message targets for the derived parameter. MUST be one of the values "Request", "Response", or "Request, Response". The semantics of these entries are defined in Section 2.2.
派生パラメーターの有効なメッセージターゲット。値「要求」、「応答」、または「リクエスト、応答」の1つでなければなりません。これらのエントリのセマンティクスは、セクション2.2で定義されています。
Reference:
参照：
Reference to the document or documents that specify the derived component, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
派生コンポーネントを指定するドキュメントまたはドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIを含む。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
The table below contains the initial contents of the "HTTP Signature Derived Component Names" registry.
以下の表には、「HTTP署名派生コンポーネント名」レジストリの初期内容が含まれています。
+===================+==============+========+==========+===========+
| Name | Description | Status | Target | Reference |
+===================+==============+========+==========+===========+
| @signature-params | Reserved for | Active | Request, | Section |
| | signature | | Response | 2.3 of |
| | parameters | | | RFC 9421 |
| | line in | | | |
| | signature | | | |
| | base | | | |
+-------------------+--------------+--------+----------+-----------+
| @method | The HTTP | Active | Request | Section |
| | request | | | 2.2.1 of |
| | method | | | RFC 9421 |
+-------------------+--------------+--------+----------+-----------+
| @authority | The HTTP | Active | Request | Section |
| | authority, | | | 2.2.3 of |
| | or target | | | RFC 9421 |
| | host | | | |
+-------------------+--------------+--------+----------+-----------+
| @scheme | The URI | Active | Request | Section |
| | scheme of | | | 2.2.4 of |
| | the request | | | RFC 9421 |
| | URI | | | |
+-------------------+--------------+--------+----------+-----------+
| @target-uri | The full | Active | Request | Section |
| | target URI | | | 2.2.2 of |
| | of the | | | RFC 9421 |
| | request | | | |
+-------------------+--------------+--------+----------+-----------+
| @request-target | The request | Active | Request | Section |
| | target of | | | 2.2.5 of |
| | the request | | | RFC 9421 |
+-------------------+--------------+--------+----------+-----------+
| @path | The full | Active | Request | Section |
| | path of the | | | 2.2.6 of |
| | request URI | | | RFC 9421 |
+-------------------+--------------+--------+----------+-----------+
| @query | The full | Active | Request | Section |
| | query of the | | | 2.2.7 of |
| | request URI | | | RFC 9421 |
+-------------------+--------------+--------+----------+-----------+
| @query-param | A single | Active | Request | Section |
| | named query | | | 2.2.8 of |
| | parameter | | | RFC 9421 |
+-------------------+--------------+--------+----------+-----------+
| @status | The status | Active | Response | Section |
| | code of the | | | 2.2.9 of |
| | response | | | RFC 9421 |
+-------------------+--------------+--------+----------+-----------+
Table 4: Initial Contents of the HTTP Signature Derived Component Names Registry
表4：HTTP署名派生コンポーネント名レジストリの初期内容
This document defines several kinds of component identifiers, some of which can be parameterized in specific circumstances to provide unique modified behavior. IANA has created and now maintains a new registry titled "HTTP Signature Component Parameters" to record and maintain the set of parameter names, the component identifiers they are associated with, and the modifications these parameters make to the component value. Definitions of parameters MUST define the targets to which they apply (such as specific field types, derived components, or contexts). Initial values for this registry are given in Section 6.5.2. Future assignments and modifications to existing assignments are to be made through the Expert Review registration policy [RFC8126].
このドキュメントでは、いくつかの種類のコンポーネント識別子を定義します。一部のコンポーネント識別子は、特定の状況でパラメーター化されて、一意の修正された動作を提供できます。IANAは、パラメーター名のセット、関連付けられているコンポーネント識別子、およびこれらのパラメーターがコンポーネント値に対して行う変更を記録および維持するために、「HTTP署名コンポーネントパラメーター」というタイトルの新しいレジストリを作成し、維持しています。パラメーターの定義は、適用するターゲット（特定のフィールドタイプ、派生コンポーネント、またはコンテキストなど）を定義する必要があります。このレジストリの初期値は、セクション6.5.2に記載されています。既存の課題に対する将来の割り当てと変更は、専門家のレビュー登録ポリシー[RFC8126]を通じて行われます。
The DE is expected to do the following:
DEは次のことを行うことが期待されています。
* Ensure that the name follows the template presented in Section 6.5.1; this includes ensuring that the length of the name is not excessive while still being unique and recognizable for its defined function.
* 名前がセクション6.5.1に示されているテンプレートに従っていることを確認してください。これには、名前の長さが過度ではなく、定義された機能に対してユニークで認識できるようにすることが含まれます。
* Ensure that the definition of the field sufficiently defines any interactions or incompatibilities with other existing parameters known at the time of the registration request.
* フィールドの定義が、登録要求時に既知の他の既存のパラメーターとの相互作用または非互換性を十分に定義していることを確認してください。
* Ensure that the component value defined by the component identifier with the parameter applied can be deterministically derived from the target HTTP message in cases where the parameter changes the component value.
* パラメーターがコンポーネント値を変更する場合のターゲットHTTPメッセージから、適用されたパラメーターを使用してコンポーネント識別子によって定義されたコンポーネント値がターゲットHTTPメッセージから決定的に導出できることを確認してください。
Name:
名前：
A name for the parameter. The name MUST be an ASCII string that conforms to the key ABNF rule defined in Section 3.1.2 of [STRUCTURED-FIELDS] and SHOULD NOT exceed 20 characters in length. The name MUST be unique within the context of the registry.
パラメーターの名前。名前は、[構造化場]のセクション3.1.2で定義されているキーABNFルールに準拠するASCII文字列でなければならず、長さ20文字を超えてはなりません。名前は、レジストリのコンテキスト内で一意でなければなりません。
Description:
説明：
A description of the parameter's function.
パラメーターの関数の説明。
Reference:
参照：
Reference to the document or documents that specify the derived component, preferably including a URI that can be used to retrieve a copy of the document(s). An indication of the relevant sections may also be included but is not required.
派生コンポーネントを指定するドキュメントまたはドキュメントへの参照。できれば、ドキュメントのコピーを取得するために使用できるURIを含む。関連するセクションの兆候も含まれる場合がありますが、必要ありません。
The table below contains the initial contents of the "HTTP Signature Component Parameters" registry.
以下の表には、「HTTP署名コンポーネントパラメーター」レジストリの初期内容が含まれています。
+======+=======================================+===============+
| Name | Description | Reference |
+======+=======================================+===============+
| sf | Strict Structured Field serialization | Section 2.1.1 |
| | | of RFC 9421 |
+------+---------------------------------------+---------------+
| key | Single key value of Dictionary | Section 2.1.2 |
| | Structured Fields | of RFC 9421 |
+------+---------------------------------------+---------------+
| bs | Byte Sequence wrapping indicator | Section 2.1.3 |
| | | of RFC 9421 |
+------+---------------------------------------+---------------+
| tr | Trailer | Section 2.1.4 |
| | | of RFC 9421 |
+------+---------------------------------------+---------------+
| req | Related request indicator | Section 2.4 |
| | | of RFC 9421 |
+------+---------------------------------------+---------------+
| name | Single named query parameter | Section 2.2.8 |
| | | of RFC 9421 |
+------+---------------------------------------+---------------+
Table 5: Initial Contents of the HTTP Signature Component Parameters Registry
表5：HTTP署名コンポーネントパラメーターレジストリの初期内容
In order for an HTTP message to be considered _covered_ by a signature, all of the following conditions have to be true:
httpメッセージを署名によって_covered_と見なすためには、次のすべての条件を真でなければなりません。
* A signature is expected or allowed on the message by the verifier.
* Verifierによるメッセージに署名が予想または許可されます。
* The signature exists on the message.
* メッセージに署名が存在します。
* The signature is verified against the identified key material and algorithm.
* 署名は、識別されたキーマテリアルとアルゴリズムに対して検証されます。
* The key material and algorithm are appropriate for the context of the message.
* 重要な資料とアルゴリズムは、メッセージのコンテキストに適しています。
* The signature is within expected time boundaries.
* 署名は予想される時間境界内です。
* The signature covers the expected content, including any critical components.
* 署名は、重要なコンポーネントを含む予想されるコンテンツをカバーします。
* The list of covered components is applicable to the context of the message.
* 対象コンポーネントのリストは、メッセージのコンテキストに適用できます。
In addition to the application requirement definitions listed in Section 1.4, the following security considerations provide discussion and context regarding the requirements of creating and verifying signatures on HTTP messages.
セクション1.4にリストされているアプリケーション要件定義に加えて、次のセキュリティに関する考慮事項は、HTTPメッセージの署名を作成および検証する要件に関する議論とコンテキストを提供します。
HTTP message signatures only provide security if the signature is verified by the verifier. Since the message to which the signature is attached remains a valid HTTP message without the Signature or Signature-Input fields, it is possible for a verifier to ignore the output of the verification function and still process the message. Common reasons for this could be relaxed requirements in a development environment or a temporary suspension of enforcing verification while debugging an overall system. Such temporary suspensions are difficult to detect under positive-example testing, since a good signature will always trigger a valid response whether or not it has been checked.
HTTPメッセージ署名は、署名が検証剤によって検証されている場合にのみセキュリティを提供します。署名が添付されているメッセージは、署名または署名入力フィールドのない有効なHTTPメッセージのままであるため、検証者は検証関数の出力を無視し、メッセージを処理することができます。これの一般的な理由は、開発環境での要件の緩和、またはシステム全体をデバッグしながら実施検証の一時的な一時停止である可能性があります。このような一時的な一時停止は、正の署名が常に確認されているかどうかにかかわらず有効な応答をトリガーするため、肯定的なテストで検出するのが困難です。
To detect this, verifiers should be tested using both valid and invalid signatures, ensuring that an invalid signature fails as expected.
これを検出するには、有効な署名と無効な署名の両方を使用して検証剤をテストし、予想どおりに無効な署名が失敗するようにする必要があります。
The use of HTTP message signatures does not negate the need for TLS or its equivalent to protect information in transit. Message signatures provide message integrity over the covered message components but do not provide any confidentiality for communication between parties.
HTTPメッセージ署名の使用は、TLSの必要性や、輸送中の情報を保護するための同等物を否定するものではありません。メッセージの署名は、カバーされたメッセージコンポーネント上のメッセージの整合性を提供しますが、パーティー間のコミュニケーションの機密性を提供しません。
TLS provides such confidentiality between the TLS endpoints. As part of this, TLS also protects the signature data itself from being captured by an attacker. This is an important step in preventing signature replay (Section 7.2.2).
TLSは、TLSエンドポイント間でそのような機密性を提供します。この一部として、TLSは署名データ自体が攻撃者によってキャプチャされるのを防ぎます。これは、署名のリプレイを防ぐための重要なステップです（セクション7.2.2）。
When TLS is used, it needs to be deployed according to the recommendations provided in [BCP195].
TLSを使用する場合、[BCP195]で提供される推奨事項に従って展開する必要があります。
Any portions of the message not covered by the signature are susceptible to modification by an attacker without affecting the signature. An attacker can take advantage of this by introducing or modifying a header field or other message component that will change the processing of the message but will not be covered by the signature. Such an altered message would still pass signature verification, but when the verifier processes the message as a whole, the unsigned content injected by the attacker would subvert the trust conveyed by the valid signature and change the outcome of processing the message.
署名でカバーされていないメッセージの一部は、署名に影響を与えることなく攻撃者が変更する可能性があります。攻撃者は、メッセージの処理を変更しますが、署名ではカバーされないヘッダーフィールドまたはその他のメッセージコンポーネントを導入または変更することで、これを利用できます。このような変更されたメッセージは署名検証に合格しますが、検証者がメッセージ全体としてメッセージを処理すると、攻撃者が注入する署名のないコンテンツは、有効な署名によって伝えられた信頼を覆し、メッセージの処理の結果を変更します。
To combat this, an application of this specification should require as much of the message as possible to be signed, within the limits of the application and deployment. The verifier should only trust message components that have been signed. Verifiers could also strip out any sensitive unsigned portions of the message before processing of the message continues.
これに対処するには、この仕様のアプリケーションには、アプリケーションと展開の制限内で、できるだけ多くのメッセージに署名する必要があります。検証者は、署名されたメッセージコンポーネントのみを信頼する必要があります。Verifiersは、メッセージの処理が継続する前に、メッセージの敏感な署名のない部分を削除することもできます。
Since HTTP message signatures allow sub-portions of the HTTP message to be signed, it is possible for two different HTTP messages to validate against the same signature. The most extreme form of this would be a signature over no message components. If such a signature were intercepted, it could be replayed at will by an attacker, attached to any HTTP message. Even with sufficient component coverage, a given signature could be applied to two similar HTTP messages, allowing a message to be replayed by an attacker with the signature intact.
HTTPメッセージ署名により、HTTPメッセージのサブパーティションが署名されるため、2つの異なるHTTPメッセージが同じ署名に対して検証される可能性があります。これの最も極端な形式は、メッセージコンポーネントなしの署名です。そのような署名が傍受された場合、HTTPメッセージに添付された攻撃者によって自由に再生される可能性があります。十分なコンポーネントカバレッジがあっても、特定の署名を2つの類似したHTTPメッセージに適用できるため、署名が無傷の攻撃者がメッセージを再生できます。
To counteract these kinds of attacks, it's first important for the signer to cover sufficient portions of the message to differentiate it from other messages. In addition, the signature can use the nonce signature parameter to provide a per-message unique value to allow the verifier to detect replay of the signature itself if a nonce value is repeated. Furthermore, the signer can provide a timestamp for when the signature was created and a time at which the signer considers the signature to be expired, limiting the utility of a captured signature value.
これらの種類の攻撃に対抗するために、署名者がメッセージの十分な部分を他のメッセージと区別するためにカバーすることが最初に重要です。さらに、署名はNonCe署名パラメーターを使用して、1人の署名パラメーターを使用して、NonCe値が繰り返された場合に検証者が署名自体のリプレイを検出できるようにするために、一定の一意の値を提供できます。さらに、署名者は、署名が作成されたときと、署名者が署名の有効期限が切れ、キャプチャされた署名値のユーティリティを制限する時期のタイムスタンプを提供できます。
If a verifier wants to trigger a new signature from a signer, it can send the Accept-Signature header field with a new nonce parameter. An attacker that is simply replaying a signature would not be able to generate a new signature with the chosen nonce value.
Verifierが署名者から新しい署名をトリガーしたい場合、Accect-Signatureヘッダーフィールドを新しいNONCEパラメーターで送信できます。単に署名を再生している攻撃者は、選択したNonCe値で新しい署名を生成することができません。
Applications of HTTP message signatures need to decide which message components will be covered by the signature. Depending on the application, some components could be expected to be changed by intermediaries prior to the signature's verification. If these components are covered, such changes would, by design, break the signature.
HTTPメッセージ署名のアプリケーションは、どのメッセージコンポーネントが署名でカバーされるかを決定する必要があります。アプリケーションに応じて、一部のコンポーネントは、署名の検証の前に仲介者によって変更されると予想される場合があります。これらのコンポーネントがカバーされている場合、そのような変更は、設計上、署名を破壊します。
However, this document allows for flexibility in determining which components are signed precisely so that a given application can choose the appropriate portions of the message that need to be signed, avoiding problematic components. For example, a web application framework that relies on rewriting query parameters might avoid using the @query derived component in favor of sub-indexing the query value using @query-param derived components instead.
ただし、このドキュメントにより、特定のアプリケーションが問題のあるコンポーネントを避けて、署名する必要があるメッセージの適切な部分を選択できるように、どのコンポーネントが正確に署名されているかを柔軟に決定することができます。たとえば、クエリパラメーターの書き換えに依存するWebアプリケーションフレームワークは、 @Query-Param派生コンポーネントを使用してクエリ値をサブインデックスすることを支持して、@Query派生コンポーネントの使用を避ける場合があります。
Some components are expected to be changed by intermediaries and ought not to be signed under most circumstances. The Via and Forwarded header fields, for example, are expected to be manipulated by proxies and other middleboxes, including replacing or entirely dropping existing values. These fields should not be covered by the signature, except in very limited and tightly coupled scenarios.
一部のコンポーネントは仲介者によって変更されると予想されており、ほとんどの状況では署名されるべきではありません。たとえば、VIAおよび転送されたヘッダーフィールドは、既存の値の交換または完全にドロップするなど、プロキシやその他のミドルボックスによって操作されると予想されます。これらのフィールドは、非常に限られた、緊密に結合されたシナリオを除いて、署名でカバーされるべきではありません。
Additional considerations for choosing signature aspects are discussed in Section 1.4.
署名の側面を選択するための追加の考慮事項については、セクション1.4で説明します。
Some HTTP fields have values and interpretations that are similar to HTTP signature parameters or derived components. In most cases, it is more desirable to sign the non-field alternative. In particular, the following fields should usually not be included in the signature unless the application specifically requires it:
一部のHTTPフィールドには、HTTP署名パラメーターまたは派生コンポーネントに似た値と解釈があります。ほとんどの場合、非フィールドの代替に署名することがより望ましいです。特に、アプリケーションが具体的に必要としない限り、通常、次のフィールドを署名に含めるべきではありません。
"date"
"日付"
The Date header field value represents the timestamp of the HTTP message. However, the creation time of the signature itself is encoded in the created signature parameter. These two values can be different, depending on how the signature and the HTTP message are created and serialized. Applications processing signatures for valid time windows should use the created signature parameter for such calculations. An application could also put limits on how much skew there is between the Date field and the created signature parameter, in order to limit the application of a generated signature to different HTTP messages. See also Sections 7.2.2 and 7.2.1.
日付ヘッダーフィールド値は、HTTPメッセージのタイムスタンプを表します。ただし、署名自体の作成時間は、作成された署名パラメーターにエンコードされています。これらの2つの値は、署名とHTTPメッセージがどのように作成され、シリアル化されているかによって異なります。有効なタイムウィンドウの署名を処理するアプリケーションは、そのような計算に作成された署名パラメーターを使用する必要があります。アプリケーションは、生成された署名のアプリケーションを異なるHTTPメッセージに制限するために、日付フィールドと作成された署名パラメーターの間にあるかどうかを制限することもできます。セクション7.2.2および7.2.1も参照してください。
"host"
"ホスト"
The Host header field is specific to HTTP/1.1, and its functionality is subsumed by the @authority derived component, defined in Section 2.2.3. In order to preserve the value across different HTTP versions, applications should always use the @authority derived component. See also Section 7.5.4.
ホストヘッダーフィールドはHTTP/1.1に固有であり、その機能はセクション2.2.3で定義されている@Authority派生コンポーネントによって包含されます。異なるHTTPバージョンにわたって値を保持するには、アプリケーションは常に@Authority派生コンポーネントを使用する必要があります。セクション7.5.4も参照してください。
HTTP message signature values are identified in the Signature and Signature-Input field values by unique labels. These labels are chosen only when attaching the signature values to the message and are not accounted for during the signing process. An intermediary is allowed to relabel an existing signature when processing the message.
HTTPメッセージ署名値は、一意のラベルによって署名および署名入力フィールド値で識別されます。これらのラベルは、署名値をメッセージに添付する場合にのみ選択され、署名プロセス中に説明されません。メッセージを処理するときに、既存の署名を仲介することが許可されています。
Therefore, applications should not rely on specific labels being present, and applications should not put semantic meaning on the labels themselves. Instead, additional signature parameters can be used to convey whatever additional meaning is required to be attached to, and covered by, the signature. In particular, the tag parameter can be used to define an application-specific value as described in Section 7.2.7.
したがって、アプリケーションは特定のラベルが存在することに依存してはならず、アプリケーションはラベル自体にセマンティックな意味を置くべきではありません。代わりに、追加の署名パラメーターを使用して、署名を添付し、カバーするために必要な追加の意味を伝えることができます。特に、タグパラメーターを使用して、セクション7.2.7で説明されているアプリケーション固有の値を定義できます。
Since multiple signatures can be applied to one message (Section 4.3), it is possible for an attacker to attach their own signature to a captured message without modifying existing signatures. This new signature could be completely valid based on the attacker's key, or it could be an invalid signature for any number of reasons. Each of these situations needs to be accounted for.
複数の署名を1つのメッセージ（セクション4.3）に適用できるため、攻撃者は既存の署名を変更せずにキャプチャされたメッセージに独自の署名を添付することができます。この新しい署名は、攻撃者のキーに基づいて完全に有効になる可能性があります。または、いくつかの理由で無効な署名である可能性があります。これらの各状況を説明する必要があります。
A verifier processing a set of valid signatures needs to account for all of the signers, identified by the signing keys. Only signatures from expected signers should be accepted, regardless of the cryptographic validity of the signature itself.
検証器処理有効な署名のセットは、署名キーによって識別されるすべての署名者を考慮する必要があります。 署名自体の暗号化の妥当性に関係なく、予想される署名者からの署名のみを受け入れる必要があります。
A verifier processing a set of signatures on a message also needs to determine what to do when one or more of the signatures are not valid. If a message is accepted when at least one signature is valid, then a verifier could drop all invalid signatures from the request before processing the message further. Alternatively, if the verifier rejects a message for a single invalid signature, an attacker could use this to deny service to otherwise valid messages by injecting invalid signatures alongside the valid signatures.
メッセージの署名のセットを処理する検証剤は、1つ以上の署名が無効である場合に何をすべきかを決定する必要があります。少なくとも1つの署名が有効なときにメッセージが受け入れられた場合、メッセージをさらに処理する前に、検証者が要求からすべての無効な署名をドロップすることができます。あるいは、Verifierが単一の無効な署名のメッセージを拒否した場合、攻撃者はこれを使用して、有効な署名とともに無効な署名を注入することにより、そうでなければ有効なメッセージにサービスを拒否できます。
Multiple applications and protocols could apply HTTP signatures on the same message simultaneously. In fact, this is a desired feature in many circumstances; see Section 4.3. A naive verifier could become confused while processing multiple signatures, either accepting or rejecting a message based on an unrelated or irrelevant signature. In order to help an application select which signatures apply to its own processing, the application can declare a specific value for the tag signature parameter as defined in Section 2.3. For example, a signature targeting an application gateway could require tag="app-gateway" as part of the signature parameters for that application.
複数のアプリケーションとプロトコルは、同じメッセージにHTTP署名を同時に適用できます。実際、これは多くの状況で望ましい機能です。セクション4.3を参照してください。無関係または無関係な署名に基づいてメッセージを受け入れるか拒否するかの複数の署名を処理する際に、素朴な検証者は混乱する可能性があります。アプリケーションが独自の処理に適用される署名を選択するのを支援するために、アプリケーションはセクション2.3で定義されているように、タグ署名パラメーターの特定の値を宣言できます。たとえば、アプリケーションゲートウェイをターゲットにする署名では、そのアプリケーションの署名パラメーターの一部としてtag = "app-gateway"が必要になる場合があります。
The use of the tag parameter does not prevent an attacker from also using the same value as a target application, since the parameter's value is public and otherwise unrestricted. As a consequence, a verifier should only use a value of the tag parameter to limit which signatures to check. Each signature still needs to be examined by the verifier to ensure that sufficient coverage is provided, as discussed in Section 7.2.1.
タグパラメーターを使用しても、パラメーターの値は公開されており、その他の場合は無制限であるため、攻撃者がターゲットアプリケーションと同じ値を使用することも妨げません。結果として、検証者はタグパラメーターの値のみを使用して、チェックする署名を制限する必要があります。セクション7.2.1で説明したように、各署名は、検証剤によってまだ検討する必要があります。
On its own, this specification does not provide coverage for the content of an HTTP message under the signature, in either a request or a response. However, [DIGEST] defines a set of fields that allow a cryptographic digest of the content to be represented in a field. Once this field is created, it can be included just like any other field as defined in Section 2.1.
それ自体では、この仕様は、リクエストまたは応答のいずれかで、署名の下でHTTPメッセージのコンテンツのカバレッジを提供しません。ただし、[Digest]は、コンテンツの暗号化ダイジェストをフィールドで表現できる一連のフィールドを定義します。このフィールドが作成されると、セクション2.1で定義されている他のフィールドと同様に含めることができます。
For example, in the following response message:
たとえば、次の応答メッセージで：
HTTP/1.1 200 OK
Content-Type: application/json
{"hello": "world"}
The digest of the content can be added to the Content-Digest field as follows:
コンテンツのダイジェストは、次のようにコンテンツダイジェストフィールドに追加できます。
NOTE: '\' line wrapping per RFC 8792
HTTP/1.1 200 OK
Content-Type: application/json
Content-Digest: \
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
{"hello": "world"}
This field can be included in a signature base just like any other field along with the basic signature parameters:
このフィールドは、基本的な署名パラメーターとともに、他のフィールドと同様に署名ベースに含めることができます。
"@status": 200
"content-digest": \
sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
"@signature-input": ("@status" "content-digest")
From here, the signing process proceeds as usual.
ここから、署名プロセスはいつものように進行します。
Upon verification, it is important that the verifier validate not only the signature but also the value of the Content-Digest field itself against the actual received content. Unless the verifier performs this step, it would be possible for an attacker to substitute the message content but leave the Content-Digest field value untouched to pass the signature. Since only the field value is covered by the signature directly, checking only the signature is not sufficient protection against such a substitution attack.
検証すると、検証者が署名だけでなく、実際の受信コンテンツに対してコンテンツダイジェストフィールド自体の値も検証することが重要です。Verifierがこのステップを実行しない限り、攻撃者がメッセージコンテンツを置き換えることができますが、コンテンツダイジェストのフィールド値は署名を通過させるために残します。フィールド値のみが署名で直接カバーされるため、署名のみをチェックすることは、そのような置換攻撃に対する十分な保護ではありません。
As discussed in [DIGEST], the value of the Content-Digest field is dependent on the content encoding of the message. If an intermediary changes the content encoding, the resulting Content-Digest value would change. This would in turn invalidate the signature. Any intermediary performing such an action would need to apply a new signature with the updated Content-Digest field value, similar to the reverse proxy use case discussed in Section 4.3.
[ダイジェスト]で説明したように、コンテンツダイジストフィールドの値は、メッセージのコンテンツエンコードに依存します。仲介者がコンテンツエンコーディングを変更すると、結果のコンテンツダイジェスト値が変更されます。これにより、署名が無効になります。このようなアクションを実行する仲介者は、セクション4.3で説明されている逆プロキシユースケースと同様に、更新されたコンテンツダイジェストフィールド値を使用して新しい署名を適用する必要があります。
Applications that make use of the req parameter (Section 2.4) also need to be aware of the limitations of this functionality. Specifically, if a client does not include something like a Content-Digest header field in the request, the server is unable to include a signature that covers the request's content.
REQパラメーター（セクション2.4）を使用するアプリケーションも、この機能の制限を認識する必要があります。具体的には、クライアントがリクエストにコンテンツダイジェストヘッダーフィールドのようなものを含めていない場合、サーバーはリクエストのコンテンツをカバーする署名を含めることができません。
This document does not define any of its own cryptographic primitives and instead relies on other specifications to define such elements. If the signature algorithm or key used to process the signature base is vulnerable to any attacks, the resulting signature will also be susceptible to these same attacks.
このドキュメントは、独自の暗号化プリミティブを定義するものではなく、代わりにそのような要素を定義するために他の仕様に依存しています。署名ベースの処理に使用される署名アルゴリズムまたはキーが攻撃に対して脆弱である場合、結果の署名はこれらの同じ攻撃の影響を受けやすくなります。
A common attack against signature systems is to force a signature collision, where the same signature value successfully verifies against multiple different inputs. Since this specification relies on reconstruction of the signature base from an HTTP message and the list of components signed is fixed in the signature, it is difficult but not impossible for an attacker to effect such a collision. An attacker would need to manipulate the HTTP message and its covered message components in order to make the collision effective.
署名システムに対する一般的な攻撃は、同じ署名値が複数の異なる入力に対して正常に検証される署名の衝突を強制することです。この仕様は、HTTPメッセージからの署名ベースの再構築に依存しており、署名されたコンポーネントのリストは署名に固定されているため、攻撃者がそのような衝突を行うことは困難ですが、不可能ではありません。攻撃者は、衝突を効果的にするために、HTTPメッセージとそのカバーされたメッセージコンポーネントを操作する必要があります。
To counter this, only vetted keys and signature algorithms should be used to sign HTTP messages. The "HTTP Signature Algorithms" registry is one source of trusted signature algorithms for applications to apply to their messages.
これに対抗するには、HTTPメッセージに署名するために、審査されたキーと署名アルゴリズムのみを使用する必要があります。「HTTP署名アルゴリズム」レジストリは、アプリケーションがメッセージに適用するための信頼できる署名アルゴリズムの1つのソースです。
While it is possible for an attacker to substitute the signature parameters value or the signature value separately, the signature base generation algorithm (Section 2.5) always covers the signature parameters as the final value in the signature base using a deterministic serialization method. This step strongly binds the signature base with the signature value in a way that makes it much more difficult for an attacker to perform a partial substitution on the signature base.
攻撃者が署名パラメーター値または署名値を個別に置き換えることは可能ですが、署名ベース生成アルゴリズム（セクション2.5）は、決定論的シリアル化方法を使用して署名ベースの最終値として署名パラメーターを常にカバーします。このステップは、署名値で署名ベースを強く結合し、攻撃者が署名ベースに部分的な置換を実行することをはるかに困難にします。
A foundational assumption of signature-based cryptographic systems is that the signing key is not compromised by an attacker. If the keys used to sign the message are exfiltrated or stolen, the attacker will be able to generate their own signatures using those keys. As a consequence, signers have to protect any signing key material from exfiltration, capture, and use by an attacker.
署名ベースの暗号化システムの基本的な仮定は、署名キーが攻撃者によって損なわれていないことです。メッセージに署名するために使用されるキーが除外または盗まれている場合、攻撃者はそれらのキーを使用して独自の署名を生成できます。結果として、署名者は、攻撃者による剥離、捕獲、および使用から署名の重要な資料を保護する必要があります。
To combat this, signers can rotate keys over time to limit the amount of time that stolen keys are useful. Signers can also use key escrow and storage systems to limit the attack surface against keys. Furthermore, the use of asymmetric signing algorithms exposes key material less than the use of symmetric signing algorithms (Section 7.3.3).
これに対処するために、署名者は時間の経過とともにキーを回転させて、盗まれたキーが役立つ時間を制限することができます。署名者は、キーエスクローとストレージシステムを使用して、攻撃面をキーに制限することもできます。さらに、非対称署名アルゴリズムの使用は、対称的な署名アルゴリズムの使用よりも少ないキー資料を公開します（セクション7.3.3）。
This document allows both asymmetric and symmetric cryptography to be applied to HTTP messages. By their nature, symmetric cryptographic methods require the same key material to be known by both the signer and verifier. This effectively means that a verifier is capable of generating a valid signature, since they have access to the same key material. An attacker that is able to compromise a verifier would be able to then impersonate a signer.
このドキュメントにより、非対称および対称的な暗号化の両方をHTTPメッセージに適用できます。その性質上、対称的な暗号化方法には、署名者と検証剤の両方が知っているのと同じ重要な資料が必要です。これは、同じ重要な資料にアクセスできるため、検証剤が有効な署名を生成できることを事実上意味します。検証者を妥協できる攻撃者は、署名者になりすまします。
Where possible, asymmetric methods or secure key agreement mechanisms should be used in order to avoid this type of attack. When symmetric methods are used, distribution of the key material needs to be protected by the overall system. One technique for this is the use of separate cryptographic modules that separate the verification process (and therefore the key material) from other code, minimizing the vulnerable attack surface. Another technique is the use of key derivation functions that allow the signer and verifier to agree on unique keys for each message without having to share the key values directly.
可能であれば、このタイプの攻撃を避けるために、非対称の方法または安全な主要な契約メカニズムを使用する必要があります。対称的な方法を使用する場合、主要な材料の分布は、システム全体によって保護する必要があります。これの1つの手法は、検証プロセス（したがって重要な資料）を他のコードから分離する個別の暗号化モジュールの使用であり、脆弱な攻撃面を最小化することです。もう1つの手法は、キー値を直接共有することなく、署名者と検証者が各メッセージの一意のキーに同意できるようにするキー派生関数の使用です。
Additionally, if symmetric algorithms are allowed within a system, special care must be taken to avoid key downgrade attacks (Section 7.3.6).
さらに、システム内で対称アルゴリズムが許可されている場合、キーダウングレード攻撃を避けるために特別な注意を払う必要があります（セクション7.3.6）。
The existence of a valid signature on an HTTP message is not sufficient to prove that the message has been signed by the appropriate party. It is up to the verifier to ensure that a given key and algorithm are appropriate for the message in question. If the verifier does not perform such a step, an attacker could substitute their own signature using their own key on a message and force a verifier to accept and process it. To combat this, the verifier needs to ensure not only that the signature can be validated for a message but that the key and algorithm used are appropriate.
HTTPメッセージに有効な署名が存在することは、メッセージが適切な当事者によって署名されたことを証明するのに十分ではありません。特定のキーとアルゴリズムが問題のメッセージに適切であることを確認するのは、検証剤次第です。検証者がそのようなステップを実行しない場合、攻撃者はメッセージの自分のキーを使用して自分の署名を置き換え、検証者にそれを受け入れて処理するように強制することができます。これと戦うために、検証者は、署名がメッセージのために検証できるだけでなく、使用されるキーとアルゴリズムが適切であることを確認する必要があります。
Some cryptographic primitives, such as RSA-PSS and ECDSA, have non-deterministic outputs, which include some amount of entropy within the algorithm. For such algorithms, multiple signatures generated in succession will not match. A lazy implementation of a verifier could ignore this distinction and simply check for the same value being created by re-signing the signature base. Such an implementation would work for deterministic algorithms such as HMAC and EdDSA but fail to verify valid signatures made using non-deterministic algorithms. It is therefore important that a verifier always use the correctly defined verification function for the algorithm in question and not do a simple comparison.
RSA-PSSやECDSAなどの一部の暗号化プリミティブには、アルゴリズム内のある程度のエントロピーを含む非決定的な出力があります。このようなアルゴリズムの場合、連続して生成された複数の署名は一致しません。検証者の怠zyな実装は、この区別を無視し、署名ベースに再署名することによって作成されている同じ値を単純に確認できます。このような実装は、HMACやEDDSAなどの決定論的アルゴリズムで機能しますが、非決定的なアルゴリズムを使用して作成された有効な署名の検証に失敗します。したがって、検証者は、問題のアルゴリズムに対して正しく定義された検証関数を常に使用し、単純な比較を行わないことが重要です。
Applications of this specification need to protect against key specification downgrade attacks. For example, the same RSA key can be used for both RSA-PSS and RSA v1.5 signatures. If an application expects a key to only be used with RSA-PSS, it needs to reject signatures for any key that uses the weaker RSA 1.5 specification.
この仕様のアプリケーションは、主要な仕様から保護する必要があります。たとえば、同じRSAキーをRSA-PSSとRSA V1.5の両方の署名に使用できます。アプリケーションがキーをRSA-PSSでのみ使用することを期待する場合、より弱いRSA 1.5仕様を使用するキーの署名を拒否する必要があります。
Another example of a downgrade attack would be when an asymmetric algorithm is expected, such as RSA-PSS, but an attacker substitutes a signature using a symmetric algorithm, such as HMAC. A naive verifier implementation could use the value of the public RSA key as the input to the HMAC verification function. Since the public key is known to the attacker, this would allow the attacker to create a valid HMAC signature against this known key. To prevent this, the verifier needs to ensure that both the key material and the algorithm are appropriate for the usage in question. Additionally, while this specification does allow runtime specification of the algorithm using the alg signature parameter, applications are encouraged to use other mechanisms such as static configuration or a higher-protocol-level algorithm specification instead, preventing an attacker from substituting the algorithm specified.
ダウングレード攻撃のもう1つの例は、RSA-PSSなどの非対称アルゴリズムが予想される場合ですが、攻撃者はHMACなどの対称アルゴリズムを使用して署名を置き換えます。素朴な検証器の実装は、HMAC検証関数への入力として、パブリックRSAキーの値を使用できます。公開鍵は攻撃者に知られているため、これにより、攻撃者はこの既知のキーに対して有効なHMAC署名を作成することができます。これを防ぐために、検証者は、問題の使用に適していることを検証する必要があります。さらに、この仕様ではALG署名パラメーターを使用してアルゴリズムのランタイム仕様が許可されていますが、アプリケーションは静的構成や代わりに高プロトコルレベルのアルゴリズムの仕様などの他のメカニズムを使用して、攻撃者が指定されたアルゴリズムを置き換えるのを防ぐことをお勧めします。
When applying the req parameter (Section 2.4) or multiple signatures (Section 4.3) to a message, it is possible to sign the value of an existing Signature field, thereby covering the bytes of the existing signature output in the new signature's value. While it would seem that this practice would transitively cover the components under the original signature in a verifiable fashion, the attacks described in [JACKSON2019] can be used to impersonate a signature output value on an unrelated message.
REQパラメーター（セクション2.4）または複数の署名（セクション4.3）をメッセージに適用する場合、既存の署名フィールドの値に署名し、それにより、新しい署名の値の既存の署名出力のバイトをカバーすることができます。このプラクティスは、元の署名の下でコンポーネントを検証可能な方法でトランザティブにカバーするように思われますが、[Jackson2019]に記載されている攻撃を使用して、無関係なメッセージの署名出力値になりすまします。
In this example, Alice intends to send a signed request to Bob, and Bob wants to provide a signed response to Alice that includes a cryptographic proof that Bob is responding to Alice's incoming message. Mallory wants to intercept this traffic and replace Alice's message with her own, without Alice being aware that the interception has taken place.
この例では、アリスはボブに署名されたリクエストを送信するつもりであり、ボブはボブがアリスの次のメッセージに応答しているという暗号化の証拠を含むアリスに署名された応答を提供したいと考えています。マロリーは、このトラフィックを傍受し、アリスのメッセージを自分のメッセージに置き換えたいと考えています。
1. Alice creates a message Req_A and applies a signature Sig_A using her private key Key_A_Sign.
1. アリスはメッセージReq_aを作成し、秘密Key_a_signを使用して署名Sig_aを適用します。
2. Alice believes she is sending Req_A to Bob.
2. アリスは、Req_aをBobに送っていると信じています。
3. Mallory intercepts Req_A and reads the value Sig_A from this message.
3. MalloryはReq_aを傍受し、このメッセージからValue Sig_aを読み取ります。
4. Mallory generates a different message Req_M to send to Bob instead.
4. Malloryは、代わりにBobに送信するために別のメッセージReq_mを生成します。
5. Mallory crafts a signing key Key_M_Sign such that she can create a valid signature Sig_M over her request Req_M using this key, but the byte value of Sig_M exactly equals that of Sig_A.
5. Malloryは、このキーを使用してReques Req_mで有効な署名SIG_Mを作成できるように、署名キーキー_m_Signを作成しますが、Sig_mのバイト値はSig_aのバイト値に正確に等しくなります。
6. Mallory sends Req_M with Sig_M to Bob.
6. Malloryは、sig_mとreq_mをBobに送信します。
7. Bob validates Sig_M against Mallory's verification key Key_M_Verify. At no time does Bob think that he's responding to Alice.
7. ボブは、Malloryの検証Key_m_verifyに対してSig_mを検証します。ボブがアリスに応答しているとは考えていません。
8. Bob responds with response message Res_B to Req_M and creates signature Sig_B over this message using his key Key_B_Sign. Bob includes the value of Sig_M under Sig_B's covered components but does not include anything else from the request message.
8. ボブは応答メッセージRES_BでREQ_Mに応答し、Key_B_Signを使用してこのメッセージの上に署名SIG_Bを作成します。ボブには、sig_bの対象コンポーネントの下にあるsig_mの値が含まれていますが、リクエストメッセージの他のものは含まれていません。
9. Mallory receives the response Res_B from Bob, including the signature Sig_B value. Mallory replays this response to Alice.
9. Malloryは、署名SIG_B値を含むBOBからRES_Bを受信します。マロリーはアリスにこの応答を再生します。
10. Alice reads Res_B from Mallory and verifies Sig_B using Bob's verification key Key_B_Verify. Alice includes the bytes of her original signature Sig_A in the signature base, and the signature verifies.
10. AliceはMalloryのRES_Bを読み取り、BOBの検証Key_B_Verifyを使用してSIG_Bを検証します。アリスには、署名ベースに元の署名Sig_aのバイトが含まれており、署名が検証されます。
11. Alice is led to believe that Bob has responded to her message and believes she has cryptographic proof of this happening, but in fact Bob responded to Mallory's malicious request and Alice is none the wiser.
11. アリスは、ボブが彼女のメッセージに応答し、彼女がこの出来事の暗号化の証拠を持っていると信じていると信じるように導かれますが、実際、ボブはマロリーの悪意のある要求に応答し、アリスは賢明ではありません。
To mitigate this, Bob can sign more portions of the request message than just the Signature field, in order to more fully differentiate Alice's message from Mallory's. Applications using this feature, particularly for non-repudiation purposes, can stipulate that any components required in the original signature also be covered separately in the second signature. For signed messages, requiring coverage of the corresponding Signature-Input field of the first signature ensures that unique items such as nonces and timestamps are also covered sufficiently by the second signature.
これを緩和するために、ボブは、アリスのメッセージをマロリーのメッセージとより完全に区別するために、署名フィールドよりも多くの要求メッセージの一部に署名できます。この機能を使用するアプリケーションは、特に非和解の目的で、元の署名に必要なコンポーネントも2番目の署名で個別にカバーされていることを規定できます。署名されたメッセージの場合、最初の署名の対応する署名入力フィールドのカバレッジを必要とすることにより、Noncesやタイムスタンプなどの一意のアイテムが2番目の署名によって十分にカバーされることが保証されます。
An attacker could effectively deny a service by modifying an otherwise benign signature parameter or signed message component. While rejecting a modified message is the desired behavior, consistently failing signatures could lead to (1) the verifier turning off signature checking in order to make systems work again (see Section 7.1.1) or (2) the application minimizing the requirements related to the signed component.
攻撃者は、良性の署名パラメーターまたは署名されたメッセージコンポーネントを変更することにより、サービスを効果的に拒否できます。変更されたメッセージを拒否することは望ましい動作ですが、一貫して失敗する署名は（1）システムを再度機能させるために署名チェックをオフにするために、検証剤が署名チェックをオフにする可能性があります（セクション7.1.1を参照）、または（2）署名されたコンポーネント。
If such failures are common within an application, the signer and verifier should compare their generated signature bases with each other to determine which part of the message is being modified. If an expected modification is found, the signer and verifier can agree on an alternative set of requirements that will pass. However, the signer and verifier should not remove the requirement to sign the modified component when it is suspected that an attacker is modifying the component.
そのような障害がアプリケーション内で一般的である場合、署名者と検証者は、生成された署名ベースを互いに比較して、メッセージのどの部分が変更されているかを決定する必要があります。予想される変更が見つかった場合、署名者と検証者は、合格する一連の要件に同意できます。ただし、署名者と検証者は、攻撃者がコンポーネントを変更していると疑われる場合、修正されたコンポーネントに署名する要件を削除しないでください。
The verifier needs to make sure that the signed message components match those in the message itself. For example, the @method derived component requires that the value within the signature base be the same as the HTTP method used when presenting this message. This specification encourages this by requiring the verifier to derive the signature base from the message, but lazy caching or conveyance of a raw signature base to a processing subsystem could lead to downstream verifiers accepting a message that does not match the presented signature.
検証者は、署名されたメッセージコンポーネントがメッセージ自体のコンポーネントと一致することを確認する必要があります。たとえば、@method派生コンポーネントでは、署名ベース内の値が、このメッセージを提示するときに使用したHTTPメソッドと同じであることが必要です。この仕様は、検証者がメッセージから署名ベースを導出することを要求することによりこれを奨励しますが、処理サブシステムへの生の署名ベースの怠zyなキャッシングまたは伝達により、下流の検証者が提示された署名と一致しないメッセージを受け入れる可能性があります。
To counter this, the component that generates the signature base needs to be trusted by both the signer and verifier within a system.
これに対抗するために、署名ベースを生成するコンポーネントは、システム内の署名者と検証者の両方によって信頼される必要があります。
The signature context for deriving message component values includes the target HTTP message itself, any associated messages (such as the request that triggered a response), and additional information that the signer or verifier has access to. Both signers and verifiers need to carefully consider the source of all information when creating component values for the signature base and take care not to take information from untrusted sources. Otherwise, an attacker could leverage such a loosely defined message context to inject their own values into the signature base string, overriding or corrupting the intended values.
メッセージコンポーネント値を導出するための署名コンテキストには、ターゲットHTTPメッセージ自体、関連するメッセージ（応答をトリガーした要求など）、および署名者または検証者がアクセスできる追加情報が含まれます。署名者と検証者の両方が、署名ベースのコンポーネント値を作成する際に、すべての情報のソースを慎重に検討し、信頼できないソースから情報を取得しないように注意する必要があります。それ以外の場合、攻撃者は、このような定義されたメッセージコンテキストを活用して、意図した値をオーバーライドまたは破損する署名ベース文字列に独自の値を注入できます。
For example, in most situations, the target URI of the message is as defined in [HTTP], Section 7.1. However, let's say that there is an application that requires signing of the @authority of the incoming request, but the application doing the processing is behind a reverse proxy. Such an application would expect a change in the @authority value, and it could be configured to know the external target URI as seen by the client on the other side of the proxy. This application would use this configured value as its target URI for the purposes of deriving message component values such as @authority instead of using the target URI of the incoming message.
たとえば、ほとんどの状況では、メッセージのターゲットURIは[http]、セクション7.1で定義されています。ただし、着信要求の@Authorityの署名を必要とするアプリケーションがあるとしましょうが、処理を行うアプリケーションは逆プロキシの背後にあります。このようなアプリケーションは、@Authority値の変更が予想され、プロキシの反対側のクライアントが見た外部ターゲットURIを知るように構成できます。このアプリケーションは、着信メッセージのターゲットURIを使用する代わりに、@Authorityなどのメッセージコンポーネント値を導出する目的で、この設定された値をターゲットURIとして使用します。
This approach is not without problems, as a misconfigured system could accept signed requests intended for different components in the system. For this scenario, an intermediary could instead add its own signature to be verified by the application directly, as demonstrated in Section 4.3. This alternative approach requires a more active intermediary but relies less on the target application knowing external configuration values.
誤解されたシステムは、システム内のさまざまなコンポーネントを対象とした署名された要求を受け入れる可能性があるため、このアプローチは問題がないわけではありません。このシナリオでは、セクション4.3で実証されているように、仲介者は代わりに、アプリケーションによって直接検証される独自の署名を追加することができます。この代替アプローチには、よりアクティブな仲介者が必要ですが、外部構成値を知っているターゲットアプリケーションに依存しません。
As another example, Section 2.4 defines a method for signing response messages and also including portions of the request message that triggered the response. In this case, the context for component value calculation is the combination of the response and request messages, not just the single message to which the signature is applied. For this feature, the req flag allows both signers to explicitly signal which part of the context is being sourced for a component identifier's value. Implementations need to ensure that only the intended message is being referred to for each component; otherwise, an attacker could attempt to subvert a signature by manipulating one side or the other.
別の例として、セクション2.4は、応答メッセージに署名する方法を定義し、応答をトリガーしたリクエストメッセージの一部も含めます。この場合、コンポーネント値の計算のコンテキストは、署名が適用される単一のメッセージだけでなく、応答メッセージと要求メッセージの組み合わせです。この機能では、REQフラグを使用すると、両方の署名者がコンポーネント識別子の値に対してソースを供給されているコンテキストのどの部分が供給されているかを明示的に信号することができます。実装は、意図したメッセージのみが各コンポーネントに対して参照されていることを確認する必要があります。それ以外の場合、攻撃者は、どちらか一方を操作して署名を覆そうとします。
It is possible that the context for deriving message component values could be distinct for each signature present within a single message. This is particularly the case when proxies mutate messages and include signatures over the mutated values, in addition to any existing signatures. For example, a reverse proxy can replace a public hostname in a request to a service with the hostname for the individual service host to which it is forwarding the request. If both the client and the reverse proxy add signatures covering @authority, the service host will see two signatures on the request, each signing different values for the @authority message component, reflecting the change to that component as the message made its way from the client to the service host.
メッセージコンポーネント値を導出するためのコンテキストは、単一のメッセージ内に存在する各署名に対して異なる可能性があります。これは、既存の署名に加えて、プロキシがメッセージを変異させ、変異した値に署名を含める場合に特に当てはまります。たとえば、リバースプロキシは、リクエストにリクエストにリクエストにパブリックホスト名を置き換えることができます。クライアントとリバースプロキシの両方が@Authorityをカバーする署名を追加する場合、サービスホストはリクエストに2つの署名が表示され、それぞれが@Authorityメッセージコンポーネントの異なる値に署名し、メッセージが次のように変更されたときにそのコンポーネントの変更を反映しています。クライアントからサービスホスト。
In such a case, it's common for the internal service to verify only one of the signatures or to use externally configured information, as discussed in Section 7.4.3. However, a verifier processing both signatures has to use a different message component context for each signature, since the component value for the @authority component will be different for each signature. Verifiers like this need to be aware of both the reverse proxy's context for incoming messages and the target service's context for the message coming from the reverse proxy. The verifier needs to take particular care to apply the correct context to the correct signature; otherwise, an attacker could use knowledge of this complex setup to confuse the inputs to the verifier.
そのような場合、セクション7.4.3で説明したように、内部サービスが署名の1つのみを検証したり、外部構成情報を使用したりすることが一般的です。ただし、両方の署名を処理するVerifierは、各署名の異なるメッセージコンポーネントコンテキストを使用する必要があります。これは、 @authorityコンポーネントのコンポーネント値が署名ごとに異なるためです。このような検証者は、着信メッセージに対する逆プロキシのコンテキストと、逆プロキシからのメッセージに対するターゲットサービスのコンテキストの両方を認識する必要があります。検証者は、正しい署名に正しいコンテキストを適用するために特に注意を払う必要があります。それ以外の場合、攻撃者はこの複雑なセットアップの知識を使用して、入力を検証器に混同することができます。
Such verifiers also need to ensure that any differences in message component contexts between signatures are expected and permitted. For example, in the above scenario, the reverse proxy could include the original hostname in a Forwarded header field and could sign @authority, forwarded, and the client's entry in the Signature field. The verifier can use the hostname from the Forwarded header field to confirm that the hostname was transformed as expected.
このような検証剤は、署名間のメッセージコンポーネントコンテキストの違いが予想され、許可されていることを確認する必要があります。たとえば、上記のシナリオでは、逆プロキシには、転送されたヘッダーフィールドに元のホスト名を含めることができ、@authority、転送、署名フィールドへのクライアントのエントリに署名できます。Verifierは、転送されたヘッダーフィールドのホスト名を使用して、ホスト名が予想どおりに変換されたことを確認できます。
The definition of HTTP field names does not allow for the use of the @ character anywhere in the name. As such, since all derived component names start with the @ character, these namespaces should be completely separate. However, some HTTP implementations are not sufficiently strict about the characters accepted in HTTP field names. In such implementations, a sender (or attacker) could inject a header field starting with an @ character and have it passed through to the application code. These invalid header fields could be used to override a portion of the derived message content and substitute an arbitrary value, providing a potential place for an attacker to mount a signature collision (Section 7.3.1) attack or other functional substitution attack (such as using the signature from a GET request on a crafted POST request).
HTTPフィールド名の定義では、名前のどこにでも @文字を使用することはできません。そのため、派生したすべてのコンポーネント名は @文字で始まるため、これらの名前空間は完全に分離する必要があります。ただし、一部のHTTP実装は、HTTPフィールド名で受け入れられている文字について十分に厳格ではありません。このような実装では、送信者（または攻撃者）は、 @文字から始まるヘッダーフィールドを注入し、アプリケーションコードに渡すことができます。これらの無効なヘッダーフィールドを使用して、派生したメッセージコンテンツの一部をオーバーライドし、任意の価値を代用して、攻撃者が署名の衝突（セクション7.3.1）攻撃またはその他の機能的置換攻撃を取り付ける潜在的な場所を提供することができます（作成されたPOSTリクエストのGETリクエストからの署名）。
To combat this, when selecting values for a message component, if the component name starts with the @ character, it needs to be processed as a derived component and never processed as an HTTP field. Only if the component name does not start with the @ character can it be taken from the fields of the message. The algorithm discussed in Section 2.5 provides a safe order of operations.
これに対処するには、メッセージコンポーネントの値を選択する場合、コンポーネント名が @文字で始まる場合、派生コンポーネントとして処理し、HTTPフィールドとして処理されることはありません。コンポーネント名が @文字で始まらない場合にのみ、メッセージのフィールドから取得できます。セクション2.5で説明されているアルゴリズムは、安全な操作順序を提供します。
The signature base generation algorithm (Section 2.5) uses the value of an HTTP field as its component value. In the common case, this amounts to taking the actual bytes of the field value as the component value for both the signer and verifier. However, some field values allow for transformation of the values in semantically equivalent ways that alter the bytes used in the value itself. For example, a field definition can declare some or all of its values to be case insensitive or to have special handling of internal whitespace characters. Other fields have expected transformations from intermediaries, such as the removal of comments in the Via header field. In such cases, a verifier could be tripped up by using the equivalent transformed field value, which would differ from the byte value used by the signer. The verifier would have a difficult time finding this class of errors, since the value of the field is still acceptable for the application but the actual bytes required by the signature base would not match.
署名ベース生成アルゴリズム（セクション2.5）は、HTTPフィールドの値をコンポーネント値として使用します。一般的な場合、これは、署名者と検証剤の両方のコンポーネント値として、フィールド値の実際のバイトを取得することになります。ただし、一部のフィールド値により、値自体で使用されるバイトを変更する意味的に同等の方法で値を変換できます。たとえば、フィールド定義は、その値の一部またはすべてが、症例の鈍感であるか、内部空白文字の特別な取り扱いがあると宣言できます。他のフィールドは、Via Headerフィールドでのコメントの削除など、仲介者からの変革を期待しています。そのような場合、署名者が使用するバイト値とは異なる同等の変換されたフィールド値を使用して、検証剤をつまずくことができます。フィールドの値はアプリケーションではまだ許容されますが、署名ベースに必要な実際のバイトは一致しないため、検証者はこのクラスのエラーを見つけるのに苦労します。
When processing such fields, the signer and verifier have to agree on how to handle such transformations, if at all. One option is to not sign problematic fields, but care must be taken to ensure that there is still sufficient signature coverage (Section 7.2.1) for the application. Another option is to define an application-specific canonicalization value for the field before it is added to the HTTP message, such as to always remove internal comments before signing or to always transform values to lowercase. Since these transformations are applied prior to the field being used as input to the signature base generation algorithm, the signature base will still simply contain the byte value of the field as it appears within the message. If the transformations were to be applied after the value is extracted from the message but before it is added to the signature base, different attack surfaces such as value substitution attacks could be launched against the application. All application-specific additional rules are outside the scope of this specification, and by their very nature these transformations would harm interoperability of the implementation outside of this specific application. It is recommended that applications avoid the use of such additional rules wherever possible.
そのようなフィールドを処理する場合、署名者と検証者は、そのような変換をどのように処理するかについて同意する必要があります。1つの選択肢は、問題のあるフィールドに署名しないことですが、アプリケーションに十分な署名カバレッジ（セクション7.2.1）があることを確認するために注意する必要があります。別のオプションは、署名する前に常に内部コメントを削除したり、常に値を低セースに変換するなど、HTTPメッセージに追加される前に、フィールドのアプリケーション固有の正規化値を定義することです。これらの変換は、フィールドが署名ベースジェネレーションアルゴリズムへの入力として使用される前に適用されるため、署名ベースには、メッセージ内に表示されるフィールドのバイト値がまだ含まれています。値がメッセージから抽出された後に署名ベースに追加される前に、変換が適用される場合、アプリケーションに対して値置換攻撃などの異なる攻撃面を起動することができます。すべてのアプリケーション固有の追加のルールは、この仕様の範囲外であり、本質的にこれらの変換は、この特定のアプリケーション以外の実装の相互運用性を損なうでしょう。アプリケーションは、可能な限りそのような追加のルールの使用を避けることをお勧めします。
Several parts of this specification rely on the parsing of Structured Field values [STRUCTURED-FIELDS] -- in particular, strict serialization of HTTP Structured Field values (Section 2.1.1), referencing members of a Dictionary Structured Field (Section 2.1.2), and processing the @signature-input value when verifying a signature (Section 3.2). While Structured Field values are designed to be relatively simple to parse, a naive or broken implementation of such a parser could lead to subtle attack surfaces being exposed in the implementation.
この仕様のいくつかの部分は、構造化されたフィールド値[構造化場]の解析に依存しています。特に、辞書構造化場のメンバーを参照するHTTP構造化場値の厳密なシリアル化（セクション2.1.1）（セクション2.1.2）、および署名を確認するときに @署名入力値を処理します（セクション3.2）。構造化されたフィールド値は、解析が比較的簡単になるように設計されていますが、このようなパーサーの素朴なまたは壊れた実装により、実装で微妙な攻撃面が露出される可能性があります。
For example, if a buggy parser of the @signature-input value does not enforce proper closing of quotes around string values within the list of component identifiers, an attacker could take advantage of this and inject additional content into the signature base through manipulating the Signature-Input field value on a message.
たとえば、 @Signature-Input値のバギーパーサーがコンポーネント識別子のリスト内の文字列値に関する引用符の適切なクロージングを強制しない場合、攻撃者はこれを利用して、署名を操作して追加のコンテンツを署名ベースに挿入できます。 - メッセージのフィールド値のインプット。
To counteract this, implementations should use fully compliant and trusted parsers for all Structured Field processing, on both the signer side and the verifier side.
これに対抗するために、実装は、署名者側と検証者側の両方で、すべての構造化されたフィールド処理に完全に準拠した信頼できるパーサーを使用する必要があります。
Some message components are expressed in different ways across HTTP versions. For example, the authority of the request target is sent using the Host header field in HTTP/1.1 but with the :authority pseudo-header in HTTP/2. If a signer sends an HTTP/1.1 message and signs the Host header field but the message is translated to HTTP/2 before it reaches the verifier, the signature will not validate, as the Host header field could be dropped.
一部のメッセージコンポーネントは、HTTPバージョン全体でさまざまな方法で表されます。たとえば、リクエストターゲットの権限は、HTTP/1.1のホストヘッダーフィールドを使用して送信されますが、http/2の権限擬似ヘッダー。署名者がHTTP/1.1メッセージを送信し、ホストヘッダーフィールドに署名しますが、メッセージが検証剤に到達する前にHTTP/2に翻訳される場合、ホストヘッダーフィールドを削除できるため、署名は検証されません。
It is for this reason that HTTP message signatures define a set of derived components that define a single way to get the value in question, such as the @authority derived component (Section 2.2.3) in lieu of the Host header field. Applications should therefore prefer derived components for such options where possible.
このため、HTTPメッセージ署名は、ホストヘッダーフィールドの代わりに @authority派生コンポーネント（セクション2.2.3）など、問題の値を取得する単一の方法を定義する派生コンポーネントのセットを定義します。したがって、アプリケーションは、可能な場合はそのようなオプションの派生コンポーネントを好む必要があります。
Any ambiguity in the generation of the signature base could provide an attacker with leverage to substitute or break a signature on a message. Some message component values, particularly HTTP field values, are potentially susceptible to broken implementations that could lead to unexpected and insecure behavior. Naive implementations of this specification might implement HTTP field processing by taking the single value of a field and using it as the direct component value without processing it appropriately.
署名ベースの生成のあいまいさは、攻撃者にレバレッジを提供して、メッセージの署名を代用または破損することができます。一部のメッセージコンポーネント値、特にHTTPフィールド値は、予期しない不安定な動作につながる可能性のある壊れた実装の影響を受けやすくなります。この仕様の素朴な実装は、フィールドの単一値を取得し、適切に処理せずに直接コンポーネント値として使用することにより、HTTPフィールド処理を実装する場合があります。
For example, if the handling of obs-fold field values does not remove the internal line folding and whitespace, additional newlines could be introduced into the signature base by the signer, providing a potential place for an attacker to mount a signature collision (Section 7.3.1) attack. Alternatively, if header fields that appear multiple times are not joined into a single string value, as required by this specification, similar attacks can be mounted, as a signed component value would show up in the signature base more than once and could be substituted or otherwise attacked in this way.
たとえば、obs折りのフィールド値の処理が内部線の折りたたみと空白を削除しない場合、追加のニューラインを署名者によって署名ベースに導入し、攻撃者が署名の衝突をマウントする潜在的な場所を提供することができます（セクション7.3.1）攻撃。あるいは、複数回表示されるヘッダーフィールドが単一の文字列値に結合されない場合、この仕様で要求されるように、同様の攻撃を取り付けることができます。そうでなければ、このように攻撃されます。
To counter this, the entire field value processing algorithm needs to be implemented by all implementations of signers and verifiers.
これに対抗するには、署名者と検証剤のすべての実装によってフィールドバリュー処理アルゴリズム全体を実装する必要があります。
When an HTTP field occurs multiple times in a single message, these values need to be combined into a single one-line string value to be included in the HTTP signature base, as described in Section 2.5. Not all HTTP fields can be combined into a single value in this way and still be a valid value for the field. For the purposes of generating the signature base, the message component value is never meant to be read back out of the signature base string or used in the application. Therefore, it is considered best practice to treat the signature base generation algorithm separately from processing the field values by the application, particularly for fields that are known to have this property. If the field values that are being signed do not validate, the signed message should also be rejected.
単一のメッセージでHTTPフィールドが複数回発生する場合、セクション2.5で説明されているように、HTTP署名ベースに含めるために、これらの値を単一の1行の文字列値に結合する必要があります。すべてのHTTPフィールドをこの方法で単一の値に結合できるわけではなく、フィールドにとって有効な値になるわけではありません。署名ベースを生成するために、メッセージコンポーネント値が署名ベースの文字列から読み戻されたり、アプリケーションで使用されたりすることを意図したものではありません。したがって、特にこのプロパティを持っていることが知られているフィールドでは、アプリケーションによるフィールド値の処理とは別に、署名ベース生成アルゴリズムを扱うことがベストプラクティスと見なされます。署名されているフィールド値が検証されない場合、署名されたメッセージも拒否する必要があります。
If an HTTP field allows for unquoted commas within its values, combining multiple field values can lead to a situation where two semantically different messages produce the same line in a signature base. For example, take the following hypothetical header field with an internal comma in its syntax, here used to define two separate lists of values:
HTTPフィールドがその値内で引用されていないコンマを許可する場合、複数のフィールド値を組み合わせることで、2つの意味的に異なるメッセージが署名ベースで同じ線を生成する状況につながる可能性があります。たとえば、内部コンマを構文に備えた次の仮想ヘッダーフィールドを使用します。ここでは、値の2つの個別のリストを定義するために使用されます。
Example-Header: value, with, lots
Example-Header: of, commas
For this header field, sending all of these values as a single field value results in a single list of values:
このヘッダーフィールドでは、これらすべての値を単一のフィールド値として送信すると、値の単一のリストが得られます。
Example-Header: value, with, lots, of, commas
Both of these messages would create the following line in the signature base:
これらのメッセージは両方とも、署名ベースに次の行を作成します。
"example-header": value, with, lots, of, commas
Since two semantically distinct inputs can create the same output in the signature base, special care has to be taken when handling such values.
2つの意味的に異なる入力は、署名ベースに同じ出力を作成できるため、そのような値を処理する際には特別な注意が必要です。
Specifically, the Set-Cookie field [COOKIE] defines an internal syntax that does not conform to the List syntax provided in [STRUCTURED-FIELDS]. In particular, some portions allow unquoted commas, and the field is typically sent as multiple separate field lines with distinct values when sending multiple cookies. When multiple Set-Cookie fields are sent in the same message, it is not generally possible to combine these into a single line and be able to parse and use the results, as discussed in [HTTP], Section 5.3. Therefore, all the cookies need to be processed from their separate field values, without being combined, while the signature base needs to be processed from the special combined value generated solely for this purpose. If the cookie value is invalid, the signed message ought to be rejected, as this is a possible padding attack as described in Section 7.5.7.
具体的には、セットクーキーフィールド[Cookie]は、[構造化場]で提供されるリスト構文に準拠していない内部構文を定義します。特に、一部の部分は引用されていないコンマを許可し、通常、フィールドは複数のCookieを送信するときに異なる値を持つ複数の個別のフィールドラインとして送信されます。複数のセットクッキーフィールドが同じメッセージで送信される場合、[HTTP]、セクション5.3で説明されているように、これらを単一の行に組み合わせて解析して使用できることは一般に不可能です。したがって、すべてのCookieは、組み合わせることなく、個別のフィールド値から処理する必要がありますが、署名ベースは、この目的のためだけに生成された特別な複合値から処理する必要があります。Cookie値が無効である場合、セクション7.5.7で説明されているように、これは可能なパディング攻撃であるため、署名されたメッセージを拒否する必要があります。
To deal with this, an application can choose to limit signing of problematic fields like Set-Cookie, such as including the field in a signature only when a single field value is present and the results would be unambiguous. Similar caution needs to be taken with all fields that could have non-deterministic mappings into the signature base. Signers can also make use of the bs parameter to armor such fields, as described in Section 2.1.3.
これに対処するために、アプリケーションは、単一のフィールド値が存在し、結果が明確になる場合にのみ署名にフィールドを含めるなど、セットクッキーなどの問題のあるフィールドの署名を制限することを選択できます。非決定的マッピングを署名ベースに入れる可能性のあるすべてのフィールドでも、同様の注意を払う必要があります。署名者は、セクション2.1.3で説明されているように、BSパラメーターを使用してそのようなフィールドを装甲することもできます。
Since HTTP field values need to be combined into a single string value to be included in the HTTP signature base (see Section 2.5), it is possible for an attacker to inject an additional value for a given field and add this to the signature base of the verifier.
HTTPフィールド値はHTTP署名ベースに含めるために単一の文字列値に結合する必要があるため（セクション2.5を参照）、攻撃者は特定のフィールドに追加値を注入し、これを署名ベースに追加することができます検証剤。
In most circumstances, this causes the signature validation to fail as expected, since the new signature base value will not match the one used by the signer to create the signature. However, it is theoretically possible for the attacker to inject both a garbage value into a field and a desired value into another field in order to force a particular input. This is a variation of the collision attack described in Section 7.3.1, where the attacker accomplishes their change in the message by adding to existing field values.
ほとんどの状況では、これにより、新しい署名ベース値が署名者が署名を作成するために使用するものと一致しないため、これにより署名検証が予想どおりに失敗します。ただし、攻撃者が特定の入力を強制するために、攻撃者がゴミの値と目的の値の両方を別のフィールドに注入することが可能です。これは、セクション7.3.1で説明されている衝突攻撃のバリエーションであり、攻撃者は既存のフィールド値を追加することによりメッセージの変更を達成します。
To counter this, an application needs to validate the content of the fields covered in the signature in addition to ensuring that the signature itself validates. With such protections, the attacker's padding attack would be rejected by the field value processor, even in the case where the attacker could force a signature collision.
これに対抗するために、アプリケーションは、署名自体が検証されることを確認することに加えて、署名でカバーされているフィールドのコンテンツを検証する必要があります。このような保護により、攻撃者が署名の衝突を強制できる場合でも、攻撃者のパディング攻撃はフィールドバリュープロセッサによって拒否されます。
The HTML form parameters format defined in Section 5 ("application/ x-www-form-urlencoded") of [HTMLURL] is widely deployed and supported by many application frameworks. For convenience, some of these frameworks in particular combine query parameters that are found in the HTTP query and those found in the message content, particularly for POST messages with a Content-Type value of "application/x-www-form-urlencoded". The @query-param derived component identifier defined in Section 2.2.8 draws its values only from the query section of the target URI of the request. As such, it would be possible for an attacker to shadow or replace query parameters in a request by overriding a signed query parameter with an unsigned form parameter, or vice versa.
[htmlurl]のセクション5（ "アプリケーション/ x-www-form-urlencoded"）で定義されたHTMLフォームパラメーター形式は、多くのアプリケーションフレームワークによって広く展開およびサポートされています。便利なため、特にこれらのフレームワークのいくつかは、HTTPクエリとメッセージコンテンツに見られるクエリパラメーター、特に「Application/X-WWW-Form-Form-Form-Urlencoded」のコンテンツタイプの値を持つ投稿メッセージの場合、クエリパラメーターを組み合わせています。セクション2.2.8で定義されている @Query-Param派生コンポーネント識別子は、リクエストのターゲットURIのクエリセクションからのみ値を描画します。そのため、攻撃者は、署名されたクエリパラメーターを符号なしのフォームパラメーターでオーバーライドすることにより、またはその逆で署名されたクエリパラメーターをオーバーライドすることにより、要求でクエリパラメーターをシャドウまたは置き換えることが可能です。
To counter this, an application needs to make sure that values used for the signature base and the application are drawn from a consistent context, in this case the query component of the target URI. Additionally, when the HTTP request has content, an application should sign the message content as well, as discussed in Section 7.2.8.
これに対抗するために、アプリケーションは、署名ベースとアプリケーションに使用される値が、ターゲットURIのクエリコンポーネント、この場合は一貫したコンテキストから描かれていることを確認する必要があります。さらに、HTTP要求にコンテンツがある場合、セクション7.2.8で説明したように、アプリケーションもメッセージコンテンツに署名する必要があります。
If a signer uses the same key with multiple verifiers or uses the same key over time with a single verifier, the ongoing use of that key can be used to track the signer throughout the set of verifiers that messages are sent to. Since cryptographic keys are meant to be functionally unique, the use of the same key over time is a strong indicator that it is the same party signing multiple messages.
署名者が複数の検証剤を使用して同じキーを使用するか、単一の検証剤を使用して同じキーを使用する場合、そのキーの継続的な使用を使用して、メッセージが送信される検証者のセット全体で署名者を追跡できます。暗号化キーは機能的に一意であることを意図しているため、時間の経過とともに同じキーを使用することは、複数のメッセージに署名するのと同じパーティーであることを強く指標です。
In many applications, this is a desirable trait, and it allows HTTP message signatures to be used as part of authenticating the signer to the verifier. However, it could also result in unintentional tracking that a signer might not be aware of. To counter this kind of tracking, a signer can use a different key for each verifier that it is in communication with. Sometimes, a signer could also rotate their key when sending messages to a given verifier. These approaches do not negate the need for other anti-tracking techniques to be applied as necessary.
多くのアプリケーションでは、これは望ましい特性であり、HTTPメッセージ署名を検証者に署名者を認証する一部として使用できます。ただし、署名者が気付いていない可能性があるという意図的でない追跡が発生する可能性があります。この種の追跡に対抗するために、署名者は、通信中の検証者ごとに異なるキーを使用できます。特定の検証者にメッセージを送信するときに、署名者がキーを回転させることもあります。これらのアプローチは、必要に応じて他のアンチトラッキング技術を適用する必要性を否定するものではありません。
HTTP message signatures do not provide confidentiality for any of the information protected by the signature. The content of the HTTP message, including the value of all fields and the value of the signature itself, is presented in plaintext to any party with access to the message.
HTTPメッセージ署名は、署名によって保護されている情報のいずれにも機密性を提供しません。すべてのフィールドの値と署名自体の値を含むHTTPメッセージのコンテンツは、メッセージにアクセスできる当事者にプレーンテキストで提示されます。
To provide confidentiality at the transport level, TLS or its equivalent can be used, as discussed in Section 7.1.2.
セクション7.1.2で説明するように、輸送レベルで機密性を提供するために、TLSまたはその同等物を使用できます。
It is important to balance the need for providing useful feedback to developers regarding error conditions without providing additional information to an attacker. For example, a naive but helpful server implementation might try to indicate the required key identifier needed for requesting a resource. If someone knows who controls that key, a correlation can be made between the resource's existence and the party identified by the key. Access to such information could be used by an attacker as a means to target the legitimate owner of the resource for further attacks.
追加情報を攻撃者に提供することなく、エラー条件に関する開発者に有用なフィードバックを提供する必要性のバランスをとることが重要です。たとえば、素朴で役立つサーバーの実装は、リソースを要求するために必要なキー識別子を示しようとする場合があります。誰かが誰がそのキーを制御しているかを知っている場合、リソースの存在とキーによって特定された当事者との間に相関関係を築くことができます。そのような情報へのアクセスは、さらなる攻撃のためにリソースの正当な所有者を標的とする手段として攻撃者が使用できます。
A core design tenet of this specification is that all message components covered by the signature need to be available to the verifier in order to recreate the signature base and verify the signature. As a consequence, if an application of this specification requires that a particular field be signed, the verifier will need access to the value of that field.
この仕様のコアデザインのテントは、署名ベースを再現して署名を確認するために、署名の対象となるすべてのメッセージコンポーネントが検証器が利用できるようにする必要があることです。結果として、この仕様の適用で特定のフィールドに署名する必要がある場合、検証者はそのフィールドの値にアクセスする必要があります。
For example, in some complex systems with intermediary processors, this could cause surprising behavior where, for fear of breaking the signature, an intermediary cannot remove privacy-sensitive information from a message before forwarding it on for processing. One way to mitigate this specific situation would be for the intermediary to verify the signature itself and then modify the message to remove the privacy-sensitive information. The intermediary can add its own signature at this point to signal to the next destination that the incoming signature was validated, as shown in the example in Section 4.3.
たとえば、中間プロセッサを備えた複雑なシステムでは、これにより、署名を破ることを恐れて、仲介者が処理のために転送する前にプライバシーに敏感な情報をメッセージから削除できない驚くべき行動を引き起こす可能性があります。この特定の状況を軽減する1つの方法は、仲介者が署名自体を検証し、メッセージを変更してプライバシーに敏感な情報を削除することです。セクション4.3の例に示すように、仲介者はこの時点で独自の署名を追加するために、次の目的地に次の目的地に信号を送ることができます。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[ASCII] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[FIPS186-5]
NIST, "Digital Signature Standard (DSS)",
DOI 10.6028/NIST.FIPS.186-5, February 2023,
<https://doi.org/10.6028/NIST.FIPS.186-5>.
[HTMLURL] WHATWG, "URL (Living Standard)", January 2024,
<https://url.spec.whatwg.org/>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[HTTP/1.1] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
June 2022, <https://www.rfc-editor.org/info/rfc9112>.
[POSIX.1] IEEE, "The Open Group Base Specifications Issue 7, 2018
edition", 2018,
<https://pubs.opengroup.org/onlinepubs/9699919799/>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517,
DOI 10.17487/RFC7517, May 2015,
<https://www.rfc-editor.org/info/rfc7517>.
[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[STRUCTURED-FIELDS]
Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 8941, DOI 10.17487/RFC8941, February 2021,
<https://www.rfc-editor.org/info/rfc8941>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[AWS-SIGv4]
Amazon Simple Storage Service, "Authenticating Requests
(AWS Signature Version 4)", March 2006,
<https://docs.aws.amazon.com/AmazonS3/latest/API/sig-v4-
authenticating-requests.html>.
[BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[CLIENT-CERT]
Campbell, B. and M. Bishop, "Client-Cert HTTP Header
Field", RFC 9440, DOI 10.17487/RFC9440, July 2023,
<https://www.rfc-editor.org/info/rfc9440>.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[DIGEST] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/info/rfc9530>.
[JACKSON2019]
Jackson, D., Cremers, C., Cohn-Gordon, K., and R. Sasse,
"Seems Legit: Automated Analysis of Subtle Attacks on
Protocols that Use Signatures", CCS '19: Proceedings of
the 2019 ACM SIGSAC Conference on Computer and
Communications Security, pp. 2165-2180,
DOI 10.1145/3319535.3339813, November 2019,
<https://dl.acm.org/doi/10.1145/3319535.3339813>.
[JWS] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension",
RFC 7239, DOI 10.17487/RFC7239, June 2014,
<https://www.rfc-editor.org/info/rfc7239>.
[RFC7468] Josefsson, S. and S. Leonard, "Textual Encodings of PKIX,
PKCS, and CMS Structures", RFC 7468, DOI 10.17487/RFC7468,
April 2015, <https://www.rfc-editor.org/info/rfc7468>.
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP
APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016,
<https://www.rfc-editor.org/info/rfc7807>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8792] Watsen, K., Auerswald, E., Farrel, A., and Q. Wu,
"Handling Long Lines in Content of Internet-Drafts and
RFCs", RFC 8792, DOI 10.17487/RFC8792, June 2020,
<https://www.rfc-editor.org/info/rfc8792>.
[RFC9457] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details
for HTTP APIs", RFC 9457, DOI 10.17487/RFC9457, July 2023,
<https://www.rfc-editor.org/info/rfc9457>.
[SIGNING-HTTP-MESSAGES]
Cavage, M. and M. Sporny, "Signing HTTP Messages", Work in
Progress, Internet-Draft, draft-cavage-http-signatures-12,
21 October 2019, <https://datatracker.ietf.org/doc/html/
draft-cavage-http-signatures-12>.
[SIGNING-HTTP-REQS-OAUTH]
Richer, J., Ed., Bradley, J., and H. Tschofenig, "A Method
for Signing HTTP Requests for OAuth", Work in Progress,
Internet-Draft, draft-ietf-oauth-signed-http-request-03, 8
August 2016, <https://datatracker.ietf.org/doc/html/draft-
ietf-oauth-signed-http-request-03>.
[TLS] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
There have been many attempts to create signed HTTP messages in the past, including other non-standardized definitions of the Signature field that is used within this specification. It is recommended that developers wishing to support this specification, other published documents, or other historical drafts do so carefully and deliberately, as incompatibilities between this specification and other documents or various versions of other drafts could lead to unexpected problems.
この仕様内で使用される署名フィールドの他の非標準化された定義を含む、過去に署名済みのHTTPメッセージを作成する試みがたくさんありました。この仕様、その他の公開されたドキュメント、またはその他の歴史的ドラフトをサポートしたい開発者は、この仕様や他のドキュメントまたは他のドラフトのさまざまなバージョンの間の非互換性が予期しない問題につながる可能性があるため、慎重かつ故意にそうすることをお勧めします。
It is recommended that implementors first detect and validate the Signature-Input field defined in this specification to detect that the mechanism described in this document is in use and not an alternative. If the Signature-Input field is present, all Signature fields can be parsed and interpreted in the context of this specification.
実装者は、この仕様で定義されている署名入力フィールドを最初に検出および検証して、このドキュメントで説明したメカニズムが使用されており、代替ではないことを検出することをお勧めします。署名入力フィールドが存在する場合、この仕様のコンテキストですべての署名フィールドを解析および解釈できます。
The following non-normative examples are provided as a means of testing implementations of HTTP message signatures. The signed messages given can be used to create the signature base with the stated parameters, creating signatures using the stated algorithms and keys.
以下の非規範的な例は、HTTPメッセージ署名の実装をテストする手段として提供されます。指定されたメッセージを使用して、指定されたパラメーターを使用して署名ベースを作成し、指定されたアルゴリズムとキーを使用して署名を作成できます。
The private keys given can be used to generate signatures, though since several of the demonstrated algorithms are non-deterministic, the results of a signature are expected to be different from the exact bytes of the examples. The public keys given can be used to validate all signed examples.
指定されたプライベートキーを使用して署名を生成できますが、実証されたアルゴリズムのいくつかは非決定的であるため、署名の結果は例の正確なバイトとは異なると予想されます。指定されたパブリックキーを使用して、署名されたすべての例を検証できます。
This section provides cryptographic keys that are referenced in example signatures throughout this document. These keys MUST NOT be used for any purpose other than testing.
このセクションでは、このドキュメント全体の例の署名で参照されている暗号化キーを提供します。これらのキーは、テスト以外の目的に使用してはなりません。
The key identifiers for each key are used throughout the examples in this specification. It is assumed for these examples that the signer and verifier can unambiguously dereference all key identifiers used here and that the keys and algorithms used are appropriate for the context in which the signature is presented.
各キーのキー識別子は、この仕様の例全体で使用されます。これらの例では、署名者と検証者がここで使用されているすべてのキー識別子すべてが明確に控除できること、および使用されるキーとアルゴリズムは署名が提示されるコンテキストに適していると想定されています。
The components for each private key, in PEM format [RFC7468], can be displayed by executing the following OpenSSL command:
PEM形式[RFC7468]の各秘密鍵のコンポーネントは、次のOpenSSLコマンドを実行することで表示できます。
openssl pkey -text
This command was tested with all the example keys on OpenSSL version 1.1.1m. Note that some systems cannot produce or use all of these keys directly and may require additional processing. All keys are also made available in JWK format.
このコマンドは、OpenSSLバージョン1.1.1mのすべてのサンプルキーでテストされました。一部のシステムは、これらすべてのキーを直接生成または使用できず、追加の処理が必要になる場合があることに注意してください。すべてのキーもJWK形式で利用可能になります。
The following key is a 2048-bit RSA public and private key pair, referred to in this document as test-key-rsa. This key is encoded in PEM format, with no encryption.
次のキーは、このドキュメントでTest-Key-RSAと呼ばれる2048ビットRSAパブリックおよび秘密鍵ペアです。このキーは、暗号化なしでPEM形式でエンコードされています。
-----BEGIN RSA PUBLIC KEY-----
MIIBCgKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrw
WEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFq
MGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75jfZg
kne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0P
uKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZSFlQ
PSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQAB
-----END RSA PUBLIC KEY-----
-----BEGIN RSA PRIVATE KEY-----
MIIEqAIBAAKCAQEAhAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsP
BRrwWEBnez6d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsd
JKFqMGmXCQvEG7YemcxDTRPxAleIAgYYRjTSd/QBwVW9OwNFhekro3RtlinV0a75
jfZgkne/YiktSvLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKI
lE0PuKxI4T+HIaFpv8+rdV6eUgOrB2xeI1dSFFn/nnv5OoZJEIB+VmuKn3DCUcCZ
SFlQPSXSfBDiUGhwOw76WuSSsf1D4b/vLoJ10wIDAQABAoIBAG/JZuSWdoVHbi56
vjgCgkjg3lkO1KrO3nrdm6nrgA9P9qaPjxuKoWaKO1cBQlE1pSWp/cKncYgD5WxE
CpAnRUXG2pG4zdkzCYzAh1i+c34L6oZoHsirK6oNcEnHveydfzJL5934egm6p8DW
+m1RQ70yUt4uRc0YSor+q1LGJvGQHReF0WmJBZHrhz5e63Pq7lE0gIwuBqL8SMaA
yRXtK+JGxZpImTq+NHvEWWCu09SCq0r838ceQI55SvzmTkwqtC+8AT2zFviMZkKR
Qo6SPsrqItxZWRty2izawTF0Bf5S2VAx7O+6t3wBsQ1sLptoSgX3QblELY5asI0J
YFz7LJECgYkAsqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOM
cCNq8SyYbTqgnWlB9ZfcAm/cFpA8tYci9m5vYK8HNxQr+8FS3Qo8N9RJ8d0U5Csw
DzMYfRghAfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1
mwJ5AL0pYF0G7x81prlARURwHo0Yf52kEw1dxpx+JXER7hQRWQki5/NsUEtv+8RT
qn2m6qte5DXLyn83b1qRscSdnCCwKtKWUug5q2ZbwVOCJCtmRwmnP131lWRYfj67
B/xJ1ZA6X3GEf4sNReNAtaucPEelgR2nsN0gKQKBiGoqHWbK1qYvBxX2X3kbPDkv
9C+celgZd2PW7aGYLCHq7nPbmfDV0yHcWjOhXZ8jRMjmANVR/eLQ2EfsRLdW69bn
f3ZD7JS1fwGnO3exGmHO3HZG+6AvberKYVYNHahNFEw5TsAcQWDLRpkGybBcxqZo
81YCqlqidwfeO5YtlO7etx1xLyqa2NsCeG9A86UjG+aeNnXEIDk1PDK+EuiThIUa
/2IxKzJKWl1BKr2d4xAfR0ZnEYuRrbeDQYgTImOlfW6/GuYIxKYgEKCFHFqJATAG
IxHrq1PDOiSwXd2GmVVYyEmhZnbcp8CxaEMQoevxAta0ssMK3w6UsDtvUvYvF22m
qQKBiD5GwESzsFPy3Ga0MvZpn3D6EJQLgsnrtUPZx+z2Ep2x0xc5orneB5fGyF1P
WtP+fG5Q6Dpdz3LRfm+KwBCWFKQjg7uTxcjerhBWEYPmEMKYwTJF5PBG9/ddvHLQ
EQeNC8fHGg4UXU8mhHnSBt3EA10qQJfRDs15M38eG2cYwB1PZpDHScDnDA0=
-----END RSA PRIVATE KEY-----
The same public and private key pair in JWK format:
JWK形式の同じパブリックキーペアとプライベートキーペア：
NOTE: '\' line wrapping per RFC 8792
{
"kty": "RSA",
"kid": "test-key-rsa",
"p": "sqeUJmqXE3LP8tYoIjMIAKiTm9o6psPlc8CrLI9CH0UbuaA2JCOMcCNq8Sy\
YbTqgnWlB9ZfcAm_cFpA8tYci9m5vYK8HNxQr-8FS3Qo8N9RJ8d0U5CswDzMYfRgh\
AfUGwmlWj5hp1pQzAuhwbOXFtxKHVsMPhz1IBtF9Y8jvgqgYHLbmyiu1mw",
"q": "vSlgXQbvHzWmuUBFRHAejRh_naQTDV3GnH4lcRHuFBFZCSLn82xQS2_7xFO\
qfabqq17kNcvKfzdvWpGxxJ2cILAq0pZS6DmrZlvBU4IkK2ZHCac_XfWVZFh-PrsH\
_EnVkDpfcYR_iw1F40C1q5w8R6WBHaew3SAp",
"d": "b8lm5JZ2hUduLnq-OAKCSODeWQ7Uqs7eet2bqeuAD0_2po-PG4qhZoo7VwF\
CUTWlJan9wqdxiAPlbEQKkCdFRcbakbjN2TMJjMCHWL5zfgvqhmgeyKsrqg1wSce9\
7J1_Mkvn3fh6CbqnwNb6bVFDvTJS3i5FzRhKiv6rUsYm8ZAdF4XRaYkFkeuHPl7rc\
-ruUTSAjC4GovxIxoDJFe0r4kbFmkiZOr40e8RZYK7T1IKrSvzfxx5AjnlK_OZOTC\
q0L7wBPbMW-IxmQpFCjpI-yuoi3FlZG3LaLNrBMXQF_lLZUDHs77q3fAGxDWwum2h\
KBfdBuUQtjlqwjQlgXPsskQ",
"e": "AQAB",
"qi": "PkbARLOwU_LcZrQy9mmfcPoQlAuCyeu1Q9nH7PYSnbHTFzmiud4Hl8bIXU\
9a0_58blDoOl3PctF-b4rAEJYUpCODu5PFyN6uEFYRg-YQwpjBMkXk8Eb39128ctA\
RB40Lx8caDhRdTyaEedIG3cQDXSpAl9EOzXkzfx4bZxjAHU9mkMdJwOcMDQ",
"dp": "aiodZsrWpi8HFfZfeRs8OS_0L5x6WBl3Y9btoZgsIeruc9uZ8NXTIdxaM6\
FdnyNEyOYA1VH94tDYR-xEt1br1ud_dkPslLV_Aac7d7EaYc7cdkb7oC9t6sphVg0\
dqE0UTDlOwBxBYMtGmQbJsFzGpmjzVgKqWqJ3B947li2U7t63HXEvKprY2w",
"dq": "b0DzpSMb5p42dcQgOTU8Mr4S6JOEhRr_YjErMkpaXUEqvZ3jEB9HRmcRi5\
Gtt4NBiBMiY6V9br8a5gjEpiAQoIUcWokBMAYjEeurU8M6JLBd3YaZVVjISaFmdty\
nwLFoQxCh6_EC1rSywwrfDpSwO29S9i8Xbaap",
"n": "hAKYdtoeoy8zcAcR874L8cnZxKzAGwd7v36APp7Pv6Q2jdsPBRrwWEBnez6\
d0UDKDwGbc6nxfEXAy5mbhgajzrw3MOEt8uA5txSKobBpKDeBLOsdJKFqMGmXCQvE\
G7YemcxDTRPxAleIAgYYRjTSd_QBwVW9OwNFhekro3RtlinV0a75jfZgkne_YiktS\
vLG34lw2zqXBDTC5NHROUqGTlML4PlNZS5Ri2U4aCNx2rUPRcKIlE0PuKxI4T-HIa\
Fpv8-rdV6eUgOrB2xeI1dSFFn_nnv5OoZJEIB-VmuKn3DCUcCZSFlQPSXSfBDiUGh\
wOw76WuSSsf1D4b_vLoJ10w"
}
The following key is a 2048-bit RSA public and private key pair, referred to in this document as test-key-rsa-pss. This key is PKCS #8 encoded in PEM format, with no encryption.
次のキーは、このドキュメントでTest-Key-RSA-PSSと呼ばれる2048ビットRSAパブリックおよび秘密鍵ペアです。このキーは、暗号化なしでPEM形式でエンコードされたPKCS＃8です。
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr4tmm3r20Wd/PbqvP1s2
+QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct+Lh1GH45x28Rw3Ry53mm+
oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7OyrFAHq
gDsznjPFmTOtCEcN2Z1FpWgchwuYLPL+Wokqltd11nqqzi+bJ9cvSKADYdUAAN5W
Utzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw9lq4
aOT9v6d+nb4bnNkQVklLQ3fVAvJm+xdDOp9LCNCN48V2pnDOkFV6+U9nV5oyc6XI
2wIDAQAB
-----END PUBLIC KEY-----
-----BEGIN PRIVATE KEY-----
MIIEvgIBADALBgkqhkiG9w0BAQoEggSqMIIEpgIBAAKCAQEAr4tmm3r20Wd/Pbqv
P1s2+QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvMs8ct+Lh1GH45x28Rw3Ry5
3mm+oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95AndTrifbIFPNU8PPMO7Oyr
FAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL+Wokqltd11nqqzi+bJ9cvSKADYdUA
AN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSyZYoA485mqcO0GVAdVw
9lq4aOT9v6d+nb4bnNkQVklLQ3fVAvJm+xdDOp9LCNCN48V2pnDOkFV6+U9nV5oy
c6XI2wIDAQABAoIBAQCUB8ip+kJiiZVKF8AqfB/aUP0jTAqOQewK1kKJ/iQCXBCq
pbo360gvdt05H5VZ/RDVkEgO2k73VSsbulqezKs8RFs2tEmU+JgTI9MeQJPWcP6X
aKy6LIYs0E2cWgp8GADgoBs8llBq0UhX0KffglIeek3n7Z6Gt4YFge2TAcW2WbN4
XfK7lupFyo6HHyWRiYHMMARQXLJeOSdTn5aMBP0PO4bQyk5ORxTUSeOciPJUFktQ
HkvGbym7KryEfwH8Tks0L7WhzyP60PL3xS9FNOJi9m+zztwYIXGDQuKM2GDsITeD
2mI2oHoPMyAD0wdI7BwSVW18p1h+jgfc4dlexKYRAoGBAOVfuiEiOchGghV5vn5N
RDNscAFnpHj1QgMr6/UG05RTgmcLfVsI1I4bSkbrIuVKviGGf7atlkROALOG/xRx
DLadgBEeNyHL5lz6ihQaFJLVQ0u3U4SB67J0YtVO3R6lXcIjBDHuY8SjYJ7Ci6Z6
vuDcoaEujnlrtUhaMxvSfcUJAoGBAMPsCHXte1uWNAqYad2WdLjPDlKtQJK1diCm
rqmB2g8QE99hDOHItjDBEdpyFBKOIP+NpVtM2KLhRajjcL9Ph8jrID6XUqikQuVi
4J9FV2m42jXMuioTT13idAILanYg8D3idvy/3isDVkON0X3UAVKrgMEne0hJpkPL
FYqgetvDAoGBAKLQ6JZMbSe0pPIJkSamQhsehgL5Rs51iX4m1z7+sYFAJfhvN3Q/
OGIHDRp6HjMUcxHpHw7U+S1TETxePwKLnLKj6hw8jnX2/nZRgWHzgVcY+sPsReRx
NJVf+Cfh6yOtznfX00p+JWOXdSY8glSSHJwRAMog+hFGW1AYdt7w80XBAoGBAImR
NUugqapgaEA8TrFxkJmngXYaAqpA0iYRA7kv3S4QavPBUGtFJHBNULzitydkNtVZ
3w6hgce0h9YThTo/nKc+OZDZbgfN9s7cQ75x0PQCAO4fx2P91Q+mDzDUVTeG30mE
t2m3S0dGe47JiJxifV9P3wNBNrZGSIF3mrORBVNDAoGBAI0QKn2Iv7Sgo4T/XjND
dl2kZTXqGAk8dOhpUiw/HdM3OGWbhHj2NdCzBliOmPyQtAr770GITWvbAI+IRYyF
S7Fnk6ZVVVHsxjtaHy1uJGFlaZzKR4AGNaUTOJMs6NadzCmGPAxNQQOCqoUjn4XR
rOjr9w349JooGXhOxbu8nOxX
-----END PRIVATE KEY-----
The same public and private key pair in JWK format:
JWK形式の同じパブリックキーペアとプライベートキーペア：
NOTE: '\' line wrapping per RFC 8792
{
"kty": "RSA",
"kid": "test-key-rsa-pss",
"p": "5V-6ISI5yEaCFXm-fk1EM2xwAWekePVCAyvr9QbTlFOCZwt9WwjUjhtKRus\
i5Uq-IYZ_tq2WRE4As4b_FHEMtp2AER43IcvmXPqKFBoUktVDS7dThIHrsnRi1U7d\
HqVdwiMEMe5jxKNgnsKLpnq-4NyhoS6OeWu1SFozG9J9xQk",
"q": "w-wIde17W5Y0Cphp3ZZ0uM8OUq1AkrV2IKauqYHaDxAT32EM4ci2MMER2nI\
UEo4g_42lW0zYouFFqONwv0-HyOsgPpdSqKRC5WLgn0VXabjaNcy6KhNPXeJ0Agtq\
diDwPeJ2_L_eKwNWQ43RfdQBUquAwSd7SEmmQ8sViqB628M",
"d": "lAfIqfpCYomVShfAKnwf2lD9I0wKjkHsCtZCif4kAlwQqqW6N-tIL3bdOR-\
VWf0Q1ZBIDtpO91UrG7pansyrPERbNrRJlPiYEyPTHkCT1nD-l2isuiyGLNBNnFoK\
fBgA4KAbPJZQatFIV9Cn34JSHnpN5-2ehreGBYHtkwHFtlmzeF3yu5bqRcqOhx8lk\
YmBzDAEUFyyXjknU5-WjAT9DzuG0MpOTkcU1EnjnIjyVBZLUB5Lxm8puyq8hH8B_E\
5LNC-1oc8j-tDy98UvRTTiYvZvs87cGCFxg0LijNhg7CE3g9piNqB6DzMgA9MHSOw\
cElVtfKdYfo4H3OHZXsSmEQ",
"e": "AQAB",
"qi": "jRAqfYi_tKCjhP9eM0N2XaRlNeoYCTx06GlSLD8d0zc4ZZuEePY10LMGWI\
6Y_JC0CvvvQYhNa9sAj4hFjIVLsWeTplVVUezGO1ofLW4kYWVpnMpHgAY1pRM4kyz\
o1p3MKYY8DE1BA4KqhSOfhdGs6Ov3Dfj0migZeE7Fu7yc7Fc",
"dp": "otDolkxtJ7Sk8gmRJqZCGx6GAvlGznWJfibXPv6xgUAl-G83dD84YgcNGn\
oeMxRzEekfDtT5LVMRPF4_AoucsqPqHDyOdfb-dlGBYfOBVxj6w-xF5HE0lV_4J-H\
rI63Od9fTSn4lY5d1JjyCVJIcnBEAyiD6EUZbUBh23vDzRcE",
"dq": "iZE1S6CpqmBoQDxOsXGQmaeBdhoCqkDSJhEDuS_dLhBq88FQa0UkcE1QvO\
K3J2Q21VnfDqGBx7SH1hOFOj-cpz45kNluB832ztxDvnHQ9AIA7h_HY_3VD6YPMNR\
VN4bfSYS3abdLR0Z7jsmInGJ9X0_fA0E2tkZIgXeas5EFU0M",
"n": "r4tmm3r20Wd_PbqvP1s2-QEtvpuRaV8Yq40gjUR8y2Rjxa6dpG2GXHbPfvM\
s8ct-Lh1GH45x28Rw3Ry53mm-oAXjyQ86OnDkZ5N8lYbggD4O3w6M6pAvLkhk95An\
dTrifbIFPNU8PPMO7OyrFAHqgDsznjPFmTOtCEcN2Z1FpWgchwuYLPL-Wokqltd11\
nqqzi-bJ9cvSKADYdUAAN5WUtzdpiy6LbTgSxP7ociU4Tn0g5I6aDZJ7A8Lzo0KSy\
ZYoA485mqcO0GVAdVw9lq4aOT9v6d-nb4bnNkQVklLQ3fVAvJm-xdDOp9LCNCN48V\
2pnDOkFV6-U9nV5oyc6XI2w"
}
The following key is a public and private elliptical curve key pair over the curve P-256, referred to in this document as test-key-ecc-p256. This key is encoded in PEM format, with no encryption.
次のキーは、このドキュメントでTest-Key-ECC-P256と呼ばれる曲線P-256上のパブリックおよびプライベート楕円曲線キーペアです。このキーは、暗号化なしでPEM形式でエンコードされています。
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lf
w0EkjqF7xB4FivAxzic30tMM4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ==
-----END PUBLIC KEY-----
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIFKbhfNZfpDsW43+0+JjUr9K+bTeuxopu653+hBaXGA7oAoGCCqGSM49
AwEHoUQDQgAEqIVYZVLCrPZHGHjP17CTW0/+D9Lfw0EkjqF7xB4FivAxzic30tMM
4GF+hR6Dxh71Z50VGGdldkkDXZCnTNnoXQ==
-----END EC PRIVATE KEY-----
The same public and private key pair in JWK format:
JWK形式の同じパブリックキーペアとプライベートキーペア：
{
"kty": "EC",
"crv": "P-256",
"kid": "test-key-ecc-p256",
"d": "UpuF81l-kOxbjf7T4mNSv0r5tN67Gim7rnf6EFpcYDs",
"x": "qIVYZVLCrPZHGHjP17CTW0_-D9Lfw0EkjqF7xB4FivA",
"y": "Mc4nN9LTDOBhfoUeg8Ye9WedFRhnZXZJA12Qp0zZ6F0"
}
The following key is an elliptical curve key over the Edwards curve ed25519, referred to in this document as test-key-ed25519. This key is PKCS #8 encoded in PEM format, with no encryption.
次のキーは、このドキュメントでTest-Key-Ed25519と呼ばれるEdwards Curve Ed25519上の楕円曲線キーです。このキーは、暗号化なしでPEM形式でエンコードされたPKCS＃8です。
-----BEGIN PUBLIC KEY-----
MCowBQYDK2VwAyEAJrQLj5P/89iXES9+vFgrIy29clF9CC/oPPsw3c5D0bs=
-----END PUBLIC KEY-----
-----BEGIN PRIVATE KEY-----
MC4CAQAwBQYDK2VwBCIEIJ+DYvh6SEqVTm50DFtMDoQikTmiCqirVv9mWG9qfSnF
-----END PRIVATE KEY-----
The same public and private key pair in JWK format:
JWK形式の同じパブリックキーペアとプライベートキーペア：
{
"kty": "OKP",
"crv": "Ed25519",
"kid": "test-key-ed25519",
"d": "n4Ni-HpISpVObnQMW0wOhCKROaIKqKtW_2ZYb2p9KcU",
"x": "JrQLj5P_89iXES9-vFgrIy29clF9CC_oPPsw3c5D0bs"
}
The following shared secret is 64 randomly generated bytes encoded in Base64, referred to in this document as test-shared-secret:
次の共有秘密は、このドキュメントでテスト共有秘密と呼ばれるBase64でエンコードされた64のランダムに生成されたバイトです。
NOTE: '\' line wrapping per RFC 8792
uzvJfB4u3N0Jy4T7NZ75MDVcr8zSTInedJtkgcu46YW4XByzNJjxBdtjUkdJPBt\
bmHhIDi6pcl8jsasjlTMtDQ==
This section provides non-normative examples that may be used as test cases to validate implementation correctness. These examples are based on the following HTTP messages:
このセクションでは、実装の正確性を検証するためのテストケースとして使用できる非規範的な例を示します。これらの例は、次のHTTPメッセージに基づいています。
For requests, this test-request message is used:
リクエストのために、このテスト要求メッセージが使用されます。
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"}
For responses, this test-response message is used:
応答のために、このテスト応答メッセージが使用されます。
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"}
This example presents a minimal signature using the rsa-pss-sha512 algorithm over test-request, covering none of the components of the HTTP message but providing a timestamped signature proof of possession of the key with a signer-provided nonce.
この例では、RSA-PSSSHA512アルゴリズムをテストレクエスト上で使用した最小限の署名を示しており、HTTPメッセージのコンポーネントはいずれもカバーしていませんが、署名者が提供する非CEとのキーの所有のタイムスタンプの署名証明を提供します。
The corresponding signature base is:
対応する署名ベースは次のとおりです。
NOTE: '\' line wrapping per RFC 8792
"@signature-params": ();created=1618884473;keyid="test-key-rsa-pss"\
;nonce="b3k2pp5k7z-50gnwp.yemd"
This results in the following Signature-Input and Signature header fields being added to the message under the signature label sig-b21:
これにより、次の署名入力および署名ヘッダーフィールドが署名ラベルSIG-B21の下にメッセージに追加されます。
NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b21=();created=1618884473\
;keyid="test-key-rsa-pss";nonce="b3k2pp5k7z-50gnwp.yemd"
Signature: sig-b21=:d2pmTvmbncD3xQm8E9ZV2828BjQWGgiwAaw5bAkgibUopem\
LJcWDy/lkbbHAve4cRAtx31Iq786U7it++wgGxbtRxf8Udx7zFZsckzXaJMkA7ChG\
52eSkFxykJeNqsrWH5S+oxNFlD4dzVuwe8DhTSja8xxbR/Z2cOGdCbzR72rgFWhzx\
2VjBqJzsPLMIQKhO4DGezXehhWwE56YCE+O6c0mKZsfxVrogUvA4HELjVKWmAvtl6\
UnCh8jYzuVG5WSb/QEVPnP5TmcAnLH1g+s++v6d4s8m0gCw1fV5/SITLq9mhho8K3\
+7EPYTU8IU1bLhdxO5Nyt8C8ssinQ98Xw9Q==:
Note that since the covered components list is empty, this signature could be applied by an attacker to an unrelated HTTP message. In this example, the nonce parameter is included to prevent the same signature from being replayed more than once, but if an attacker intercepts the signature and prevents its delivery to the verifier, the attacker could apply this signature to another message. Therefore, the use of an empty covered components set is discouraged. See Section 7.2.1 for more discussion.
対象コンポーネントリストは空であるため、この署名は攻撃者によって無関係なHTTPメッセージに適用できることに注意してください。この例では、同じ署名が複数回リプレイされるのを防ぐためにNONCEパラメーターが含まれていますが、攻撃者が署名をインターセプトし、検証者への配信を防ぐと、攻撃者はこの署名を別のメッセージに適用できます。したがって、空の覆われたコンポーネントセットの使用は落胆します。詳細については、セクション7.2.1を参照してください。
Note that the RSA-PSS algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.
ここで使用されているRSA-PSSアルゴリズムは非決定的であることに注意してください。つまり、アルゴリズムが実行されるたびに異なる署名値が作成されることを意味します。ここで提供される署名値は、指定されたキーに対して検証できますが、新しく生成された署名値は、例と一致するとは期待されていません。セクション7.3.5を参照してください。
This example covers additional components (the authority, the Content-Digest header field, and a single named query parameter) in test-request using the rsa-pss-sha512 algorithm. This example also adds a tag parameter with the application-specific value of header-example.
この例では、RSA-PSS-Sha512アルゴリズムを使用したテストレクエストの追加コンポーネント（機関、コンテンツダイジーヘッダーフィールド、および単一の名前のクエリパラメーター）をカバーしています。この例では、ヘッダー標本のアプリケーション固有の値を持つタグパラメーターも追加されています。
The corresponding signature base is:
対応する署名ベースは次のとおりです。
NOTE: '\' line wrapping per RFC 8792
"@authority": example.com
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"@query-param";name="Pet": dog
"@signature-params": ("@authority" "content-digest" \
"@query-param";name="Pet")\
;created=1618884473;keyid="test-key-rsa-pss"\
;tag="header-example"
This results in the following Signature-Input and Signature header fields being added to the message under the label sig-b22:
これにより、次の署名入力および署名ヘッダーフィールドがラベルSIG-B22の下のメッセージに追加されます。
NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b22=("@authority" "content-digest" \
"@query-param";name="Pet");created=1618884473\
;keyid="test-key-rsa-pss";tag="header-example"
Signature: sig-b22=:LjbtqUbfmvjj5C5kr1Ugj4PmLYvx9wVjZvD9GsTT4F7GrcQ\
EdJzgI9qHxICagShLRiLMlAJjtq6N4CDfKtjvuJyE5qH7KT8UCMkSowOB4+ECxCmT\
8rtAmj/0PIXxi0A0nxKyB09RNrCQibbUjsLS/2YyFYXEu4TRJQzRw1rLEuEfY17SA\
RYhpTlaqwZVtR8NV7+4UKkjqpcAoFqWFQh62s7Cl+H2fjBSpqfZUJcsIk4N6wiKYd\
4je2U/lankenQ99PZfB4jY3I5rSV2DSBVkSFsURIjYErOs0tFTQosMTAoxk//0RoK\
UqiYY8Bh0aaUEb0rQl3/XaVe4bXTugEjHSw==:
Note that the RSA-PSS algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.
ここで使用されているRSA-PSSアルゴリズムは非決定的であることに注意してください。つまり、アルゴリズムが実行されるたびに異なる署名値が作成されることを意味します。ここで提供される署名値は、指定されたキーに対して検証できますが、新しく生成された署名値は、例と一致するとは期待されていません。セクション7.3.5を参照してください。
This example covers all applicable message components in test-request (including the content type and length) plus many derived components, again using the rsa-pss-sha512 algorithm. Note that the Host header field is not covered because the @authority derived component is included instead.
この例では、RSA-PSS-SHA512アルゴリズムを使用して、テスト要求（コンテンツタイプと長さを含む）に加えて、多くの派生コンポーネントに加えて、適用されるすべてのメッセージコンポーネントをカバーしています。@Authority派生コンポーネントが代わりに含まれるため、ホストヘッダーフィールドはカバーされていません。
The corresponding signature base is:
対応する署名ベースは次のとおりです。
NOTE: '\' line wrapping per RFC 8792
"date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST
"@path": /foo
"@query": ?param=Value&Pet=dog
"@authority": example.com
"content-type": application/json
"content-digest": sha-512=:WZDPaVn/7XgHaAy8pmojAkGWoRx2UFChF41A2svX\
+TaPm+AbwAgBWnrIiYllu7BNNyealdVLvRwEmTHWXvJwew==:
"content-length": 18
"@signature-params": ("date" "@method" "@path" "@query" \
"@authority" "content-type" "content-digest" "content-length")\
;created=1618884473;keyid="test-key-rsa-pss"
This results in the following Signature-Input and Signature header fields being added to the message under the label sig-b23:
これにより、次の署名入力および署名ヘッダーフィールドがラベルSIG-B23の下のメッセージに追加されます。
NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b23=("date" "@method" "@path" "@query" \
"@authority" "content-type" "content-digest" "content-length")\
;created=1618884473;keyid="test-key-rsa-pss"
Signature: sig-b23=:bbN8oArOxYoyylQQUU6QYwrTuaxLwjAC9fbY2F6SVWvh0yB\
iMIRGOnMYwZ/5MR6fb0Kh1rIRASVxFkeGt683+qRpRRU5p2voTp768ZrCUb38K0fU\
xN0O0iC59DzYx8DFll5GmydPxSmme9v6ULbMFkl+V5B1TP/yPViV7KsLNmvKiLJH1\
pFkh/aYA2HXXZzNBXmIkoQoLd7YfW91kE9o/CCoC1xMy7JA1ipwvKvfrs65ldmlu9\
bpG6A9BmzhuzF8Eim5f8ui9eH8LZH896+QIF61ka39VBrohr9iyMUJpvRX2Zbhl5Z\
JzSRxpJyoEZAFL2FUo5fTIztsDZKEgM4cUA==:
Note in this example that the value of the Date header field and the value of the created signature parameter need not be the same. This is due to the fact that the Date header field is added when creating the HTTP message and the created parameter is populated when creating the signature over that message, and these two times could vary. If the Date header field is covered by the signature, it is up to the verifier to determine whether its value has to match that of the created parameter or not. See Section 7.2.4 for more discussion.
この例では、日付ヘッダーフィールドの値と作成された署名パラメーターの値は同じではないことに注意してください。これは、HTTPメッセージの作成時に日付ヘッダーフィールドが追加され、作成されたパラメーターがそのメッセージの上に署名を作成するときに入力され、これらの2回は異なる可能性があるためです。日付ヘッダーフィールドが署名でカバーされている場合、その値が作成されたパラメーターの値と一致するかどうかを判断するのは検証者次第です。詳細については、セクション7.2.4を参照してください。
Note that the RSA-PSS algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.
ここで使用されているRSA-PSSアルゴリズムは非決定的であることに注意してください。つまり、アルゴリズムが実行されるたびに異なる署名値が作成されることを意味します。ここで提供される署名値は、指定されたキーに対して検証できますが、新しく生成された署名値は、例と一致するとは期待されていません。セクション7.3.5を参照してください。
This example covers portions of the test-response message using the ecdsa-p256-sha256 algorithm and the key test-key-ecc-p256.
この例は、ECDSA-P256-SHA256アルゴリズムとキーテストキー-ECC-P256を使用したテスト応答メッセージの一部をカバーしています。
The corresponding signature base is:
対応する署名ベースは次のとおりです。
NOTE: '\' line wrapping per RFC 8792
"@status": 200
"content-type": application/json
"content-digest": sha-512=:mEWXIS7MaLRuGgxOBdODa3xqM1XdEvxoYhvlCFJ4\
1QJgJc4GTsPp29l5oGX69wWdXymyU0rjJuahq4l5aGgfLQ==:
"content-length": 23
"@signature-params": ("@status" "content-type" "content-digest" \
"content-length");created=1618884473;keyid="test-key-ecc-p256"
This results in the following Signature-Input and Signature header fields being added to the message under the label sig-b24:
これにより、次の署名入力および署名ヘッダーフィールドがラベルSIG-B24の下のメッセージに追加されます。
NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b24=("@status" "content-type" \
"content-digest" "content-length");created=1618884473\
;keyid="test-key-ecc-p256"
Signature: sig-b24=:wNmSUAhwb5LxtOtOpNa6W5xj067m5hFrj0XQ4fvpaCLx0NK\
ocgPquLgyahnzDnDAUy5eCdlYUEkLIj+32oiasw==:
Note that the ECDSA signature algorithm in use here is non-deterministic, meaning that a different signature value will be created every time the algorithm is run. The signature value provided here can be validated against the given keys, but newly generated signature values are not expected to match the example. See Section 7.3.5.
ここで使用されているECDSA署名アルゴリズムは非決定的であることに注意してください。つまり、アルゴリズムが実行されるたびに異なる署名値が作成されることを意味します。ここで提供される署名値は、指定されたキーに対して検証できますが、新しく生成された署名値は、例と一致するとは期待されていません。セクション7.3.5を参照してください。
This example covers portions of the test-request message using the hmac-sha256 algorithm and the secret test-shared-secret.
この例では、HMAC-Sha256アルゴリズムと秘密のテスト共有秘密分泌範囲を使用して、テスト要求メッセージの一部をカバーしています。
The corresponding signature base is:
対応する署名ベースは次のとおりです。
NOTE: '\' line wrapping per RFC 8792
"date": Tue, 20 Apr 2021 02:07:55 GMT
"@authority": example.com
"content-type": application/json
"@signature-params": ("date" "@authority" "content-type")\
;created=1618884473;keyid="test-shared-secret"
This results in the following Signature-Input and Signature header fields being added to the message under the label sig-b25:
これにより、次の署名入力および署名ヘッダーフィールドがラベルSIG-B25の下のメッセージに追加されます。
NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b25=("date" "@authority" "content-type")\
;created=1618884473;keyid="test-shared-secret"
Signature: sig-b25=:pxcQw6G3AjtMBQjwo8XzkZf/bws5LelbaMk5rGIGtE8=:
Before using symmetric signatures in practice, see the discussion regarding security trade-offs in Section 7.3.3.
実際に対称署名を使用する前に、セクション7.3.3のセキュリティトレードオフに関する議論を参照してください。
This example covers portions of the test-request message using the Ed25519 algorithm and the key test-key-ed25519.
この例では、ED25519アルゴリズムとキーテストキー-ED25519を使用したテストレクエストメッセージの一部をカバーしています。
The corresponding signature base is:
対応する署名ベースは次のとおりです。
NOTE: '\' line wrapping per RFC 8792
"date": Tue, 20 Apr 2021 02:07:55 GMT
"@method": POST
"@path": /foo
"@authority": example.com
"content-type": application/json
"content-length": 18
"@signature-params": ("date" "@method" "@path" "@authority" \
"content-type" "content-length");created=1618884473\
;keyid="test-key-ed25519"
This results in the following Signature-Input and Signature header fields being added to the message under the label sig-b26:
これにより、次の署名入力および署名ヘッダーフィールドがラベルSIG-B26の下のメッセージに追加されます。
NOTE: '\' line wrapping per RFC 8792
Signature-Input: sig-b26=("date" "@method" "@path" "@authority" \
"content-type" "content-length");created=1618884473\
;keyid="test-key-ed25519"
Signature: sig-b26=:wqcAqbmYJ2ji2glfAMaRy4gruYYnx2nEFN2HN6jrnDnQCK1\
u02Gb04v9EDgwUPiu4A0w6vuQv5lIp5WPpBKRCw==:
In this example, there is a TLS-terminating reverse proxy sitting in front of the resource. The client does not sign the request but instead uses mutual TLS to make its call. The terminating proxy validates the TLS stream and injects a Client-Cert header field according to [CLIENT-CERT], and then applies a signature to this field. By signing this header field, a reverse proxy not only can attest to its own validation of the initial request's TLS parameters but can also authenticate itself to the backend system independently of the client's actions.
この例では、リソースの前にTLS終了リバースプロキシがあります。クライアントはリクエストに署名するのではなく、代わりに相互TLSを使用して電話をかけます。終了プロキシは、TLSストリームを検証し、[クライアントキャット]に従ってクライアントケルトヘッダーフィールドを注入し、このフィールドに署名を適用します。このヘッダーフィールドに署名することにより、逆プロキシは、初期リクエストのTLSパラメーターの独自の検証を証明できるだけでなく、クライアントのアクションとは無関係にバックエンドシステムに認証することもできます。
The client makes the following request to the TLS-terminating proxy using mutual TLS:
クライアントは、相互TLSを使用して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"}
The proxy processes the TLS connection and extracts the client's TLS certificate to a Client-Cert header field and passes it along to the internal service hosted at service.internal.example. This results in the following unsigned request:
プロキシはTLS接続を処理し、クライアントのTLS証明書をクライアントキャットヘッダーフィールドに抽出し、service.internal.exampleでホストされている内部サービスに渡します。これにより、次の署名のないリクエストが得られます。
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"}
Without a signature, the internal service would need to trust that the incoming connection has the right information. By signing the Client-Cert header field and other portions of the internal request, the internal service can be assured that the correct party, the trusted proxy, has processed the request and presented it to the correct service. The proxy's signature base consists of the following:
署名がなければ、内部サービスは、着信接続が正しい情報を持っていることを信頼する必要があります。クライアントケルトヘッダーフィールドと内部リクエストの他の部分に署名することにより、内部サービスは、正しい当事者である信頼できるプロキシがリクエストを処理し、それを正しいサービスに提示したことを保証できます。プロキシの署名ベースは、次のもので構成されています。
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"
This results in the following signature:
これにより、次の署名が得られます。
NOTE: '\' line wrapping per RFC 8792
xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6Mce9315T6xoklyy0y\
zhD9ah4JHRwMLOgmizw==
which results in the following signed request sent from the proxy to the internal service with the proxy's signature under the label ttrp:
その結果、ラベルTTRPの下にあるプロキシの署名を使用して、プロキシから内部サービスに送信された次の署名済みリクエストが得られます。
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"}
The internal service can validate the proxy's signature and therefore be able to trust that the client's certificate has been appropriately processed.
内部サービスは、プロキシの署名を検証することができ、したがって、クライアントの証明書が適切に処理されたことを信頼することができます。
HTTP allows intermediaries and applications to transform an HTTP message without affecting the semantics of the message itself. HTTP message signatures are designed to be robust against many of these transformations in different circumstances.
HTTPを使用すると、メッセージ自体のセマンティクスに影響を与えることなく、仲介者とアプリケーションがHTTPメッセージを変換することができます。HTTPメッセージ署名は、さまざまな状況でこれらの変換の多くに対して堅牢になるように設計されています。
For example, the following HTTP request message has been signed using the Ed25519 algorithm and the key test-key-ed25519:
たとえば、次のHTTP要求メッセージは、ED25519アルゴリズムとキーテストキー-ED25519を使用して署名されています。
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==:
The signature base string for this message is:
このメッセージの署名ベース文字列は次のとおりです。
"@method": GET
"@path": /demo
"@authority": example.org
"accept": application/json, */*
"@signature-params": ("@method" "@path" "@authority" "accept")\
;created=1618884473;keyid="test-key-ed25519"
The following message has been altered by adding the Accept-Language header field as well as adding a query parameter. However, since neither the Accept-Language header field nor the query is covered by the signature, the same signature is still valid:
次のメッセージは、compect-languageヘッダーフィールドを追加し、クエリパラメーターを追加することにより変更されました。ただし、Accept-Languageヘッダーフィールドもクエリも署名でカバーされていないため、同じ署名がまだ有効です。
NOTE: '\' line wrapping per RFC 8792
GET /demo?name1=Value1&Name2=value2¶m=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==:
The following message has been altered by removing the Date header field, adding a Referer header field, and collapsing the Accept header field into a single line. The Date and Referer header fields are not covered by the signature, and the collapsing of the Accept header field is an allowed transformation that is already accounted for by the canonicalization algorithm for HTTP field values. The same signature is still valid:
次のメッセージは、日付ヘッダーフィールドを削除し、参照ヘッダーフィールドを追加し、受け入れヘッダーフィールドを単一行に崩壊させることにより変更されました。日付と参照ヘッダーフィールドは署名の対象ではなく、Acceptヘッダーフィールドの崩壊は、HTTPフィールド値のCanonicalizationアルゴリズムによってすでに説明されている許可された変換です。同じ署名がまだ有効です：
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==:
The following message has been altered by reordering the field values of the original message but not reordering the individual Accept header fields. The same signature is still valid:
以下のメッセージは、元のメッセージのフィールド値を並べ替えることで変更されましたが、個々の受け入れヘッダーフィールドを並べ替えることはありません。同じ署名がまだ有効です：
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==:
The following message has been altered by changing the method to POST and the authority to "example.com" (inside the Host header field). Since both the method and authority are covered by the signature, the same signature is NOT still valid:
次のメッセージは、メソッドを投稿する方法と「example.com」に権限を変更することにより変更されました（ホストヘッダーフィールド内）。方法と権限の両方が署名によってカバーされているため、同じ署名はまだ有効ではありません。
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==:
The following message has been altered by changing the order of the two instances of the Accept header field. Since the order of fields with the same name is semantically significant in HTTP, this changes the value used in the signature base, and the same signature is NOT still valid:
次のメッセージは、Acceptヘッダーフィールドの2つのインスタンスの順序を変更することにより変更されました。同じ名前のフィールドの順序は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: */*
Accept: application/json
Signature-Input: transform=("@method" "@path" "@authority" \
"accept");created=1618884473;keyid="test-key-ed25519"
Signature: transform=:ZT1kooQsEHpZ0I1IjCqtQppOmIqlJPeo7DHR3SoMn0s5J\
Z1eRGS0A+vyYP9t/LXlh5QMFFQ6cpLt2m0pmj3NDA==:
This specification was initially based on [SIGNING-HTTP-MESSAGES]. The editors would like to thank the authors of [SIGNING-HTTP-MESSAGES] -- Mark Cavage and Manu Sporny -- for their work on that Internet-Draft and their continuing contributions. This specification also includes contributions from [SIGNING-HTTP-REQS-OAUTH] and other similar efforts.
この仕様は、最初は[signing-http messages]に基づいていました。編集者は、そのインターネットドラフトと継続的な貢献に関する彼らの仕事について、[Singing-http messages]の著者に感謝したいと思います。この仕様には、[signing-http-reqs-oauth]およびその他の同様の取り組みからの貢献も含まれています。
The editors would also like to thank the following individuals (listed in alphabetical order) for feedback, insight, and implementation of this document and its predecessors: Mark Adamcin, Mark Allen, Paul Annesley, Karl Böhlmark, Stéphane Bortzmeyer, Sarven Capadisli, Liam Dennehy, Stephen Farrell, Phillip Hallam-Baker, Tyler Ham, Eric Holmes, Andrey Kislyuk, Adam Knight, Dave Lehn, Ilari Liusvaara, Dave Longley, James H. Manger, Kathleen Moriarty, Yoav Nir, Mark Nottingham, Adrian Palmer, Lucas Pardue, Roberto Polli, Julian Reschke, Michael Richardson, Wojciech Rygielski, Rich Salz, Adam Scarr, Cory J. Slep, Dirk Stein, Henry Story, Lukasz Szewc, Chris Webber, and Jeffrey Yasskin.
編集者はまた、このドキュメントとその前任者のフィードバック、洞察、および実装について、以下の個人（アルファベット順にリストされている）に感謝したいと思います：マーク・アダムシン、マーク・アレン、ポール・アヌリー、カール・ボールマーク、ステファン・ボルツメイヤー、サルベン・カパディスリ、リアム・デネヒーイ、スティーブン・ファレル、フィリップ・ハラム・ベーカー、タイラー・ハム、エリック・ホームズ、アンドレイ・キシュリューク、アダム・ナイト、デイブ・レーン、イラリ・リウウスヴァーラ、デイブ・ロングリー、ジェームズ・H・マンガー、キャスリーン・モリアーティ、ヨーブ・ニール、マーク・ノッティンガム、アドリアン・パルマー、ルーカス・パルドエ、ロベルト・ポリスリ、ジュリアン・レシュケ、マイケル・リチャードソン、ウォージチ・リギエルスキー、リッチ・サルツ、アダム・スカール、コリー・J・スリー、ダーク・スタイン、ヘンリー・ストーリー、ルカス・シューク、クリス・ウェバー、ジェフリー・ヤスキン。
Annabelle Backman (editor)
Amazon
P.O. Box 81226
Seattle, WA 98108-1226
United States of America
Email: richanna@amazon.com
URI: https://www.amazon.com/
Justin Richer (editor)
Bespoke Engineering
Email: ietf@justin.richer.org
URI: https://bspk.io/
Manu Sporny
Digital Bazaar
203 Roanoke Street W.
Blacksburg, VA 24060
United States of America
Email: msporny@digitalbazaar.com