HTTP 消息签名

本文档中关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 BCP 14 中对 RFC2119 的定义来解释（同时参见 [RFC2119] 和 [RFC8174]），仅当这些关键字全部大写时适用。

术语 "HTTP message", "HTTP request", "HTTP response", "target URI", "gateway", "header field", "intermediary", "request target", "trailer field", "sender", "method", 和 "recipient" 按 [HTTP] 中的定义使用。

为简便起见，文中使用“签名”一词同时指代数字签名（使用非对称密码学）和带键的 MAC（使用对称密码学）。类似地，动词“签名”指的是对给定签名基础生成数字签名或带键 MAC。限定术语“数字签名”专指使用非对称密码学签名操作输出的值。

本文档使用来自 [STRUCTURED-FIELDS] 第 3 节 的术语来指定数据类型：List、Inner List、Dictionary、Item、String、Integer、Byte Sequence 和 Boolean。

本文档使用 ABNF 定义若干字符串构造，并使用下列 ABNF 规则：VCHAR, SP, DQUOTE, 和 LF。本文档还使用了来自 [STRUCTURED-FIELDS] 的 ABNF 规则：sf-string, inner-list, 和 parameters。此外，本文档使用了来自 [HTTP] 与 [HTTP/1.1] 的 ABNF 规则：field-content, obs-fold, 和 obs-text。

HTTP Message Signature:

覆盖 HTTP 消息一个或多个部分的数字签名或带键 MAC。注意单个 HTTP 消息可以包含多个 HTTP 消息签名。

Signer:

生成或已生成 HTTP 消息签名的实体。注意多个实体可以作为签名者对给定 HTTP 消息应用各自的签名。

Verifier:

验证或已验证某个 HTTP 消息签名与 HTTP 消息相符的实体。注意 HTTP 消息签名可能会被多次验证，且可能由不同实体执行。

HTTP Message Component:

可由 HTTP 消息签名覆盖的 HTTP 消息的一部分。

Derived Component:

通过指定算法或过程从 HTTP 消息派生出的 HTTP 消息组件。见 第 2.2 节。

HTTP Message Component Name:

标识 HTTP 消息组件来源的字符串，例如字段名或派生组件名。

HTTP Message Component Identifier:

HTTP 消息组件名与任何参数的组合。该组合在特定的 HTTP 消息签名及其适用的 HTTP 消息范围内唯一标识某一具体的 HTTP 消息组件。

HTTP Message Component Value:

在特定 HTTP 消息上下文中与给定组件标识符相关联的值。组件值由 HTTP 消息导出，并通常受到规范化过程处理。

Covered Components:

一个有序集合，列出字段（第 2.1 节）和派生组件（第 2.2 节）的 HTTP 消息组件标识符，表示签名覆盖的消息组件集合，且永远不包含 @signature-params 标识符本身。该集合的顺序被保留并在签名者与验证者之间传达，以便重建签名基础。

Signature Base:

签名者与验证者使用覆盖组件集合和 HTTP 消息生成的字节序列。签名基础由密码算法处理以生成或验证 HTTP 消息签名。

HTTP Message Signature Algorithm:

描述签名与验证过程的密码算法，以在 第 3.3 节 中定义的 HTTP_SIGN 与 HTTP_VERIFY 原语为基础来描述。

Key Material:

创建或验证签名所需的密钥材料。密钥材料通常以显式的密钥标识符标识，允许签名者向验证者指示使用了哪个密钥。

Creation Time:

表示签名被生成时间点的时间戳，由签名者声明。

Expiration Time:

表示签名不再被验证者接受的时间点的时间戳，由签名者声明。

Target Message:

应用 HTTP 消息签名的目标 HTTP 消息。

Signature Context:

从中提取 HTTP 消息组件值的数据源。上下文包括目标消息以及签名者或验证者可能拥有的任何额外信息，例如请求的完整目标 URI 或与响应相关的请求消息。

术语 "UNIX timestamp" 指代 [POSIX.1] 第 4.16 节所称的“自纪元以来的秒数”。

本文档包含非规范性的部分和完整 HTTP 消息示例。有些示例使用单个反斜杠 (\) 表示长值的换行，依据 [RFC8792]。换行示例中的 \ 字符及换行后的前导空格不是值的一部分。

HTTP 允许并有时要求中间体以多种方式转换消息。这可能导致接收方收到的消息与最初发送的消息在位级上不等同。在这种情况下，接收方将无法验证基于发送方 HTTP 消息原始字节的完整性保护，因为验证数字签名或 MAC 需要签名者和验证者拥有完全相同的签名基础。既然消息的精确原始字节不能作为签名基础的可靠来源，则签名者和验证者必须从各自版本的消息中独立创建签名基础，采用对安全变更有弹性的机制，不因不改变消息含义的安全更改而失败。

由于种种原因，严格定义何为“安全变更”与“非安全变更”并不现实。应用以多种方式使用 HTTP，且可能对消息中的某一特定信息（例如消息内容、方法或特定头字段）是否相关存在分歧。因此，通用解决方案需要为签名者提供对哪些消息组件被签名的某种控制。

HTTP 应用可能运行在无法完全访问或控制 HTTP 消息的环境中（例如浏览器的 JavaScript 环境），或使用抽象化协议细节的库（例如 Java HTTP Client (HttpClient) 库）。这些应用需要能够在对 HTTP 消息的了解不完整的情况下生成和验证签名。

• 不同字段名的字段重排序（见 [HTTP] 第 5.3 节）。
• 具有相同字段名的字段合并（见 [HTTP] 第 5.2 节）。
• 移除 Connection 头字段中列出的字段（见 [HTTP] 第 7.6.1 节）。
• 添加指示控制选项的字段（见 [HTTP] 第 7.6.1 节）。
• 增加或移除传输编码（见 [HTTP] 第 7.7 节）。
• 添加诸如 Via（见 [HTTP] 第 7.6.3 节）和 Forwarded（见 [RFC7239] 第 4 节）之类的字段。
• 不同版本 HTTP 之间的转换（例如 HTTP/1.x 与 HTTP/2 之间的转换）。
• 对任何不区分大小写的组件（例如字段名、请求 URI 方案或主机）改变大小写（例如 "Origin" 改为 "origin"）。
• 对请求目标和授权（authority）做出同时应用且不改变消息目标 URI 的修改（参见 [HTTP] 第 7.1 节）。

