摘要

  • draft-mcewan-adkm-problem-statement-00 研究的是：稳定标识符如何在密钥不断演化时保持可验证连续性，同时不要求每次变化都由外部行政签发者重新授权，也不强制进入一个全球共识系统。
  • 最关键的边界在于，现用密钥可以有权签署日常操作，却仍然不应当然有权独自建立任意未来密钥状态；否则一旦现用密钥失陷，攻击者便能把短期控制变成合法外观下的永久继承。
  • 可审计系统需要分别留下日常签名、继任授权、恢复参与、历史有效性、新鲜度、冲突观察、应用决策与实际结果的凭据。

凌晨两点十四分，一把服务密钥仍在正常签署请求。两分钟后，值班人员发现它可能已泄露。再过两分钟，一份格式正确、签名有效的状态事件抵达：原密钥批准了一把新密钥，随后宣布自己退役。

链条整齐，摘要一致，签名全部通过。

但如果原密钥已经落入攻击者手中，这条漂亮的恢复记录恰恰可能是持久化手段。攻击者不只借用了今天的权力，还利用今天的权力制造了明天的权力。系统若把“验签成功”直接等同于“有权指定继任者”，就会把入侵写成一次合规轮换。

2026 年 9 月 20 日发布的个人 Internet-Draft《Autonomous Decentralized Key Management Problem Statement》把这个问题划出了一条清楚的技术边界。它讨论稳定标识符如何跨越例行轮换、紧急替换、门限变化、委托、恢复与撤销，并让依赖方验证一条密码学相连的事件历史。它没有宣布解决方案，也没有选择事件格式、观察者网络、账本、存储方式或恢复算法。

同一把密钥，不是同一种权力

很多系统把授权压缩成一个布尔值：签名有效，或者无效。草案的术语迫使实现者展开这个布尔值。Key State 不只是一把公钥，而是某一时刻有效的公钥集合、签名门限、角色与其他授权参数。Key Event 是建立或改变状态的已认证声明。Controller 只能按照协议规则批准被允许的转换。

因此，一把密钥可以被允许签署应用消息，却不能单独降低门限；可以轮换一把业务密钥，却需要恢复角色共同参与；可以委托受限角色，却不能删除所有其他控制者；可以撤销自己，却不能独自任命不受限制的继任者。这里没有唯一正确的组织设计，只有一个不可隐藏的问题：每一种转换究竟调用了哪一类权力？

证据面 能回答的问题 单独不能回答的问题
现用密钥签名 这把密钥是否签过这些字节 它是否足以批准这类状态转换
转换政策 哪些角色、门限与版本适用 输入是否足够新鲜、密钥是否已失陷
相连事件历史 当前状态是否沿允许路径形成 它是否为最新且唯一的路径
恢复批准 独立恢复能力是否参与 所有恢复能力是否仍彼此独立
一致性证据 检查范围内是否发现冲突历史 世界上是否不存在尚未被发现的分支
应用决策 本地政策是否接受该状态用于某次操作 操作是否真的成功并产生预期结果

一条有效历史，仍可能是旧历史

草案定义的 Local Evidence Verification 允许依赖方只凭本地可得的密码学材料，验证展示出来的状态以及通向该状态的已认证历史，而不必同步查询一个指定权威。这对边缘节点、间歇联网环境和隔离网络很重要。

定义同时明说：本地验证本身不能证明这就是最新状态。便携的证明可以验证一条链，却不会随身携带全球时钟。它也不能保证别处没有更晚的合法转换，更不能保证控制者没有向另一群依赖方展示第二条同样可验的历史。

所以必须把三个问题分别保存：历史能否通过密码学验证；状态是否足够新鲜；是否观察到冲突历史。低风险诊断设备可以接受昨天的检查点，金融签名服务可能要求一分钟内的观察者记录与多方交叉检查。两者使用同一事件格式，并不需要假装存在同一风险容忍度。

