feat: protect postbox message content

This commit is contained in:
2026-08-02 03:40:57 +02:00
parent 7d310d5c33
commit 8f8d259a76
12 changed files with 611 additions and 29 deletions
+23 -4
View File
@@ -12,10 +12,13 @@ needed a role, process, portal, campaign, or service responsibility. It may look
like an inbox for a message task or like a vault for content shared with the
current holders of that responsibility; neither form is owned by one account.
The strategic target is an encrypted administrative postbox. The first
implementation may start with ordinary persisted messages, but the model must
not prevent later end-to-end encryption, role/function key epochs, signed
manifests, external-recipient tokens, or honest retraction semantics. The
The strategic target is an encrypted administrative postbox. The current
implementation supports ordinary persisted messages and an optional
server-readable Encryption envelope for message bodies. The model also retains
external ciphertext, wrapped-key, signed-manifest, external-recipient-token,
and key-epoch metadata needed for later independently reviewed E2EE profiles.
The server-envelope profile is not E2EE, and subjects, routing, participants,
and attachment references remain visible. The
cross-module target architecture is recorded in
`govoplan-core/docs/POSTBOX_E2EE_ARCHITECTURE.md`.
@@ -330,6 +333,22 @@ The WebUI should start as an administration and inbox surface:
Campaign, files, portal, and mail behavior should arrive as optional integrations after the core postbox model is stable.
### Current content-protection profile
An exact Postbox or template revision may select `server_envelope_v1` and an
Encryption vault. New locally authored and delivered message bodies are then
stored in `body_ciphertext` with an owner-bound envelope reference; clear body
text is not persisted. Reads ask the optional `encryption.content_cipher`
capability to open the exact tenant, message, and envelope tuple. Missing
Encryption, a lost deployment key, a destroyed vault key, ciphertext tampering,
or a mismatched resource causes a fail-closed read.
Plaintext Postboxes continue to work without Encryption. A protected Postbox
cannot silently fall back to plaintext. Database recovery of protected messages
requires Postbox and Encryption tables from the same consistency point plus the
matching provider/deployment key. Hierarchy-routed copies retain the source
envelope reference rather than decrypting and re-encrypting during routing.
## E2EE Readiness Checklist
Before the data model is considered stable, verify that it can represent: