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^[1]. 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^[2]. 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. The strongest objection is that a seal is only as trustworthy as the key behind it^[3]. Whoever holds the private key can seal anything, so a stolen or misused key produces artifacts that verify perfectly and mean nothing. Entirely correct, and it moves the governance question rather than dissolving it: who holds the signing key, under what controls, and how its compromise is detected and reversed. Revocation is part of the answer and has limits that should be stated plainly. In the reference implementation, a version can be revoked only while the key that sealed it is the current one; once a key has been rotated and its private half discarded, versions sealed under it can no longer be revoked by that mechanism — a disclosed limitation, not a hidden one. There is a quieter assumption in 'verify offline with the published key'. The verifier must first obtain the right public key, and fetching it from the issuer's website means trusting that website and the connection to it at that moment. This is the key-distribution problem every signature system inherits. The web's answer for certificates was to publish them in append-only public logs, so that a key issued in someone's name cannot be issued quietly^[4]; software supply-chain systems have adopted the same pattern for signed releases^[5]. An authority system that wants verification without trust in its operator needs an equivalent: a published, append-only history of which keys an issuer has used, and when. Finally, canonical form is harder than it looks. A canonicalisation scheme fixes key order, whitespace, and string escaping, but it inherits the number model of the format underneath — in JSON's case, double-precision floating point^[6]. An integer beyond about nine quadrillion, or a decimal that has no exact binary form, can round differently in two implementations, and two honest parties will then compute different hashes of what they believe is the same artifact. Artifacts that carry money or identifiers should represent them as strings.

• 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?
• How would a verifier who has never dealt with you know that the public key they fetched is really yours?

No responses yet. Be the first to answer one of the questions above.

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.
6. 06Describe what happens to every artifact you have sealed if the signing key is stolen tomorrow.