145 lines
9.4 KiB
Markdown
145 lines
9.4 KiB
Markdown
# 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.
|