[Task] Select the first trusted Postbox encryption and hand-over policy profile #25

New Issue

2026-07-28T23:01:06+02:00

zemion commented

2026-07-28 23:01:06 +02:00

Decisions required

Before Postbox claims end-to-end encryption or distributes historical key epochs, select and document:

history available to a new incumbent;
recovery/escrow authority and quorum;
ordinary key rewrap versus full ciphertext re-encryption triggers;
assurance/quorum for delegation, hand-over, emergency access, export, and destruction;
vacancy escalation without granting unrelated plaintext access;
external-recipient proof and token profile.

Constraint

The plaintext first slice may reserve compatible metadata and interfaces, but must not imply that expiry or revocation removes plaintext already fetched or exported.

## Decisions required Before Postbox claims end-to-end encryption or distributes historical key epochs, select and document: - history available to a new incumbent; - recovery/escrow authority and quorum; - ordinary key rewrap versus full ciphertext re-encryption triggers; - assurance/quorum for delegation, hand-over, emergency access, export, and destruction; - vacancy escalation without granting unrelated plaintext access; - external-recipient proof and token profile. ## Constraint The plaintext first slice may reserve compatible metadata and interfaces, but must not imply that expiry or revocation removes plaintext already fetched or exported.

zemion added the

module/postbox codex/needs-human area/security area/governance

priority

p1

labels 2026-07-28 23:01:06 +02:00

zemion commented

2026-07-30 14:37:29 +02:00

Partial product decision and policy briefing

A function-bound Postbox belongs to the function/unit context, not to the individual incumbent. Obtaining the effective function therefore grants access to the complete retained Postbox history by default, subject only to explicit classification/compartment policy. It is not limited to messages arriving after assignment.

For E2EE this means the new incumbent must receive authorized key wraps for every retained historical key epoch. Adding an incumbent should rewrap epoch/data keys, not re-encrypt every ciphertext. Assignment or revocation creates a new epoch for future messages; revocation cannot erase plaintext or exports already obtained.

Recommended public-administration profile:

per-user/device identity keys owned by Identity Trust;
Postbox content-key epochs and recipient wraps owned by a future broad govoplan-encryption capability;
automatic historical rewrap after an effective, audited function assignment;
organization recovery key under 2-of-3 or stronger threshold custody, never one universal administrator key;
hierarchy/vacancy routing grants only the routed message, not unrelated parent access to the entire history;
external recipients receive per-message encryption/share access, never Postbox membership/history;
disabling encryption is blocked until all protected content is authorized, decrypted/migrated, integrity-verified, and audited.

Still to choose: the default recovery quorum, device assurance profile, whether any no-escrow profile is supported, the external-recipient proof/token profile, and export/destruction assurance. The history-access question itself is resolved.

## Partial product decision and policy briefing A function-bound Postbox belongs to the function/unit context, not to the individual incumbent. Obtaining the effective function therefore grants access to the complete retained Postbox history by default, subject only to explicit classification/compartment policy. It is not limited to messages arriving after assignment. For E2EE this means the new incumbent must receive authorized key wraps for every retained historical key epoch. Adding an incumbent should rewrap epoch/data keys, not re-encrypt every ciphertext. Assignment or revocation creates a new epoch for future messages; revocation cannot erase plaintext or exports already obtained. Recommended public-administration profile: - per-user/device identity keys owned by Identity Trust; - Postbox content-key epochs and recipient wraps owned by a future broad `govoplan-encryption` capability; - automatic historical rewrap after an effective, audited function assignment; - organization recovery key under 2-of-3 or stronger threshold custody, never one universal administrator key; - hierarchy/vacancy routing grants only the routed message, not unrelated parent access to the entire history; - external recipients receive per-message encryption/share access, never Postbox membership/history; - disabling encryption is blocked until all protected content is authorized, decrypted/migrated, integrity-verified, and audited. Still to choose: the default recovery quorum, device assurance profile, whether any no-escrow profile is supported, the external-recipient proof/token profile, and export/destruction assurance. The history-access question itself is resolved.

zemion commented

2026-07-30 21:48:55 +02:00

Codex State: ready

Summary

Product defaults confirmed: new function incumbents receive authorized message history.
Use a 2-of-3 administrative recovery quorum with managed-device assurance; do not offer a no-escrow profile in v1.
External access is per-message, expiring, and protected by a second factor; bulk export and destructive recovery actions require two-person approval.

Suggested status label: status/ready

