Summary

  • RFC 9942 can bind a candidate entry to a signed Merkle-tree root, or relate two observed roots through a consistency proof; neither receipt says that the log is complete.
  • Completeness, signer trust, root observation, validity, suspension and the decision made from a logged claim require their own records.

RFC 9942 gives COSE a compact way to carry proofs about a Verifiable Data Structure. Its initial profile, RFC9162_SHA256, registers two useful proof types: inclusion and consistency. The distinction matters because each proof has a deliberately limited subject.

For inclusion, a verifier applies the proof to the bytes of a candidate entry. If that produces the expected Merkle root, the root becomes the signed COSE payload; signature verification then confirms that this entry was included in that VDS state. That is strong evidence about these bytes, this proof, this root and this signer. It is not evidence that all events the log ought to have received were entered, nor that the verifier has seen every root the log issued.

Consistency is equally precise. A receipt can bind an older and a newer tree size through a path, with the newer root carried as a detached payload. RFC 9942 calls for signature verification and then consistency verification against a previous inclusion observation. Success supports an append-only relation between the supplied observations. It does not independently discover an unseen fork, establish the log operator's mandate, or turn a current root into an exhaustive history.

That order is operationally important. A valid signature over an invalid proof must not be accepted as a valid receipt; RFC 9942 recommends one boolean result for the combined operation. Yet even a fully valid combined result leaves other questions outside the object: which key was trusted for this purpose, how roots were acquired, whether the receipt is within a policy window, whether it has been suspended, and whether the underlying assertion merits action. The RFC leaves validity-period and status-update expression to profiles, and cautions that log length and header fields can reveal information.

Cédric Fournet is one of four named authors of this collective IETF work. His public Microsoft Research record provides professional context, not evidence that Microsoft operates a conforming log or that any particular transparency service is honest. Running-code evidence starts with the bounded proof and keeps its missing joins visible.

Sources