摘要

  • RFC 9999 为证据、背书、参考值、证明结果和评估策略规定了统一且可自描述的 CMW，使这些消息能进入 CBOR、JSON、JWT、CWT 与 X.509 环境。
  • Record、Tag 或 Collection CMW 提供结构与类型，不自行提供真实性、完整性、保密性，也不会把多个部件绑定成一台设备。
  • 代表复合设备的 Collection 必须让各份证据具备密码学关联；此后仍由验证者评估，由依赖方依据自己的策略决定允许什么操作。

设想一台准备进入受限计算集群的服务器。CPU 报告启动链，SmartNIC 报告固件状态，GPU 的证明环境提供第三份证据。收集服务把三份对象放进一个 Collection CMW，交给验证者。

攻击者只替换 SmartNIC 那一项，换成另一台健康设备上复制来的有效证据。三份内部签名可能全部通过；媒体类型可以全部识别；集合本身也能正常解析。可这份材料已不再描述一台机器。若没有机制证明各部件共享设备身份、时效上下文与受保护的组合关系，三个绿色勾号恰好可以组成一条错误结论。

RFC 9999 于 2026 年 7 月作为 IETF 标准轨道文档发布，全名是 Remote ATtestation procedureS (RATS) Conceptual Message Wrapper。它给 RATS 的概念消息提供共同信封，便利跨协议传递与处理器分流。它没有把信封升级为事实。

五种消息不是五种同义词

RFC 9334 先区分角色，再区分产物。证明者产生 Evidence。验证者把 Evidence、Endorsements、Reference Values 和针对证据的 Appraisal Policy 结合起来，形成 Attestation Result。依赖方再用针对证明结果的策略，决定某项应用动作是否获准。

RFC 9999 把这五种功能登记为 CMW 指示位：0 到 4 分别对应参考值、背书、证据、证明结果和评估策略。Record CMW 保存媒体类型或 CoAP Content-Format、序列化后的值，以及在类型可能含混时使用的 ind 位图。

这个位图回答的是“应当把这些字节交给哪一类处理器”，不是“这些字节是否可信”。参考值可能过期，背书可能来自不受信的制造商密钥，证据可能真实却已经超出新鲜度窗口，证明结果可能只适用于另一版验证策略，评估策略自身也可能被篡改。

CMW 允许核心处理器不理解内部材料：明确类型选择插件，内部对象可以不透明地经过核心。于是，分流能力只是一种路由权限。能挑选解码器的组件，不应因此获得批准设备的权力。

Collection 是树，不是裁决书

Record 与 Tag 是 CMW 树的叶节点。Record 直接写明序列化格式；CBOR Tag 由 CoAP Content-Format 推导标签号。Collection 是中间节点，用唯一标签装载多个 CMW，也可以继续嵌套 Collection。

这种结构对应真实硬件。一台数据中心服务器可能由 CPU、SmartNIC、GPU 三个独立证明环境分别产生不同格式的 Evidence。Collection 能保留差异，而不要求每种硬件组合重新发明外层协议。

但 Collection 并不等于“一台设备”。标准允许它混合不同概念消息，也允许装载涉及多台设备的材料。可选的 __cmwc_t URI 或 OID 给集合定义类型，并为标签提供解释命名空间。它可以声明一种允许的装配方式，却仍然只是元数据；若没有保护和验证，它关于结构的说法并不是结构本身的证明。

Collection 可以递归，因此实现可以限制嵌套深度。两套都宣称符合标准的软件，可能接受不同深度。网关只展开一层、验证者却接受四层，会造成语义落差、资源耗尽面，甚至打开未经审议的处理路径。部署方必须统一最大深度与失败方式，不能把“某个库解析成功”当成端到端合同。

三个签名之间，缺的是绑定关系

RFC 9999 说得很直接：Record、Tag 与 Collection CMW 本身不提供真实性、完整性或保密性。CBOR CMW 可以用 COSE_Sign1 签名，JSON CMW 可以用 JWS 签名；CMW 也能作为 cmw claim 进入 CWT 或 JWT。这些是可选择的保护手段，不是包装器自动附带的属性。

