摘要

  • 9 月 28 日提交的个人 Internet-Draft 主张：若代理委托记录要留作多年后的证据，就要连同签名密钥通往信任锚的路径和可信时间依据一起保存。
  • 草案提出的是后量子过渡要求，不是已经生效的 IETF 规范；它指出长期审计可能遇到的缺口，并未报告量子攻击或断言当前 OAuth 在线验证失效。

今天，一项代理请求带着发行方签发的凭证到达服务。服务通过 TLS 连接下载发行方密钥集，找到验签公钥，核对凭证并按自己的规则放行。这个当场判断可以完全合理。可是多年以后，审计者只拿到凭证和一把公钥：当初那次连接由哪条证书链保护？链上的算法是什么？这把钥匙何时被发行方使用？如果这些材料当年没有另行留存，今天“签名有效”的结论无法自动转成关于过去的完整证明。

V. K. Uppalapati 于 9 月 28 日提交的《Post-Quantum Requirements for Software and AI Agent Identity》第 00 版，把上述差异作为核心切口。IETF Datatracker 当前标为 I-D Exists；它是个人提交、意向状态为 Informational，并不是 WIMSE 工作组通过的文本，更不是 RFC。作者考察现有代理身份机制后认为，经 TLS 获取的 OAuth 密钥集与信任锚之间的绑定通常不会被要求随委托凭证归档。这个“尚无普遍要求”是作者的研究判断，不能扩大成所有部署都没有保存证据。

草案没有否定在线 TLS 的作用。连接建立时，TLS 可使取钥的客户端确认服务器身份；问题发生在连接结束之后。一个组织可以把下载到的密钥集和运输层证书链一同留下，但若将来要把材料交给外部审计者，对方还得相信这家组织没有把别的密钥集拼进档案。由独立可验证的签名绑定来证明密钥来源，举证强度不同。发行方自己写一句“这是我的钥匙”也不能替代对该绑定的独立证明。在线准入与可向第三方说明的历史来源，必须分开设计。

还有一道不能由密钥路径回答的题：时间。签名在合适的验证路径下可以指向一把签名密钥，却不会自行记录可靠的签署时刻。RFC 3161 的时间戳服务可对数据摘要给出有签名的存在时间声明；RFC 4998 则给出长期证据在算法或证书失效前续接保护的办法。这些机制今天有用，但时间戳本身也是签名。如果未来某种计算能力足以攻破其中使用的传统公钥算法，一张旧式时间戳不能仅凭印着旧日期就获得后量子保证。因此新草案提出尽早锚定记录、在尚未确定的过渡日期之后使用后量子强度的锚，并持续续期。它既没有替 IETF 定日期，也没有宣称这种量子计算机已经出现。

把代理末端凭证改成后量子签名，仍不能绕开上游的可信链。草案指出：末端再强，如果签发路径最后落在传统算法保护的根上，整条路径的抗量子性质就不能按末端计算。通过传统 Web PKI 取得 OAuth 密钥集也有相似的历史证据问题。先更换末端算法可以为迁移铺路，却不能补回过去从未保存的连接路径或可信时间。草案要求未来机制让每一跳所用算法对验证者可见，并随证据保存；能否成为广泛互通的规则尚未可知。

这不是“验签通过就等于有人授权”的故事。发行方签了某项声明，不等于人类委托、接收方授权政策、记录时间与密钥来源都已被证明。新草案挑出的，是操作时最容易被忽略的一环：服务在连接中相信一把钥匙的依据，未必跟着委托记录走到档案室。

资料来源