摘要

  • LAMPS 的一次签名证书草案用 signedDocumentBinding 把证书限定到一组签名输入，但它明确说明：即使验证者没有检查这项绑定，普通密码学验签仍可成功。signature_valid 与 dataTbsHash 比对成功必须是两张独立回执。
  • 证书还代表 CA 声称私钥为一次操作新建、只使用一次并随即销毁。这是签发流程声明，不是扩展字段直接观察到的事实。无到期时间与无吊销渠道减少了一类生命周期状态，却把长期可信度更多地转移给 CA 政策、签发证据与档案保存。

一张证书把 notAfter 写成 9999 年最后一秒，又携带 noRevAvail，说明没有吊销信息可查。证书里的 signedDocumentBinding 保存了某组待签名数据的摘要。普通验签结果为真。

这些事实中，哪一个证明系统真的拿当前文件核对过那项绑定？没有一个。

第 02 版 One Signature Certificates 正是在处理这种边界。它设想签名时即时生成私钥与证书，私钥只完成一次数字签名，然后立即销毁。证书绑定到相应内容，通常没有实际到期日，也不提供吊销机制。这样做希望减少长期复用私钥和不断增长的吊销状态，为日后验证缩小依赖面。

该文档是 LAMPS 工作组在 IETF stream 中的活跃 Internet-Draft，目标状态为 Proposed Standard。第 02 版日期为 2026 年 7 月 1 日，2027 年 1 月 2 日到期；Datatracker 标为 WG Document，IESG 状态是 I-D Exists。它不是 RFC，也不能证明已有 CA 采用、某把密钥确实销毁、验证软件确实检查绑定，或档案多年后仍可通过验证。

一张证书承载了几种不同性质的声明

新扩展名为 signedDocumentBinding。其 ASN.1 结构包含 dataTbsHash、hashAlg 与可选 bindingType。前两者给出待签数据的摘要及摘要算法，后一项说明怎样从某种签名格式中得到需要哈希的字节。

这是一项可以重新计算的范围声明：此证书面向这组签名输入。扩展同时表达另一种流程声明：CA 说关联私钥只为这份绑定文件生成，完成签名后即被销毁。草案要求把具体流程与销毁保证写入适用的证书政策。

两种证据不能混为一谈。接收者可以重建字节、计算摘要并比较 dataTbsHash，却不能透过这个摘要看到远程签名服务是否真的临时生成密钥，是否阻止了第二次调用，是否清除了备份、复制件与崩溃转储，或是否执行了所引用的 CP/CPS。

因此回执至少要分别保存：扩展原值、绑定输入的精确哈希、证书政策标识及版本、签发交易、密钥生成事件、唯一授权的签名请求、销毁命令与独立观察到的销毁结果。把这些压成“一次性证书有效”，事后便无法分辨是密码学事实还是 CA 的流程承诺。

验签可以成功，而绑定从未检查

第 02 版的安全考量直接写明：成功完成密码学验签，并不要求先验证 signedDocumentBinding。所以即使绑定没有被检查，签名也可能正确通过。依赖方“应当”把当前签名内容与扩展中的 dataTbsHash 比较，以限制证书替换和非预期复用。

这正是运营接口最容易丢失的信息。通用密码库按照签名格式和证书公钥返回成功；上层应用把这个布尔值直接变成批准。证书可能原本为另一组输入签发，或者本应只用一次的密钥实际产生了另一份仍能数学验证的签名。普通验签并不回答证书用途是否越界。

决策记录需要至少两项状态。signature_valid 表示签名原语与格式核验结果；document_binding_match 表示系统解析了哪一种 bindingType、重建了哪些字节、使用哪个摘要算法、读取到哪个预期 dataTbsHash，以及最终是否相等。

若没有执行第二项，其状态只能是 not_checked，不能继承第一项的绿色结果。是否把 not_checked 视为拒绝，可以由采用者的 profile 决定；但任何真正依赖“一证一文”约束的业务，都必须把草案的 SHOULD 转成自己的强制政策，并证明归档复验、批量验证、移动端与外部验证服务都执行了同一检查。

bindingType 决定“同一文件”究竟是哪组字节

当 bindingType 缺省时使用 default binding。它对实际送入签名算法的数据进行哈希：XML 的 SignedInfo、CMS 的 DER SignedAttributes，或者其他格式对应的签名输入。

难点在于某些签名结构会包含签名者证书或证书摘要，而证书自身又保存 dataTbsHash。如果双方互相包含，就出现先生成哪一个都依赖另一个的循环。第 02 版因此禁止在这类情形使用默认绑定，并为不同格式规定排除规则。