当 Collection 代表一台复合或分层设备的 Evidence 时，其中所有证据消息都必须通过密码学方式绑定。目的正是阻止攻击者用健康设备的证据替换受损部件。绑定可以是覆盖整个集合的对象签名，也可以是共同标识、关联 nonce、部件之间的签名或哈希。创建 Collection 的证明者负责保护集合内容。

不同做法支持不同结论。收集服务的外层签名只证明该服务签过这些字节，未必证明它属于设备的证明信任根。多个成员都声称同一序列号，若每个成员都能任意填写序列号，价值很低。共同 nonce 只有在它经受认证的路径到达每个证明环境，并被每份回复实际绑定时，才连接同一会话。哈希链能保护成员关系，却未必证明签名者就是声称的部件。

因此审计记录不能只保留 signature_valid=true。至少还要保存原始 Collection 哈希、外层形式、集合类型、项目标签、内部媒体类型与指示位、签名者和密钥标识、新鲜度材料、设备绑定主张、嵌套深度、绑定方法与验证记录。否则事后无法判断密码学覆盖了叶节点、集合装配，还是仅覆盖了最外面的传输令牌。

换一个载体，就多一条信任边界

RFC 9999 登记了 application/cmw+cbor、application/cmw+json、application/cmw+cose、application/cmw+jws，也登记 JWT/CWT 的 cmw claim，并为证书、证书请求和吊销列表规定 X.509 扩展。

不同载体覆盖的表面不同。JWS 可以签集合，却不一定保护日后被抽出并单独缓存的 Evidence。JWT 可以验证发行者，却不能自动证明内部 Collection 是同一发行者产生。TLS 保护两个端点之间的信道，不证明被转发的内部材料来自原始设备。把 CBOR 重新编码成 JSON，也许保留语义，却可能使逐字节签名失效，并丢掉法证复演所需的原对象。

所以承载协议必须拥有自己的集成合同。RFC 9999 要求它说明允许哪些概念消息及组合、需要何种保护、CMW 如何接入、两套安全模型如何相互影响。只写一句“负载使用 CMW”，只是委托了语法，没有说明权限。

X.509 的 critical 选择尤其能看清这件事。CMW 扩展通常不应标为 critical；但若其中消息是授予资源访问的必要条件，而旧依赖方可能忽略扩展、绕过控制，就可以标为 critical。这里的 critical 不是排版偏好，而是在问：不认识证明条件的旧实现，是失败关闭，还是继续放行。

证书还会扩大披露范围。Evidence 可能含个人信息，也可能暴露 HSM 型号、补丁级别等运营细节。申请者愿意向 CA 披露，不等于同意把它写进广泛分发的公有证书。RFC 9999 因此要求，CA 若要公开传播第三方证据，应在认证实践声明中明确规则。瞬时评估输入一旦进入长期凭证，就可能变成长期侦察材料。

证明结果仍不是授权

最危险的压缩发生在链条末端：验证者给出正面的 Attestation Result，网关就把它直接当放行指令。这样做消除了依赖方自己的场景、策略与责任。

RFC 9334 刻意保留两个策略所有者。Verifier Owner 决定如何评估 Evidence；Relying Party Owner 决定证明结果如何影响具体动作。同一份有效结果，可能足以允许低风险遥测，只能让控制平面进入隔离区，却完全不足以批准密钥签名。时间、网络区域、请求能力与业务例外都属于依赖方上下文。

可复演的决策记录应连接而不混淆这些层：证据集合与绑定记录；背书和参考值版本；验证策略与证明结果；依赖方策略和请求动作；最终允许、拒绝、限权或隔离结果。只存一个布尔值会丢掉因果，只存结果令牌则会丢掉真正实施权限的主体。

这也是 Lu Heng “运行代码优先”在证明系统中的含义。正式信封是必要出处，但只有实际执行才能表明处理器、验证策略与访问控制是否遵守了边界。“最小初始规范”支持 CMW 这种薄而共同的语法；绑定方式、允许组合与后果仍须由本地负责方明确。“现实层”则要求把类型位、密码学保护、评估结论和生产动作看成四种不同事实。