Tenant-KEK-Rotation ohne Neuverschlüsselung des Archivbestands
(Envelope-Encryption bleibt aus ARC-02 unverändert, Objekt-DEKs werden
nicht angefasst).
Core (API-10, RotateTenantKEK) ersetzt den Tenant-KEK durch einen neuen
Wert und hält keine Historie vor — TenantKEKHandler liefert immer nur den
aktuellen Schlüssel. Damit Mail Altbestand nach einer Rotation weiterhin
lesen kann, versioniert Mail selbst jeden bezogenen Tenant-KEK:
- crypto/kekversions.go: KEKVersionStore, lokal verschlüsselt mit
eigenem Wrap-Schlüssel (nur über Umgebungsvariable), erkennt Rotation
automatisch (RecordIfNew), erlaubt gezieltes Sperren einer Version
(Revoke).
- crypto/service.go: Service.WithVersionStore (optional, Open bleibt für
Rückwärtskompatibilität unverändert), Seal zeichnet die verwendete
KEK-Version auf, neue Methode OpenAtVersion liest mit historischer
statt aktueller Version.
- encstorage.go: neuer .dek.version-Sidecar (gleiches Muster wie der
bestehende .dek-Sidecar), GetDecrypted nutzt OpenAtVersion; fehlender
Sidecar (Altobjekte vor ARC-08) fällt auf Version 0 zurück, identisches
Verhalten wie vorher.
Prüfungen (alle real durchgeführt, siehe mail/docs/ARC-08-PRUEFPROTOKOLL.md):
1. TestRotation_OldArchiveStaysReadableAfterMasterKeyRotation: Altbestand
nach realer Rotation weiterhin lesbar über OpenAtVersion, naives Open
mit dem neuen Schlüssel schlägt für das alte Objekt real fehl.
2. TestRotation_CompromisedOldKeyCanBeRevoked: gesperrte Version blockiert
Lesezugriff real, andere Versionen bleiben unberührt.
3. Rotationsvorgang vollständig durchgespielt (siehe Prüfprotokoll).
Kein Umbau: storage/dedup/indexworker/search unverändert, bestehende
ARC-02-Tests (encstorage_test.go) unverändert weiterhin grün.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HhgFcLS8tYMhDJpP74C6AQ
