摘要

  • RATS 工作组当前的 CoSERV 草案明确允许：当接收方无法满足整个 RIM-ID 查询时，只返回一个子集；最极端的空集也可以是有效结果。
  • 确定性编码、查询绑定、签名验证和到期时间证明的是这次返回交换的完整性与时效边界，并不证明服务方资料库的覆盖完整，也不替代依赖方的判断。
  • 运营者应在协议结果之外保存一份检索收据，把查询范围、资料集代次、返回项、遗漏项、来源、缓存路径、验证结论和本地处置连成可复核记录。

一张合格答卷，可以没有答完

远程证明之所以需要一套架构，而不是一个“可信”按钮，是因为不同主体说的是不同的话。RFC 9334 区分证明者、验证者和依赖方：证明者提交证据，验证者形成证明结果，依赖方再决定是否授予访问、限制能力或要求补充材料。签名不能替依赖方做决定，验证结果也不是设备永远安全的证书。

同样的区分应当向前延伸到参考值和背书材料的检索。RATS 工作组正在推进的 CoSERV 草案，全称为 Concise Selector for Endorsements and Reference Values，解决的正是如何用紧凑选择器取得证明评估所需材料。当前版本是工作组互联网草案 draft-ietf-rats-coserv-07，不是 RFC，也不是已经批准的 IETF 标准。

这套机制认真处理了传输中的几个难题。查询采用确定性 CBOR 编码；在 HTTP 绑定里，同一组查询字节可以形成稳定的 GET 地址与缓存键。响应与查询加密绑定，中间缓存若把另一个查询的结果偷梁换柱，验证不会照常通过。结果集带有强制到期时间，不能比所含 RIM 材料活得更久，无效 RIM 也不能混入有效结果。

这些保证都很重要。它们共同证明：眼前这组字节确实属于眼前这个查询，内容没有被无声改写，且仍在声明的有效时间内。可是它们没有证明服务方的后台资料库收齐了所有相关材料，也没有证明查询把所有相关范围都写进去了。

换句话说，正确性有边界。真实性回答“谁签了”；完整性回答“字节是否被改”；查询绑定回答“是不是这个问题的答案”；新鲜度回答“是否仍在时限内”；覆盖完整性才回答“相关总体是否都被查到并返回”。前四项全部通过时，第五项仍可能未知。

草案里最值得运营者圈出的空集

第 07 版草案 对 RIM-ID 查询给出一个清楚但容易被仪表盘遮住的规则：如果接收方无法满足整个查询，可以只返回其中一个子集；在最坏情形下，空集仍是有效结果。

这并非设计疏忽。允许部分回答，比强迫服务方编造不存在的材料，或把“我没有”伪装成语法错误，更诚实也更可部署。问题发生在协议语义被管理界面放大之后。绿色的“valid”若被翻译成“所需材料齐全”，就把草案没有作出的承诺塞进了一个状态灯。

假设查询列出五个 RIM 键，响应返回三个。三个对象都可能验签成功、版本关系正确、尚未过期，也精确绑定到此次查询。另两个没有出现，却至少存在几种不同原因：服务方根本没有收录；服务方持有但请求者无权获取；选择器规则把它们排除；上游采集尚未完成；格式不受支持；或一次运营故障使索引暂时看不见。签名能保护返回的三个对象，无法替运营者在这些原因中选择一个。

即便空集也不能自动等同于“世上不存在”。它最多表明：这个接收方按照这次交换的规则，返回了零项有效结果。它不能证明所有上游来源都没有相关背书，不能证明本地资料库本应包含的对象从未存在，也不能证明换一个有权限的请求者、另一种选择器或稍后的资料集代次仍会得到空集。

草案还规定，对于带整数版本计数器的标签，最高计数器代表相关标签的最新修订。这解决的是可见材料内部如何排序。它没有把“本库所见最高版本”变成“全世界已经发布的最高版本”。如果上游同步落后一代，本地最大值仍然可以计算正确，同时仍然陈旧。

选择器既是技术条件，也是治理裁量

环境查询必须在实例、组或类中选择一种环境类型。实例或组不能在同一环境查询里和类选择器混用。同类的多个选择器按“或”关系扩大候选；类选择器内部已填写的字段按“与”关系共同收窄；未填写字段则像通配条件。带状态的环境测量还可能进一步限制匹配。

这些规则让请求可重复，却也揭示一个常被忽略的事实：查询不是自然界自动给出的窗口，而是某人构造的视图。实例选择器可以精准到一台设备，类选择器可以覆盖一个产品族；一个字段留空会扩大范围，另一个字段填错会把相关材料全部挡在门外。于是，“系统没有找到”可能意味着资料确实不存在，也可能意味着系统被要求只去一个不会找到它的角落查看。

