Zusammenfassung

  • Die OpenPGP-Arbeitsgruppe hat am 4. September einen bis 18. September laufenden Adoptionsaufruf für einen Entwurf eröffnet, der geheimes Material als extern markiert und einen optionalen Locator-Hinweis zulässt. Ein Ergebnis wird hier nicht vorweggenommen.
  • Der Hinweis ist beratend. Ein Empfänger darf trotz Hinweis die Best-Effort-Suche verwenden und Unbekanntes ignorieren. Revision 03 definiert kein konkretes Hinweisschema; im geltenden IANA-Register fehlen der vorgeschlagene External-Wert und das neue Register.
  • Der Stub bewahrt kryptografische Identität, aber nicht Softwareunterstützung, Gerätepräsenz, Autorisierung oder Recovery. Diese lokalen Beobachtungen gehören in einen getrennten, geschützten Übergabenachweis.

Der Aufruf hat ein Enddatum, noch kein Ergebnis

Stephen Farrell eröffnete den WG-Aufruf am 4. September nach einer Vorstellung auf der IETF 126. Bis zum 18. September soll die Arbeitsgruppe beraten, ob draft-dkg-openpgp-external-secrets-03 zu ihrer Arbeit werden soll. Der individuelle Entwurf beschreibt ein Drahtformat für OpenPGP-Schlüssel, deren geheimer Anteil in einem externen kryptografischen System verbleibt.

Der Datatracker zeigt Call For Adoption By WG Issued als WG-Status und I-D Exists auf IESG-Ebene. Revision 03 ist vom 22. Juli 2026, läuft am 23. Januar 2027 ab und trägt als individueller Internet-Draft keine IETF-Billigung.

Daniel Kahn Gillmor, Andrew Gallagher und Heiko Schäfer haben die Übernahme unterstützt. Paul Schaub erklärte sich für den Adoptionsfall zur Mitarbeit als Editor bereit. Solche Antworten dokumentieren Argumente und Beteiligung, sind aber weder Abstimmungsstand noch die ausstehende Feststellung der Chairs.

Auch 252? ist noch kein zugeteilter Wert. Der Entwurf schlägt ihn als neuen S2K Usage Octet vor und beantragt ein Locator-Hinweisregister. Im aktuellen IANA-Register gibt es weder die Zeile External unter 252 noch dieses neue Register.

Der öffentliche Teil dient als Suchschlüssel

RFC 9580 beschreibt Secret Key Packets und Transferable Secret Keys. Nach Revision 03 bleiben die öffentlichen Parameter erhalten. Anstelle des geheimen Materials signalisiert der S2K-Wert External, dass eine andere Komponente die Geheimoperation ausführt. Danach kann ein Hinweis folgen.

Bei der Best-Effort-Suche prüft eine Implementierung die von ihr unterstützten Systeme auf passendes öffentliches Schlüsselmaterial. Dadurch hängt die kryptografische Zuordnung nicht von einer freien Bezeichnung wie „Karte zwei“ ab.

Der Hinweis ist dennoch keine verbindliche Adresse. Ist er leer, beginnt Best Effort. Ist er unbekannt oder nutzlos, kann die Implementierung ihn ignorieren und weiter suchen. Selbst bei einem verstandenen Hinweis darf sie die eigenen Suchwege verwenden. Ein Erzeuger ohne sinnvollen Hinweis soll keine nachlaufenden Daten anfügen.

Revision 03 legt noch kein Hinweisschema fest. Das vorgeschlagene, zunächst leere Register reserviert 96–111 für private oder experimentelle Nutzung; andere Einträge sollen Specification Required folgen. Standardisiert würde zunächst die Erweiterungsstelle, nicht ein universelles Geräteverzeichnis.

Ein Treffer ist keine Berechtigung

Dass dieselbe Schlüsselsubstanz auf mehreren Geräten liegen kann, macht eine starre Adresse problematisch. Eine USB-Karte bekommt an einem anderen Hub einen anderen Pfad. Eine Anwendung unterstützt Smartcards, eine andere TPMs oder einen entfernten HSM. Eine PKCS-#11-URI kann Objekte in diesem Modell präzise bezeichnen, aber andere externe Systeme nicht automatisch vereinheitlichen.

Ein öffentlicher Schlüsseltreffer sagt: Ein erreichbarer Kandidat meldet entsprechendes geheimes Material. Er sagt nicht, wem es rechtmäßig gehört, wer diese Signatur genehmigt hat oder ob weitere Kopien bestehen. Das System kann danach PIN, Passwort, Biometrie oder Tastendruck fordern und die Operation trotzdem ablehnen.

