imbas-verify 0.1.0 → 0.1.1

package/CHANGELOG.md

@@ -0,0 +1,35 @@
+# Changelog
+
+All notable changes to `imbas-verify`. The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and the project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+`0.x` is deliberate: the record format is still settling, and a `1.0.0` would invite a consumer
+to build against it before it does.
+
+## [Unreleased]
+
+## [0.1.1]
+
+### Changed
+
+- **Verify-only build; no signing code shipped.** The package previously included
+  `signEnvelope`, `counterSignEnvelope` and every key-creation function, because the verifier
+  compiled the same source files the engine does. The tool that checks the evidence could also
+  manufacture it, which made "you do not have to trust us" false in the one way that matters.
+  Signing now lives in a module the verifier does not compile, and a test asserts that no
+  shipped file contains `createSign`, `generateKeyPair`, a private-key loader or a signing
+  entry point.
+
+  Nothing about verification changed: the same records verify, the same tampered ones are
+  refused, and the CLI surface is identical.
+
+## [0.1.0]
+
+### Added
+
+- First release. Verifies a signed Imbas approval record without the engine: DSSE envelope over
+  an in-toto Statement, ECDSA P-256, patch digest, provenance chain head, optional key-retirement
+  check.
+- `FORMAT.md` ships inside the package, so a record can be checked with `openssl` alone without
+  reaching anything else.
+- Zero runtime dependencies.

package/FORMAT.md