治理记录因此不能只保留查询哈希。哈希证明后来看到的是同一组查询字节，却不解释当时为何采用这个范围、谁批准了选择器语义、它与待作出的业务决定有何关系。对于高风险资产，选择器过窄本身可能就是控制失效；对于隐私敏感设备，选择器过宽又可能形成不必要的识别面。

CoSERV 草案提醒，实例选择器可能带来隐私风险。问责不应演变成公开设备清单。精确查询字节可以存入受控证据库，普通运营日志只保留受保护的指纹、选择器类型和批准记录。可复核性要求有权人员能够还原范围，不等于让所有人看到实例标识。

来源材料和汇集材料不能混成一个来源

检索系统往往同时持有源材料，以及经中介收集、打包或聚合的材料。二者都可以成为签名结果的一部分，却承载不同的来源陈述。一个汇集对象的签名可以证明谁打包了它以及字节未被篡改，不能自动证明中介访问了每个上游来源、采集任务全部成功、所有格式都被支持，或没有对象因许可与访问政策被滤除。

这好比一个封口完美的档案袋。封条证明袋子没有在路上被打开，不证明档案室的每个抽屉都被搜过。

同理，外层验证不能无声继承内层每一项权威。依赖方可能先验证 CoSERV 响应，再验证其中的 CoRIM，再检查背书签发者，最后判断这些主张是否真的适用于眼前证据。每一层都回答一个较窄的问题。把外层“验证成功”当成深层全部可信，会把权限、适用性和评估决策统统藏进一个布尔值。

到期时间也应按原义理解。结果强制到期，能够限制旧答案被无限重放；结果不能活得比内部 RIM 更久。这并不意味着新生成的响应就来自完整资料库。一个刚打印的库存表，可以非常新，也可以忠实复制一个漏项数据库。

缓存不会纠正一个有效的部分答案

确定性查询很适合形成 HTTP 缓存键。这能降低重复计算，提高可用性，也让签名结果在有效期内被安全复用。但缓存多加了一只钟：服务方资料库何时变化、缓存何时取到响应、依赖方何时据此行动，不再是同一个时刻。

缓存可以完全正确地反复返回一个仍然有效的部分结果。它没有撒谎，只是在履行缓存职责。如果审计记录只留下最终验签成功，后来的人就无法知道答案来自哪个缓存、缓存何时取得对象、适用了什么新鲜度指令、服务方是否已经换了资料集代次，以及依赖方为什么没有重新查询。

Lucas Pardue 在 2026 年 8 月 15 日提交的 HTTP Directorate 早期审查 给出“Not Ready”，讨论了缓存、隐私、HEAD、查询长度、验证器和新鲜度等问题。这是一位审查者的意见，不是工作组结论，更不是 IETF 拒绝该草案。本文的完整性判断也不依赖这份审查；草案自身允许子集和空集，已经足以确立边界。审查的价值，是提醒运营者：传输层完全正确，也可能让一个部分答案在决策链上存续更久。

需要新增的是收据，而不是夸大协议

不必要求 CoSERV 响应承担一张宇宙级完整性证书。更可行的办法，是在协议对象之外保存一份检索与完整性收据。它至少应连接以下事实：

  • 精确的确定性查询字节，或能回到受控原文的保护指纹；
  • 所用配置、结果类型、选择器种类及其“或”“与”和通配语义；
  • 请求的 RIM 键或选择器分支；
  • 服务方与资料集代次，以及服务方对该资料集覆盖范围作出的有限声明；
  • 实际返回的键与材料；
  • 已知遗漏项，以及“无权、无库存、不匹配、无效、不支持、检索失败”等明确原因；
  • 材料是直接来源还是汇集对象，相应来源链如何；
  • RIM 有效期、响应到期、检索时间与缓存路径；
  • 签名与结构验证结果；
  • 本地评估、最终处置和何种变化会触发重查。

这些字段不能再压缩成一个“成功”。“本资料集覆盖某某来源”是服务方陈述；服务方给遗漏原因签名，只证明它确实作出该陈述，不证明原因客观为真。依赖方决定隔离、降权、继续服务或改查第二来源，又是另一项事实。

一份好的记录会允许审计者读到这样的事件：五个键中返回三个；一个因权限不足而省略，一个因资料暂不可用而省略；三个均通过验证；依赖方没有把缺失当成安全，而是暂时限制工作负载，并约定资料集代次变化后重查。这个叙述比“CoSERV 成功”长，却终于能够回答谁在何时依据什么作了决定。

资料来源