• 在字段值中使用、添加或移除首尾空白。
• 在字段值中使用、添加或移除 obs-fold（见 [HTTP/1.1] 第 5.2 节）。

我们可以将这些转换识别为那些即便在签名覆盖的消息组件上执行也不应阻止签名验证的转换。此外，对签名未覆盖的组件所做的任何更改都不应阻止签名验证。

关于此类转换的示例以及它们对消息签名的影响，请参见 附录 B.4。

其它转换，例如解析并重新序列化已覆盖组件的字段值或更改派生组件的值，可能导致签名不再针对目标消息验证。使用本规范的应用需要谨慎，确保所选覆盖组件能充分处理应用预期的转换。

• 预期和必需包含在覆盖组件列表中的组件标识符集合（参见 第 2 节）和签名参数（参见 第 2.3 节）。例如，一个授权协议可以强制要求覆盖 Authorization 字段以保护授权凭证，并强制要求签名参数包含 created 参数；而期望语义相关的消息内容的 API 则可以要求存在并被覆盖的 Content-Digest 字段（见 [DIGEST]）并强制要求签名参数中的 tag 参数取 API 特定的值。
• 任何必需或预期被覆盖的组件字段或参数的预期 Structured Field 类型（参见 [STRUCTURED-FIELDS]）。
• 检索用于验证签名的密钥材料的方法。应用通常使用签名参数的 keyid 参数（参见 第 2.3 节）并定义从该参数解析密钥的规则，尽管也可以通过预注册签名者密钥等其它方式获知适当的密钥。
• 签名者可使用且验证者可接受的允许签名算法集合。
• 确定用于验证签名的算法是否适合所用密钥材料与消息上下文的方法。例如，该过程可以使用签名参数的 alg 参数（参见 第 2.3 节）明确说明算法、从密钥材料派生算法，或使用签名者与验证者预先协定的算法。
• 确定用于签名的给定密钥与算法是否适合消息上下文的方法。例如，期望仅使用 ECDSA 签名的服务器应知道拒绝任何 RSA 签名，或期望非对称密码学的服务器应拒绝任何对称密码学签名。
• 确定从 HTTP 消息及其应用上下文派生消息组件的上下文的方法。通常这是目标 HTTP 消息本身，但上下文也可能包含通过配置为应用所知的附加信息，例如外部主机名。
• 如果需要使用 第 2.4 节 提供的机制在请求与响应之间进行绑定，则需要指定为提供此类绑定所需的请求消息和响应消息的所有元素。
• 当签名无效、密钥材料不适当、有效性时间窗口超出规格、组件值无法计算或在签名验证过程中发生任何其它错误时，验证方向签名者返回的错误消息与代码。例如，如果签名被用作认证机制，则返回 401 (Unauthorized) 或 403 (Forbidden) HTTP 状态码可能合适。如果响应来自 HTTP API，则可返回例如 400 (Bad Request) 的状态码并包含更多细节（参见 [RFC7807] 与 [RFC9457]），例如指示使用了错误的密钥材料。

在选择这些参数时，应用必须确保验证者能获取到重建签名基础所需的所有信息。例如，处于反向代理后面的服务器若要使用派生组件 @target-uri，需要知道原始请求 URI，尽管反向代理可能改变显见的目标 URI（另见 第 7.4.3 节）。另外，在响应中使用签名的应用需要确保接收签名响应的客户端能够访问所有被签名的消息部分，包括服务器使用 req（“request-response”）参数（见 第 2.4 节）签名的任何请求部分。

关于这类配置文件的细节属于应用层面的范畴，超出本规范范围；不过第 7 节 中讨论了一些额外的考虑事项。特别地，在选择必需的组件标识符集合时，需要确保覆盖范围对应用足够，如 第 7.2.1 节 与 第 7.2.8 节 所述。本规范仅构成应用完整安全系统的一部分。在基于此工具构建完整安全系统时，对整个系统进行安全分析非常重要。历史系统（如 AWS Signature Version 4 [AWS-SIGv4]）可为如何将类似机制应用于某一应用提供启发，但参考这些历史系统并不能替代对 HTTP 消息签名应用进行的安全分析。

HTTP 字段的组件名称是其字段名的小写形式（参见 [HTTP] 第 5.1 节）。尽管 HTTP 字段名不区分大小写，在将其用作组件名称时，实装必须使用小写字段名（例如 content-type、date、etag）。

HTTP 字段的组件值是目标消息中该命名字段的字段值（见 [HTTP] 第 5.5 节）。除非被附加参数和规则（例如下文所述的 req 与 tr 标记）覆盖，否则字段值必须从目标消息的命名头字段中获取。对于大多数字段，字段值为 ASCII 字符串（如 [HTTP] 推荐），组件值就是该字符串。某些实现中可能存在其它编码，因此所有非 ASCII 的字段值必须在加入签名基础之前编码为 ASCII。正如 第 2.1.3 节 所述，bs 参数提供了封装此类有问题字段值的方法。

除非被附加参数与规则覆盖，HTTP 字段值必须按照 [HTTP] 第 5.2 节 中定义的方式合并为单个值以创建组件值。具体来说，以多次字段形式发送的 HTTP 字段必须通过使用单个逗号和单个空格作为分隔符（"," + " "）将值连接起来来合并。注意中间体被允许在逗号之间使用任意数量的空白来合并值，如果验证者不考虑这种行为，签名可能会失败，因为签名者和验证者在各自的签名基础中看到的组件值会不同。为提高鲁棒性，建议签名的消息尽量只包含被签名字段的单个实例，尤其是对任何基于列表的字段，应使用下述算法序列化字段值。这能增加字段值通过中间体时保持不变的概率。若无法采用该方法且需要分别发送字段的多个实例，则建议签名者和验证者对任何基于列表的字段采用严格算法，收集所有单独字段值并按下述严格算法合并，以应对可能的中间体行为。当字段为 List 或 Dictionary 类型的结构化字段时，可通过要求对字段值进行严格的结构化字段序列化来更直接地实现这一效果，详见 第 2.1.1 节。

