Zusammenfassung

  • draft-mcewan-adkm-problem-statement-00 beschreibt die Interoperabilitätslücke für stabile Kennungen mit veränderlichem Schlüsselzustand, ohne dass jeder Übergang erneut von einer Verwaltungsstelle genehmigt oder zwingend in einen globalen Konsens aufgenommen werden muss.
  • Ein aktiver Schlüssel kann für den laufenden Betrieb gültig sein und trotzdem absichtlich nicht ausreichen, um allein einen beliebigen Nachfolgezustand zu autorisieren. Sonst vererbt sich seine Kompromittierung auf alle künftigen Schlüssel.
  • Gültige Historie, Aktualität, beobachtete Konfliktfreiheit, Wiederherstellungsbeteiligung, lokale Autorisierung und tatsächliche Wirkung brauchen getrennte Belege.

Die gefährlichste Zeile im Incident-Log kann wie eine Erfolgsmeldung aussehen: „Schlüssel rotiert, alte Berechtigung entfernt, neue Signatur gültig.“ Wenn aber der alte Schlüssel bereits kompromittiert war, kann genau diese Zeile den dauerhaften Zugriff des Angreifers besiegeln.

Der Grund liegt nicht in schwacher Kryptografie. Die Signatur kann perfekt sein. Das System hat nur zwei Befugnisse zusammengelegt: heute handeln und morgen die Herrschaft vergeben.

Der individuelle Internet-Draft Autonomous Decentralized Key Management Problem Statement vom 20. September 2026 formuliert diese Trennung als offene Architekturfrage. Eine stabile Kennung soll Rotation, Notfallersatz, Schwellenänderung, Delegation, Wiederherstellung und Widerruf überstehen. Verifizierende Parteien sollen die authentisierte Ereigniskette prüfen können, ohne für jeden Schritt eine neue externe Ausstellung oder ein zwingendes Welt-Ledger zu benötigen.

Der Signatur fehlt die Rollenbezeichnung

Key State ist die Menge aus öffentlichen Schlüsseln, Signaturschwellen, Rollen und weiteren Autorisierungsparametern. Ein Key Event begründet oder verändert diesen Zustand. Ein Controller darf nur Übergänge genehmigen, die Zustand und Protokollregeln erlauben.

Damit kann ein Betriebsschlüssel Anwendungsnachrichten signieren, ohne eine Schwelle senken zu dürfen. Er kann eine Rotation anstoßen, aber eine getrennte Recovery-Rolle benötigen. Er kann eine begrenzte Rolle delegieren, ohne sämtliche anderen Controller zu löschen. Er kann sich selbst widerrufen, ohne allein einen unbeschränkten Nachfolger zu ernennen.

Beleg Was er zeigt Was er allein nicht zeigt
Signatur des aktiven Schlüssels Dieser Schlüssel signierte die Bytes Er genügte für diese Übergangsklasse
Übergangsregel Rollen, Schwellen und Version Schlüssel und Inputs waren unverletzt und aktuell
Verkettete Historie Der Zustand folgt erlaubten Übergängen Es ist die neueste und einzige Historie
Recovery-Freigabe Eine getrennte Fähigkeit wirkte mit Alle Recovery-Fähigkeiten blieben unabhängig
Konsistenzbeleg Ein Konflikt wurde im Prüfbereich erkannt Anderswo existiert kein unbekannter Zweig
Anwendungsentscheidung Lokale Regeln akzeptierten den Zustand Die reale Operation war erfolgreich

Lokale Prüfung ohne erfundene Weltzeit

Local Evidence Verification erlaubt die Prüfung eines Zustands und seiner authentisierten Vorgeschichte mit lokal verfügbarem Material, ohne synchrone Anfrage an eine festgelegte Stelle. Das ist für Edge-, Offline- und intermittierend verbundene Systeme wertvoll.

Der Entwurf grenzt die Aussage ausdrücklich ein: Die lokale Prüfung beweist nicht, dass kein späterer Zustand existiert. Ein alter Zustand bleibt kryptografisch gültig. Zwei widersprüchliche Historien können jeweils intern gültig sein. Der Beleg transportiert eine Kette, aber keinen universellen Gegenwartsbegriff.

Daher sind drei Resultate nötig: Historie gültig; Zustand für diese Nutzung frisch genug; kein Konflikt im angegebenen Suchbereich beobachtet. Ein Wartungsgerät kann einen älteren Stand akzeptieren, während ein Zahlungsdienst eine jüngere Beobachtung und mehrere unabhängige Quellen verlangt.

