Skip to main content

Signing and Provenance

System9 attaches provenance at the moment of origin and checks it at the moment of use. A signature is not a database row that a system of record vouches for later. It is a value that travels with the artifact and can be re-derived and re-checked by anyone holding the signer's public key.

Signed at origin​

Signing happens where the artifact is produced, not at a checkpoint it passes through afterward:

ArtifactSigned where
A captured frameOn the device, at capture, with content-provenance markings
A policyBy the issuing entity, before it replicates
A workflow stepWith a cell-identity signature over its input and output hashes
A modelIn the provisioning pipeline; a signed-manifest admission gate refuses an altered artifact at load
A jobAs a signed envelope addressed entity-to-entity
A shared datasetIts compiled policy travels with it in a signed envelope
A cross-org listingA signed attestation of the offer's identity, content fingerprint, reach, and scope
A cell's configurationAn attestation signed by the cell itself
A licenceEd25519, verified offline

The consequence is a property most platforms cannot state: an action anywhere in the estate traces back through an unbroken cryptographic chain to the entity that authorized it. Verification recomputes what was signed and checks it, rather than trusting that an intermediary preserved it faithfully.

Canonical bytes​

A signature is only reproducible if both sides agree, exactly, on the bytes that were signed. System9 defines a canonical body for each signed artifact class: a deterministic, sorted-key, compact serialization that both runtimes reproduce byte-for-byte. A content hash (lowercase SHA-256 hex over the canonical bytes) is carried alongside the signature; the verifier recomputes it from the artifact's own fields, so a field altered after signing surfaces as a hash mismatch before any signature check runs.

Serialization details that would otherwise drift silently, key ordering, Unicode escaping, whether a scope is treated as an ordered list or an unordered set, are frozen as part of the contract and pinned by cross-language fixtures, so a producer on one runtime and a verifier on the other never disagree.

Domain separation: one signature, one purpose​

Every signed body is prefixed with a domain separator: a short, purpose- specific tag mixed into the signed message. A cross-org listing is signed over s9.crossorg.listing.v1 bytes; a package, a receipt, and a grant each carry their own separator. Because the separator is part of what the key signs, a signature minted for one artifact class cannot be replayed as another, a listing signature presented as a package signature simply fails to verify.

Each artifact class also carries a frozen provenance version. Any change to the set of signed fields must bump that version, so an old artifact never silently verifies under new rules, and moving the wire format is a deliberate, multi-file change rather than a quiet re-stamp.

Verified at use​

Verification is designed to be stateless, pure, offline, and fail-closed. It recomputes the canonical bytes, checks the content hash, checks the signature against a pinned public key, and returns a verdict, never a crash on malformed input, and never a silent pass. It reads the current time from the caller rather than a wall clock, so a disconnected cell judges validity windows against its own anchor-corrected clock.

This is what makes provenance hold at the edge. The Edge Agent consumes signed attestations, commands, configuration, ontology snapshots, cross-org listings, and verifies them locally against keys pinned out-of-band, with no cell to call. Signing stays a cell-side act; verification runs on both runtimes.

Content and certificate transparency​

Beyond artifact signatures, System9 maintains transparency logs so that issuance itself is checkable. Signed artifacts are appended to an RFC 6962 Merkle log, and a recipient can verify an inclusion proof, reproducing the leaf hash and walking the audit path to the signed tree head, to confirm an artifact was logged and the log was not forged. Issued X.509 and SSH certificates are recorded in a certificate transparency log answering "was a certificate issued behind my back?", backed by full RFC 5280 path validation on the verifying side.

For physical observations, C2PA content-provenance verification authenticates each sensor capture against its signing certificate on the ingest path.

Design status

Signing paths are described by mechanism. C2PA verification of inbound captures runs on the ingest path; C2PA signing of outbound content is not presented as a shipping control. Transparency-log inclusion-proof verification is implemented and covered by known-answer tests on both runtimes.