Sealing, Integrity and Provenance

After this lesson, the reader should understand:

• 01Explain why a governance artifact must be canonicalised before it is sealed.
• 02State what a cryptographic seal establishes and what it does not.
• 03Distinguish integrity and provenance from legal validity.

What the signature does not fix

An institution seals an authority artifact that, it later emerges, encoded the wrong threshold. The seal verifies perfectly. What did the seal buy?

Integrity and provenance — and only those. Anyone can confirm the artifact is exactly what the institution issued, by whom, and when, and that every decision bound to it used that version unaltered. What the seal cannot do is make a wrong threshold right: a signature over a defective rule is a verifiable record of a defect. This is the correct division of labour. Sealing removes the argument about whether the artifact was tampered with, so the argument can be about whether the authority was correct — which is a governance question, resolved by the compilation and review process, not by cryptography. In the NOMOS reference implementation the mechanics are concrete: the artifact is put into a canonical byte form (RFC 8785 JSON Canonicalization) and signed with an Ed25519 key whose identifier travels inside the seal. The public key is published at a well-known URL, so a third party verifies a sealed artifact offline — recompute the canonical hash, check the signature against the published key — with no secret and no call to the issuer; a standalone verifier does exactly that in about 130 lines with nothing beyond Node's built-in crypto. The hash deliberately excludes the seal itself and any later attestations, so a regulator co-signing a version does not invalidate the issuer's signature over it.

• What must be true of a canonical form for two parties to hash it identically?
• Should decision records be sealed individually, batched, or chained?
• Who holds the issuer's signing keys, and what governs their use?
• If the seal cannot establish legal validity, what work is it doing in a dispute?

Specify the sealed record for one decision.

1. 01Define the canonical form of the authority artifact.
2. 02State what the seal covers and who signs it.
3. 03List the fields of the execution record, including the artifact hash.
4. 04Describe the steps a third party takes to verify the record without contacting you.
5. 05Identify what a successful verification does and does not prove.

• RFC 8785 — JSON Canonicalization Scheme.
• Digital signatures — integrity, authenticity, non-repudiation.
• Software supply chain — signed releases and provenance attestation (in-toto, SLSA).
• Records authenticity — the archival distinction between integrity and validity.
• Computable Authority, §12 — 'Provenance and Independent Verification'.
• NOMOS reference implementation — canonicalise (RFC 8785) then Ed25519-sign with a published public key; a zero-dependency offline verifier; the hash excludes the seal and later attestations so co-signing never breaks it.