From 7f923afdad307cf88b491f905c7600f53db4abca Mon Sep 17 00:00:00 2001 From: Albrecht Degering Date: Tue, 21 Jul 2026 20:47:54 +0200 Subject: [PATCH] docs(core): refine function-bound postbox encryption --- docs/POSTBOX_E2EE_ARCHITECTURE.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/docs/POSTBOX_E2EE_ARCHITECTURE.md b/docs/POSTBOX_E2EE_ARCHITECTURE.md index 00850b5..6729049 100644 --- a/docs/POSTBOX_E2EE_ARCHITECTURE.md +++ b/docs/POSTBOX_E2EE_ARCHITECTURE.md @@ -57,6 +57,11 @@ The trust layer should provide: - key rotation and epoch tracking - recovery policy hooks +Recovery must be organizationally governed. A server-held universal plaintext +key would defeat the E2EE claim; any escrow, threshold recovery, or emergency +grant needs an explicit assurance profile, authority/quorum, audit trail, and +user-visible consequence. + ## Role And Function Postboxes Role-bound access needs special handling. A postbox can be bound to an @@ -75,6 +80,30 @@ rewrapping service: Key epochs are required when role membership changes. Older messages may remain readable according to policy, but new access must use the current epoch. +The function-bound container exists independently of membership. It may remain +vacant and continue to receive ciphertext without falling back to an unrelated +personal mailbox. Zero, one, or several incumbents are valid states. Each +incumbent receives an independently auditable, device-bound wrapped-key path; +the postbox is never copied into their account ownership. + +A new assignment or hand-over rotates the function/postbox key epoch. Envelope +encryption permits the normal rotation path to rewrap per-message data keys +rather than rewrite large ciphertext objects; a security policy may require +full content re-encryption for selected compromise or cryptographic-profile +events. The history available to a new incumbent must be selected policy (all +retained history, a bounded historical window, or assignment-time content) and +recorded with the grant. + +Delegation is a time-bounded represented-function grant, not a copy or +substitution of the postbox. Expiry or withdrawal stops future key release and +actions. It cannot revoke plaintext already decrypted, printed, exported, or +captured outside the platform. Multiple simultaneous incumbents and delegates +remain distinguishable in key-fetch and action evidence. + +Postbox content and signed manifests are immutable. Correction or replacement +creates a linked new object/version; it never silently substitutes ciphertext +or evidence that another actor may already have inspected. + ## External Recipients External recipients may need one-time or time-limited access without a full