## Codex State: ready ### Summary - Product defaults confirmed: new function incumbents receive authorized message history. - Use a 2-of-3 administrative recovery quorum with managed-device assurance; do not offer a no-escrow profile in v1. - External access is per-message, expiring, and protected by a second factor; bulk export and destructive recovery actions require two-person approval. Suggested status label: `status/ready`

zemion commented

2026-07-30 21:50:18 +02:00

Codex State: ready

Summary

Product defaults confirmed: new function incumbents receive authorized message history. Use a 2-of-3 administrative recovery quorum with managed-device assurance; do not offer a no-escrow profile in v1. External access is per-message, expiring, and protected by a second factor; bulk export and destructive recovery actions require two-person approval.

Suggested status label: status/ready

## Codex State: ready ### Summary - Product defaults confirmed: new function incumbents receive authorized message history. Use a 2-of-3 administrative recovery quorum with managed-device assurance; do not offer a no-escrow profile in v1. External access is per-message, expiring, and protected by a second factor; bulk export and destructive recovery actions require two-person approval. Suggested status label: `status/ready`

zemion added codex/ready

and removed

labels 2026-08-03 00:05:39 +02:00

zemion commented

2026-08-03 00:05:40 +02:00

The recorded product defaults resolve the prior decision gate: authorized new incumbents receive history; v1 uses managed-device assurance and 2-of-3 administrative recovery; external access is per-message, expiring, second-factor protected; bulk export and destructive recovery require two-person approval. Relabelled ready for implementation.

zemion removed the codex/needs-human label 2026-08-03 00:06:03 +02:00

zemion commented

2026-08-20 03:45:33 +02:00

Implemented and pushed the configurable Postbox content-protection spectrum.

server_envelope_v1 is the recommended standard: Encryption-owned envelopes, vault selection, institutional recovery, fail-closed writes, and governed migration ledger use.
external_e2ee_v1 is server-blind: only ciphertext, signed manifest, wrapped keys, and SHA-256 continuity are accepted. A reviewed external client owns device/private-key handling.
plaintext_v1 remains an explicit compatibility choice and is labelled as no application-layer encryption.
Each Postbox now configures incumbent history, ordinary/compromise rotation, recovery, hand-over, emergency, export, destruction, external-recipient assurance, and metadata-only vacancy escalation.
Future-only and historical transitions are idempotent, revision-guarded, audited, and require the configured user-consent/institutional/dual-control evidence and quorum. E2EE history changes wait for explicit client transforms; previously fetched/exported plaintext is never claimed to be revocable.
Admin UI exposes policy editing, profile availability, transition validation/history, dirty-state handling, and the managed-envelope default for new locally configured Postboxes/templates.

Commits: govoplan-core@557c776, govoplan-postbox@174ee97, govoplan@f407419.

Verification: full focused workspace gate passed, including 51 Postbox tests, migration upgrade/downgrade coverage, 57 WebUI module permutations, full-product bundle budgets, seven Playwright conformance tests, manifest/contracts/inventory checks, and module-specific UI checks.

Implemented and pushed the configurable Postbox content-protection spectrum. - `server_envelope_v1` is the recommended standard: Encryption-owned envelopes, vault selection, institutional recovery, fail-closed writes, and governed migration ledger use. - `external_e2ee_v1` is server-blind: only ciphertext, signed manifest, wrapped keys, and SHA-256 continuity are accepted. A reviewed external client owns device/private-key handling. - `plaintext_v1` remains an explicit compatibility choice and is labelled as no application-layer encryption. - Each Postbox now configures incumbent history, ordinary/compromise rotation, recovery, hand-over, emergency, export, destruction, external-recipient assurance, and metadata-only vacancy escalation. - Future-only and historical transitions are idempotent, revision-guarded, audited, and require the configured user-consent/institutional/dual-control evidence and quorum. E2EE history changes wait for explicit client transforms; previously fetched/exported plaintext is never claimed to be revocable. - Admin UI exposes policy editing, profile availability, transition validation/history, dirty-state handling, and the managed-envelope default for new locally configured Postboxes/templates. Commits: `govoplan-core@557c776`, `govoplan-postbox@174ee97`, `govoplan@f407419`. Verification: full focused workspace gate passed, including 51 Postbox tests, migration upgrade/downgrade coverage, 57 WebUI module permutations, full-product bundle budgets, seven Playwright conformance tests, manifest/contracts/inventory checks, and module-specific UI checks.

zemion closed this issue

2026-08-20 03:45:34 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-postbox#25