CAdES 绑定从 DER SignerInfo 中移除 SigningCertificate 与 SigningCertificateV2 属性后再计算。XAdES 绑定对 SignedInfo 做规范化，同时移除指向 SignedProperties 的 Reference，其余字符、空白与换行必须保留。JWS 和 COSE 则只绑定 payload，把受保护与不受保护的 header 都排除在 dataTbsHash 之外。

所以人眼看到的同一份内容，在不同 binding type 下可能得到不同摘要。JWS 的 payload 绑定一致，也不证明 alg、key identifier、证书引用或其他受保护 header 相同；这些仍由 JWS 验证和应用政策负责。

运营回执应记录格式、binding 标识、规范化/排除规则版本、实现构建号，以及重建后字节的独立哈希。草案为未来 IANA registry 提出的要求是确定、无歧义并解释循环依赖；一个已经注册的名称仍不能证明两个实现生成了完全相同的字节串。

“没有吊销可用”不等于“无需纠错”

草案建议把 notAfter 设为 99991231235959Z，表示终端证书没有明确到期时间；同时建议加入 RFC 9608 的 id-ce-noRevAvail，告诉依赖方本证书不提供吊销机制。

这两个字段都不证明为什么可以不吊销。其合理性依赖整个流程：密钥只短暂存在，只签过一次且随即销毁；后来出现的吊销原因通常不应推翻已经在可信时间成立的历史签名。长期复用密钥的未来暴露面很大，真正销毁的一次性密钥则小得多。

但风险没有消失，只是集中到签发时刻。密钥是否真的全新？系统是否只接受一个授权请求？HSM 复制、备份、重试队列、内存镜像或故障恢复是否留下副本？销毁是否发生在任何未授权使用之前？CA 所引用的政策是否要求、记录并审计了这些控制？

noRevAvail 只能说明依赖方不应期待这张证书的 CRL 或 OCSP。它不能替这些问题作证。验证器还必须区分“profile 有意不设吊销机制”“网络暂时取不到吊销数据”和“软件根本不认识此 profile”。

签发时间继承了时间戳的权力

长期验证通常需要 best-signature-time，也就是最早能可信证明签名已经存在的时刻。RFC 3161 使用独立时间戳机构提供一种路径。第 02 版则认为：一次签名证书与签名同时创建，所以证书签发时间可以建立签名时间，CA 承担类似时间戳机构的角色。

这种耦合能减少对象，但也扩大 CA 的证据权力。签发者不再只说明某个身份与公钥的关系；它还在说明唯一签名发生的时间、证书绑定到哪组内容、私钥是否临时生成，以及签名后是否立即销毁。

采用者应明确这项权力来自何处。回执要写清 best-signature-time 是来自证书签发、RFC 3161 时间戳、Signature Validation Token、档案证据记录，还是其中若干项。应保留时钟来源、签发交易、政策与审计记录；不能只看到语法正确的 notBefore 就把它当成独立第三方时间证明。

终端证书活到 9999 年，CA 不会因此永生

草案明确提醒：终端证书没有到期日，不等于 CA 信任没有到期日。初次验证通常假设在 CA 证书有效期内完成。

多年后重新验证，可能需要把 CA 的密钥和身份作为本地 trust anchor 保存，也可能依赖交叉认证、证书库中的续期 CA 证书或新的信任配置。如何在 CA 证书有效期之外继续建立信任，被草案列在范围外。

因此 99991231235959Z 只移除了一项终端到期检查，并未保存到 9999 年的完整路径。算法会老化，trust store 会更替，CA 会轮换或退出，政策会更新，档案会迁移，验证软件也会消失。原始签名字节、证书链、政策文本、时间证据、当时的验证结果与信任锚历史仍须可恢复。

采购所谓“永久有效签名”服务时，应询问它会导出哪些证据、脱离原服务后谁能复验、CA 信任怎样延续、算法不再可接受时如何处理，以及在没有终端吊销渠道的情况下，如何纠正一次性密钥审计失败造成的业务决策。

文件绑定成立，仍不等于外部结果成立

完整通过绑定检查，只能证明一项窄关系：此证书在这个 hash algorithm 与 binding rule 下，为这组重建出的签名输入签发。它不证明签署者理解内容、具有这笔交易的权限、看到了最终显示版本，或让承诺的外部动作真正发生。

一次性密钥也不会自动产生“不可否认”。身份核验、同意仪式、委托权限、显示完整性、应用政策、法律环境、交付与档案托管都是独立判断。若签名触发付款、软件发布、凭证签发或监管记录保存，就必须同时保留 effect receipt。

最小而可靠的做法，是给证据链分类型：证书语法；路径与信任；签名数学；文件绑定；CA 流程；密钥生命周期；可信时间；签署身份与权限；应用决定；持久保存；外部结果。一次签名证书可以缩小前半段，却不能替后半段作证。