注意，某些 HTTP 字段（例如 Set-Cookie [COOKIE]）不遵循允许以这种方式合并字段值的语法（即从多个输入得到的合并输出并不一定是单一且不含歧义的）。尽管组件值在消息签名过程中不会被解析，仅作为签名基础的一部分（参见 第 2.5 节），在签名此类字段时仍需谨慎，因为合并后的值可能会产生歧义。针对这类有问题字段，bs 参数（见 第 2.1.3 节）提供了封装方法。关于此问题的更多讨论见 第 7.5.6 节。

1. 创建一个有序列表，包含消息中该字段每个实例的字段值，按其在消息中出现的顺序（或将出现的顺序）。
2. 从列表中每一项删除前导和尾随空白。注意，因 HTTP 字段值不允许包含前导和尾随空白，在合规实现中这将是无操作。
3. 移除行内任何过时的折行（obsolete line folding），并以单个空格（" "）替换，如 [HTTP/1.1] 第 5.2 节 所述。注意该行为特定于 HTTP/1.1，其他版本的 HTTP 规范不允许内部折行。
4. 以单个逗号（","）和单个空格（" "）连接该值列表。

得到的字符串即为该字段的组件值。

注意，某些 HTTP 字段具有多种有效的序列化形式且语义等价，例如允许中间体更改大小写的不区分大小写的值。对该类字段进行签名和处理的应用必须考虑如何处理这些字段的值，以确保签名者和验证者能够派生出相同的值，详见 第 7.5.2 节。

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

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

X-Empty-Header:(SP)

在签名基础生成算法（见 第 2.5 节）中会被序列化为冒号之后跟随空字符串的形式，冒号前后会加入空格。

"x-empty-header":(SP)

sf

一个布尔标志，指示组件值使用结构化字段值的严格编码序列化（见 第 2.1.1 节）。

key

一个字符串参数，用于从字典结构化字段中选择单个成员值（参见 第 2.1.2 节）。

bs

一个布尔标志，指示在将个别字段值合并到组件值之前使用 Byte Sequence 数据结构对其进行编码（参见 第 2.1.3 节）。

req

一个用于已签名响应的布尔标志，表明组件值是从触发该响应消息的请求中派生的，而不是直接从响应消息中获取。注意该参数也可应用于任何以请求为目标的派生组件标识符（参见 第 2.4 节）。

tr

一个布尔标志，指示字段值取自消息的 trailer 字段（见 [HTTP] 第 6.5 节）。若无该标志，字段值则取自消息的头字段（见 [HTTP] 第 6.3 节，参见 第 2.1.4 节）。

可以同时指定多个参数，但有些组合是冗余或不兼容的。例如，当对字典项使用 key 参数时，其功能已被覆盖，因为 key 要求对值进行严格序列化。bs 参数要求使用消息中字段值的原始字节，因此与要求字段值在合并后进行解析的数据结构（如 sf 或 key）不兼容。

可以在第 第 6.5 节 建立的 “HTTP Signature Component Parameters” 注册表中定义附加参数。

除了 HTTP 字段之外，还有若干可从控制数据、签名上下文或要签名的 HTTP 消息的其它方面派生出的组件。通过定义组件名称、可能的参数、消息目标以及其组件值的派生方法，可以将这些派生组件包含进签名基础。

派生组件名称必须以 “at”（@）字符开头。这将派生组件名称与 HTTP 字段名区分开来；根据 [HTTP] 第 5.1 节，HTTP 字段名不能包含 @ 字符。HTTP 消息签名的处理器必须将派生组件名称与字段名分开处理，详见 第 7.5.1 节。

@method

请求使用的方法（参见 第 2.2.1 节）。

@target-uri

请求的完整目标 URI（参见 第 2.2.2 节）。

@authority

请求目标 URI 的 authority（参见 第 2.2.3 节）。

@scheme

请求目标 URI 的 scheme（参见 第 2.2.4 节）。

@request-target

请求目标（参见 第 2.2.5 节）。

@path

请求目标 URI 的绝对路径部分（参见 第 2.2.6 节）。

@query

请求目标 URI 的查询部分（参见 第 2.2.7 节）。

@query-param

请求目标 URI 的已解析并编码的查询参数（参见 第 2.2.8 节）。

@status

响应的状态码（参见 第 2.2.9 节）。

附加的派生组件名称在 “HTTP Signature Derived Component Names” 注册表中定义（参见 第 6.4 节）。

派生组件值取自签名目标消息的上下文。该上下文包括关于消息本身的信息（例如控制数据）以及签名者或验证者持有的任何额外状态与上下文。特别地，当对响应进行签名时，签名者可以通过使用 req 参数（参见 第 2.4 节）将原始请求的任何派生组件包含进来。

request:

从 HTTP 请求消息派生并应用的值，详见 [HTTP] 第 3.4 节。若签名的目标消息为响应，则可使用 req 参数包含以请求为目标的派生组件（见 第 2.4 节）。

response:

从 HTTP 响应消息派生并应用的值，详见 [HTTP] 第 3.4 节。

request, response:

可从请求消息或响应消息中派生并应用的值。

派生组件定义必须定义其可应用的所有目标消息类型。

派生组件值必须仅限可打印字符与空格，且不得包含任何换行字符。派生组件值不得以空白字符开始或结束。

