Release Signing and Offline Trust Contract

Trust Domains

Release-artifact signing and customer-license signing are separate trust domains. A release key MUST NOT sign licenses, and a license key MUST NOT sign ISOs, model packs, update bundles, channel indexes, trust bundles or revocation lists. Test keys are conspicuously identified and MUST NOT be trusted by a production verifier.

The release hierarchy has these roles:

Role	Permitted signatures	Required custody
Offline release root	Subordinate-key authorization, root rotation and emergency trust recovery	Offline, encrypted hardware/removable custody; dual control; never connected to build or distribution systems
Artifact-signing subordinate	Approved ISO, model-pack and update manifests plus release provenance handoff	Dedicated signing device/service isolated from builders; short-lived operator authorization; no exportable plaintext key
Metadata-signing subordinate	Channel indexes and withdrawal notices	Separate from artifact builder and distribution publisher; constrained namespace/purpose
Revocation/trust subordinate	Versioned revocation lists and routine trust bundles	Offline-capable controlled signer; cannot sign artifacts

Each key record declares key ID/fingerprint, algorithm, purpose, environment, activation/expiry, issuer, status, permitted artifact namespaces/channels and ceremony evidence ID. Verifiers reject a valid cryptographic signature when the key purpose, namespace, channel, time policy or trust path is wrong.

Ownership and Separation of Duties

The repository MAY display Cezen Technologies as the accountable organization rather than personal names, but every release MUST link an access-controlled approval record that attributes authorized people to these roles:

Security owner approves trust policy, ceremonies, key status and emergency revocation.
Release owner requests signing only after build/evidence gates pass.
Signing operators execute dual-controlled signing and cannot be the sole build executor.
Independent release reviewer verifies manifest, provenance, evidence and requested channel.
Distribution publisher publishes immutable bytes and metadata but has no signing key.
Support/recovery owner receives withdrawal/recovery instructions and verifies field media.

No person can alone build, approve, sign and publish a stable release. Public use of the company name does not satisfy this control without the restricted role-attribution record. Stable signing requires a release request plus independent approval bound to exact manifest, artifact, SBOM and provenance digests. Emergency action may shorten timing but not remove dual control or evidence.

Key Generation, Backup and Custody

Production keys are generated inside the approved signing boundary from an approved entropy source. Private key material is non-exportable where supported. Any permitted backup is encrypted to two or more custodians or protected by an approved threshold mechanism so one custodian cannot recover it. Custody inventory records tamper seals/device serials, storage locations, access events and quarterly presence checks without exposing secrets.

Root use requires an offline ceremony on a clean controlled workstation, two authorized custodians, an independent witness, time-bounded change request, verified ceremony tooling and recorded public outputs. The ceremony evidence includes inputs/outputs by digest, participants by role, device and tool versions, photographs or equivalent custody evidence where policy permits, and destruction or resealing confirmation. Secret key bytes, PINs and recovery shares never enter logs or release evidence.

Loss, suspected access, custody discrepancy, failed integrity check or unexplained signature triggers incident handling and suspension of the affected key before further signing.

Signing Handoff and Publication

The reproducible builder emits immutable unsigned artifact, canonical manifest, SBOM and provenance digests into a read-only handoff.
The independent reviewer reconciles source revision, inventory, test evidence and target channel.
The release owner submits an immutable signing request containing all digests, policy version, artifact namespace/version and approval IDs.
Signing operators re-hash every input inside the signing boundary, verify approvals/policy and sign only the canonical manifest/attestation objects specified by the contract.
A signing receipt binds request, signer key ID, input/output digests, time source/confidence, operators by role and ceremony/session ID.
The publisher verifies signatures and receipts, publishes immutable bytes, then publishes the signed channel mapping. Post-publication retrieval must reproduce every published digest.

Any digest or approval mismatch aborts the session. Retrying creates a new signing receipt; an output from an aborted or unapproved session cannot be promoted.

Rotation, Expiry and Trust Distribution

Subordinate keys have explicit activation/expiry and SHOULD rotate at least annually or sooner after policy/technology change. The offline root rotates only through a root ceremony. Rotation uses an overlap window: existing trusted authority signs the successor trust record, new media embeds both currently required public keys, and verification evidence proves old-supported, overlap and new-only paths. Expired keys cannot sign new releases; previously signed supported artifacts remain acceptable only under the approved historical-signature/time policy and non-revoked status.

Every bootable artifact embeds a versioned trust snapshot sufficient to verify its own payload. Installed appliances accept newer signed trust bundles through the same offline fail-closed import flow. Trust state is monotonic by sequence number/security floor; rollback requires separately authorized break-glass recovery and cannot be hidden as a normal import.

Public trust material, fingerprints and signed metadata may be distributed broadly. Distribution systems are untrusted for integrity: appliances rely on the embedded root and signed sequence, not the download location or removable-media label.

Revocation and Emergency Recovery

A root- or authorized revocation-signer-signed list identifies key ID, status, effective time, reason class, minimum trust sequence and required operator behavior. Revocation lists are versioned, monotonic and importable without network access. Policy sets a maximum acceptable age for new imports; stale policy blocks artifact activation according to the declared fail-closed rule while preserving local recovery, diagnostics, export and an already healthy installation unless a signed emergency directive explicitly requires deactivation.

Emergency procedure:

Suspend signing/publishing and preserve suspected artifacts, logs and custody evidence.
Security owner plus second authorized approver classify scope: subordinate, metadata, revocation signer or root compromise.
Use an unaffected authority to issue a higher-sequence revocation/trust bundle and signed customer advisory. If the root is affected, invoke the separately stored recovery-root/field-recovery plan; ordinary compromised-root signatures cannot restore trust.
Publish verified recovery media through at least two controlled channels and provide offline fingerprint verification to support.
Test clean, stale-policy, revoked-key, rollback-attempt, interrupted-import and already-installed behavior before release; record affected artifact IDs and successor paths.
Close only after inventory reconciliation, key replacement, customer/support communication and independent incident review.

Revocation MUST block new use of affected signatures. It MUST NOT silently erase customer data or brick recovery access. Mandatory shutdown/removal requires an explicit signed emergency policy and product/security approval with a documented recovery path.

Acceptance Evidence

Gate 1 requires approved role assignments, hierarchy/purpose constraints, custody design, rotation and revocation policy, maximum revocation age, emergency recovery path and test inventory. Gate 3 adds ceremony/signing receipts, public-key fingerprints, signature verification, purpose/namespace/time negatives and post-publication retrieval. Gate 5/6 adds offline trust import, stale/revoked/rollback, rotation overlap, interruption and emergency tabletop evidence with independent review.

Required negative vectors include wrong trust domain, wrong key purpose, unknown/revoked/expired/not- yet-valid key, wrong artifact namespace/channel, stale/lower-sequence trust state, tampered manifest, approval digest mismatch and test-key use in production policy.

Decisions Requiring Named Approval

Cezen Technologies ownership plus restricted attribution of authorized Security, Release, signing-operator, reviewer, publisher and Support people and alternates.
Approved signing hardware/service, threshold/backup method, custody locations and ceremony tooling.
Key lifetimes, rotation/overlap duration, historical-signature rule and maximum revocation-list age.
Time source/confidence policy for disconnected signing and verification.
Recovery-root or equivalent compromised-root field recovery design and storage.
Emergency severity matrix, response/communication targets and mandatory-deactivation authority.
Evidence storage, access, retention and privacy policy for ceremonies and incidents.

9.4 KiB Raw Blame History