Summary
- 一份仍在演进的个人互联网草案设想由理解 RATS 的身份文件服务接收证明结果,再向工作负载发放旧系统熟悉的密钥、令牌或凭证,以尽量减少改造范围。
- 这种桥接会产生签发后的时间缝隙:证据、评估策略、运行位置或具体声明已经改变时,下游仍可能按普通有效期与撤销规则接受原凭证。
- Daniel Kade 提议建立“证明—凭证租约”,把凭证与证据时期、两层策略版本、声明类别、工作负载密钥和变更触发器绑定,并把新判断转换为旧服务原生支持的状态事件。此方案是编辑性治理建议,并非 IETF 共识。
一次没有攻击者的失效
德国到法国的迁移之所以是好例子,正因为它不需要入侵、私钥泄露或伪造签名。工作负载第一次接受检查时完全合格。验证者按照当时的证据评估策略产生证明结果,身份文件服务再按照自己的结果评估策略决定签发。之后发生的只是云环境里再普通不过的调度动作。
draft-bdnr-rats-trustworthy-credentials-02 明确提醒:迁移可能使 Country=Germany 变为不实,但 Region=Europe 仍然成立。变化是否要求撤权,取决于凭证究竟授权什么。一个面向欧洲范围的能力也许可以继续;一个只能在德国境内使用的数据权限则可能必须停止。若把整组声明压成一个“可信”结论,系统就无法解释为何同一次迁移对两项权限产生不同后果。
问题由此落在签发之后。远程证明是特定时点、特定政策下对状态的判断;普通凭证则被设计成可以在有效期内反复出示。前者被转换成后者以后,原来的条件并不会消失,只是下游看不见了。
“最小爆炸半径”不是偷懒
这份草案面对的是很实际的部署条件。许多协作服务无法处理 RATS 证据和证明结果:软件可能来自第三方,运行环境不便修改,语言栈缺少实现,安全变更需要重新审查,或者负责团队根本没有能力承接另一套信任协议。让每个旧服务都原生理解远程证明,往往意味着整个计划受制于最难改的那一个组件。
草案因此把凭证代理、密钥代理或凭证机构设计为双重角色:它既是 RATS 的依赖方,又是身份文件服务。工作负载向这个中介证明状态;中介接受结果后,返回合作方已经认识的身份文件。这里的“身份文件”可以是密钥、令牌或凭证,既可能短期,也可能长期。草案讨论了密钥代理、预置持有证明凭证以及签发新持有证明凭证或短期承载令牌等路径。
这确实能减少改造。既有 TLS、证书校验、令牌验证与服务授权逻辑可以继续工作,私钥也可留在工作负载内部。把这种目标简单批评为“绕过证明”是不公平的。真正需要追问的是:既然下游被刻意保持无感,谁来承担它因此看不到的生命周期责任?
答案只能指向中介。它在入口处替旧服务理解了证明,就必须在信任改变时,把改变重新翻译成旧服务能够执行的动作。
系统里其实有三只钟
RFC 9334 划分了两个政策判断。验证者用“证据评估策略”解释证据,产生证明结果;依赖方再用“证明结果评估策略”决定这个结果是否足以支持具体用途。结果真实、来源可信,并不自动等于可以授权。
这两步都有时间边界。证据的新鲜度必须适合使用场景,证明结果也有自己的有效窗口。RFC 9334 同时承认无法消灭竞态:结果产生后的下一刻,设备状态或策略就可能变化。因此,结果不得被使用到其有效期之外,但在有效期之内也不能假装世界静止。
身份文件服务再签发一张凭证,就引入第三只钟。证书有起止时间,令牌有到期时间,状态服务和撤销列表也有刷新节奏。这些是旧服务能看见的钟;证据时期和评估策略版本通常不是。如果凭证可用八小时,而关键位置声明只适合信任五分钟,那么五分钟的限制并没有被工程设计消除,只是被装进了一个表面寿命更长的对象。
把凭证缩短并非完整答案。十分钟的凭证仍可能越过五分钟的声明边界;持续证明能够更快发现变化,却仍需有人把新结果转换成对已流通凭证的处理。撤销只有在“哪张凭证依赖哪项声明”可追踪、且依赖方确实读取状态时,才是闭环。
密码学正确不等于语义仍然正确
JWS 的签名能够证明受保护对象没有被篡改,并来自相应签名密钥。RFC 5280 下的证书路径检查能够验证签发者、名称、约束、时间和配置中的撤销信息。持有证明能说明出示者掌握相应私钥。它们都不会重新执行当初促成签发的证据评估。
于是会出现一种不带技术故障的错误:旧服务严格按照自身规则完成了正确校验,却在使用一个已经过时的前提。凭证未过期、未撤销、签名无误,服务接受它完全符合自己掌握的信息。责任不应被推给一个按设计就看不到 RATS 的组件。
中介在签发后仍然是信任链的一部分。它连接着两个变化速度不同的体系:一边是证据、参考值、认可材料、验证者与声明;另一边是证书有效期、令牌到期、密钥轮换和撤销。这个连接必须成为可操作的状态,而不能只剩一条事后无人查询的签发日志。
声明不是一个不可拆分的绿灯
位置迁移表明,证明结果中的属性会以不同速度老化。国家可能变化,区域保持;运行运营方可能变化,测量的软件组件不变;配置状态可能改变,安全启动状态仍然成立;新策略也可能只淘汰一种算法,而不否定工作负载的全部身份。
身份文件服务需要按授权实际使用的粒度记录依赖。若一项能力只要求位于欧洲,国家声明可以是附加信息而非继续授权的必要条件。若另一项能力要求数据处理必须在德国,国家就是强依赖。把二者写进同一张不可分割的粗粒度凭证,会让按比例纠正变得困难:要么留下不该继续的权限,要么为一项变化切断无关业务。
这种依赖图还能约束运营激励。过度撤销会制造事故,久而久之使团队选择忽略证明信号;过度存续则让凭证在依据消失后继续携带权力。可审计的问题不应只是“当时是否通过”,而应是“哪项变化影响哪项能力,为什么采取或不采取动作”。
工作负载身份必须绑在被证明的密钥上
草案特别区分了发起申请的客户端与真正被证明的工作负载。EST 客户端可能运行在工作负载可信计算基础之外的虚拟机管理器或编排器中。它可以为了建立安全信道而认证自己,但不能因此决定服务应返回哪个工作负载身份。身份依据必须来自证据与证明,私钥也应由工作负载持有。
签发之后同样需要这条原则。迁移、更新或撤销事件必须通过被证明的工作负载密钥和身份关联到凭证,不能只依赖当时转发请求的编排器会话。否则,每一次网络交互都可能通过认证,最终处理的却是另一工作负载的凭证。
LAMPS 的 CSR 证明草案在相邻场景中指出:证书机构或注册机构一旦使用证明,就负责把多份证明陈述彼此绑定,并绑定到申请中的公钥;相关要求也应写入认证业务声明。这说明“绑定责任”需要明确归属,但不能被误读为当前可信凭证草案已经解决了整个生命周期。
WIMSE 的工作负载凭证草案则把身份表达与持有证明分开。私钥控制回答的是“谁在出示”;它不回答“签发时的每项环境属性现在是否仍成立”。完善密钥轮换和信任锚,也无法自动刷新已经过时的地理声明。
建立一份证明—凭证租约
Daniel Kade 提议由身份文件服务维护“证明—凭证租约”。它不是要发明一种旧服务不认识的新凭证,而是以最少持久状态保留两种有效性制度之间的连接。旧服务继续做熟悉的到期与撤销检查,中介负责把 RATS 世界的变化转换成这些原生信号。
租约首先记录凭证标识和类型、工作负载身份、由工作负载持有的公钥及持有证明绑定。随后记录签发采用的证据时期与新鲜度上限、验证者身份及证据评估策略版本、身份文件服务采用的结果评估策略版本。策略升级或验证者更换时,系统才能找到需要重新判断的凭证,而不是等待它们自然到期。
第二部分是声明依赖图。凭证中的每项实际能力应连接到支持它的最小声明类别:国家、区域、软件测量、密钥保护或运营环境。依赖可以标为强制、参考,或者仅用于决定更短寿命。无需把原始证据全部复制进租约;受保护的引用、时期和结果摘要足以承担连接功能,同时还应遵守隐私与保存期限。
第三部分是时间上限。凭证寿命不应在没有说明的情况下超过最短的关键依赖;如果持续观察与可靠状态传播提供了同等控制,可以明确记录例外。这不是要求所有凭证都尽可能短,而是禁止把默认八小时当成风险分析。
最后是触发与翻译。迁移、密钥轮换、评估策略更新、参考值撤回、软件变化、修复失败和认可材料变化,都可以触发重新证明。新判断对应的动作可以是换发、缩小范围、暂停、撤销,或在变化与权限无关时留下有理由的“不处理”决定。中介还要证明原生状态信号已经发出,并能被每一类依赖方接收。
“已撤销”不是交付证明
在数据库里给凭证加上 revoked,并不表示旧服务已经停止接受它。有的服务缓存状态,有的只在连接建立时查询,有的依靠短期令牌自然到期,有的每次请求都做内省。租约必须写明真实的执行路径和最大传播延迟。
因此,审计要看一条完整的时间线:谁报告迁移,身份文件服务多久重评,使用何种证书状态或令牌撤销渠道,既有会话如何处置,离线依赖方如何收敛,替代凭证是否先缩权,再让旧凭证失效。只统计“撤销请求成功”会把最关键的最后一公里排除在外。
例外也必须有生命周期。验证者故障时,值班负责人也许允许工作负载继续三十分钟;这并非天然错误。但授权人、范围、到期、补偿监控和事后处置都应存在。“暂时无法证明”不能在重复续签中变成永久的第二条信任路径。
草案提供了问题,不提供部署结论
可信凭证草案对未完成部分相当坦率:短期承载令牌仍需要另一协议或扩展,/serverkeygen 的改造也需更多细节。草案强调受保护信道、密钥安全与少改工作负载和协作方,却没有给出跨越全部生命周期的治理闭环。
这对于个人互联网草案并不异常。截止本文研究日期,它没有正式 IETF 地位,内容仍可变化。LAMPS 与 WIMSE 的相邻草案虽让公钥绑定、凭证寿命和轮换问题更加具体,也同样不能证明这套租约已成为标准或已有部署。
冻结来源没有提供任何命名服务的上线证据、实际凭证寿命、迁移事故、合规违规、市场采用率或性能数据。开头的场景取自草案自身的地理声明警告,用来检验设计边界,而不是指控某个运营方。
Sources
- https://heng.lu/the-policy-mirror/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
- https://datatracker.ietf.org/doc/html/draft-bdnr-rats-trustworthy-credentials-02
- https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/
- https://datatracker.ietf.org/doc/draft-bdnr-rats-trustworthy-credentials/history/
- https://author-tools.ietf.org/iddiff?url1=draft-bdnr-rats-trustworthy-credentials-01&url2=draft-bdnr-rats-trustworthy-credentials-02
- https://www.rfc-editor.org/rfc/rfc9334.html
- https://www.rfc-editor.org/rfc/rfc9711.html
- https://datatracker.ietf.org/doc/html/draft-ietf-lamps-csr-attestation-29
- https://datatracker.ietf.org/doc/html/draft-ietf-wimse-workload-creds-02
- https://datatracker.ietf.org/doc/html/draft-ietf-wimse-arch-08
- https://www.rfc-editor.org/rfc/rfc7030.html
- https://www.rfc-editor.org/rfc/rfc5280.html
- https://www.rfc-editor.org/rfc/rfc7515.html
会员简报
档案背景详情
使用相应会员等级登录,即可解锁完整简报与来源注释。
仅限 Strategic Circle
Strategic Circle
所有读者均可浏览。加入并登录后可解锁档案简报。
加入 Strategic Circle仅限 Leadership Alliance
Leadership Alliance
符合条件的 IP 资产所有者和管理层可登录查看 Leadership Alliance 简报。
加入 Leadership Alliance
