摘要

  • RFC 9999 为 RATS 中的 Evidence、Attestation Results、Endorsements、Reference Values 与 Appraisal Policies 提供自描述封装，使它们能跨 CBOR、JSON、JWT、CWT、X.509、HTTP、MIME 与 CoAP 场景流动。
  • Record、Tag 与 Collection CMW 解决识别、分流和组合结构，并不自行提供真实性、完整性、机密性、时效、语义评估或业务授权。
  • 当一个 Collection 声称代表同一复合或分层设备时，所有 Evidence 必须有可验证的整体保护或成员间绑定；分别有效的签名不能证明它们属于同一设备、同一拓扑时代和同一次事务。

验证器收到了一只很整齐的“箱子”。第一格写着 CPU，第二格是 SmartNIC，第三格是 GPU。三个载荷都能解码，媒体类型都已注册，内部签名也分别通过。自动化系统于是把整台服务器标成绿色，准备释放生产签名密钥。

但箱子的外观没有证明三件东西原本就在一起。CPU 证据可能来自申请密钥的服务器，SmartNIC 证据可能来自库房里的健康备件，GPU 证据可能是昨天保存的旧报告。攻击者无需伪造任何签名，只要把三段各自真实的历史拼成一台从未存在过的“健康机器”。

RFC 9999 正是在这条边界上值得管理层关注。它于 2026 年 7 月以 IETF Standards Track RFC 发布，定义 RATS Conceptual Message Wrapper，简称 CMW。标准要解决的是互操作：远程证明有不同概念消息、声明格式、序列化与承载协议，系统不应每增加一种证明技术就重写整个核心。

CMW 可以准确告诉软件“这是什么、交给谁处理、怎样组合”。它不替软件决定“应不应该相信”。

包装之前，权力已经被分成三段

RFC 9334 定义了 RATS 的角色分工。Attester 产生 Evidence；Verifier 把 Evidence 与 Endorsements、Reference Values 及 Appraisal Policy 一起评估，生成 Attestation Results；Relying Party 再用自己的政策决定是否允许入网、释放数据、接受命令或发放密钥。

这不是同一个判断重复三次。Evidence 回答“设备主张了什么”；Verifier 回答“这些主张在某套参考和政策下意味着什么”；Relying Party 回答“即使评估成立，本业务现在准许做什么”。RFC 9999 为这些对象提供共同外壳，却没有合并三个主体的决定权。

Record CMW 由 type、不透明的 value 和可选 ind 指示器组成。ind 可以说明载荷包含 Reference Values、Endorsements、Evidence、Attestation Results 或 Appraisal Policy。Tag CMW 按 RFC 9277 的规则，从 CoAP Content-Format 推导 CBOR 标签。Collection CMW 以局部唯一的标签组织多个 CMW，还能递归地包含其他 Collection。

IANA RATS Parameters 登记概念消息指示位。RFC 9711 定义 Entity Attestation Token，RFC 9782 定义相应媒体类型。注册表、类型和标签让核心程序选择正确处理器，也让新格式接入时不破坏既有协议。

然而，正确分流不是背书。type 能指出 EAT 处理器，不能证明 EAT 里的 claim 为真；ind 能说载荷扮演 Evidence，不能证明写入这个位的人有资格为设备作证；IANA 分配能避免编号冲突，不能保证运营者已经支持、理解或信任该格式。

外壳没有凭空生成安全属性

RFC 9999 明确说明：CMW 是 encapsulation，不是 security format。Record、Tag 与 Collection 本身不提供真实性、完整性或机密性。

安全保护可能已经在内部概念消息里，也可能包在 CMW 外部。CBOR CMW 可使用 RFC 9052 的 COSE 结构，JSON CMW 可使用 RFC 7515 的 JWS。安全信道保护传输过程，挑战—响应协议可以约束重放。

这些保护的作用域不同。一次经过认证的连接能说明谁参与了当次连接，却未必在对象转发和落盘后继续保存来源。三份成员各自有签名，只能说明三个密钥分别签过三段字节，未必说明三段字节属于同一机器。覆盖整个 Collection 的签名能保护组合，但还要确认签名者有权声明该组合，以及签名覆盖的 profile 清楚定义了组合含义。

RFC 9781 提供了最直接的反例。UCCS 是 Unprotected CWT Claims Set。把 UCCS 放入 CMW，只让接收方更容易识别和运输它，不会把“未保护”变成“已认证”。RFC 9999 给出在外层增加签名的办法。安全来自额外、可验证的控制，而不是包装名称。

因此，生产记录不能只写“signed=true”。它要说明：哪一层的哪些字节被哪把密钥、以什么用途保护；受信任依据是什么；经过抽取、缓存和转发之后，原来的保护范围是否仍然成立。

三份真件可以组成一台假机器

现实设备本来就是复合体。数据中心服务器可能让 CPU、SmartNIC 和 GPU 分别执行证明；运营商路由器可能有机框、主控板与多块线卡；分层启动链则由上一层测量下一层。