HTTP 消息签名具有元数据属性，用以提供关于签名生成与验证的信息，这些元数据由已覆盖组件的有序集合与参数的有序集合组成，参数包含签名创建时间戳、用于验证的密钥材料标识符以及其它辅助信息。该元数据在签名基础中由一个特殊的消息组件表示；该特殊消息组件的处理方式与其它消息组件略有不同。具体地，签名参数消息组件必须作为签名基础的最后一行出现（参见 第 2.5 节），并且该组件标识符不得在任何签名的已覆盖组件集合中列出，包括其自身。

签名参数组件的名称为 @signature-params。

created:

创建时间，UNIX 时间戳形式的整数类型。不支持子秒精度。建议包含此参数。

expires:

过期时间，UNIX 时间戳形式的整数类型。不支持子秒精度。

nonce:

为该签名生成的随机唯一值，作为字符串值。

alg:

来自 “HTTP Signature Algorithms” 注册表的 HTTP 消息签名算法，作为字符串值。

keyid:

用于标识密钥材料的标识符，作为字符串值。

tag:

签名的应用特定标签，作为字符串值。应用使用该值帮助标识与特定应用或协议相关的签名。

附加参数可以在 “HTTP Signature Metadata Parameters” 注册表中定义（参见 第 6.3 节）。注意参数本身没有通用顺序，但一旦为给定参数集合选择了某种顺序，就不能在不改变签名参数值的情况下更改该顺序。

1. 令输出为空字符串。
2. 确定已覆盖组件的组件标识符的顺序（不包括 @signature-params 本身）。一旦选择该顺序就不能更改。此顺序必须与用于创建签名基础的顺序相同（参见 第 2.5 节）。
3. 将已覆盖组件的组件标识符（包括所有参数）按有序 Inner List 的字符串值序列化，依据 [STRUCTURED-FIELDS] 第 4.1.1.1 节，然后将其附加到输出。注意组件标识符可以包含自身的参数，这些参数是有序集合。一旦为某组件的参数选择了顺序，该顺序就不得更改。
4. 确定任意签名参数的顺序。一旦选择该顺序就不得更改。
5. 按 [STRUCTURED-FIELDS] 第 4.1.1.2 节 的规则将参数按顺序附加到 Inner List 中，跳过对于该消息签名不可用或未使用的参数。
6. 输出即包含签名参数组件值。

注意，这里使用 [STRUCTURED-FIELDS] 第 4.1.1.1 节 的 Inner List 序列化来表示已覆盖组件值，而不是使用 第 4.1.1 节 的 List 序列化，以便与该值在 Signature-Input 字段中的并行性（参见 第 4.1 节）更好地对应。

NOTE: '\' line wrapping per RFC 8792

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

注意 HTTP 消息可能包含多个签名（参见 第 4.3 节），但每个签名的签名参数条目仅包含用于该单一签名的签名参数。

当一个请求消息导致生成签名响应消息时，签名者可以通过在组件标识符中添加 req 参数，将请求消息的部分内容包含到签名基础中。

req

一个布尔标志，指示组件值是从触发该响应消息的请求中派生的，而不是直接从响应消息中获取。

该参数可以应用于 HTTP 字段以及以请求为目标的派生组件，两者语义相同。使用该参数的消息组件的组件值按通常方式计算，但数据从请求消息中提取，而不是从所签名的目标响应消息中提取。

注意，相同的组件名称在同一签名基础中可以既带有 req 参数也不带该参数，分别表示来自请求消息与响应消息的同名组件。

req 参数可以与适用于组件标识符的其它参数组合使用，例如字典字段的 key 参数。

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

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

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

服务器使用其自身的密钥对响应签名，覆盖了响应的若干字段。除此之外，服务器还将若干来自最初触发该响应的请求消息的组件包含进来。此示例中，服务器在响应的已覆盖组件中包含了请求的 method、authority、path 以及 content-digest。请求与响应的 Content-Digest 均被包含在响应签名内。对于本示例的应用，查询被认为与响应无关，因此未被覆盖。其它应用会根据其需要做出不同决定，详见 第 1.4 节。

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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

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

注意此处使用的 ECDSA 签名算法为非确定性算法，这意味着每次运行算法都会生成不同的签名值。此处给出的签名值可用来对示例中的密钥进行验证，但新生成的签名值不应与本示例匹配。参见 第 7.3.5 节。

由于请求中的组件值不会在响应消息中重复出现，请求者必须将原始消息组件值保留足够长的时间，以便验证使用这些组件标识符参数的响应签名。在大多数情况下，这意味着请求者需要保留原始请求消息，因为签名者可能会根据应用需要在响应中包含请求的任意部分。由于中间体可能在请求被服务器处理前修改请求消息，应用需要谨慎避免对这样的被修改值进行签名，否则客户端将无法验证由此生成的签名。

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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

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

注意此处使用的 ECDSA 签名算法为非确定性算法，每次运行将产生不同签名值。此处提供的签名值可使用给定密钥进行验证，但新生成的签名值不应与示例一致。参见 第 7.3.5 节。

为已签名请求生成响应的应用应该签名请求签名值的所有组件，以提供足够的覆盖和防护，防范一类碰撞攻击，详见 第 7.3.7 节。本示例中的服务器在响应签名中包含了客户端请求签名中 Signature-Input 字段所列的所有组件，此外还包含了响应的组件。

尽管在语法上可以将请求消息的 Signature 与 Signature-Input 字段包含到响应签名组件中，但此做法不建议。原因在于“签名的签名”并不会像直观期望的那样提供传递性的覆盖，且此做法容易遭受多种攻击，详见 第 7.3.7 节。需要以安全方式表示签名已被成功处理或接收的应用必须仔细指定替代机制。

响应签名只能覆盖在使用该标志时包含在请求消息中的内容。因此，如果应用需要在响应签名中包含请求的消息内容，客户端需通过某种手段覆盖该内容，例如添加 Content-Digest 字段。有关更多信息，见 第 7.2.8 节。

req 参数不得用于以请求消息为目标的签名中的任何组件。

签名基础是一个 ASCII 字符串 [ASCII]，包含由签名覆盖的经规范化的 HTTP 消息组件。签名基础创建算法的输入是已覆盖组件标识符的有序集合及其关联值，以及在 第 2.3 节 中讨论的任何附加签名参数。