@@ -1,155 +1,155 @@
-# The Imbas approval record format
-
-This document is shipped inside the `imbas-verify` package so that you do not need to trust,
-reach, or have an account with Imbas to check a record. Everything below is enough to write
-an independent verifier. That is the point of publishing it.
-
-## 1. What a record is
-
-A record is a **DSSE envelope** (Dead Simple Signing Envelope, from the in-toto attestation
-specification) wrapping an **in-toto Statement v1**. Both formats are published, and `openssl`
-can verify the signature, so checking a record needs a public key and a shell — nothing else.
-
-Deliberately not Sigstore keyless signing. That flow publishes the signer's identity to a
-public transparency log, and an operator approving a change on their own machine should not
-have to announce that to the world. The key is local to the installation, and section 6 says
-plainly what that bounds.
-
-## 2. The envelope
-
-```json
-{
-  "payloadType": "application/vnd.in-toto+json",
-  "payload": "<base64 of the statement JSON>",
-  "signatures": [{ "keyid": "<sha256 hex>", "sig": "<base64 DER signature>" }]
-}
-```
-
-- **`payloadType`** is fixed at `application/vnd.in-toto+json`. Check it before anything else.
-- **`payload`** is the statement, base64-encoded. Decode **strictly**. `Buffer.from(x, "base64")`
-  silently skips characters it does not recognise, which can verify a tampered payload against
-  different bytes and then blame the cryptography for what is really bad encoding.
-- **`keyid`** is the lowercase hex `sha256` of the **DER SubjectPublicKeyInfo** — not of the PEM
-  text, and not of the private key.
-- **`sig`** is base64 of a **DER-encoded** ECDSA signature. Not IEEE-P1363 (the fixed `r||s`
-  form). Using the wrong one produces a signature that fails to verify for a reason that looks
-  like tampering, so if you are writing your own verifier, this is the first thing to check.
-- A record may carry **more than one signature**, for counter-signing. Every signature present
-  must be checked; the format's value is that there is more than one, so a verifier that checks
-  only `signatures[0]` throws away the reason counter-signing exists.
-
-## 3. PAE — the bytes that are actually signed
-
-You do not sign the JSON. You sign the **Pre-Authentication Encoding** of the payload, so that
-the type and the body cannot be swapped apart:
-
-```
-PAE(type, payload) = "DSSEv1" SP len(type) SP type SP len(payload) SP payload
-```
-
-where `SP` is a single space and `len()` is the **byte** length in ASCII decimal. The whole of
-it in JavaScript:
-
-```js
-const payload = Buffer.from(envelope.payload, "base64");
-const type = Buffer.from(envelope.payloadType, "utf8");
-const pae = Buffer.concat([
-  Buffer.from(`DSSEv1 ${type.length} `, "ascii"),
-  type,
-  Buffer.from(` ${payload.length} `, "ascii"),
-  payload,
-]);
-```
-
-`type.length` and `payload.length` are **byte** counts. Using `payload.toString("utf8").length`
-is wrong for any payload containing non-ASCII, and the error it produces is a signature failure
-that looks like an attack.
-
-## 4. The statement
-
-The decoded payload is an in-toto Statement:
-
-```json
-{
-  "_type": "https://in-toto.io/Statement/v1",
-  "subject": [{ "name": "changes.patch", "digest": { "sha256": "<hex>" } }],
-  "predicateType": "https://somernorth.co.uk/imbas/approval/v1",
-  "predicate": { "...": "the approval" }
-}
-```
-
-- **`subject[0].digest.sha256`** is over the **raw patch bytes**, exactly as stored. Do not
-  normalise line endings before hashing: that reports a mismatch for an honest file.
-- **`predicate`** carries the decision: which stage, which gate, who approved, the artifact, the
-  explainer shown, and the provenance chain head this approval continues from.
-
-The parsed statement must never be trusted before the envelope is known to hold what was
-signed. Otherwise a record can describe one thing and carry another, and both halves look
-individually valid.
-
-## 5. Verifying with `openssl` alone
-
-You need the record, the installation's public key PEM, and optionally the patch.
-
-```sh
-# 1. rebuild the signed bytes -> pae.bin, and extract signatures[0].sig -> sig.der
-#    (the fifteen lines in section 3, then base64 -d the sig field)
-
-# 2. verify
-openssl dgst -sha256 -verify imbas-pub.pem -signature sig.der pae.bin
-```
-
-`Verified OK` and exit 0, or `Verification failure` and exit 1.
-
-```sh
-# 3. the patch digest, if you have the patch
-sha256sum patch.diff     # compare with subject[0].digest.sha256
-```
-
-On Windows without coreutils, `sha256sum` ships with Git for Windows beside `openssl` at
-`C:\Program Files\Git\usr\bin\sha256sum.exe`. Any tool that hashes raw bytes agrees.
-
-If the `keyid` does not match the key you were given, you are verifying against the wrong key —
-check that before concluding the record was altered. "Wrong key" and "record tampered" are
-different problems with different fixes.
-
-## 6. What a record proves, and what it does not
-
-It proves:
-
-- **These exact bytes were signed** by the holder of the private key whose public half has the
-  quoted `keyid` — the signature is over the PAE bytes, so neither the payload nor the type can
-  change undetected.
-- **The patch is the one approved**, if the subject digest matches the file you hold.
-- **The chain head is intact**, if you check it: each record quotes the hash of the one before,
-  so an inserted or removed approval breaks the sequence.
-- **The decision that was recorded**, including who approved, at which gate, and what explainer
-  they were shown.
-
-It does not prove:
-
-- **That the change is good.** An approval records a decision, not a judgement about quality.
-  A careless approver produces a perfectly valid record.
-- **That the signer is who you think.** The key is local to one installation. Unless you obtained
-  the public key through a channel you already trust, a valid signature proves only that *some*
-  installation signed it. This is the honest limit of not using a transparency log, and it is
-  why the key must be pinned out of band.
-- **That a key was not revoked, unless you say so.** Pass `--retirements` to check. The three
-  answers stay distinct: `not listed` means the verifier looked and found nothing; `unchecked`
-  means you gave it nothing to look at. Only the first is a fact about the key.
-- **That the record is the only one.** Nothing here makes a record unique or non-repudiable
-  across installations.
-
-## 7. What the verifier does not do
-
-`imbas-verify` does not contact a network, apply a patch, read a configuration file, or open a
-data directory. It reads the files you name on the command line and nothing else. It has zero
-runtime dependencies: what you install is what is in the tarball.
-
-`--require-signer <keyid>` fails unless the named keyid has a valid signature — useful when you
-are given several keys and only some are acceptable for a given change.
-
-## 8. Licence and scope
-
-This document and the verifier are Apache-2.0. The engine that **produces** these records is a
-separate product; it is not included, not licensed here, and not required to check one.
+# The Imbas approval record format
+
+This document is shipped inside the `imbas-verify` package so that you do not need to trust,
+reach, or have an account with Imbas to check a record. Everything below is enough to write
+an independent verifier. That is the point of publishing it.
+
+## 1. What a record is
+
+A record is a **DSSE envelope** (Dead Simple Signing Envelope, from the in-toto attestation
+specification) wrapping an **in-toto Statement v1**. Both formats are published, and `openssl`
+can verify the signature, so checking a record needs a public key and a shell — nothing else.
+
+Deliberately not Sigstore keyless signing. That flow publishes the signer's identity to a
+public transparency log, and an operator approving a change on their own machine should not
+have to announce that to the world. The key is local to the installation, and section 6 says
+plainly what that bounds.
+
+## 2. The envelope
+
+```json
+{
+  "payloadType": "application/vnd.in-toto+json",
+  "payload": "<base64 of the statement JSON>",
+  "signatures": [{ "keyid": "<sha256 hex>", "sig": "<base64 DER signature>" }]
+}
+```
+
+- **`payloadType`** is fixed at `application/vnd.in-toto+json`. Check it before anything else.
+- **`payload`** is the statement, base64-encoded. Decode **strictly**. `Buffer.from(x, "base64")`
+  silently skips characters it does not recognise, which can verify a tampered payload against
+  different bytes and then blame the cryptography for what is really bad encoding.
+- **`keyid`** is the lowercase hex `sha256` of the **DER SubjectPublicKeyInfo** — not of the PEM
+  text, and not of the private key.
+- **`sig`** is base64 of a **DER-encoded** ECDSA signature. Not IEEE-P1363 (the fixed `r||s`
+  form). Using the wrong one produces a signature that fails to verify for a reason that looks
+  like tampering, so if you are writing your own verifier, this is the first thing to check.
+- A record may carry **more than one signature**, for counter-signing. Every signature present
+  must be checked; the format's value is that there is more than one, so a verifier that checks
+  only `signatures[0]` throws away the reason counter-signing exists.
+
+## 3. PAE — the bytes that are actually signed
+
+You do not sign the JSON. You sign the **Pre-Authentication Encoding** of the payload, so that
+the type and the body cannot be swapped apart:
+
+```
+PAE(type, payload) = "DSSEv1" SP len(type) SP type SP len(payload) SP payload
+```
+
+where `SP` is a single space and `len()` is the **byte** length in ASCII decimal. The whole of
+it in JavaScript:
+
+```js
+const payload = Buffer.from(envelope.payload, "base64");
+const type = Buffer.from(envelope.payloadType, "utf8");
+const pae = Buffer.concat([
+  Buffer.from(`DSSEv1 ${type.length} `, "ascii"),
+  type,
+  Buffer.from(` ${payload.length} `, "ascii"),
+  payload,
+]);
+```
+
+`type.length` and `payload.length` are **byte** counts. Using `payload.toString("utf8").length`
+is wrong for any payload containing non-ASCII, and the error it produces is a signature failure
+that looks like an attack.
+
+## 4. The statement
+
+The decoded payload is an in-toto Statement:
+
+```json
+{
+  "_type": "https://in-toto.io/Statement/v1",
+  "subject": [{ "name": "changes.patch", "digest": { "sha256": "<hex>" } }],
+  "predicateType": "https://somernorth.co.uk/imbas/approval/v1",
+  "predicate": { "...": "the approval" }
+}
+```
+
+- **`subject[0].digest.sha256`** is over the **raw patch bytes**, exactly as stored. Do not
+  normalise line endings before hashing: that reports a mismatch for an honest file.
+- **`predicate`** carries the decision: which stage, which gate, who approved, the artifact, the
+  explainer shown, and the provenance chain head this approval continues from.
+
+The parsed statement must never be trusted before the envelope is known to hold what was
+signed. Otherwise a record can describe one thing and carry another, and both halves look
+individually valid.
+
+## 5. Verifying with `openssl` alone
+
+You need the record, the installation's public key PEM, and optionally the patch.
+
+```sh
+# 1. rebuild the signed bytes -> pae.bin, and extract signatures[0].sig -> sig.der
+#    (the fifteen lines in section 3, then base64 -d the sig field)
+
+# 2. verify
+openssl dgst -sha256 -verify imbas-pub.pem -signature sig.der pae.bin
+```
+
+`Verified OK` and exit 0, or `Verification failure` and exit 1.
+
+```sh
+# 3. the patch digest, if you have the patch
+sha256sum patch.diff     # compare with subject[0].digest.sha256
+```
+
+On Windows without coreutils, `sha256sum` ships with Git for Windows beside `openssl` at
+`C:\Program Files\Git\usr\bin\sha256sum.exe`. Any tool that hashes raw bytes agrees.
+
+If the `keyid` does not match the key you were given, you are verifying against the wrong key —
+check that before concluding the record was altered. "Wrong key" and "record tampered" are
+different problems with different fixes.
+
+## 6. What a record proves, and what it does not
+
+It proves:
+
+- **These exact bytes were signed** by the holder of the private key whose public half has the
+  quoted `keyid` — the signature is over the PAE bytes, so neither the payload nor the type can
+  change undetected.
+- **The patch is the one approved**, if the subject digest matches the file you hold.
+- **The chain head is intact**, if you check it: each record quotes the hash of the one before,
+  so an inserted or removed approval breaks the sequence.
+- **The decision that was recorded**, including who approved, at which gate, and what explainer
+  they were shown.
+
+It does not prove:
+
+- **That the change is good.** An approval records a decision, not a judgement about quality.
+  A careless approver produces a perfectly valid record.
+- **That the signer is who you think.** The key is local to one installation. Unless you obtained
+  the public key through a channel you already trust, a valid signature proves only that *some*
+  installation signed it. This is the honest limit of not using a transparency log, and it is
+  why the key must be pinned out of band.
+- **That a key was not revoked, unless you say so.** Pass `--retirements` to check. The three
+  answers stay distinct: `not listed` means the verifier looked and found nothing; `unchecked`
+  means you gave it nothing to look at. Only the first is a fact about the key.
+- **That the record is the only one.** Nothing here makes a record unique or non-repudiable
+  across installations.
+
+## 7. What the verifier does not do
+
+`imbas-verify` does not contact a network, apply a patch, read a configuration file, or open a
+data directory. It reads the files you name on the command line and nothing else. It has zero
+runtime dependencies: what you install is what is in the tarball.
+
+`--require-signer <keyid>` fails unless the named keyid has a valid signature — useful when you
+are given several keys and only some are acceptable for a given change.
+
+## 8. Licence and scope
+
+This document and the verifier are Apache-2.0. The engine that **produces** these records is a
+separate product; it is not included, not licensed here, and not required to check one.

