摘要

  • RATS 交互模型草案第 20 版新增附录 B，以背书材料和参考值的提取为例，让稳定的 GET 网址充当隐式句柄，供同样的查询共享缓存。
  • 供应方把材料、查询和到期时间一起签入响应。检查者仍须按自己的规则，把这些材料与设备当次提交的证据分开判断。

抽屉的地址，文件的期限

设备证明自己处于什么状态，先得交出证据，检查者还得知道证据何时产生。用来比对的背书材料、参考值则可能被许多检查者反复取用，直到供应方更新它们。RATS 架构把设备、背书者、参考值提供者、检查者和最后使用结论的一方列成不同角色，正是为了让一份材料不替所有人作决定。

10 月 28 日的更新仍是 RATS 工作组的 Internet-Draft，目标是拟议标准；新增附录只是交互示例，不是已部署系统的报告。它问了一个朴素问题：若每次取参考材料都塞进独一无二的句柄，同样的问题便变成不同的请求，缓存如何复用？

另一个工作组草案 CoSERV索性不在查询中放时间戳等易变字段。同样的环境标识与声明选择会编码成同样的字节，形成固定的网址路径。HTTP 可以用这条路径作缓存键。设备验证次数很多，参考材料改动较少时，供应方不用每次都从头答题。

新附录给这条网址添了一个角色：attEnvIDs 与 claimSelection 组成按环境查询，GET 网址在示例中充当一个时期起点的隐式句柄。供应方把背书材料、参考值、查询与到期时间共同签进响应，到期时间封住这一结果的使用区间。草案假定相关角色有可靠时源，并以 Epoch Bell 举例。网址告诉检查者去哪个抽屉；签名响应告诉他这次拿到的是什么、何时过期。

CoSERV 原文还有两条硬线：每组结果必须写到期时间，过期后消费者不得继续视其有效；HTTP 缓存宣称的保鲜时长也不得越过这个期限。存在不可信中间方时，签名把结果与原查询绑定。需要直接回源的消费者可发送 Cache-Control: no-cache。缓存省的是重复运输，省不了核对期限。

供应方决定提供哪些参考值以及签多久。检查者选自己的评估政策，核对设备证据，决定这份参考材料能否进入计算。依赖结论的一方再决定实际操作。新增示例把这三次交接放到台面上：一个稳定网址能提高效率，却不能替设备拿到永久通行证。

来源：RATS 第 20 版；第 19 版；Datatracker 状态；CoSERV 第 07 版；Epoch Markers 第 06 版；RFC 9334。