组件标识符使用 [STRUCTURED-FIELDS] 第 4 节定义的严格序列化规则进行序列化。组件标识符具有一个组件名称，该名称是使用 sf-string ABNF 规则序列化的 String Item 值。组件标识符 MAY 还可以包括使用 parameters ABNF 规则序列化的已定义参数。第 2.3 节 中定义的签名参数行遵循相同模式，但组件标识符是一个具有固定值且无参数的 String Item，而组件值始终是带有可选参数的 Inner List。

注意，这意味着组件名称本身的序列化被双引号包围，参数随后以分号分隔列表的形式附加，例如 "cache-control"、"@authority"、"@signature-params"，或 "example-dictionary";key="foo"。

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

为创建签名基础，签名者或验证者按照下述算法对签名的已覆盖组件中每个组件标识符（包括其参数）串联条目。所有在下文描述的错误MUST立即导致算法失败，并且不输出签名基础。

1. 令输出为空字符串。

2. 对于已覆盖组件集合中的每个消息组件项（按顺序）：

   11.

   如果该组件标识符（包括其参数）已被添加到签名基础中，则产生错误。

   12.

   将已覆盖组件的组件标识符按 component-identifier ABNF 规则序列化后附加。注意该序列化将组件名称置于双引号内，并在引号外追加任何参数。

   13.

   附加一个冒号（:）。

   14.

   附加一个空格（" "）。

   15.

   确定该组件标识符的组件值。

   • 如果组件标识符具有一个未知的参数，则产生错误。
   • 如果组件标识符具有彼此互不兼容的参数（例如 bs 与 sf），则产生错误。
   • 如果组件标识符包含 req 参数并且目标消息是请求，则产生错误。
   • 如果组件标识符包含 req 参数并且目标消息是响应，则该组件值的上下文为触发该响应消息的相关请求消息。否则，组件值的上下文为目标消息本身。
   • 如果组件名称以 "at"（@）字符开头，则按为该派生组件在 第 2.2 节 中定义的特定规则从消息中派生该组件的值，并处理任何已知的有效参数。如果派生组件名未知或无法派生值，则产生错误。
   • 如果组件名称不以 "at"（@）字符开头，则按 第 2.1 节 所述对 HTTP 字段值进行规范化，包括处理任何已知的有效参数。如果在上下文中无法找到该字段或无法获取该值，则产生错误。

   16.

   附加该已覆盖组件的规范化组件值。

   17.

   附加一个换行符（\n）。

3. 按下述方式，根据 signature-params-line 规则附加签名参数组件（第 2.3 节）：

   11.

   将签名参数的组件标识符按 component-identifier 规则序列化后附加，即确切的值 "@signature-params"（包括双引号）。

   12.

   附加一个冒号（:）。

   13.

   附加一个空格（" "）。

   14.

   附加签名参数的规范化组件值，如 第 2.3 节 中定义，即带参数的 Inner List 结构化字段值。

4. 如果输出字符串包含任何非 ASCII 字符 [ASCII]，则产生错误。
5. 返回输出字符串。

• 签名者或验证者不理解该派生组件名称。
• 组件名称标识的字段在消息中不存在或其值格式错误。
• 组件标识符包含一个未知的或不适用于其所附组件标识符的参数。
• 组件标识符指示使用结构化字段序列化（通过 sf 参数），但该字段被已知不是结构化字段或实现不知其结构化字段类型。
• 组件标识符是字典成员标识符，但引用的字段在消息中不存在、不是字典结构化字段、或其值格式错误。
• 组件标识符是字典成员标识符或命名查询参数标识符，但引用的成员在组件值中不存在或其值格式错误。例如，标识符为 "example-dict";key="c"，而 Example-Dict 头字段的值为 a=1, b=2，其中没有 c 值。

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

注意，上述示例签名基础并不包含结束所示示例的最后换行符，规范中其它位置展示的示例签名基础亦是如此。

创建 HTTP 消息签名的过程以签名上下文（包括目标消息）和应用要求为输入。输出是签名值和一组签名参数，这些信息可以通过将它们添加到消息中来传达给验证者。

1. 签名者从潜在签名算法集合中为签名选择一个 HTTP 签名算法和用于签名的密钥材料。潜在算法集合由应用决定，超出本文档范围。签名者MUST选择适合签名算法并满足算法定义的任何要求（例如密钥大小或格式）的密钥材料。签名者选择算法与密钥材料的机制超出本文档范围。
2. 签名者将签名的创建时间设置为当前时间。
3. 如适用，签名者将签名的过期时间属性设置为签名到期的时间。过期时间是对验证者的提示，表明签名者在该时刻之后不再为签名担保。适当的过期长度以及对该参数的处理要求由应用具体决定。

4. 签名者创建表示将由签名覆盖的消息组件的组件标识符的有序集合，并向该集合附加签名元数据参数。该集合的序列化值随后将用作 Signature-Input 字段的值，如 第 4.1 节 所述。

   • 一旦选择了已覆盖组件的顺序，该顺序在签名的整个生命周期内MUST NOT改变。
   • 每个已覆盖组件标识符MUST要么是签名上下文中的一个 HTTP 字段（参见 第 2.1 节），要么是第 2.2 节 或 “HTTP Signature Derived Component Names” 注册表中列出的一个派生组件。
   • 请求的签名者SHOULD在已覆盖组件中包含部分或全部消息控制数据，例如 @method、@authority、@target-uri 或它们的某种组合。
   • 签名者SHOULD包含 created 签名元数据参数以指示签名创建时间。
   • @signature-params 派生组件标识符MUST NOT出现在已覆盖组件标识符列表中。该派生组件必须始终作为签名基础的最后一行，以确保签名始终覆盖其自身的元数据且元数据不得被替换。
   • 关于在该集合中包含哪些内容及其顺序的进一步指导超出本文档范围。
