摘要

  • RFC 1984 的核心不是一句“支持强加密”，而是拒绝把公开认证、私钥保管、用户恢复、签名权限和会话解密当成一种能力。
  • 跨国限制可能让厂商采用最弱共同机制；但相互防范的政府不会自然成为共同托管人，托管副本也不等于会话明文可恢复。

认证机构只需看见公钥

互联网架构委员会与通过现有 IETF 名录呈现的互联网工程指导组在 RFC 1984 中先承认了第三方的正当角色：认证机构可以签署“某个身份使用某把公钥”这一声明，政府也可以为公民与政府之间的交易运行认证机构。

这个角色不需要取得私钥。证书能证明认证机构签过某个绑定，却不能证明认证机构生成、保存或调用过用户私钥，更不能证明终端没有泄露。托管中心则直接保存或重建秘密能力。一个发表可验证声明，一个增加可执行主体；把它们并称为“信任”会掩盖真正的权限转移。

因此，证书不能单独证明唯一签署者。唯一性还依赖私钥生成、保管、访问控制、设备完整性和撤销记录。即使证书始终有效，复制私钥也会改变签名的证据含义。

数据恢复必须回答“为谁恢复”

RFC 1984 没有把所有恢复机制都否定掉。用户可能愿意为长期保存的文件保留一份可恢复密钥，以承担额外托管风险换取业务连续性。文件丢失风险与会话结束后的访问需求并不相同；只用于交谈的密钥未必需要长期存在。

强制访问把选择权移走。若额外副本只掌握在政府手里，而数据所有者丢钥时无法调用，它就不能兑现“为客户恢复”的产品承诺。数据库里有一份副本，只证明某处存过一个秘密，不证明副本仍是当前版本、持有人能合法取用、内容未泄露、删除已完成，或目标数据确实由它保护。

恢复因此至少有四张不同收据：密钥是否入库，谁能批准取用，所有者能否恢复数据，访问后是否留下不可抵赖的审计轨迹。少任何一张，都不能用“已托管”概括系统状态。

签名密钥一旦共享，排他性就已经消失

签名与认证密钥的任务不是隐藏内容，而是让接收者把一个行为归给某个主体。若第三方也能调用相同私钥，第三方便获得制造“有效行为”的能力。合法持有人日后可以说签名来自托管方；被告也可以质疑证据由掌钥政府生成。

问题不只在于第三方会不会作恶，而在于验证者原本依赖的前提已经改变。签名密钥的价值来自受控排他性，托管则把排他性改成共同控制。给保密数据设置恢复密钥，并不构成把签名密钥一并托管的理由。

最弱共同机制如何进入产品

RFC 1984 对国际限制的观察是一条产品工程规律。面对多个国家互相冲突的要求，跨国厂商可以选择一个都能接受的弱机制，以减少版本、测试和支持成本。于是最严限制不只影响本国，还可能成为全球产品的安全上限。

另一条路是维护分区版本。它能为部分市场保留更强保护，却制造版本漂移、兼容分支、更新责任和受限版本越界流通的风险。出口许可只能说明某一项目在某些条件下获准；它不能证明同一构建全球可得、客户已安装、版本可互操作，或产品整体安全。

托管也不是跨国折中。两个把对方视作潜在对手的政府，不会愿意彼此交出访问密钥。所谓共同托管需要先解决司法管辖、密钥分享、授权和责任问题，而这些信任条件可能比原始商业交易更难建立。

解开外层，不代表看见消息

合规的托管加密可以只是外层。使用者先用另一机制加密，再套上可托管的外层；托管方解开后得到的仍是密文。一次成功解密也只证明某段密文与某组密钥、状态相容，不证明所有会话都采用该密钥，更不证明明文作者、合法授权或商业可信度。

RFC 1984 还把长期私钥与会话状态分开。使用前向保密时，事后取得长期密钥未必能还原过去会话；攻击者可能必须在交谈进行时控制终端。原文明确说这是简化描述，因此正确结论不是“所有前向保密都不可托管”，而是“长期密钥副本不能单独证明历史明文可恢复”。

密钥长度只回答一个问题

短密钥可能随着算力增长而失效，尤其当内容需要保密多年。能被一个资源充足主体攻破的系统，也可能被其他主体攻破。但长密钥并不是系统安全证书：随机数、实现、端点、协议组合、密钥保管和更新都可能失败。

2015 年，IETF 状态变更记录显示原文在不改写的情况下升为最佳当前实践，今天列为 BCP 200。这证明技术共同体后来确认了文档地位，不证明任何政府改法、厂商部署或系统合规。

RFC 1984 留下的不是一张万能答案，而是一套拒绝替代的问法：认证不是保管，保管不是所有者恢复，恢复不是作者身份，长期密钥不是会话明文，许可不是全球可用，密钥长度也不是系统安全。

一手记录

RFC 1984 纯文本 · RFC 1984 HTML · RFC Editor 记录 · IETF 文档记录 · 状态变更 · 状态历史 · IESG 表决 · IAB 介绍 · IESG 介绍 · 现有 IETF 名录条目