Summary

  • The current CoSERV working-group draft permits a recipient that cannot satisfy an entire RIM-ID query to return a subset; in the limiting case, an empty set is a valid result.
  • Deterministic encoding, query binding, signature verification and expiry protect the returned exchange, not the completeness of the provider's collection or the relying party's interpretation.
  • Operators should preserve a separate retrieval receipt joining the exact request, provider coverage statement, returned and omitted keys, provenance, freshness, verification and the local decision.

A perfect answer to a narrower question

Remote attestation divides trust work among several actors. An attester produces evidence about an environment. A verifier evaluates that evidence and creates an attestation result. A relying party decides what to do. The RATS architecture is valuable partly because it refuses to compress those roles into one vague claim that a device is “trusted.”

The same discipline is needed one step earlier, when a relying party or verifier retrieves endorsements and reference values. Those artifacts help establish what measurements are expected, who vouches for relevant properties and which comparison material applies to the environment under appraisal. The active RATS working-group draft Concise Selector for Endorsements and Reference Values—CoSERV—defines compact queries and results for that retrieval problem.

Its machinery is careful. Queries use deterministic CBOR encoding. In the HTTP binding, those bytes can support a stable GET URL and cache key. A signed response is bound to the query, so an intermediary cannot simply substitute a response for another query and still expect verification to succeed. Results carry an expiry; they cannot legitimately outlive the RIM material they contain, and invalid RIMs are excluded. These properties make the response more transportable and more defensible.

They do not make it exhaustive.

This is not a cryptographic shortcoming. It is a category boundary. Authenticity asks whether the object is what its issuer signed. Integrity asks whether it changed. Query binding asks whether this result belongs to this request. Freshness asks whether it remains within its declared time window. Completeness asks whether the relevant population was fully searched and whether every applicable item was returned. The first four can all succeed while the fifth remains unknown.

The empty-set sentence that matters

The clearest evidence appears in the draft's treatment of RIM-ID queries. A recipient that cannot satisfy the entire query may return only a subset. In the worst case, the empty set is still a valid result. That language is operationally sensible: a responder should be able to return what it can supply without fabricating unavailable material or turning partial holdings into malformed protocol output.

But it changes what a green verification mark can honestly mean. “Valid result” cannot be expanded into “complete answer.” An empty result can establish that the responder validly returned no items under the exchange rules. It cannot establish that no applicable endorsement or reference value exists anywhere, that none existed in the responder's upstream sources, or even that the responder's local collection was fully populated at the time.

Nor does a non-empty response close the gap. Suppose a RIM-ID request names five keys and the result contains three. Those three may be authentic, current and exactly bound to the query. The response still needs an external explanation if an operator wants to distinguish among four very different states: the provider did not hold the other two; it held them but the requester lacked access; it judged them outside the selector; or an ingestion failure made them temporarily invisible. Cryptography protects the three returned objects. It does not choose among explanations for the two absences.

The draft also defines a “latest” rule for integer version counters: the highest counter is the latest revision for the relevant tag. That is useful ordering inside the material available to the responder. It is not a proof that the responder has observed the latest artifact in the world. A locally highest counter can be stale relative to an upstream collection. “Latest among what I have” and “latest that exists” are different propositions.

Selectors define a view, not the universe

CoSERV's environment selectors make the same point from another direction. A query chooses one environment kind—instance, group or class. Instance and group selection cannot be mixed with class selection in the same environment query. Multiple selectors of one kind operate as alternatives, while populated fields inside a class selector narrow the match together; fields left unset behave as wildcards. Stateful measurements may narrow the result further.

These rules make requests reproducible. They also mean that the query is a constructed view. A result can be complete relative to one interpretation of that view yet omit material that a different selector construction would expose. If an operator says only “the query passed,” a later reviewer cannot tell whether the scope was deliberately narrow, accidentally narrow or appropriate to the decision.

That distinction matters because attestation systems are decision systems. A selector is not a neutral search box. It determines which reference material becomes eligible to influence an appraisal. An instance selector may locate a very specific device. A class selector may deliberately cover a family. A wildcard may broaden one dimension while an asserted field narrows another. The resulting evidence boundary is a policy choice expressed in protocol form.