5. 签名者使用这些参数和签名基础创建算法（参见 第 2.5 节）创建签名基础。
6. 签名者使用 HTTP_SIGN 原语函数，用签名者选择的签名算法和所选的密钥材料对签名基础进行签名。HTTP_SIGN 原语和若干具体签名算法的应用在 第 3.3 节 中定义。
7. 签名函数的字节数组输出即为要包含在 第 4.2 节 中 Signature 字段的 HTTP 消息签名输出值。

注意，此处使用的 RSA-PSS 算法为非确定性算法，这意味着每次运行算法都会生成不同的签名值。所提供的签名值可以针对给定密钥进行验证，但新生成的签名值不应与示例匹配。参见 第 7.3.5 节。

验证 HTTP 消息签名的过程以签名上下文（包括目标消息，特别是其 Signature 与 Signature-Input 字段）和应用要求为输入。验证的输出要么为成功验证，要么为错误。

1. 按 Sections 第 4.1 节 与 第 4.2 节 所述解析 Signature 与 Signature-Input 字段，并提取要验证的签名及其标签。

   11.

   如果存在多个签名值，基于验证者的策略与配置确定应处理哪一个签名。如果找不到适用的签名，则产生错误。

   12.

   如果所选的 Signature 字段值没有相应的 Signature-Input 字段值（即具有相同标签的项），则产生错误。

2. 将所选 Signature-Input 字段的值解析为带参数的 Inner List，以获取要验证的已覆盖组件的有序列表和该签名的签名参数。
3. 解析对应的 Signature 字段的值以获取要验证的签名字节数组值。
4. 检查签名参数，以确认签名满足本文档以及应用定义的任何附加要求，例如哪些消息组件必须由签名覆盖（参见 第 3.2.1 节）。
5. 确定该签名的验证密钥材料。如果密钥材料通过静态配置或外部协议协商等外部方式已知，验证者将使用适用技术从这些外部知识中获取密钥材料。如果签名参数中标识了密钥，验证者将解引用该密钥标识符以获得适用于该签名的密钥材料。验证者必须确定该密钥材料在该签名所呈现的上下文中的可信性。如果标识了一个验证者不认识或不信任，或与预配置不匹配的密钥，则验证MUST失败。

6. 确定用于验证的算法：

   11.

   从应用已知的允许算法集合开始。如果下列任一步选择的算法不在此集合中，则签名验证失败。

   12.

   如果算法通过静态配置或外部协议协商等外部方式已知，验证者将使用该算法。

   13.

   如果算法可以从密钥材料中确定，例如通过键值本身的算法字段，验证者将使用该算法。

   14.

   如果算法在签名参数中显式声明为来自“HTTP Signature Algorithms”注册表的值，验证者将使用所引用的算法。

   15.

   如果算法在多处指定（例如静态配置、签名参数中的 alg，以及密钥材料本身），则解析出的算法MUST一致。如果算法不一致，验证者MUST使验证失败。

7. 使用接收到的 HTTP 消息和已解析的签名参数重建签名基础，使用 第 2.5 节 定义的算法。@signature-params 的输入值为该签名的 Signature-Input 字段的值，按 第 2.3 节 中描述的规则序列化。注意这不包括 Signature-Input 字段中的签名标签。
8. 如果密钥材料适合该算法，应用适当的 HTTP_VERIFY 密码学验证算法，对重建的签名基础、密钥材料和签名值进行验证。HTTP_VERIFY 原语和若干具体算法在 第 3.3 节 中定义。
9. 验证算法函数的结果即为密码学验证函数的最终结果。

如果上述任一步失败或产生错误，则签名验证失败。

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

在附加要求至少签名 method、authority、path、content-digest、content-length 和 content-type 项，并且签名创建时间戳在验证时足够新鲜的情形下，验证通过。

HTTP 消息签名MUST使用适合密钥材料、环境以及签名者和验证者需求的密码学数字签名或 MAC 方法。本规范并不严格限制可用的签名算法，任何满足这些基本要求的签名算法MAY由 HTTP 消息签名的应用使用。

HTTP_SIGN (M, Ks)  ->  S

HTTP_VERIFY (M, Kv, S) -> V

下列各节包含若干常见签名算法，并示范这些密码学原语如何映射到上述 HTTP_SIGN 与 HTTP_VERIFY 定义。如何选择方法可通过显式算法（alg）签名参数（见 第 2.3 节）、通过引用密钥材料或由签名者与验证者之间的相互约定来传达。通过 alg 参数选择的签名算法MUST使用来自 “HTTP Signature Algorithms” 注册表（参见 第 6.2 节）的值。

NOTE: '\' line wrapping per RFC 8792

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

为便于签名验证，Signature-Input 字段值必须包含在生成签名基础的 @signature-params 值（见 第 2.3 节）中使用的相同序列化值。注意在结构化字段值中，列表顺序和参数顺序必须被保留。

签名者可以将 Signature-Input 字段作为尾部（trailer）包含，以便在处理完消息内容后进行签名。然而，由于中间体可能丢弃 trailers（参见 [HTTP]），因此建议仅将 Signature-Input 字段作为头字段包含，以避免签名被意外从消息中剥离。

单个 HTTP 消息中可以包含多个 Signature-Input 字段。签名标签在所有字段值中必须唯一。

NOTE: '\' line wrapping per RFC 8792

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

签名者可以将 Signature 字段作为尾部包含，以便在处理完消息内容后进行签名。然而，由于中间体可能丢弃 trailers（参见 [HTTP]），因此建议仅将 Signature 字段作为头字段包含，以避免签名被意外从消息中剥离。

单个 HTTP 消息中可以包含多个 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"}

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

尽管代理还可以在新签名的已覆盖组件中包含客户端原始消息的 Signature 字段值和 Signature-Input 字段，但由于在对签名值再次签名方面存在已知弱点（见 第 7.3.7 节），此做法不建议。代理能够验证客户端的签名；代理对消息所做的更改会在源服务器看到该消息时使现有签名失效。在本例中，源服务器可能在其签名上下文中拥有额外信息以解释 authority 的变化，但此做法需要额外的配置并需谨慎处理（见 第 7.4.4 节）。在其它应用中，源服务器可能无法验证原始签名本身，但仍希望验证代理已对客户端签名做出适当的验证。需要以安全方式表明签名已被成功处理或接收的应用需仔细指定替代机制以安全地发送此类信号。

