v1.5.0

Sigilbase evidence verifier v1.5.0

verify.php sha256:
3a8b1831024d47c3bceabeb55294b968dec7ef6ab5fd4293ee5429840c854a0a

Every run prints this hash. Compare it with the line above before you
trust what a verifier tells you.

Five results

A verification now reports five things separately, because they answer
different questions:

Result	What it covers
Content integrity	The hash chain, payload hashes, Merkle roots and checkpoint signatures
Signing identity	Whether the checkpoints were signed by a key this verifier trusts, inside that key's window
Timestamps	The RFC 3161 anchors, against trust roots the verifier carries
Scope	The range and completeness the manifest claims
Redactions	Whether every absent payload is named by an authenticated declaration

Content integrity is a question about the bundle. Signing identity is a
question about the world outside it: anyone can produce a hash chain and
sign it with a key of their own, and a bundle cannot establish whose keys
it carries. Reporting both under one word could only ever answer one.

Four exit codes

Exit	Word	Meaning
0	PASS	Every result that was checked holds
1	FAIL	Content integrity, redactions or a key window failed
2	ERROR	Usage, an unreadable bundle, or an unknown format
3	UNCONFIRMED	The maths holds, but the signing identity or the timestamps could not be confirmed

Exit 3 is not a failure and not a pass. It means the bundle is internally
sound and its origin is not established — which is the true answer for a
bundle signed by a key you have not told the verifier to trust.

Trusted keys, and how to change them

The release carries Sigilbase's signing keys, compiled into verify.php
from keys/sigilbase.json. Keys are matched on their public key bytes,
and each is identified by a fingerprint you can recompute yourself: the
first 16 hex characters of the SHA-256 of the raw public key.

php verify.php --keys my-keys.json bundle.zip

--keys replaces the set entirely. The file uses the same shape as
https://app.sigilbase.io/api/v1/keys, so you can fetch the keys
yourself and verify against what you fetched rather than against what we
shipped. Private deployments and test keys use the same option.

--tsa-roots roots.pem does the same for timestamp authorities. An
anchor that chains only to a root the bundle itself supplied makes the
timestamps result unconfirmed: that shows the bundle is self-consistent,
not that an authority you trust issued the timestamp.

Format 1.5: declarations travel with the bundle

A bundle whose payloads have been destroyed now carries the declarations
that destroyed them, in declarations.ndjson, with
declaration_proofs.json holding an audit path and sealing checkpoint
for any that sit outside the exported range.

An absent payload is accepted only when a declaration in the bundle:

1. recomputes its own entry hash,
2. matches its payload hash,
3. carries the action matching the kind of absence,
4. names that exact stream and sequence in its targets,
5. was sealed in a checkpoint whose signature verifies inside its key's
   trusted window, and
6. comes after the event, when it sits in the same stream.

redactions.json remains as a convenience index and decides nothing.

A bundle below format 1.5 that contains an absent payload does not
verify, and says to export the range again. There is nothing in such a
bundle to check the absence against, and reporting that as a pass would
be reporting a verdict that was never reached.

Bundle size no longer bounds who can verify

events.ndjson is read a line at a time, and both Merkle trees are
folded as the events go past rather than built from arrays of them, so
memory does not grow with the export. A 92.6 MB bundle of 1,000,000
events — 1.35 GB of events.ndjson — verifies inside PHP's default 128
MB limit, and in fact inside 32 MB.

The exception is --consistency, which generates a proof over the whole
tree and therefore does hold the entry hashes. Ordinary verification
never does.

Other

• --help prints usage and exits 0.
• The conformance corpus ships keys.json, the published test key that
  signs it. Pass it as --keys when running the corpus.

Upgrading

Bundles at every earlier format still verify. Re-export any bundle that
contains a redacted or erased payload to get one whose absences can be
checked.

v1.4.2

Verifier 1.4.2: verifies sigilbase-evidence/1 through /1.4

Anchor validation holds every issuer certificate in a timestamp token's
chain to CA rules: basicConstraints cA, keyCertSign where keyUsage is
present, validity at genTime, and pathLenConstraint.

Checkpoint validation holds every checkpoint to its signing key's active
window, as stated in the manifest, comparing the seal time in the signed
preimage against the key's created_at and retired_at.

The release carries the conformance corpus and the golden vectors that
every implementation is held to.

sha256 of verify.php:
b9f5bece52742856ef7c8ffaf4978799e216a595e0168f25dd2d2d5c04269c08

v1.4.0

Release v1.4.0: the SigilSign blocks and per-version release builds

Format 1.4 adds three optional, informational-but-verifiable files:
documents.json (a stream's documents by hash and metadata),
signatures.json (signature records carrying per-signer facts including
the sha256 of the exact version each signer viewed and signed), and
links.json (document-to-event associations with the sequences of their
ledgered facts). The verifier cross-checks every stated hash and
sequence against the events themselves and fails the bundle on any
contradiction - metadata must never tell a different story from the
chain - while fields it does not know, including any claim about legal
effect or validity, are ignored entirely and can never influence the
verdict. Signatures recorded in these bundles are simple electronic
signatures; the format asserts nothing about their effect in any
jurisdiction. Format 1.4 also reserves witness.json and
attestations.json for cross-tenant witnessing and the verification
attestation chain, specified but not yet emitted. Formats 1 through 1.3
verify exactly as before. Releases now build per tag: the test matrix
runs and the release carries verify.php, FORMAT.md, and their SHA-256
checksums.

v1.3.0

Verifier 1.3.0: verifies sigilbase-evidence/1 through /1.3

v1.2.0

Verifier 1.2.0: verifies sigilbase-evidence/1, /1.1 and /1.2

v1.1.0

Verifier 1.1.0: verifies sigilbase-evidence/1 and /1.1