Recovery braucht eine terminale Zeile

Kein Protokoll kann Wiederherstellung garantieren, wenn der Angreifer alle Geheimnisse und Recovery-Fähigkeiten besitzt, die für künftige Zustände ausreichen. Diese Grenze muss vor dem Vorfall in einer Kompromittierungsmatrix stehen.

Zu prüfen sind mindestens: nur der aktive Schlüssel; ein Anteil einer Schwelle; aktiver Schlüssel plus Recovery-Anteil; vollständige Gerätekontrolle bei sicherer Offline-Recovery; Verlust sämtlicher Betriebs- und Recovery-Fähigkeiten; Netzpartition während der Wiederherstellung. Für jede Kombination müssen Veto, Wartezeit, Beobachtung und terminaler Zustand benannt werden.

„Rotation unterstützt“ ist keine Sicherheitszusage. Vom kompromittierten Schlüssel autorisierte Rotation kann die Persistenz vollenden.

Mehrere gültige Historien ohne globale Totalordnung

ADKM verlangt keine weltweite Totalordnung. Dadurch hängt die Kennung nicht zwingend von Verfügbarkeit, Governance und Finalität eines Konsenssystems ab. Gleichzeitig kann ein böswilliger Controller verschiedenen Parteien unterschiedliche gültige Historien zeigen.

Der Entwurf nennt unabhängige Beobachter, Gossip, Gegenprüfung und Transparenz, ohne eine Lösung auszuwählen. RFC 9162 und die Key Transparency Architecture zeigen, wie Tree Heads, Konsistenzbeweise, Monitoring und Gossip widersprüchliche Ansichten auffindbar machen. Schweigen ist dennoch kein Weltbeweis.

Ein Beobachtungsbeleg muss Identität, Commitment, Zeitpunkt, gemerkten Vorgänger, Gegenstellen und Netzlage festhalten. Eclipse-Angriff, Partition, verzögerte Verbreitung, selektive Offenlegung und Kollusion verändern die Bedeutung von „kein Konflikt beobachtet“.

Nachbararchitekturen bleiben Nachbarn

RFC 5280 und RFC 6960 bilden ein administratives Vertrauensmodell mit CAs, Trust Anchors und Zertifikatsstatus. ADKM ersetzt es nicht. Certificate Transparency macht Ausstellung auditierbar. RFC 7401 demonstriert selbstzertifizierende Host-Identitäten. DID Core definiert ein Datenmodell; Aktualisierung, Recovery und Versionierung bleiben methodenspezifisch.

ADKM fragt enger, ob Controller-autorisierte Zustandsfolge, stabile Kennung, verifizierbare Historie, Begrenzung kompromittierter Schlüssel und explizite Konsistenzbelege in ein anwendungsunabhängiges Modell passen.

Kanonische Bytes lösen keine Mandatsfrage

JCS, deterministisches CBOR und dCBOR helfen, identische Bytes zu signieren. Ohne eindeutige Darstellung können gleiche logische Ereignisse verschiedene Digests erzeugen.

Kanonisierung bestimmt aber weder Schwellenrecht noch Recovery-Unabhängigkeit oder Frische. Sie macht die Darstellung eindeutig, nicht die Entscheidung legitim.

Ein begrenzter Übergangsbeleg

Zu speichern sind Kennung und Inception-Bindung, Digest des Vorgängers, Sequenz oder Epoche, Ereignistyp, alte und neue Schlüssel, Rollen und Schwellen, genaue Policy-Version, jede Freigabe samt Autoritätsklasse, Recovery-Beteiligung, Darstellungsprofil, Ereignis-Digest, Beobachter und Zeiten, Konfliktprüfbereich sowie Frischequelle und Höchstalter.

Danach erstellt die Anwendung einen eigenen Beleg: akzeptierter Zustand, Operation, lokale Regel und Ergebnis. Authentischer Zustand ist keine Zugriffsfreigabe; Freigabe ist kein Wirkungsnachweis.

Dokumentstatus

Revision 00 ist ein individueller, als Informational vorgesehener Internet-Draft und läuft am 24. März 2027 aus. Er beweist weder WG-Annahme, IETF-Konsens, Implementierung, Deployment, Interoperabilität, Vorfall noch Produktsicherheit und wählt bewusst keine Lösung.

Quellen