[Decision] Separate module activation from data-protection opt-in #5

New Issue

2026-08-03T21:10:40+02:00

zemion commented

2026-08-03 21:10:40 +02:00

Decision boundary

Enabling the Encryption module must only make encryption capabilities and administration surfaces available. It must not silently encrypt existing or newly created module data.

The owning module needs an explicit protection profile/policy and a migration workflow before content changes protection state.

Decisions still required

Which scopes may opt data in: system template, tenant, module, collection, object, or combinations.
Whether new data inherits protection automatically once a profile is active.
Required custodians, recovery quorum, key rotation, and evidence per profile.
Disable semantics: prohibit disable while protected content exists, or require a verified decrypt/rekey/export migration first.
Handling of externally encrypted data that GovOPlaN cannot decrypt.
Worker/node key access and cache lifetime in a horizontally scaled deployment.
Rollback guarantees when a bulk protection migration partially completes.

Baseline recommendation

Use explicit versioned protection profiles owned by Encryption and referenced by feature modules. Activation and entitlement remain reversible software/configuration operations; protection-state transitions are durable governed migrations with preflight, checkpoints, rollback/recovery evidence, and no implicit decrypt-on-disable.

## Decision boundary Enabling the Encryption module must only make encryption capabilities and administration surfaces available. It must not silently encrypt existing or newly created module data. The owning module needs an explicit protection profile/policy and a migration workflow before content changes protection state. ## Decisions still required - Which scopes may opt data in: system template, tenant, module, collection, object, or combinations. - Whether new data inherits protection automatically once a profile is active. - Required custodians, recovery quorum, key rotation, and evidence per profile. - Disable semantics: prohibit disable while protected content exists, or require a verified decrypt/rekey/export migration first. - Handling of externally encrypted data that GovOPlaN cannot decrypt. - Worker/node key access and cache lifetime in a horizontally scaled deployment. - Rollback guarantees when a bulk protection migration partially completes. ## Baseline recommendation Use explicit versioned protection profiles owned by Encryption and referenced by feature modules. Activation and entitlement remain reversible software/configuration operations; protection-state transitions are durable governed migrations with preflight, checkpoints, rollback/recovery evidence, and no implicit decrypt-on-disable.

zemion added the

status

needs-info

module/encryption codex/needs-human area/governance

labels 2026-08-03 21:10:40 +02:00

zemion commented

2026-08-03 21:30:56 +02:00

Codex State: needs-info

Summary

Platform module activation is now explicitly separated from domain data-protection state.
Enabling Encryption exposes capabilities and administration only; it does not encrypt existing or new domain records automatically.

Next / Blocked

Decide protection-policy scope and defaults, migration and rollback semantics, disable behavior, key custody/recovery quorum, and how each owning module reports partially protected data.

Suggested status label: status/needs-info

## Codex State: needs-info ### Summary - Platform module activation is now explicitly separated from domain data-protection state. - Enabling Encryption exposes capabilities and administration only; it does not encrypt existing or new domain records automatically. ### Next / Blocked - Decide protection-policy scope and defaults, migration and rollback semantics, disable behavior, key custody/recovery quorum, and how each owning module reports partially protected data. Suggested status label: `status/needs-info`

zemion commented

2026-08-04 13:16:44 +02:00

Codex State: done

Summary

Product decision approved on 2026-08-04: module activation exposes Encryption capabilities only and never changes protection state implicitly.
Profiles are versioned system templates activated per tenant and applied at owner-module collection or object scope; access groups/users are policy subjects, not cryptographic scopes.
New objects inherit protection only inside an explicitly activated scope; existing content uses checkpointed copy-on-write migration with verified cutover and an explicit inverse migration for rollback.
The first production profile is managed server-envelope encryption through a KMS/HSM provider. The bundled local AES-GCM provider remains bounded; tenant-held and true client E2EE are separate opt-in profiles.
Recovery defaults to high-assurance 2-of-3 distinct tenant custodians with requester separation. Disable remains blocked until every protected object is decrypted, migrated, exported, or destroyed with evidence; externally opaque content must be resolved first.
Horizontally scaled nodes receive short-lived in-memory unwrap grants and persist no node-local key material.

Next / Blocked

Implement provider-specific KMS/HSM profiles and feature-module migrations under implementation issues; true E2EE remains a separately governed profile.

## Codex State: done ### Summary - Product decision approved on 2026-08-04: module activation exposes Encryption capabilities only and never changes protection state implicitly. - Profiles are versioned system templates activated per tenant and applied at owner-module collection or object scope; access groups/users are policy subjects, not cryptographic scopes. - New objects inherit protection only inside an explicitly activated scope; existing content uses checkpointed copy-on-write migration with verified cutover and an explicit inverse migration for rollback. - The first production profile is managed server-envelope encryption through a KMS/HSM provider. The bundled local AES-GCM provider remains bounded; tenant-held and true client E2EE are separate opt-in profiles. - Recovery defaults to high-assurance 2-of-3 distinct tenant custodians with requester separation. Disable remains blocked until every protected object is decrypted, migrated, exported, or destroyed with evidence; externally opaque content must be resolved first. - Horizontally scaled nodes receive short-lived in-memory unwrap grants and persist no node-local key material. ### Next / Blocked - Implement provider-specific KMS/HSM profiles and feature-module migrations under implementation issues; true E2EE remains a separately governed profile.

zemion closed this issue

2026-08-04 13:16:44 +02:00

zemion removed the

status

needs-info

codex/needs-human labels 2026-08-04 13:18:28 +02:00

zemion commented

2026-08-04 14:42:01 +02:00

Codex State: note

Summary

Clarification accepted: client E2EE remains a configurable, explicit protection profile with managed KMS/HSM envelope encryption as the first production profile.
Before activation, the UI must show a profile- and module-specific consequence matrix for server search, Dataflow/reporting, inspection, previews, collaboration, legal hold/export, recovery, and metadata leakage.
Warnings are not the enforcement boundary: capability preflight must block unsupported operations, record policy provenance and acknowledgment, and prohibit silent plaintext/server-managed fallback.

Next / Blocked

Treat profile activation, recipient/recovery changes, and exit from E2EE as governed client-capable migrations rather than a reversible toggle once ciphertext exists.
Preserve protocol-neutral envelopes, opaque ciphertext references, recipient/device key epochs, and no assumption that server plaintext is available while implementing managed envelope encryption first.

## Codex State: note ### Summary - Clarification accepted: client E2EE remains a configurable, explicit protection profile with managed KMS/HSM envelope encryption as the first production profile. - Before activation, the UI must show a profile- and module-specific consequence matrix for server search, Dataflow/reporting, inspection, previews, collaboration, legal hold/export, recovery, and metadata leakage. - Warnings are not the enforcement boundary: capability preflight must block unsupported operations, record policy provenance and acknowledgment, and prohibit silent plaintext/server-managed fallback. ### Next / Blocked - Treat profile activation, recipient/recovery changes, and exit from E2EE as governed client-capable migrations rather than a reversible toggle once ciphertext exists. - Preserve protocol-neutral envelopes, opaque ciphertext references, recipient/device key epochs, and no assumption that server plaintext is available while implementing managed envelope encryption first.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-encryption#5