寻求HTTP请求/响应载荷签名标准：支持Header存储与PKI验签

1. HTTP Message Signatures（RFC 9421） #

这是专门为HTTP请求/响应设计的签名标准，完全契合你的所有要求：

• 签名直接放在HTTP头中（通过Signature和Signature-Input头字段），完全不需要修改请求或响应的载荷结构
• 原生支持不可否认性：采用非对称加密签名时，发送方用私钥签名，接收方通过对应公钥验证，一旦签名有效，即可确凿证明消息由持有私钥的发送方发出，无法抵赖
• 支持PKI式的无预置公钥验证：签名时可以携带完整的X.509证书链（通过cert参数嵌入Signature-Input），接收方只需信任根CA，就能自动验证证书合法性，进而提取公钥完成签名验证，无需手动提前配置对方公钥
• 高度灵活：可以精确指定要签名的HTTP组件（比如请求方法、路径、载荷哈希值、特定请求头等），既保证载荷完整性，又能涵盖HTTP上下文信息，强化不可否认性

核心实现细节 #

• 用Content-Digest头（RFC 9530）对载荷计算哈希并存储，签名时将这个头纳入签名范围，既不用修改原始载荷，又能确保载荷未被篡改
• 示例签名头格式：

  Signature-Input: my-sig=("@method" "@path" "content-digest");created=1690000000;keyid="https://myapp.com/keys/user1";cert="MIICXTCCAgWgAwIBAgIU..."
  Signature: my-sig=:abc123xyz...:
  

2. JWS（JSON Web Signature）结合HTTP头传输 #

如果你的场景以JSON载荷为主，JWS也是符合标准的选项：

• 签名结果放在HTTP头（比如自定义X-JWS-Signature头，或复用Authorization头），原始载荷保持原样传输，无需修改
• 支持携带X.509证书链（JWS的x5c参数），接收方通过CA验证证书后获取公钥，无需手动预置
• 非对称签名模式下，同样能提供不可否认性，私钥签名的JWS无法伪造，发送方无法否认发送行为

不过相比RFC 9421，JWS更聚焦于JSON内容，而RFC 9421是为HTTP全场景设计的，适配性更广。

结论 #

优先选择HTTP Message Signatures（RFC 9421），它是当前最贴合你需求的标准方案：无需改动载荷、签名置于请求头、支持PKI自动验证公钥、原生保障不可否认性。

内容的提问来源于stack exchange，提问作者Dojo