Collection CMW 允许这些不同格式共存。可是一旦它用于证明“同一台复合或分层设备”，RFC 9999 要求所有 Evidence 必须被密码学地绑定在一起。没有整体对象保护，也没有成员内部的相互绑定，攻击者就能用健康设备的 Evidence 替换受损组件的 Evidence，让 Verifier 对错误组合给出通过结果。

标准没有把绑定限定为一种实现。Attester 可以签整个集合；成员可以共享设备标识或 nonce；成员之间可以交叉签名或哈希；承载协议也可以定义其他可验证关系。审计问题不是“有没有锁形图标”，而是：已验证的作用域是否真的把每个成员绑定到所声称的设备、拓扑时代与事务。

也不能反过来假设每个 Collection 都应代表一台设备。RFC 9999 允许汇集 Endorsements、Reference Values、Attestation Results，也允许一个集合承载多台设备的消息。Collection 只表达组合结构；可选的集合类型或 assembly profile 才解释这种组合意味着什么。

成员顺序没有语义，标签只在所属 Collection 内唯一。gpu、slot-3 或 firmware 不是全球组件身份。运营证据还必须把标签关联到实物清单、槽位、设备标识、拓扑版本和 profile 版本。

递归把兼容性风险交给了解析器

Collection 可以递归嵌套，这是表达分层设备的优势，也是资源消耗面。深度、成员数、总字节、Base64 解码、签名验证、外部 Endorsement 与 Reference Value 查询，都可能随树增长。

RFC 9999 允许实现限制最大深度，但把发现和协商细节留在标准范围之外。生产侧必须自行设定总大小、成员数、嵌套深度、单处理器时间、密码学操作次数和外部查询扇出。一个首字节成功选中解码器，并不等于获准占用无限资源。

未知类型也需要明确后果。存档或转发服务可以在不理解内容时保存不透明对象；授权服务不能悄悄忽略未知成员，再宣称完成了复合设备评估。“无效”“不支持”“缺失”“本 profile 不要求”是四个状态，不能揉成一个空值。

每个已接受类型都应对应处理器版本、支持的 profile、算法政策、资源预算与失败方式。这样，CMW 的插件式扩展才不会变成把未理解输入送入授权路径的捷径。

新鲜度不写在包装纸上

远程证明关心的是相关时刻的状态。固件升级、部件更换或参考值更新后，一份旧 Evidence 的签名仍可验证，但已经不能说明当前机器。

RFC 9334 把 freshness 作为独立问题，列出同步时间、nonce 与 epoch ID。CMW 能承载使用这些机制的消息，却不会证明所有成员都回答了同一个挑战。若 CPU 绑定 nonce A，SmartNIC 绑定 nonce B，GPU 只有时间戳，外层 Collection 无法替 Verifier 决定它们是否构成同一事务。

证据链应保留挑战值、签发者、有效窗口、时钟假设、epoch 与覆盖的成员。签名验证成功只证明一个密码学关系，没有自动证明时效。

之后仍有政策评估与业务授权。Verifier 可以证明设备符合某套固件基线，Relying Party 仍可拒绝它读取某客户数据或签署生产版本。一个真实、及时的 Attestation Result，也可能被带到从未授权它的业务上下文中。

完整关单链条是：列出预期成员；解析精确字节；验证保护；证明成员与设备、事务和时代的绑定；建立新鲜度；以指定政策评估；把结果交给指定 Relying Party；记录决定；观察实际效果。

可携带，也意味着更容易被传播

RFC 9999 允许把 CMW 放进 X.509 证书、证书请求和 CRL。这复用了成熟渠道，也可能让原本短暂、私密的硬件事实变成长期、广泛分发的信息。

申请代码签名证书的人可能愿意向 Certification Authority 透露 HSM 型号和补丁级别，却不愿让所有证书接收者看到。RFC 5280 定义 PKIX 证书与扩展处理，不提供披露同意。RFC 3647 提供 certificate policy 与 certification practice statement 框架。RFC 9999 要求应用公开传播第三方 Evidence 时，在实践声明中写清 CA 可以加入这些数据的条件。

隐私控制必须发生在签发之前：最小化 claim，限定受众与保留期，审核 profile，明确发布授权。证书撤销可以改变信任状态，不能追回已经复制的硬件信息。

用实际执行结果收束形式正确

Heng Lu 的运行代码优先在这里意味着检查真实路径：哪个解析器选择了哪个处理器，哪些字节被保护，哪把密钥被信任，绑定和新鲜度如何成立，哪个政策版本产生什么结果，最后执行了什么动作。

他的最小初始规范与本地未来决策则给出合理分层：共同 wrapper 与 registry 降低互操作成本，健康阈值、授权和责任不必被中心化；本地运营者必须为自己的决定留下明确主体与证据。

现实分层让四个事实各归其位：CMW 语法正确；某个范围受密码学保护；Verifier 完成语义评估；Relying Party 批准并实际发生了某项动作。任何一层都不能借用另一层的权威。