RFC 3125：有效签名仍然需要一份策略

摘要

数字签名可以回答一个精确问题：给定密钥和算法，这些字节能否通过验证？合同、订单或发票还会追问：证书是否适用于这个用途，签名是否发生在允许期间，签名者表达的是批准、接收还是别的承诺，撤销信息与时间戳是否满足要求，谁有权认可结果？

2001 年 9 月发布的实验性 RFC 3125，把这些条件称作 signature policy。策略规定创建与验证规则，使“在该策略之下有效”成为可判断的命题。某个法律或契约环境可以承认一项策略满足其需要；RFC 没有替那个环境做出承认。

文档区分策略发布者、签名者、验证者、仲裁者和信任服务提供者。发布者定义面向业务需要的技术与程序规则；签名者承诺按所引用的策略签署；验证者必须按它检验；仲裁者可能在争议中重做验证。共同使用一个策略对象，不等于共享同一权力。

策略必须由 Object Identifier 标识，必须存在一份规范，而且其中一份确定版要有唯一二进制编码。签名者提供用约定算法计算的确定版 hash，验证者重新检查。

这解决了名称歧义。“发票签名策略”可能有不同版本、摘要或译文；OID 选择身份，hash 把处理绑定到确切字节。可选的 ASN.1 结构以 DER 编码，使机器处理的版本获得确定表示。

但 OID 不是批准章。hash 相同只能证明双方引用同一份编码规范，不能证明策略发布者对这笔交易有管辖权，线下程序已经执行，或法院与交易伙伴承认它。因此 RFC 同时要求人类可读形式，让制度能够评估策略是否适合自身环境。

结构化策略含签署期、共同规则和承诺规则。签署期有开始时间和可选结束时间。一次签名即使数学上正确，也可能因为在期外创建而不符合策略。

共同规则可以规定签名者/验证者义务、证书信任、时间戳信任、属性信任、算法约束和扩展。承诺规则针对某种承诺补充或选择条件。批准与收讫可以要求不同证据；若承诺隐藏在消息语义里，还可使用处理“无显式承诺类型”的规则。

验证者必须先选中策略版本和承诺，再建立信任路径。同一证书链可能适合一个用途而不适合另一个；同一密钥在算法期限前后也可能获得不同结论。RFC 把这些差异变成明确输入，而不是模糊例外。

认证与注册机构、资料库、时间戳机构、证书状态应答者和属性机构都可能参与。策略可选 trust point、路径长度、证书政策、名字约束、撤销资料、时间证据与角色属性。

每项服务只回答局部问题。证书把密钥与身份主张连接起来；状态响应描述某个时间下的证书状态；时间戳证明数据早于某个受信时间形成；属性证明一个角色或资格。它们都不会独自决定交易承诺。

可复现的验证必须保存使用了哪份回复、来自哪个服务、何时取得、由哪个规则消费。若只留下绿色“valid”，仲裁者就无法还原验证路径。

有些条件能由 CMS 直接检验，例如必需的签名/未签名属性、证书引用与证书材料。有些条件则属于密钥保管、内部授权、人员操作或见证流程。

策略 hash 证明识别了哪本规则书，不证明书中每项程序都发生。签名者“按此策略签署”的表示是一项承诺，不是全知遥测。程序证据需要从审批系统、密钥管理和操作记录中另行取得。

因此，“在 OID X 下有效”不能自动改写为“有权签署”“对方已接受”“款项已结算”或“义务已履行”。这些判断有不同的数据与负责人。

RFC 强调私钥保护，也指出算法强度会随时间下降，建议实现保持模块化。策略还可约束算法与密钥长度。

多年后的验证需要知道签名时适用哪版策略、当时有哪些时间证据、算法迁移如何规定。后来弃用某算法，并不能单独回答旧证据如何处理。

RFC 3126 描述长期签名格式，RFC 3161 提供时间戳协议；RFC 2630、2634、2459 与 2560 构成当年的 CMS、S/MIME、PKIX 与状态背景；RFC 5280 与 5652 是后来的延续。这些来源解释组件，却不证明某个 RFC 3125 部署存在。

一致性条款要求签名与验证系统按 OID 引用的策略处理。它规定声称一致的参与者应该怎么做，不说明现实中有多少参与者。

RFC 3125 可由来源证明的贡献，是把策略做成一条可追踪链：OID、确定版、唯一编码、hash、承诺规则与信任条件。采用率、互操作、法律效果和争议结果需要其他档案。

完整证据包应保存原文、签名、证书、OID、策略字节、hash、签署期、承诺、路径、撤销、时间戳、属性、算法与验证器输出，再附上承认策略的契约或规则。密码学闭合一个等式；策略说明哪一个等式值得制度采信。