跳到主要内容

1.4. Application of HTTP Message Signatures (HTTP 消息签名的应用)

1.4. Application of HTTP Message Signatures (HTTP 消息签名的应用)​

HTTP 消息签名旨在成为适用于多种情形与应用的通用工具. 为正确且安全地应用 HTTP 消息签名, 本规范的应用或配置文件必须至少规定下列各项:

  • 预期并要求包含在被覆盖组成部分列表中的组成部分标识符 (第 2 节) 与签名参数 (第 2.3 节) 的集合. 例如, 授权协议可以强制覆盖 Authorization 字段以保护授权凭据, 并强制签名参数包含 created 参数 (第 2.3 节), 而期望语义相关 HTTP 消息内容的 API 可以要求定义于 [DIGEST] 的 Content-Digest 字段存在并被覆盖, 以及强制 tag 参数 (第 2.3 节) 取特定于所保护 API 的值.

  • 任何必需或预期的被覆盖组成部分字段或参数的预期 Structured Field 类型 [STRUCTURED-FIELDS].

  • 获取用于验证签名的密钥材料的手段. 应用通常使用签名参数的 keyid 参数 (第 2.3 节) 并定义从此解析密钥的规则, 尽管适当密钥也可能通过其他方式获知, 例如预注册签名者密钥.

  • 签名者可使用且验证者可接受的允许签名算法集合.

  • 确定用于验证签名的签名算法对密钥材料与消息上下文适当的手段. 例如, 过程可以使用签名参数的 alg 参数 (第 2.3 节) 显式声明算法, 从密钥材料推导算法, 或使用签名者与验证者预先约定的算法.

  • 确定用于签名的给定密钥与算法对消息上下文适当的手段. 例如, 仅期望 ECDSA 签名的服务器应知道拒绝任何 RSA 签名, 或期望非对称密码学的服务器应知道拒绝任何对称密码学.

  • 确定从 HTTP 消息及其应用上下文派生消息组成部分的上下文的手段. 虽然通常是目标 HTTP 消息本身, 上下文也可包括应用通过配置获知的附加信息, 例如外部主机名.

  • 若需使用第 2.4 节提供的机制在请求与响应之间绑定, 则请求消息与响应消息中提供此类绑定属性所需的全部元素.

  • 当签名无效, 密钥材料不当, 有效时间窗口不符合规范, 无法计算组成部分值或签名验证过程中发生任何其他错误时, 验证者向签名者返回的错误消息与代码. 例如, 若签名用作认证机制, HTTP 状态码 401 (Unauthorized) 或 403 (Forbidden) 可能适当. 若响应来自 HTTP API, 状态码 400 (Bad Request) 等的响应可包含更多细节 [RFC7807] [RFC9457], 例如指示使用了错误的密钥材料.

在选择这些参数时, HTTP 消息签名的应用必须确保验证者能够访问重现签名基所需的全部必需信息. 例如, 反向代理后的服务器需要知道原始请求 URI 才能使用派生组成部分 @target-uri, 尽管明显目标 URI 会被反向代理改变 (另见第 7.4.3 节). 此外, 在响应中使用签名的应用需要确保接收签名响应的客户端能够访问消息的全部已签名部分, 包括服务器使用 req ("request-response") 参数 (第 2.4 节) 签名的请求的任何部分.

此类配置文件细节的详细内容属于应用范畴, 在本规范范围之外, 不过第 7 节讨论了若干附加注意事项. 特别地, 在选择必需的组成部分标识符集合时, 必须谨慎确保覆盖对应用充分, 如第 7.2.1 与 7.2.8 节所述. 本规范仅定义应用完整安全系统的一部分. 基于该工具构建完整安全系统时, 对整个系统 (HTTP 消息签名为其中一部分) 进行安全分析很重要. 历史系统如 AWS Signature Version 4 [AWS-SIGv4] 可为如何将类似机制应用于应用提供启发与示例, 但审阅此类历史系统不能替代对 HTTP 消息签名应用的安全分析.

最后于 更新