Kein Treffer beweist umgekehrt keine Vernichtung. Das Gerät kann fehlen, gesperrt oder vom Treiber unbekannt sein; ein Konto kann abgelaufen sein; ein HSM kann zu langsam antworten. Die belastbare Aussage lautet nur, dass diese Implementierung unter diesen Bedingungen keine Fähigkeit erhalten hat.

Der Entwurf empfiehlt, für die Auflistung öffentlicher Schlüssel und den Abgleich keine Autorisierung zu verlangen. Geheimoperationen dürfen sie verlangen. Bei zwei Geräten mit demselben Schlüssel kann der Versuch am Gerät ohne Challenge versehentliche PIN-Sperren vermeiden. Die Oberfläche soll notwendige Interaktion ankündigen, vernünftige Timeouts nutzen und handlungsfähige Fehler anzeigen.

Deshalb besteht eine Migration aus getrennten Befunden: Stub gelesen, passendes System gefunden, Autorisierung erfüllt, Operation abgeschlossen. Ein identischer Dateihash belegt nur den ersten.

Hardware schützt nicht vor jedem Hostfehler

Externe Schlüssel können Extraktion erschweren. Manche Geräte begrenzen Operationen, fordern sichtbare Zustimmung oder attestieren die interne Erzeugung. Ein tragbares Token verschiebt Fähigkeit zwischen Rechnern, ohne die geheimen Parameter auf jede Festplatte zu kopieren.

Der Entwurf nennt zugleich die Grenzen. Hardware kann Konstruktionsfehler oder physische Schwächen haben. Ein kompromittierter Host kann Klartext oder Sitzungsschlüssel nach der Entschlüsselung stehlen. Bei einer Signatur kann der Nutzer bewusst bestätigen, während die Hostsoftware dem Gerät ein anderes Objekt als das angezeigte liefert.

Gillmor schreibt in seiner Antwort, Hardwaregeräte seien für fast alle OpenPGP-Nutzer kein sinnvoller Tausch, eine einfache Standarddarstellung für Interessierte aber schon. Schäfer betont Einsatzfelder, in denen Hardware faktisch nötig sei. Interoperabilität zu standardisieren ist keine Pflicht, dasselbe Verwahrungsmodell zu wählen.

Ein lokaler Übergabenachweis bleibt außerhalb

Seriennummern, HSM-Partitionen, Konten, Eigentümer und Recovery-Regeln gehören nicht in einen weltweit transportierten Schlüsselstub. Sie ändern sich und sind sicherheitssensibel. Die lokale Migration braucht stattdessen einen getrennten Übergabenachweis für externe Schlüssel. Das ist mein redaktioneller Vorschlag, keine IETF-Vorgabe.

Geschützt kann der Nachweis Zertifikats- und Subkey-Fingerprint, Entwurfs- oder RFC-Version, tatsächlichen Codepoint-Zustand, verstandenes Hinweisschema, Implementierung, Systemklasse, Zeitpunkt, Abgleichmethode, Autorisierungsanforderung, versuchte Operation und Ergebnis verbinden. Ersatz und Wiederherstellung sollen alte und neue Beobachtung verknüpfen.

Öffentlich genügen eine opake Referenz, die Fähigkeitsklasse und ein geprüftes Ergebnis. Seriennummer, PIN, Biometrie und interne Topologie bleiben zugriffsgeschützt. Der Nachweis dokumentiert einen Zeitpunkt; er erteilt keine Befugnis.

Heng Lus Policy Mirror trennt Akteur, Regel und Beleg. Die Minimum Initial Specification erlaubt einen kleinen gemeinsamen Kern und lokale Erweiterungen. Why BTW Media Exists verlangt die gegenwärtige Wirklichkeit: laufender Aufruf, vorgeschlagener Wert, lokal bedingte Fähigkeit.

Der Stub ist ehrlich, weil er seine Lücke ausdrückt. Der Standard kann die Lücke lesbar machen; ob sie im Einsatz geschlossen ist, muss die lokale Evidenz zeigen.

Quellen

  1. OpenPGP-WG-Adoptionsaufruf
  2. Aktueller Datatracker-Eintrag
  3. OpenPGP External Secret Keys, Revision 03
  4. Präsentation auf der IETF 126
  5. Antwort von Daniel Kahn Gillmor
  6. Antwort von Andrew Gallagher
  7. Antwort von Heiko Schäfer
  8. Antwort von Paul Schaub
  9. IANA-OpenPGP-Register
  10. RFC 9580 — OpenPGP
  11. RFC 8126 — Registerpolitik
  12. RFC 7512 — PKCS-#11-URI
  13. Heng Lu — The Policy Mirror
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Why BTW Media Exists