Digest-sealed export

Sealed is not signed, and the gap between them is the one an informed auditor tests. A seal is an unkeyed digest: it detects change, attributes nothing, and its usefulness rests entirely on the channel by which the digest reached the recipient. If the digest travels inside the file, or in the same message as the file, it demonstrates only that the bundle is internally consistent and was not corrupted in transit — an attacker who edits the bundle recomputes the digest in the same keystroke. A signature is produced under a private key: anyone holding the public half can establish both that the bundle is unchanged and that it came from the holder of that key, and nobody without the key can produce a second one. Describing an export as signed when it is digest-sealed gives the recipient a false impression of what they hold, and the question that exposes it is simply: signed with which key, and where did I get the public half?

So an export answers one of the two questions a regulator asks and not the other. Has this file changed since it was issued: yes, conditionally, provided the digest reached you independently. Who issued it: not from the seal. Provenance has to come from somewhere else — authenticated delivery, where the bundle was produced for a named account over an authenticated session and that read was itself recorded, or from the signed anchors over the underlying ledger head, which is where a signature is actually worth carrying. It is entirely reasonable to ship sealed rather than signed exports; it is not reasonable to let the word seal do a signature’s work in the covering note.

Three mechanical details decide whether a seal is checkable at all. The serialisation must be canonical — sorted keys, no whitespace, a stated approach to unicode and number formatting — or recomputation is a lottery in which two honest parties disagree about bytes that mean the same thing. The bundle must state the algorithm and exactly what the digest covers, body only or body plus metadata, because a recipient who hashes the wrong region gets a mismatch indistinguishable from an edit. And the digest must sit outside the region it covers, since a digest that covered itself could never be recomputed.

What travels inside the bundle matters more than the seal around it. An evidence bundle should carry not only the records for the period but the verdict on the log they came from: whether chain verification passed, how many entries were checked, the first sequence at which it broke if it did, which checkpoint it was verified against, and — the field to actually read — the protection level. A bare valid flag invites the recipient to assume that nothing was altered, when on an unkeyed chain it means nothing was altered without recomputing. Naming the protection level beside the flag is the difference between an auditor being informed and being misled, and it costs one string.

The failure that actually happens in practice is not cryptographic; it is truncation. Bundles are capped — so many traces, events, approvals and audit entries, over a default window — and a cap that bites without setting a flag inside the file produces a partial bundle that looks complete. Every cap should set a truncation flag, and the caps should be shown where the person downloading the file will see them, because nobody opens a sealed JSON file to check it before forwarding it to a regulator. State the window the bundle covers and the counts it returned, so that complete for the period you asked for is a question the recipient can answer without opening a ticket.