package/README.md

@@ -1,78 +1,78 @@
-# imbas-verify
-
-Check a signed Imbas approval record without Imbas.
-
-```sh
-npx imbas-verify approval.json --key installation-public.pem
-```
-
-```
-Verified OK
-  signed by  a1b2c3d4e5f60718
-  job        job_01HZX...
-  subject    changes.patch
-  sha256     9f2c... (full digest)
-  records    14
-  patch      matches the subject digest
-  retirement not listed
-```
-
-Exit code `0` means verified, `1` means a check failed and the first failing check is
-named, `2` means the arguments were wrong. Prose is for people; the exit code is the
-interface.
-
-## What it checks
-
-- **The signature** over the DSSE envelope, against the public keys you supply. Every
-  signature is checked, not the first one — a counter-signed record's value is that there
-  is more than one.
-- **The payload** is the signed bytes, byte for byte. The statement is parsed only after
-  the envelope is known to hold what was signed, so a record cannot describe one thing and
-  carry another.
-- **The patch digest**, if you pass `--patch`. It hashes the bytes, not a re-encoded
-  string.
-- **The provenance chain head** quoted in the record: that it is intact and ends at the
-  hash shown.
-- **Key retirement**, if you pass `--retirements`. The three answers are kept distinct:
-  `not listed` means the verifier looked and found nothing; `unchecked` means you gave it
-  nothing to look at. Only the first is a fact about the key.
-
-## What it does not do
-
-It does not contact a network, apply a patch, read a config file, or open a data
-directory. It reads the files you name on the command line and nothing else.
-
-It also does not tell you the change is good. An approval records a decision, and what a
-record proves and does not prove is written down in the statement itself.
-
-## Why you do not have to trust us
-
-The point of a verifier is that you can run it yourself. Two things make that true here:
-
-- **It is small.** Ten source files, all of them the record format. No pipeline, no
-  adapters, no gate logic, no configuration.
-- **It has no dependencies.** Zero. Not a smaller dependency tree — none at all. What you
-  install is what is in the tarball.
-
-The record format is public and implemented from its published specifications, so a
-record can also be checked with `openssl` alone. `FORMAT.md` in this package has the
-byte layout and the exact commands — it ships with the verifier precisely so that you do
-not need to reach anything else to check us.
-
-## Options
-
-```
---key <file>              a public key PEM to verify against. May be repeated.
---require-signer <keyid>  fail unless this keyid has a valid signature
---retirements <file>      the retirement list this verifier holds
---retirements-key <file>  the policy key's public half, to check the list's signature
---patch <file>            also check the record's subject digest against this file
---quiet                   print nothing but the failure, if any
-```
-
-## Licence
-
-Apache-2.0. See `LICENSE` and `NOTICE`.
-
-This package is the free half of Imbas. The engine that produces these records is a
-separate proprietary product; it is not included, not licensed here, and not needed.
+# imbas-verify
+
+Check a signed Imbas approval record without Imbas.
+
+```sh
+npx imbas-verify approval.json --key installation-public.pem
+```
+
+```
+Verified OK
+  signed by  a1b2c3d4e5f60718
+  job        job_01HZX...
+  subject    changes.patch
+  sha256     9f2c... (full digest)
+  records    14
+  patch      matches the subject digest
+  retirement not listed
+```
+
+Exit code `0` means verified, `1` means a check failed and the first failing check is
+named, `2` means the arguments were wrong. Prose is for people; the exit code is the
+interface.
+
+## What it checks
+
+- **The signature** over the DSSE envelope, against the public keys you supply. Every
+  signature is checked, not the first one — a counter-signed record's value is that there
+  is more than one.
+- **The payload** is the signed bytes, byte for byte. The statement is parsed only after
+  the envelope is known to hold what was signed, so a record cannot describe one thing and
+  carry another.
+- **The patch digest**, if you pass `--patch`. It hashes the bytes, not a re-encoded
+  string.
+- **The provenance chain head** quoted in the record: that it is intact and ends at the
+  hash shown.
+- **Key retirement**, if you pass `--retirements`. The three answers are kept distinct:
+  `not listed` means the verifier looked and found nothing; `unchecked` means you gave it
+  nothing to look at. Only the first is a fact about the key.
+
+## What it does not do
+
+It does not contact a network, apply a patch, read a config file, or open a data
+directory. It reads the files you name on the command line and nothing else.
+
+It also does not tell you the change is good. An approval records a decision, and what a
+record proves and does not prove is written down in the statement itself.
+
+## Why you do not have to trust us
+
+The point of a verifier is that you can run it yourself. Two things make that true here:
+
+- **It is small.** Ten source files, all of them the record format. No pipeline, no
+  adapters, no gate logic, no configuration.
+- **It has no dependencies.** Zero. Not a smaller dependency tree — none at all. What you
+  install is what is in the tarball.
+
+The record format is public and implemented from its published specifications, so a
+record can also be checked with `openssl` alone. `FORMAT.md` in this package has the
+byte layout and the exact commands — it ships with the verifier precisely so that you do
+not need to reach anything else to check us.
+
+## Options
+
+```
+--key <file>              a public key PEM to verify against. May be repeated.
+--require-signer <keyid>  fail unless this keyid has a valid signature
+--retirements <file>      the retirement list this verifier holds
+--retirements-key <file>  the policy key's public half, to check the list's signature
+--patch <file>            also check the record's subject digest against this file
+--quiet                   print nothing but the failure, if any
+```
+
+## Licence
+
+Apache-2.0. See `LICENSE` and `NOTICE`.
+
+This package is the free half of Imbas. The engine that produces these records is a
+separate proprietary product; it is not included, not licensed here, and not needed.

