1. Introduction (引言)
1. Introduction (引言)
消息完整性 (message integrity) 与真实性 (authenticity) 是许多 HTTP 应用安全运行所依赖的关键安全属性. 应用开发者通常通过在 TLS [TLS] 上运行其应用来依赖传输层提供这些属性. 然而, TLS 仅保证在单个 TLS 连接上的这些属性, 客户端与应用之间的路径可能由多个独立的 TLS 连接组成 (例如, 若应用托管在 TLS 终止网关之后, 或客户端位于 TLS 检查设备之后). 在此类情况下, TLS 无法保证客户端与应用之间的端到端消息完整性或真实性. 此外, 某些运行环境存在障碍, 使得使用 TLS (例如从浏览器呈现客户端证书) 或使用提供消息真实性所必需的特性变得不切实际. 再者, 某些应用需要将更高级别的应用专用密钥与 HTTP 消息绑定, 而与所使用的任何 TLS 证书无关. 因此, 尽管 TLS 可以满足许多基于 HTTP 应用的消息完整性与真实性需求, 它并非普适方案.
此外, 许多应用需要能够在对线上的 HTTP 消息仅有不完整了解的情况下生成并验证签名, 这是由于在签名或验证时使用会改变或向应用隐藏消息部分的库, 代理或应用框架所致. 这些应用需要一种手段来保护对应用最相关的消息部分, 而无需违反分层与抽象.
最后, 诸如 JSON Web Signature [JWS] 等基于对象的签名机制要求完整传递所签名的确切信息. 将此类技术应用于 HTTP 消息时, 需要将 HTTP 消息的元素在对象载荷中直接重复或通过包含哈希来重复. 这种做法会引入复杂性, 因为在验证签名时需要仔细核对重复信息的一致性.
本文档通过使用 HTTP 消息上的分离式签名 (detached signature), 定义了一种为 HTTP 消息的组成部分提供端到端完整性与真实性的机制. 该机制允许应用仅对消息中对应用有意义且适当的组成部分创建数字签名或消息认证码 (MAC). 严格的规范化规则确保验证者即使消息以 HTTP 允许的多种方式被转换后仍能验证签名.
本文档所述签名机制由三部分组成:
-
用于 HTTP 消息的不同协议元素及其他组成部分的通用命名法与规范化规则集, 用于创建签名基 (signature base) (第 2 节).
-
通过应用密码学原语, 使用该签名基对 HTTP 消息组成部分生成并验证签名的算法 (第 3 节).
-
将签名及相关元数据附加到 HTTP 消息以及从 HTTP 消息解析所附签名与元数据的机制. 为此, 本文档定义
Signature-Input与Signature字段 (第 4 节).
本文档还通过 Accept-Signature 字段 (第 5 节) 提供了一种在后续一条或多条消息中协商使用签名的机制. 该可选协商机制可与任一方采用的机会性或应用驱动的消息签名一并使用.
本文档定义的机制是用于构建应用整体安全机制的重要工具. 该工具包提供某些强大能力, 但不足以单独构成完整的安全叙事. 特别地, 第 1.4 节所列需求与第 7 节讨论的安全注意事项对本规范的全体实现者至关重要. 例如, 本规范未定义直接覆盖 HTTP 消息内容 (message content) (定义见 [HTTP] 第 6.4 节) 的手段, 而是依赖 Digest 规范 [DIGEST] 提供消息内容的哈希, 如第 7.2.8 节所述.