release: freeze Nexus One AI 1.0.0-rc1

specs/001-enterprise-experience/contracts/release-signing-trust.md

@@ -0,0 +1,144 @@
+# 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
+
+1. The reproducible builder emits immutable unsigned artifact, canonical manifest, SBOM and provenance
+   digests into a read-only handoff.
+2. The independent reviewer reconciles source revision, inventory, test evidence and target channel.
+3. The release owner submits an immutable signing request containing all digests, policy version,
+   artifact namespace/version and approval IDs.
+4. 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.
+5. A signing receipt binds request, signer key ID, input/output digests, time source/confidence,
+   operators by role and ceremony/session ID.
+6. 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:
+
+1. Suspend signing/publishing and preserve suspected artifacts, logs and custody evidence.
+2. Security owner plus second authorized approver classify scope: subordinate, metadata, revocation
+   signer or root compromise.
+3. 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.
+4. Publish verified recovery media through at least two controlled channels and provide offline
+   fingerprint verification to support.
+5. Test clean, stale-policy, revoked-key, rollback-attempt, interrupted-import and already-installed
+   behavior before release; record affected artifact IDs and successor paths.
+6. 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.