Accept-Signature 字段是一个字典结构化字段（在 [STRUCTURED-FIELDS] 第 3.2 节 定义），包含针对目标 HTTP 消息的一个或多个所请求消息签名的元数据。每个字典成员描述一个签名请求。成员的键是在目标 HTTP 消息上下文中唯一标识所请求消息签名的标签。

NOTE: '\' line wrapping per RFC 8792

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

组件标识符列表指示要包含在所请求签名中的确切组件标识符集合，包括所有适用的组件参数。

created:

请求签名者生成并包含创建时间。作为签名请求发送时，该参数无关联值。

expires:

请求签名者生成并包含过期时间。作为签名请求发送时，该参数无关联值。

nonce:

请求签名者在目标签名中将此参数的值作为签名的 nonce 包含。

alg:

请求签名者使用来自 “HTTP Signature Algorithms” 注册表中所指示的签名算法来创建目标签名。

keyid:

请求签名者使用所指示的密钥材料来创建目标签名。

tag:

请求签名者在目标签名中将此参数的值作为签名的 tag 包含。

1. 将字段值解析为一个 Dictionary。

2. 对于字典的每个成员：

   11.

   将该键作为输出签名的标签，如 第 4.1 节 所述。

   12.

   解析该成员的值以获取已覆盖组件标识符集合。

   13.

   确定已覆盖组件是否适用于目标消息。若不适用，则该过程失败并返回错误。

   14.

   处理所请求的参数，例如签名算法与密钥材料。若任何所请求参数无法满足，或所请求参数与被认为适合目标消息的参数冲突，则该过程失败并返回错误。

   15.

   选择并生成完成签名所需的任何附加参数。

   16.

   对目标消息创建 HTTP 消息签名。

   17.

   创建 Signature-Input 与 Signature 字段值，并将它们与该标签相关联。

3. 可选地创建任何额外的、标签唯一且不在 Accept-Signature 字段中出现的 Signature-Input 与 Signature 字段值。
4. 将所有带标签的 Signature-Input 与 Signature 字段值合并，并将这两个字段附加到目标消息上。

通过此过程，应用于目标消息的签名必须具有相同的标签，必须包含相同的已覆盖组件集合，必须处理所有被请求的参数，并且可以拥有附加参数。

Accept-Signature 字段的接收者可以忽略任何不符合应用参数的签名请求。

目标消息可以包含 Accept-Signature 字段未指定的额外签名。例如，为了覆盖额外的消息组件，签名者可以创建第二个签名，该签名包含附加组件以及所请求签名的签名输出。

本文档定义了 HTTP 签名算法，IANA 已为此创建并维护了名为 “HTTP Signature Algorithms” 的新注册表。该注册表的初始值列在 第 6.2.2 节。对现有条目的后续分配与修改应通过 Specification Required 注册策略进行 ([RFC8126])。

该注册表中列出的算法为应用提供了可与本规范一起使用的一些可能的密码学算法，但这些条目既不代表可能算法的穷尽列表，也不表示针对任何特定应用场景的适用性。应用可以实现任何满足其需求的算法，前提是签名者和验证者能安全且确定地就该算法参数达成一致。当应用需要在运行时通过 alg 签名参数指示特定算法时，该注册表在参数值与具体算法之间提供映射。然而，使用 alg 参数时需谨慎，以避免各种算法混淆和替换攻击，详见 第 7 节。

Status 值应反映标准化状态以及相关利益群体（如 IETF 或安全相关标准化组织）的一般意见。当算法首次注册时，指定专家应在有共识认为算法总体上是安全时将 Status 字段设置为 "Active"，若尚未达成该共识则设为 "Provisional"（例如用于实验性算法）。"Provisional" 并不意味着该算法已知不安全，而是表示该算法尚未就其属性达成共识。如果将来发现某注册算法存在缺陷，可更新注册表条目并将算法标注为 "Deprecated" 以表示该算法已被发现存在问题。该状态不会阻止应用使用该算法；它只是为应用提供关于算法可能已知问题的警告。指定专家还应确保注册包含关于 Status 值的解释和参考，尤其对已弃用算法非常重要。

• 确保被注册的算法标识符所引用的算法以所有参数（例如盐、哈希、所需密钥长度）完整定义。
• 确保算法定义完整指定了 HTTP_SIGN 与 HTTP_VERIFY 原语函数，包括如何将所有定义的输入与输出映射到底层密码学算法上。
• 拒绝任何作为现有注册别名的注册。
• 确保所有注册遵循 第 6.2.1 节 中给出的模板；包括确保名称长度不过长且仍然唯一且易识别。

本规范通过在标识符字符串中包含主要参数来创建算法标识符，以便使算法名称唯一且易识别。然而，该注册表中的算法标识符应被视为整体字符串值，而非各部分的组合。换言之，实现者应理解 rsa-pss-sha512 指代一整套特定参数（哈希、掩码、盐等）所定义的算法；实现者不应通过解析标识符字符串来推断签名算法的参数，且一个参数组合的注册并不意味着其它组合也被注册。

本文档定义了签名参数结构（见 第 2.3 节），该结构可包含关于消息签名的元数据参数。IANA 已创建并维护一个名为 “HTTP Signature Metadata Parameters” 的新注册表，用于记录和维护在签名参数结构的成员值中定义可用的参数集合。该注册表的初始值列在 第 6.3.2 节。对现有条目的后续分配与修改应通过 Expert Review 注册策略进行 ([RFC8126])。

• 确保名称遵循 第 6.3.1 节 中给出的模板；包括确保名称长度不过长且在定义的功能范围内仍然唯一且可识别。
• 确保所定义的功能清晰且不会与其它已注册参数冲突。
• 确保对元数据参数的定义包括其在正常签名过程中的行为以及在 Accept-Signature 字段中使用时的行为。