先写清楚什么叫终局失陷

恢复方案通常只画成功路径：现用密钥丢失，恢复能力启动，新密钥接管。草案指出了不能靠图省略的边界：如果攻击者取得了协议认定足以授权未来状态的全部秘密与恢复能力，任何密钥状态协议都无法保证恢复。

因此，运营方必须在事故前写出失陷矩阵：仅现用业务密钥失陷；多签门限中的一把失陷；现用密钥加一份恢复材料失陷；设备被控但离线恢复能力安全；全部业务与恢复能力失陷；恢复期间观察者被隔离。每一行都要说明还能否恢复、谁必须参与、需要何种等待或观察、何种组合属于终局状态。

“支持密钥轮换”不能代替这张矩阵。由失陷密钥自行完成的轮换，很可能只是攻击者把控制权迁入新钥匙。

不采用全球总序，也不能假装没有分叉

ADKM 不要求所有事件进入一个全球总序。这避免了把标识符连续性绑定到某个共识系统的可用性、治理与最终性上。但代价必须透明：恶意或失陷的控制者可能向不同依赖方出示两条有效历史。

草案列出独立观察者、gossip、交叉检查和透明度机制等候选方式，却不选择其中任何一种。Certificate Transparency 与 Key Transparency Architecture 说明日志、树头、一致性证明、监测和 gossip 如何让不一致视图更容易被发现；它们并不能把“没有报告冲突”变成“全世界只有这一条历史”。

观察者凭据必须附带范围：谁在何时观察到哪个承诺；记得哪一个前态；同哪些对等方或日志交叉检查；是否可能处于网络分区；选择性披露或串通是否能隐藏分支。只保存“未发现分叉”，却不保存检查边界，等于保存了一句无法审计的话。

相邻体系不是失败的 ADKM

RFC 5280 与 RFC 6960 在证书颁发机构、信任锚和状态服务的行政信任模型中工作；ADKM 不替代它们。RFC 9162 让证书签发可以被公开审计。RFC 7401 展示由公钥材料导出的自认证 Host Identity Tag。DID Core 定义共同数据模型和方法框架，而更新、恢复与版本行为由具体方法决定。

ADKM 的问题更窄：能否为稳定标识符、控制者授权的状态演化、可验证历史、失陷约束与显式一致性证据定义一个跨应用的共同协议模型？相邻体系可以继续作为部署方式、信任来源或补充层。

确定性字节只解决字节问题

密钥事件必须对无歧义的字节签名。JCS、CBOR 的确定性编码规则以及仍在推进的 dCBOR 都是可复用构件。两个实现若把同一事件序列化为不同字节，签名和摘要就会分裂。

但规范化不会决定谁可以降低门限，也不会证明恢复份额独立、事件足够新鲜或支付操作获得授权。确定性编码让分歧可以重现，它不赋予决策合法性。

一份不冒充全球裁决的转换凭据

每次转换至少应记录：稳定标识符与创始绑定；前态摘要；序列或 epoch；事件类型；旧、新密钥及其角色和门限；政策准确版本；每项批准及其权力类别；恢复能力是否参与；确定性表示配置；事件摘要；观察者引用与时间；冲突检查范围与结果；新鲜度来源、年龄和最大许可年龄。

应用随后另写一份决策凭据：接受了哪个状态，用于什么操作，依据哪一版本地政策，最终发生了什么。这样才能保持协调层与执行层之间的边界。状态事件可以真实，应用仍可拒绝；应用可以放行，业务操作仍可能失败。

草案没有证明什么

主文档是 2026 年 9 月 20 日发布、计划作为 Informational、2027 年 3 月 24 日到期的个人 Internet-Draft 第 00 版。它不代表工作组采纳或 IETF 共识，也不证明实现、互操作、部署、事故或某个产品的安全性。它的价值是一张问题地图，而不是完成的建筑。

来源