The current draft text gives implementers the syntax and processing rules. Governance must preserve why a particular selector was appropriate for a particular decision. Otherwise a technically valid query can become a retrospective alibi: the system found nothing because it was asked to look in precisely the place where nothing would be found.

Collection provenance is a separate claim

Reference material can arrive as source artifacts or as collected artifacts assembled by an intermediary. That difference should not disappear when both are conveyed in a signed result. A signed collection can prove who packaged it and that its bytes were not altered. It does not automatically prove that every upstream source was consulted, that collection completed successfully, or that no item was filtered by licence, access policy or format support.

This is the familiar difference between a trustworthy envelope and a complete filing cabinet. The envelope can be impeccable. The cabinet may still have a missing drawer.

The distinction also prevents “deep” trust from being inferred from “shallow” verification. A relying party might validate the CoSERV response wrapper, validate an embedded CoRIM, check an endorsement issuer and still reach a separate appraisal judgment about whether those claims apply to the evidence in front of it. Each layer has its own authority and failure modes. One signature should not silently inherit all of them.

Expiry deserves similar restraint. A mandatory result expiry is valuable because it limits how long the package can be replayed as current. The response cannot outlive the RIMs it carries. Yet a fresh response from an incomplete collection is still fresh. Recency and coverage are independent dimensions, just as a newly printed inventory can faithfully reproduce an incomplete database.

Caches preserve answers, including partial ones

The HTTP binding makes deterministic queries attractive as cache keys. That can reduce repeated work and improve availability, especially when the result is signed and remains within its validity window. But caching creates an additional clock between provider state and relying-party action.

A cache can correctly serve the same valid partial response many times. Its behavior is not dishonest; it is doing exactly what caching is meant to do. The governance risk arises when an operator records only the final verification outcome and loses the path: which cache answered, when it obtained the object, what freshness directives applied, whether validation occurred, and whether the provider's backing generation changed during the interval.

Lucas Pardue's 15 August 2026 early HTTP Directorate review marked the document “Not Ready” and raised questions about caching and privacy as well as HEAD, query size, validators and freshness. That is one reviewer's assessment, not a working-group verdict. The completeness boundary does not depend on accepting every review point: it follows directly from the draft's own subset and empty-result rule. The review is useful because it shows how transport behavior can complicate the path from a correct response to an accountable decision.

Privacy puts a limit on transparency. The draft notes that instance selectors can be sensitive. A useful audit record should not publish a device identifier merely to demonstrate that a query existed. Exact query bytes may belong in an access-controlled evidence store, with a protected fingerprint in the operational log. Completeness accountability should disclose enough to reconstruct scope without creating a new inventory of targets.

The missing object: a retrieval receipt

The protocol result should remain what it is. Inflating it into a universal completeness certificate would make deployment harder and the claim less credible. Operators instead need a companion record outside the wire contract: a retrieval and completeness receipt.

At minimum, that receipt should join:

  • the exact deterministic query bytes, or a protected fingerprint with controlled access to the bytes;
  • the CoSERV profile, result type and selector semantics used;
  • the requested RIM keys or selector branches;
  • the provider and dataset generation consulted, plus a bounded statement of what that collection claims to cover;
  • the keys and artifacts returned;
  • each known omission, with a reason such as unavailable, unauthorised, unmatched, invalid, unsupported or retrieval failure;
  • whether an artifact came from a source or a collected/aggregated object, and the relevant provenance chain;
  • RIM validity, response expiry, retrieval time and cache path;
  • signature and structural verification outcomes; and
  • the local appraisal, resulting action and trigger for re-query.

The fields must not collapse into one “success” status. Provider coverage is an assertion by the provider. A signed omission reason proves that the provider made that statement; it does not prove the statement true. The relying party's action is another fact again. A reviewer should be able to see that the provider returned three of five requested keys, explained one as unauthorised and one as unavailable, while the relying party chose to quarantine the workload pending a second source.

That record changes the management question. Instead of asking whether CoSERV worked, an operator can ask whether the returned material was sufficient for this decision, whether missing material was visible, and whether a changed collection or expired result triggered another query.

Sources