[Feature] Add versioned content-encryption envelopes and E2EE integration contracts #3

New Issue

zemion · 2026-07-30T17:34:18+02:00

zemion commented

2026-07-30 17:34:18 +02:00

Provide reusable cryptographic envelopes for modules such as Files, Postbox, Campaign, Calendar, and connector credentials without coupling those modules to a concrete vault/provider.

Acceptance criteria

Ciphertext envelopes carry bounded algorithm, key reference, version, integrity, tenant/scope, and migration metadata.
Module contracts distinguish server-readable encryption from E2EE and declare feature degradation explicitly.
Re-encryption/rotation is resumable, idempotent, observable, and leaves no mixed state without provenance.
Ownership transfer never implies key transfer; key hand-over/re-encryption is a separately authorized workflow.
Optional-module absence fails closed for encrypted content while unencrypted module combinations continue to work.
At least Files and Postbox integration fixtures validate the boundary before production rollout.

Provide reusable cryptographic envelopes for modules such as Files, Postbox, Campaign, Calendar, and connector credentials without coupling those modules to a concrete vault/provider. ## Acceptance criteria - Ciphertext envelopes carry bounded algorithm, key reference, version, integrity, tenant/scope, and migration metadata. - Module contracts distinguish server-readable encryption from E2EE and declare feature degradation explicitly. - Re-encryption/rotation is resumable, idempotent, observable, and leaves no mixed state without provenance. - Ownership transfer never implies key transfer; key hand-over/re-encryption is a separately authorized workflow. - Optional-module absence fails closed for encrypted content while unencrypted module combinations continue to work. - At least Files and Postbox integration fixtures validate the boundary before production rollout.

zemion added the

labels 2026-07-30 17:34:18 +02:00