Zusammenfassung

  • Am 24. September 2026 stellte die IESG fest, dass eine IRTF-Taxonomie zu herstellerseitig installierten Schlüsseln und Vertrauensankern zwar fünf IETF-Arbeitsgruppen berührt, deren Arbeit einer Veröffentlichung aber nicht entgegensteht.
  • Der Entwurf benennt Verfahren zur Erzeugung, Übertragung und Verwahrung von Schlüsseln, bewertet sie jedoch ausdrücklich nicht. Er ist weiterhin ein Internet-Draft mit dem Ziel eines Informational RFC.
  • Die Konfliktprüfung bescheinigt weder ein Verfahren für eine bestimmte Gerätecharge noch die Möglichkeit, verlorene Update-Befugnisse ohne Rückruf wiederherzustellen.

Eine gute Frage bei der Abnahme lautet nicht bloß, ob ein Gerät einen Vertrauensanker besitzt. Entscheidend ist, wer dessen privates Gegenstück kontrolliert, wann das Gerät gegen spätere Änderungen gesperrt wurde und wie die Befugnis zur Signatur eines Sicherheitsupdates erhalten bleibt. Der Name eines Herstellungsverfahrens beantwortet das nicht. Auch die Nachricht, die IESG habe gegen die Veröffentlichung einer entsprechenden Begriffssammlung nichts einzuwenden, füllt die Lücke nicht. Das eine ist eine Beschreibung, das andere eine Verfahrensentscheidung; für die Gerätecharge fehlt der Nachweis.

Geprüft wurde draft-irtf-t2trg-taxonomy-manufacturer-anchors-21 aus der Thing-to-Thing Research Group der IRTF. Die IESG erklärte am 24. September, der Text stehe mit Arbeiten von ANIMA, LAMPS, TEEP, RATS und SUIT in Beziehung. Diese Beziehung verhindere eine Veröffentlichung als Informational RFC aber nicht. Zugleich bat sie die IRTF, Kommentare im Datatracker zu prüfen und selbst über ihre Übernahme zu entscheiden. Der Datatracker führt den Text noch als aktiven Internet-Draft, dessen IRTF-Verfahrensschritt nach Abschluss der IESG-Prüfung aussteht. Ein RFC ist damit nicht automatisch erschienen.

RFC 5742 zieht die institutionelle Grenze. Bei Einreichungen aus dem IRTF-Strom kontrolliert die IESG Konflikte mit IETF-Standardsarbeit; die technische Würdigung liegt beim IRSG. Die Formel „verwandte Arbeit, Veröffentlichung nicht verhindert“ ist eine ausdrücklich vorgesehene Antwort. Sie macht den Entwurf weder zum IETF-Standard noch zu einer Produktprüfung oder Einsatzempfehlung. Der Entwurf selbst weist darauf hin, dass er nicht von der IETF gebilligt ist und im IETF-Standardisierungsprozess keinen formellen Status hat.

Die Taxonomie kann trotzdem nützlich sein. Sie unterscheidet im Gerät erzeugte private Schlüssel von außerhalb erzeugten und übertragenen Schlüsseln, Verfahren mit geheimem Ausgangswert und Varianten mit Secure Element. Damit rücken verschiedene Personen, Orte und Zeitpunkte der möglichen Einsicht oder Manipulation in den Blick. Außerdem sind ein Anker für den ersten Start, einer für Software-Updates und einer für die Aufnahme in eine Infrastruktur nicht austauschbare Vollmachten.

Der Text trennt den Austausch, die Ergänzung, Entfernung oder Beschädigung eines Ankers von der Kompromittierung des zugehörigen privaten Schlüssels und sogar vom Verlust des Zugangs zu einem nicht gestohlenen Schlüssel.

Gerade dieser letzte Fall bestimmt die Kosten eines Fehlers. Geht die Befugnis verloren, Updates zu signieren, lässt sich der Anker, der Updates erlaubt, womöglich nicht über denselben Kanal ersetzen. Je nach Bauart können Spezialgeräte vor Ort oder ein Austausch der Hardware nötig werden. Der Entwurf fragt deshalb nach der Strecke zwischen Erstinitialisierung und Sperrung, nach der Dauer der Verifizierbarkeit von Geräteidentitäten und nach der Verwahrung von Herstellerschlüsseln. Er vergibt dafür keine Sicherheitsnoten und behauptet keinen Fehler bei einem benannten Produkt.

Aus einem Fragenkatalog wird erst durch überprüfbare Antworten ein Betriebsnachweis.

Ein Käufer könnte für eine Geräteklasse oder Charge einen begrenzten Nachweis zur Ankerverwahrung verlangen. Darin wären die Befugnisse für Start, Update und Aufnahme, das tatsächlich verwendete Bereitstellungsverfahren, der Sperrpunkt und die für Herstellersignaturen verantwortliche Stelle zuzuordnen. Eine datierte Prüfung der Rotation, des Verlustfalls und des Ersatzwegs sowie Besitzer der Belege, Ausnahmen und Risikoakzeptanz gehören dazu. Die öffentliche Fassung muss keine privaten Schlüssel, Gerätekennungen oder empfindlichen Fertigungsdetails verraten. Das ist ein redaktioneller Vorschlag, keine neue IRTF-Vorgabe.

Der Beschluss berichtet weder über einen Angriff noch über einen Ausfall. Er öffnet einem Forschungstext den Weg zur Veröffentlichung. Ob ein konkretes Gerät langfristig verantwortbar eingesetzt wird, müssen Hersteller, Käufer und Betreiber mit Belegen entscheiden, die näher am Gerät liegen als der IESG-Beschluss.

Quellen