Evidence-Key-Rotation

Dokumentierter Trust-Anchor-Verlauf: eine ungeplante Rotation am 30. August 2026, eine geplante KMS-Migration am 4. September 2026, und ein Server-Umzug (Alex-Souverrain -> alex-core) am 14. September 2026.

Zeitachse

Ursache und Isolation (30.08.2026)

Der Produktions-Keystore und ein Test-Keystore waren per Hardlink verbunden. Ein Test-/Importprozess rief die Signierschluessel-Erzeugung auf, ohne zuvor den persistenten Store zu laden, und ueberschrieb dadurch den gemeinsamen Inode.

Die Testprozesse wurden gestoppt, die Hardlinks getrennt, die Produktionsdateien auf Modus 0600 und das Verzeichnis auf 0700 gesetzt. Die privaten Produktions-Key-Bytes wurden aus dem Testbaum entfernt.

Bundles aus diesem Zeitfenster (bis 2026-08-30T07:38:50Z) sind nicht gegen den aktuellen Well-known-Key pruefbar. Der damalige oeffentliche Schluessel liegt in keinem Archiv mehr vor; deren Fremdverifikation bleibt offen.

KMS-Migration (04.09.2026, geplant)

Im Rahmen der Evidence-Hardening-Arbeit wurde der Signierschluessel von einem lokal gespeicherten PEM auf einen Google-Cloud-KMS-Schluessel migriert (der private Schluessel verlaesst seither KMS nie mehr). Die Migration lief noch mit der Vorgaengerversion der Rotationsfunktion, bevor am selben Tag die Widerrufs-Protokollierung dazukam -- der bis dahin aktive Schluessel wurde dadurch zunaechst ohne Eintrag ersetzt. Am 06.09.2026 nachtraeglich behoben: der alte oeffentliche Schluessel wurde aus dem verschluesselten Rotations-Archiv wiederhergestellt (Hash gegen den in den betroffenen Bundles signierten signer_key_id gegengeprueft) und als vollstaendiger Eintrag samt PEM in die Trust-Anchor-Registry nachgetragen.

Damit bleiben auch Bundles aus diesem Zeitfenster (inkl. der oeffentlichen Demo-PRs #31, #33, #35 und #36) fremdverifizierbar -- der historische Schluessel steht unter trust_anchor_registry.revocations[] im Well-known-Dokument, mit public_key_pem, valid_from und revoked_at.

Server-Umzug Alex-Souverrain -> alex-core (14.09.2026)

Der Produktivserver wurde von Alex-Souverrain auf die neue, schlankere Codebasis alex-core umgestellt. Der Schluessel-Store wurde dabei frisch initialisiert statt formal rotiert -- der bis dahin aktive Schluessel (signiert u.a. die oeffentlichen Demo-PRs #37, #38 und #39) verschwand dadurch zunaechst erneut spurlos aus der Trust-Anchor-Registry, exakt dasselbe Muster wie bei der KMS-Migration zehn Tage zuvor. Am 15.09.2026 behoben: die vollstaendige Vorgaenger-Historie (inklusive des Schluessels von der KMS-Migration) wurde read-only aus dem gestoppten, aber nicht geloeschten Alex-Souverrain-Checkout auf demselben Server ausgelesen und vollstaendig in die Trust-Anchor-Registry von alex-core sowie in dieses oeffentliche Verifier-Repository uebernommen.

Damit bleiben auch Bundles aus diesem Zeitfenster (PR #37, #38, #39) fremdverifizierbar, auf demselben Weg wie oben.

Auswirkung auf Verifikation

Fuer ein Bundle mit einem signer_key_id, der nicht mehr unter trust_anchor_registry.keys[] (aktiv) steht, den passenden Eintrag in trust_anchor_registry.revocations[] suchen und dessen public_key_pem als Trust-Anchor an verify.js uebergeben. Details: ANLEITUNG.md.

Aktueller Anker: /.well-known/alex-pubkey.json