package/attestation.d.ts

@@ -1,5 +1,4 @@
 import { APPROVAL_PREDICATE_TYPE, DSSE_PAYLOAD_TYPE, IN_TOTO_STATEMENT_TYPE, type DsseEnvelope } from "./dsse.js";
-import { type InstallationKey } from "./key.js";
 import type { ApprovalPredicate } from "./record.js";
 import { type KeyRetirement, type RetirementList } from "./retirement.js";
 import { type Statement } from "./statement.js";
@@ -17,7 +16,6 @@ export interface AttestationFile {
     counter_signature?: CounterSignatureFile;
 }
 /** Writes an attestation as JSON. Two-space indent, so a human diff is readable. */
-export declare function writeAttestation(file: AttestationFile, path: string): void;
 /** A second party's signature, as it is written beside the envelope. */
 export interface CounterSignatureFile {
     /**
@@ -46,10 +44,6 @@ export interface CounterSignatureFile {
  * Throws rather than returning a result. A caller who asked to counter-sign has already
  * decided to vouch for a record, and a silent failure would leave them believing they had.
  */
-export declare function counterSign(file: AttestationFile, keys: readonly {
-    publicPem: string;
-    keyid: string;
-}[], counterKey: InstallationKey): AttestationFile;
 /**
  * Every check a verifier makes, in the order they run.
  *

package/attestation.js

@@ -9,72 +9,11 @@
  * only that the code is self-consistent.
  */
 import { createHash } from "node:crypto";
-import { readFileSync, writeFileSync } from "node:fs";
-import { APPROVAL_PREDICATE_TYPE, DSSE_PAYLOAD_TYPE, IN_TOTO_STATEMENT_TYPE, counterSignEnvelope, verifyEnvelopeSignatures, } from "./dsse.js";
+import { readFileSync } from "node:fs";
+import { APPROVAL_PREDICATE_TYPE, DSSE_PAYLOAD_TYPE, IN_TOTO_STATEMENT_TYPE, verifyEnvelopeSignatures, } from "./dsse.js";
 import { tryKeyIdOfPem } from "./key.js";
 import { judgeRetirement } from "./retirement.js";
 import { readStatement } from "./statement.js";
-/*
- * `attest` lives in `./attest-produce.js`, not here.
- *
- * It is the only function in this module that needs `predicate.ts`, and `predicate.ts`
- * reaches the pipeline, the gate helpers and the provenance store. Keeping it here meant
- * that importing the *verifier* pulled the engine's pipeline into its closure — 10
- * modules against the 5 a verifier actually uses. The verifier is given away on the
- * promise that checking a record needs nothing from Imbas, and this boundary is what keeps
- * that true; `engine/test/verify-standalone.test.ts` asserts it.
- */
-/** Writes an attestation as JSON. Two-space indent, so a human diff is readable. */
-export function writeAttestation(file, path) {
-    writeFileSync(path, `${JSON.stringify(file, null, 2)}\n`, "utf8");
-}
-/**
- * Adds a counter-signature to an existing record.
- *
- * The order of operations is the security property, and it is not negotiable:
- *
- *   1. verify every existing signature over the payload, and refuse if any fails;
- *   2. decode the payload those signatures actually cover;
- *   3. sign *those bytes*, unchanged.
- *
- * A counter-signer who signed without step 1 would be endorsing a record they had not
- * read, and their signature would add the appearance of a second opinion to a forged
- * document. Step 2 rather than re-serialising the `statement` field is the same lesson as
- * `attest`: the bytes that travel are the bytes that were signed, never a rebuild.
- *
- * Throws rather than returning a result. A caller who asked to counter-sign has already
- * decided to vouch for a record, and a silent failure would leave them believing they had.
- */
-export function counterSign(file, keys, counterKey) {
-    const verified = verifyEnvelopeSignatures(file.envelope, keys);
-    if (!verified.ok) {
-        throw new Error(`Refusing to counter-sign: the record does not verify first (${verified.check}). ${verified.message}`);
-    }
-    /*
-     * The readable copy must agree with the signed bytes.
-     *
-     * `statement` exists so a reader need not base64-decode; it is not the signed thing. But
-     * a file whose readable copy says one thing while the signature covers another is worse
-     * than no file at all — a reader who trusts the readable form has been lied to by a
-     * record that verifies. `attest` refuses to write such a file; a counter-signer must
-     * refuse to *endorse* one, because their signature would make the lie look vouched for.
-     */
-    const signed = readStatement(verified.payload);
-    if (!signed.ok || JSON.stringify(signed.statement) !== JSON.stringify(file.statement)) {
-        throw new Error("Refusing to counter-sign: the readable `statement` in this file does not match the bytes the signature covers. The file was edited after it was signed, so what a reader sees is not what was attested.");
-    }
-    // `verified.payload` is the decoded payload that every signature above was checked
-    // against, so signing it attests the same bytes rather than a re-serialisation.
-    const envelope = counterSignEnvelope(file.envelope, verified.payload, counterKey);
-    return {
-        ...file,
-        envelope,
-        counter_signature: {
-            signers: envelope.signatures.map((signature) => signature.keyid),
-            counter_signed_at: new Date().toISOString(),
-        },
-    };
-}
 function isEnvelope(value) {
     if (typeof value !== "object" || value === null)
         return false;

package/dsse.d.ts

@@ -1,19 +1,3 @@
-/**
- * DSSE: the envelope around a signed record.
- *
- * The format is not invented here. It is the Dead Simple Signing Envelope from the
- * in-toto attestation spec, because a record whose signature can only be checked by
- * the program that made it is a record nobody else can check. Choosing a published
- * format is what lets a third party verify an Imbas approval with nothing but the
- * public key and `openssl` — no Imbas code, no Imbas trust.
- *
- * The envelope carries a payload (here, an in-toto Statement), a payloadType, and a
- * signature over the *serialised pair* rather than over the payload alone. That
- * distinction is the whole point of PAE: if the signature covered only the payload,
- * an attacker could relabel the payloadType and the same signature would still verify
- * while the bytes meant something different.
- */
-import type { InstallationKey } from "./key.js";
 /** What a DSSE envelope's payload is. in-toto statements are JSON. */
 export declare const DSSE_PAYLOAD_TYPE = "application/vnd.in-toto+json";
 /** The in-toto Statement type. */
@@ -69,7 +53,8 @@ export declare function decodeBase64(text: string): Buffer | null;
  * afterwards would leave a signature over one document beside a file claiming to be
  * another, and nothing would verify it.
  */
-export declare function signEnvelope(payload: Buffer, key: InstallationKey, payloadType?: string): DsseEnvelope;
+/** The base64 signature over the PAE bytes for a payload. Shared by both signers. */
+/** The base64 signature over the PAE bytes of an in-toto statement. */
 /**
  * Adds a second, independent signature to an envelope that is already signed.
  *
@@ -90,7 +75,6 @@ export declare function signEnvelope(payload: Buffer, key: InstallationKey, payl
  * ambiguous, and an ambiguous answer is worse than a refused request: a reader would
  * count two signatures and conclude two parties.
  */
-export declare function counterSignEnvelope(envelope: DsseEnvelope, payload: Buffer, key: InstallationKey): DsseEnvelope;
 /**
  * Which check failed, so a verifier can say the first one rather than "invalid".
  *

package/dsse.js

@@ -1,3 +1,18 @@
+/**
+ * DSSE: the envelope around a signed record.
+ *
+ * The format is not invented here. It is the Dead Simple Signing Envelope from the
+ * in-toto attestation spec, because a record whose signature can only be checked by
+ * the program that made it is a record nobody else can check. Choosing a published
+ * format is what lets a third party verify an Imbas approval with nothing but the
+ * public key and `openssl` — no Imbas code, no Imbas trust.
+ *
+ * The envelope carries a payload (here, an in-toto Statement), a payloadType, and a
+ * signature over the *serialised pair* rather than over the payload alone. That
+ * distinction is the whole point of PAE: if the signature covered only the payload,
+ * an attacker could relabel the payloadType and the same signature would still verify
+ * while the bytes meant something different.
+ */
 import { verifyBytes } from "./key.js";
 /** What a DSSE envelope's payload is. in-toto statements are JSON. */
 export const DSSE_PAYLOAD_TYPE = "application/vnd.in-toto+json";
@@ -46,68 +61,6 @@ export function decodeBase64(text) {
         return null;
     return Buffer.from(text, "base64");
 }
-/**
- * Signs a payload, producing a one-signature envelope.
- *
- * `payloadType` defaults to the in-toto statement type because almost every envelope here
- * carries one. The retirement list passes its own: the type is part of the PAE bytes the
- * signature covers, so it must be chosen *before* signing. Relabelling an envelope
- * afterwards would leave a signature over one document beside a file claiming to be
- * another, and nothing would verify it.
- */
-export function signEnvelope(payload, key, payloadType = DSSE_PAYLOAD_TYPE) {
-    return {
-        payloadType,
-        payload: payload.toString("base64"),
-        // ECDSA signatures are DER-encoded here, not IEEE-P1363. Both are legitimate for
-        // ECDSA and they are not interchangeable: DER is a tagged ASN.1 SEQUENCE of r and
-        // s, P1363 is raw r||s. DER is chosen because it is what `openssl dgst -verify`
-        // reads without extra flags, and an independent check that needs Imbas-specific
-        // instructions is not independent. `signBytes` pins `dsaEncoding: "der"` to match.
-        signatures: [{ keyid: key.keyid, sig: signatureOver(payloadType, payload, key) }],
-    };
-}
-/** The base64 signature over the PAE bytes for a payload. Shared by both signers. */
-function signatureOver(payloadType, payload, key) {
-    return key.signBytes(pae(payloadType, payload)).toString("base64");
-}
-/** The base64 signature over the PAE bytes of an in-toto statement. */
-function attestationSignature(payload, key) {
-    return signatureOver(DSSE_PAYLOAD_TYPE, payload, key);
-}
-/**
- * Adds a second, independent signature to an envelope that is already signed.
- *
- * This is what makes one installation's word checkable by another. The payload is not
- * touched — not re-serialised, not reformatted — because the whole value of the first
- * signature is that it covers these exact bytes. A counter-signature over a
- * re-serialised copy would be a signature over a different document that happened to
- * mean the same thing, which is not the same claim.
- *
- * The payload arrives as bytes rather than as the envelope's base64 for one reason: the
- * caller must have already verified the existing signature and decoded it. Adding a
- * signature to bytes nobody has checked would let a counter-signer endorse a forged
- * record, and the parameter shape makes that obligation visible at the call site rather
- * than leaving it to a comment. See `verifyEnvelopeSignatures`, which is how a caller
- * earns the right to call this.
- *
- * Refuses a key that already signed. Two signatures with one keyid make "signed by whom"
- * ambiguous, and an ambiguous answer is worse than a refused request: a reader would
- * count two signatures and conclude two parties.
- */
-export function counterSignEnvelope(envelope, payload, key) {
-    if (envelope.signatures.some((signature) => signature.keyid === key.keyid)) {
-        throw new Error(`This envelope is already signed by ${key.keyid.slice(0, 16)}…. A counter-signature has to come from a second key, or it proves nothing.`);
-    }
-    if (envelope.payload !== payload.toString("base64")) {
-        throw new Error("The payload does not match the one the envelope carries, so a signature over it would attest different bytes than the existing signatures cover.");
-    }
-    return {
-        payloadType: envelope.payloadType,
-        payload: envelope.payload,
-        signatures: [...envelope.signatures, { keyid: key.keyid, sig: attestationSignature(payload, key) }],
-    };
-}
 /**
  * Checks one signature over the given payload, returning the failure or null.
  *

package/key.d.ts

@@ -11,9 +11,13 @@
  *
  * The private key is written once, with the tightest permission the OS offers, and is
  * never read into a response, a log line, a provenance record or an export. Nothing
- * in this module hands it out: `loadOrCreateKey` returns a handle whose only outward
- * key material is `publicPem()`. The private PEM lives in a closure, so a caller
- * cannot find it by spreading the object or serialising it.
+ * in this module hands it out: the loader in `signing.ts` returns a handle whose only
+ * outward key material is `publicPem()`. The private PEM lives in a closure, so a
+ * caller cannot find it by spreading the object or serialising it.
+ *
+ * This file is compiled into the published verifier, so it holds only what *checking* a
+ * signature needs. Key creation and signing live in `signing.ts`, which the verifier does
+ * not compile — the tool that checks the evidence must not be able to manufacture it.
  */
 import { type KeyObject } from "node:crypto";
 /** Where the installation key lives inside a data dir. */
@@ -72,7 +76,6 @@ export interface InstallationKey {
  */
 export declare function verifyBytes(publicPem: string, bytes: Buffer, signature: Buffer): boolean;
 /** Builds a handle around a private key already in memory. */
-export declare function handleFor(privateKey: KeyObject, publicPem: string, keyid: string): InstallationKey;
 /**
  * Loads the installation key, generating it on first use.
  *
@@ -80,7 +83,6 @@ export declare function handleFor(privateKey: KeyObject, publicPem: string, keyi
  * exists when it is first needed, in the data dir, with no separate setup step that
  * can be skipped and leave signing broken later.
  */
-export declare function loadOrCreateKey(dataDir: string): InstallationKey;
 /**
  * Loads or creates a key pair at explicit paths.
  *
@@ -89,7 +91,6 @@ export declare function loadOrCreateKey(dataDir: string): InstallationKey;
  * key rather than a copy. A second copy of the permission dance is a second place for it to
  * drift, and the drift would be invisible on Windows where the mode bits are advisory.
  */
-export declare function loadOrCreateNamedKey(privatePath: string, publicPath: string): InstallationKey;
 /**
  * The policy key: what signs a retirement list, and nothing else.
  *
@@ -108,9 +109,7 @@ export declare function loadOrCreateNamedKey(privatePath: string, publicPath: st
 export declare function policyKeyDir(dataDir: string): string;
 export declare function policyPrivateKeyPath(dataDir: string): string;
 export declare function policyPublicKeyPath(dataDir: string): string;
-export declare function loadOrCreatePolicyKey(dataDir: string): InstallationKey;
 /** An in-memory key pair, for tests and the demo. Never written to disk. */
-export declare function ephemeralKey(): InstallationKey;
 /**
  * Builds a signing handle from a private key PEM already in memory.
  *
@@ -131,4 +130,3 @@ export type PrivateKeyRead = {
     ok: false;
     message: string;
 };
-export declare function handleFromPrivatePem(text: string): PrivateKeyRead;

package/key.js

@@ -11,13 +11,16 @@
  *
  * The private key is written once, with the tightest permission the OS offers, and is
  * never read into a response, a log line, a provenance record or an export. Nothing
- * in this module hands it out: `loadOrCreateKey` returns a handle whose only outward
- * key material is `publicPem()`. The private PEM lives in a closure, so a caller
- * cannot find it by spreading the object or serialising it.
+ * in this module hands it out: the loader in `signing.ts` returns a handle whose only
+ * outward key material is `publicPem()`. The private PEM lives in a closure, so a
+ * caller cannot find it by spreading the object or serialising it.
+ *
+ * This file is compiled into the published verifier, so it holds only what *checking* a
+ * signature needs. Key creation and signing live in `signing.ts`, which the verifier does
+ * not compile — the tool that checks the evidence must not be able to manufacture it.
  */
-import { createHash, createPrivateKey, createPublicKey, generateKeyPairSync, sign, verify } from "node:crypto";
-import { chmodSync, existsSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
-import { dirname, join, resolve } from "node:path";
+import { createHash, createPublicKey, verify } from "node:crypto";
+import { join, resolve } from "node:path";
 /** Where the installation key lives inside a data dir. */
 export function keyDir(dataDir) {
     return join(resolve(dataDir), "keys");
@@ -98,13 +101,6 @@ export function verifyBytes(publicPem, bytes, signature) {
     }
 }
 /** Builds a handle around a private key already in memory. */
-export function handleFor(privateKey, publicPem, keyid) {
-    return {
-        keyid,
-        publicPem: () => publicPem,
-        signBytes: (bytes) => sign("sha256", bytes, { key: privateKey, dsaEncoding: "der" }),
-    };
-}
 /**
  * Loads the installation key, generating it on first use.
  *
@@ -112,9 +108,6 @@ export function handleFor(privateKey, publicPem, keyid) {
  * exists when it is first needed, in the data dir, with no separate setup step that
  * can be skipped and leave signing broken later.
  */
-export function loadOrCreateKey(dataDir) {
-    return loadOrCreateNamedKey(privateKeyPath(dataDir), publicKeyPath(dataDir));
-}
 /**
  * Loads or creates a key pair at explicit paths.
  *
@@ -123,34 +116,6 @@ export function loadOrCreateKey(dataDir) {
  * key rather than a copy. A second copy of the permission dance is a second place for it to
  * drift, and the drift would be invisible on Windows where the mode bits are advisory.
  */
-export function loadOrCreateNamedKey(privatePath, publicPath) {
-    if (!existsSync(privatePath)) {
-        mkdirSync(dirname(privatePath), { recursive: true });
-        const { privateKey, publicKey } = generateKeyPairSync("ec", { namedCurve: "P-256" });
-        const privatePem = privateKey.export({ type: "pkcs8", format: "pem" }).toString();
-        const publicPem = publicKey.export({ type: "spki", format: "pem" }).toString();
-        // Written with 0600 and then chmodded, which is belt and braces on POSIX and
-        // mostly a statement of intent on Windows: Windows does not map `chmod` onto a
-        // DACL, so `mode` and `chmodSync` are largely ignored there. On Windows the
-        // private key's protection comes from the ACL of the containing directory — the
-        // user's profile — not from this bit. Saying that plainly is better than implying
-        // a guarantee the platform does not give. On a shared Windows machine, securing
-        // the data dir is the operator's job and `docs/EVIDENCE.md` says so.
-        writeFileSync(privatePath, privatePem, { encoding: "utf8", mode: 0o600 });
-        writeFileSync(publicPath, publicPem, { encoding: "utf8", mode: 0o644 });
-        try {
-            chmodSync(privatePath, 0o600);
-        }
-        catch {
-            // A filesystem that cannot express modes (FAT32, some network shares) must not
-            // stop signing from working. The trade-off is documented in docs/EVIDENCE.md.
-        }
-    }
-    const privateKey = createPrivateKey(readFileSync(privatePath, "utf8"));
-    const publicKey = createPublicKey(privateKey);
-    const publicPem = publicKey.export({ type: "spki", format: "pem" }).toString();
-    return handleFor(privateKey, publicPem, keyIdOf(publicKey));
-}
 /**
  * The policy key: what signs a retirement list, and nothing else.
  *
@@ -175,34 +140,3 @@ export function policyPrivateKeyPath(dataDir) {
 export function policyPublicKeyPath(dataDir) {
     return join(policyKeyDir(dataDir), "policy-key.pub.pem");
 }
-export function loadOrCreatePolicyKey(dataDir) {
-    return loadOrCreateNamedKey(policyPrivateKeyPath(dataDir), policyPublicKeyPath(dataDir));
-}
-/** An in-memory key pair, for tests and the demo. Never written to disk. */
-export function ephemeralKey() {
-    const { privateKey, publicKey } = generateKeyPairSync("ec", { namedCurve: "P-256" });
-    return handleFor(privateKey, publicKey.export({ type: "spki", format: "pem" }).toString(), keyIdOf(publicKey));
-}
-export function handleFromPrivatePem(text) {
-    let privateKey;
-    try {
-        privateKey = createPrivateKey(text);
-    }
-    catch {
-        return {
-            ok: false,
-            message: "The signing key is not a PEM private key (it does not begin with -----BEGIN PRIVATE KEY----- or -----BEGIN EC PRIVATE KEY-----).",
-        };
-    }
-    // `createPrivateKey` also accepts a *public* key PEM in some builds, and signing with
-    // one fails deep inside OpenSSL. Asking for the private half first turns that into a
-    // sentence at the boundary.
-    if (privateKey.type !== "private") {
-        return {
-            ok: false,
-            message: `The signing key is a ${privateKey.type} key. Counter-signing needs the private half.`,
-        };
-    }
-    const publicPem = createPublicKey(privateKey).export({ type: "spki", format: "pem" }).toString();
-    return { ok: true, key: handleFor(privateKey, publicPem, tryKeyIdOfPem(publicPem) ?? keyIdOfPem(publicPem)) };
-}

package/package.json

@@ -1,11 +1,11 @@
 {
   "name": "imbas-verify",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "Check a signed Imbas approval record without the engine. Verifies signatures, the patch digest and the provenance chain head; reads only the files you name.",
   "license": "Apache-2.0",
   "type": "module",
   "bin": {
-    "imbas-verify": "./verify-cli.js"
+    "imbas-verify": "verify-cli.js"
   },
   "main": "./verify.js",
   "types": "./verify.d.ts",
@@ -24,6 +24,7 @@
     "*.d.ts",
     "README.md",
     "FORMAT.md",
+    "CHANGELOG.md",
     "LICENSE",
     "NOTICE"
   ],

package/retirement.d.ts

@@ -1,5 +1,4 @@
 import { type DsseEnvelope } from "./dsse.js";
-import { type InstallationKey } from "./key.js";
 /** One retirement, as it appears in the list. */
 export interface KeyRetirement {
     keyid: string;
@@ -161,17 +160,6 @@ export declare function isIsoDate(text: string): boolean;
  * a widening of trust, and this refuses that too — a list whose entries can be revised is
  * a list a verifier cannot reason about.
  */
-export declare function appendRetirement(input: {
-    path: string;
-    keyid: string;
-    retiredAt: string;
-    reason: string;
-    now?: string;
-    /** The keyid that replaces this one, when the operator is rotating rather than losing it. */
-    supersedes?: string;
-    /** The policy key. Required for a signed list; absent writes a bare, unsigned one. */
-    policyKey?: InstallationKey;
-}): KeyRetirement;
 /**
  * Serialises the entries once and signs those bytes.
  *
@@ -181,10 +169,6 @@ export declare function appendRetirement(input: {
  * insertion order, which is deterministic for a given object, and the entries are built in
  * one place — so a re-serialisation by `verifyListSignature` produces the same bytes.
  */
-export declare function sealList(entries: {
-    schema_version: string;
-    retirements: KeyRetirement[];
-}, key: InstallationKey): SignedRetirementList;
 /**
  * Checks the signature over a list, before any entry is read.
  *

package/retirement.js

@@ -34,8 +34,8 @@
  * would make the file worthless: a verifier reading the current state could not tell a
  * key that was never retired from one whose retirement was quietly withdrawn.
  */
-import { mkdirSync, readFileSync, writeFileSync } from "node:fs";
-import { signEnvelope, verifyEnvelopeSignatures } from "./dsse.js";
+import { readFileSync } from "node:fs";
+import { verifyEnvelopeSignatures } from "./dsse.js";
 import { tryKeyIdOfPem } from "./key.js";
 import { join, resolve } from "node:path";
 /**
@@ -266,57 +266,6 @@ export function isIsoDate(text) {
  * a widening of trust, and this refuses that too — a list whose entries can be revised is
  * a list a verifier cannot reason about.
  */
-export function appendRetirement(input) {
-    if (!isIsoDate(input.retiredAt)) {
-        throw new RetirementError("retired_at_invalid", `"${input.retiredAt}" is not an ISO 8601 timestamp. A retirement that cannot be compared against a record's time is not a retirement.`);
-    }
-    if (input.reason.trim().length === 0) {
-        throw new RetirementError("reason_required", "A retirement needs a reason. It will be read by somebody deciding whether to trust a record.");
-    }
-    /*
-     * Checked here as well as in `parseRetirement`, and this is not duplication for its own
-     * sake: the parse would catch it on the *next* read, after the operator had been told the
-     * retirement succeeded. A key that succeeded itself would make the chain follow forever,
-     * so it has to be refused before the file is written.
-     */
-    if (input.supersedes !== undefined && input.supersedes.trim().length === 0) {
-        throw new RetirementError("supersedes_invalid", "`supersedes` was given but names no key. Leave it out when the retired key has no successor.");
-    }
-    if (input.supersedes !== undefined && input.supersedes === input.keyid) {
-        throw new RetirementError("supersedes_self", `A key cannot succeed itself (${input.keyid.slice(0, 16)}…). Name the new key, or leave --supersedes out.`);
-    }
-    const read = readRetirementList(input.path);
-    if (!read.ok)
-        throw new RetirementError(read.code, read.message);
-    const existing = read.list.retirements.find((entry) => entry.keyid === input.keyid);
-    if (existing !== undefined) {
-        throw new RetirementError("already_retired", `Key ${input.keyid.slice(0, 16)}… is already retired as of ${existing.retired_at} (${existing.reason}). A second entry would leave a reader choosing between two moments.`);
-    }
-    const retirement = {
-        keyid: input.keyid,
-        retired_at: input.retiredAt,
-        reason: input.reason.trim(),
-        recorded_at: input.now ?? new Date().toISOString(),
-        ...(input.supersedes === undefined ? {} : { supersedes: input.supersedes }),
-    };
-    const entries = {
-        schema_version: read.list.schema_version,
-        retirements: [...read.list.retirements, retirement],
-    };
-    /*
-     * The list is rewritten on every retirement, and the signature is therefore over the
-     * whole list rather than appended to. That is correct: what a verifier needs is "these
-     * entries are what the policy key signed", and a signature per entry would let somebody
-     * drop an entry while leaving its neighbours' signatures intact. A single signature over
-     * the whole list makes any removal or insertion visible.
-     */
-    const signed = input.policyKey
-        ? sealList(entries, input.policyKey)
-        : { entries, envelope: null };
-    mkdirSync(join(resolve(input.path), ".."), { recursive: true });
-    writeFileSync(resolve(input.path), `${JSON.stringify(signed, null, 2)}\n`, "utf8");
-    return retirement;
-}
 /**
  * Serialises the entries once and signs those bytes.
  *
@@ -326,21 +275,6 @@ export function appendRetirement(input) {
  * insertion order, which is deterministic for a given object, and the entries are built in
  * one place — so a re-serialisation by `verifyListSignature` produces the same bytes.
  */
-export function sealList(entries, key) {
-    const payload = Buffer.from(JSON.stringify(entries), "utf8");
-    /*
-     * The payload type is the list's own, and it is chosen here rather than restamped
-     * afterwards. It is part of the PAE bytes the signature covers, so the type must be set
-     * when signing; a relabelled envelope would carry a signature over a different document
-     * and nothing would verify it.
-     */
-    return {
-        entries,
-        // ECDSA over the PAE bytes, exactly as an attestation signature is, so openssl can
-        // check this list with the same command it checks a record with.
-        envelope: signEnvelope(payload, key, RETIREMENT_PAYLOAD_TYPE),
-    };
-}
 /**
  * Checks the signature over a list, before any entry is read.
  *

package/statement.d.ts

@@ -11,8 +11,7 @@
  * and the predicate says so in its own words (step 3). A signed record that overstates
  * what it proves is worse than no record, because it gets believed.
  */
-import { APPROVAL_PREDICATE_TYPE, DSSE_PAYLOAD_TYPE, IN_TOTO_STATEMENT_TYPE, type DsseEnvelope } from "./dsse.js";
-import type { InstallationKey } from "./key.js";
+import { APPROVAL_PREDICATE_TYPE, DSSE_PAYLOAD_TYPE, IN_TOTO_STATEMENT_TYPE } from "./dsse.js";
 /** A subject digest: the algorithm and the hex digest of the exact bytes. */
 export interface SubjectDigest {
     sha256: string;
@@ -39,23 +38,6 @@ export interface Statement<T> {
 }
 /** Builds a statement around a predicate. The caller supplies the subject. */
 export declare function buildStatement<T>(subject: Subject, predicate: T): Statement<T>;
-/**
- * Serialises a statement and signs it.
- *
- * The bytes that get signed are the bytes produced here, and those are the bytes that
- * travel in the envelope — not a re-serialisation. Anything that parsed the statement
- * and wrote it back out would reorder keys or change whitespace, and the signature
- * would then cover a slightly different document than the one on disk. So the payload
- * is built once, as a Buffer, and never rebuilt.
- *
- * Key order is insertion order, which `JSON.stringify` preserves for string keys, so
- * the output is deterministic for a given statement — two attestations of the same
- * job produce byte-identical payloads, which makes them comparable.
- */
-export declare function sealStatement<T>(statement: Statement<T>, key: InstallationKey): {
-    payload: Buffer;
-    envelope: DsseEnvelope;
-};
 /**
  * Reads a statement back out of verified payload bytes.
  *

package/statement.js

@@ -11,7 +11,7 @@
  * and the predicate says so in its own words (step 3). A signed record that overstates
  * what it proves is worse than no record, because it gets believed.
  */
-import { APPROVAL_PREDICATE_TYPE, DSSE_PAYLOAD_TYPE, IN_TOTO_STATEMENT_TYPE, signEnvelope, } from "./dsse.js";
+import { APPROVAL_PREDICATE_TYPE, DSSE_PAYLOAD_TYPE, IN_TOTO_STATEMENT_TYPE, } from "./dsse.js";
 /** Builds a statement around a predicate. The caller supplies the subject. */
 export function buildStatement(subject, predicate) {
     return {
@@ -21,23 +21,6 @@ export function buildStatement(subject, predicate) {
         predicate,
     };
 }
-/**
- * Serialises a statement and signs it.
- *
- * The bytes that get signed are the bytes produced here, and those are the bytes that
- * travel in the envelope — not a re-serialisation. Anything that parsed the statement
- * and wrote it back out would reorder keys or change whitespace, and the signature
- * would then cover a slightly different document than the one on disk. So the payload
- * is built once, as a Buffer, and never rebuilt.
- *
- * Key order is insertion order, which `JSON.stringify` preserves for string keys, so
- * the output is deterministic for a given statement — two attestations of the same
- * job produce byte-identical payloads, which makes them comparable.
- */
-export function sealStatement(statement, key) {
-    const payload = Buffer.from(JSON.stringify(statement, null, 2), "utf8");
-    return { payload, envelope: signEnvelope(payload, key) };
-}
 export function readStatement(payload) {
     let parsed;
     try {