摘要

  • 10 月 28 日的个人草案指出：测量值能辨认工作负载类型，同一镜像的两个运行实例却可能完全相同。
  • 草案摆出两条身份路径：由证明结果背书的密钥，或把该密钥接到能跨换钥保留名称的 WIMSE 证书；接入方仍须核对名称与运行环境是否相配。

把同一程序复制两份，交给它们相同的镜像，再请远端判断哪一份曾经拿到那把钥匙。测量值会给出两张一样的成绩单。问题出在成绩单上没有座位号。

Tirumaleswar Reddy 等人的草案是个人提案，供 SEAT 讨论，工作组尚未选定方案。它先问一个朴素的问题：接收方需要“任意一份合格副本”，还是必须找到“指定的那一份”？前者只需要确认镜像类型；后者必须有实例级的识别依据。

第一条路不请证书机构发名牌。工作负载在被证明的环境里生成密钥，把公钥放进证明材料，TLS 握手再亮出同一把公钥。接收方检查两处是否一致，并核验运行测量值。公钥可直接呈现，也可装进自签证书。证明体系为密钥背书；密钥轮换后，旧钥匙本身无法说明新钥匙是谁的继任者。

第二条路给工作负载一个可延续的名称。WIMSE 凭证草案让证书把工作负载标识和密钥绑定，证明材料再把该密钥和被测环境绑在一起。换钥不必换名，但 WIMSE 也允许多个实例共用一个逻辑工作负载标识；发证信任域必须决定名牌究竟发给单个副本还是整组副本。这张名牌解决连续性，却把命名粒度和签发权一同写进了架构。

验完证书、验完测量值，接收方还得做一次交叉审问：这个名字究竟获准在哪一种镜像里运行？一张有效证书可以出现在一个真实但不获该名称授权的环境中。草案要求在有此要求的场景下联合评估名称和测量值。它还提醒，持有私钥的证明与公钥一致性检查，单独都不能证明私钥确实在受保护环境里生成、始终没有外流。

RATS 架构 RFC 9334把证据、验证和最终使用决策交给不同角色。新草案碰到的权力问题更具体：谁给一个副本取名，谁允许这个名字进入眼前这台机器。两道独立的绿灯，不能替代这一次联合判断。