本文档定义了对 HTTP 消息组件进行规范化的方法，包括可从目标消息上下文（而非 HTTP 字段）派生的组件。这些派生组件由一个唯一的字符串标识，称为组件名称。派生组件的名称始终以 "at" (@) 符号开头以将其与 HTTP 字段名区分开来。IANA 已创建并维护名为 “HTTP Signature Derived Component Names” 的新注册表，用于记录和维护非字段组件名称及用于产生其相关组件值的方法。该注册表的初始值列在 第 6.4.2 节。对现有条目的后续分配与修改应通过 Expert Review 注册策略进行 ([RFC8126])。

• 确保名称遵循 第 6.4.1 节 中给出的模板；包括确保名称长度不过长且在定义的功能范围内仍然唯一且可识别。
• 确保注册请求所表示的组件值可以从目标 HTTP 消息确定性地派生。
• 确保对注册请求所定义的任何参数有清晰记录，并说明其对组件值的影响。

指定专家应确保某注册项与现有派生组件定义足够区分，以证明其注册的合理性。

当将注册条目的状态设置为 "Deprecated" 时，指定专家应确保记录弃用原因以及有关如何迁移离开弃用功能的说明。

本文档定义了若干类型的组件标识符，其中一些在特定情况下可以带参数以提供独特的修改行为。IANA 已创建并现在维护一个名为 “HTTP Signature Component Parameters” 的新注册表，用于记录和维护参数名称、它们关联的组件标识符以及这些参数对组件值所做的修改。参数的定义必须定义其适用目标（例如特定字段类型、派生组件或上下文）。此注册表的初始值见 第 6.5.2 节。对现有条目的后续分配与修改应通过 Expert Review 注册策略（参见 [RFC8126]）进行。

• 确保名称符合 第 6.5.1 节 所示模板；这包括确保名称长度不过长，同时仍对其定义的功能保持唯一且易识别。
• 确保对该字段的定义能充分说明其与当时已知的其他参数之间的任何交互或不兼容性。
• 确保在参数改变组件值的情况下，带参数的组件标识符所定义的组件值能够从目标 HTTP 消息确定性地派生出来。

如果签名者对多个验证者使用相同的密钥，或在一段时间内对单个验证者重复使用相同的密钥，则该密钥的持续使用可被用于在消息发送到的验证者集合中跟踪签名者。由于加密密钥在功能上应当是唯一的，长期使用相同密钥强烈表明是同一方在对多条消息进行签名。

在许多应用中，这是一种期望的特性，使 HTTP 消息签名可用于将签名者作为身份验证的一部分向验证者证明自己。然而，这也可能导致签名者未意识到的非预期跟踪。为对抗此类跟踪，签名者可以对每个其通信的验证者使用不同的密钥。有时，签名者也可以在向给定验证者发送消息时轮换其密钥。这些方法并不否定在必要时采用其它反跟踪技术的需求。

HTTP 消息签名并不为签名所保护的任何信息提供机密性。HTTP 消息的内容，包括所有字段的值以及签名值本身，都以明文形式呈现给任何有权访问该消息的方。

如需在传输层提供机密性，可使用 TLS 或其等价方案，如 第 7.1.2 节 所述。

在向开发者提供有用的错误反馈与不向攻击者提供额外信息之间需要取得平衡。例如，一个天真但“有帮助”的服务器实现可能试图指示请求某资源所需的密钥标识符。如果有人知道谁控制该密钥，则可以将资源的存在与由该密钥标识的方相关联。访问此类信息可能被攻击者用于针对资源的合法所有者发起进一步攻击。

本规范的核心设计原则之一是，签名所覆盖的所有消息组件必须对验证者可用，以便重建签名基础并验证签名。因此，如果某个应用要求对特定字段进行签名，验证者将需要访问该字段的值。

例如，在具有中间处理器的某些复杂系统中，这可能导致一种令人惊讶的行为：为了避免破坏签名，中间体无法在将消息转发以供处理之前移除隐私敏感信息。缓解该特定情形的一种方法是中间体自行验证签名，然后修改消息以移除隐私敏感信息。此时中间体可以添加自己的签名以向下一个目的地表明进入的签名已被验证，如 第 4.3 节 的示例所示。

本节提供在文档示例签名中引用的加密密钥。这些密钥不得用于测试以外的任何用途。

每个密钥的密钥标识符在本规范的示例中反复使用。示例假定签名者与验证者能够明确地解引用此处使用的所有密钥标识符，并且所使用的密钥与算法适合签名所呈现的上下文。

openssl pkey -text

此命令在 OpenSSL 1.1.1m 上测试过所有示例密钥。注意某些系统无法直接生成或使用所有这些密钥，可能需要额外处理。所有密钥也以 JWK 格式提供。

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

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

{"message": "good dog"}

在此示例中，有一个位于资源前面的 TLS 终止反向代理。客户端不对请求进行签名，而是使用双向 TLS 发起调用。终止代理验证 TLS 流并根据 [CLIENT-CERT] 将客户端证书注入到 Client-Cert 头字段，然后对该字段应用签名。通过对该头字段进行签名，反向代理不仅可以证明其对初始请求的 TLS 参数进行了验证，还可以独立于客户端的操作向后端系统对自身进行认证。

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

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

xVMHVpawaAC/0SbHrKRs9i8I3eOs5RtTMGCWXm/9nvZzoHsIg6Mce9315T6xoklyy0y\
zhD9ah4JHRwMLOgmizw==

NOTE: '\' line wrapping per RFC 8792

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

{"hello": "world"}

内部服务可以验证代理的签名，从而信任客户端的证书已被适当处理。

HTTP 允许中间体和应用在不影响消息语义的情况下转换 HTTP 消息。HTTP 消息签名旨在在不同情况下对这些转换具有鲁棒性。

NOTE: '\' line wrapping per RFC 8792

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

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

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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

NOTE: '\' line wrapping per RFC 8792

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