Zusammenfassung

  • Der IESG genehmigte am 3. September 2026 das TLS/DTLS-1.3-Profil für das Internet der Dinge als Proposed Standard. Es berücksichtigt langlebige Geräte und wechselbare Vertrauensanker; es belegt nicht, dass eine konkrete Flotte den Wechsel ausgeführt hat.
  • Eine belastbare Migration benötigt pro Gerät Belege für autorisierte Verteilung, dauerhafte Installation, aktive Anker-Generation, gewählte Zertifikatskette, letzte Nutzung der alten Autorität, Rückfallgrenze und Empfang auf Anwendungsebene.

Die IESG-Mitteilung genehmigt draft-ietf-uta-tls13-iot-profile-25. Im Datatracker ist Version 25 mit versandter Genehmigungsmitteilung verzeichnet; eine endgültige RFC-Nummer war im geprüften Stand noch nicht zugeteilt. Der genehmigte Text ergänzt RFC 7925 für TLS/DTLS 1.2 und aktualisiert Vorgaben für X.509 und Cipher Suites.

Die operative Aussage reicht über Kryptografie hinaus. Feldgeräte können länger leben als Algorithmen, CAs, Hersteller und Betreiberverträge. Ein Trust Anchor, der über die gesamte Lebensdauer unverändert bleibt, erschwert Algorithmuswechsel, CA-Rollover, Herstellerwechsel und Reaktion auf Vorfälle.

Ein im TLS-Certificate-Nachrichtenfluss mitgeliefertes Root-Zertifikat erwirbt nicht dadurch Vertrauen, dass der zu prüfende Server es sendet. Bevorzugt wird die Bereitstellung außerhalb des Handshakes; das Root soll in der übertragenen Kette fehlen. Wer einen Anker installieren darf und ob das Gerät ihn dauerhaft aufgenommen hat, ist somit eine Steuerungsfrage.

Eine Brücke beweist Kompatibilität, nicht Ablösung

Bei gemischten Anker-Generationen kann der Server die Erweiterung certificate_authorities auswerten und eine zum Client passende Kette anbieten. Die in RFC 9810 beschriebenen Übergangszertifikate newWithOld und oldWithNew verbinden alte und neue Generation. Sie ersetzen nicht die außerbandige Bereitstellung des neuen Ankers.

Die Brücke erzeugt zwei gegensätzliche Gefahren. Bleibt sie ohne Endbedingung, verbinden sich alte Geräte weiter und die Migrationskennzahl wirkt gesund; zugleich bleibt die alte CA authentisierungsfähig. Wird sie zu früh entfernt, kann ein isoliertes Gerät gerade den authentisierten Kanal verlieren, über den es repariert werden sollte.

Ein Kalendertermin kann dieses Dilemma nicht lösen. Erforderlich sind pro Kohorte der erste nachgewiesene neue Pfad, die letzte beobachtete Nutzung des alten Pfads, ein definierter Wiederherstellungsweg und die ausdrückliche Befugnis, die Brücke danach zu demontieren.

Auslieferung endet vor dem dauerhaften Zustand

Ein sicherer Firmware-Updateprozess kann neue Trust Anchors verteilen. Die SUIT-Architektur in RFC 9019 trennt Firmware-Autor, Verteiler, Gerät und Vertrauensbeziehungen. Nach erfolgreicher Zustellung fehlen dennoch Paketprüfung, dauerhafter Schreibvorgang, Aktivierung, Neustart, Rücklesen des Speichers und eine Verbindung, die den neuen Anker tatsächlich benutzt.

Auch die Objektarten bleiben getrennt. Ein Firmwaretransport für Trust Anchors erneuert nicht automatisch End-Entity- oder Sub-CA-Zertifikate. RFC 7030 bietet mit EST Mechanismen zur Registrierung und zum Bezug von CA-Zertifikaten; Unterstützung und Erfolg sind Eigenschaften der jeweiligen Installation.

„98 Prozent aktualisiert“ ist deshalb keine Risikobeschreibung. Zwei Prozent austauschbare Sensoren unterscheiden sich von zwei Prozent Geräten, die die einzigen entfernten Aktoren einer Anlage steuern. Das Ledger muss Geräteidentität, Hardware- und Firmwaregeneration, Anker-Fingerprints, Updateergebnis, Aktivierungszeit, letzten Kontakt und Ausnahmeverantwortung erhalten.

Die drei Berechtigungsarten haben verschiedene Hüter

Das Profil behandelt X.509-Zertifikate, Raw Public Keys und externe PSKs, ohne eine Lösung für alle Systeme vorzuschreiben.

Bei X.509 sind Trust Anchor, mögliche Zwischen-CAs und End-Entity-Zertifikat gesondert zu führen. Ein Raw Public Key nach RFC 7250 spart Zertifikatsstruktur im Austausch, bindet sich aber nicht selbst an die erwartete Identität. Dafür braucht es eine geschützte Zuordnung. Ein selbstsigniertes X.509-Zertifikat bleibt X.509.

Externe PSKs verlagern die Verwahrung auf ein Geheimnis. RFC 9257 beschreibt Risiken bei Entropie, Identität und Verteilung. RFC 9258 bindet importierte PSKs an KDF- und Hashkontext von TLS 1.3. Wer das Geheimnis erzeugte, welche Geräte es teilen, wann es rotiert und für welchen Dienst es gilt, bleibt nachzuweisen.

Ein Feld „TLS aktiviert“ kann diese unterschiedlichen Macht- und Verlustmodelle nicht abbilden.

Weniger Bytes bedeuten nicht weniger Abhängigkeit

Ist der Standardbedarf von ungefähr 18 KB Verarbeitungsbuffer zu hoch, erlaubt Record Size Limit aus RFC 8449, die größte akzeptierte Record-Größe mitzuteilen. Das ist keine Messung von Gesamt-RAM, Flash, Energie oder Zertifikatsprüfzeit.

Session Resumption nach RFC 9846 kann erneute Zertifikatsauthentisierung vermeiden. Anzahl, Lebensdauer und Wiederverwendung der Tickets beeinflussen Serverzustand, Datenschutz und Replay-Kontrolle. Das IoT-Profil gestattet nicht allein 0-RTT für CoAP oder MQTT ohne geeignetes Anwendungsprofil.

Zertifikatskompression, gecachte Informationen oder Zertifikats-URLs verringern die übertragenen Bytes, können aber Cache, Abrufdienst oder stabilen Identifikator zu neuen Voraussetzungen machen. Jede Optimierung sollte festhalten, welche Kosten und welche Autorität wohin verschoben wurden.

Das Ledger der Vertrauensgeneration

Pro Gerät gehören Hardware-, Firmware- und Secure-Boot-Generation, Update-Root, Berechtigungsart sowie Fingerprints, Rollen und Richtlinien akzeptierter Anker in das Ledger. Jeder Übergang erhält getrennte Quittungen für Autorisierung, Lieferung, Prüfung, dauerhaften Schreibvorgang, Aktivierung, Neustart und Rücklesen.

Danach folgen die tatsächlich präsentierte und die akzeptierte Kette: End-Entity-Zertifikat, untergeordneter Pfad, Anker-Generation, ausgehandeltes Protokoll und Beobachtungszeit. Die Anwendungsquittung ist ein eigener Beleg. Ein TLS-Handshake authentisiert einen Peer unter einem Pfad; er belegt weder Freigabe noch Ausführung eines physischen Befehls.

Mit der Realitätsschichten-Disziplin von Lu Heng bleiben Proposed Standard, Konfigurationszustand, ausgeführte Validierung und Ergebnis voneinander getrennt. Running-Code Primacy priorisiert den beobachteten Gerätezustand. Die minimale Anfangsspezifikation mit lokaler Zukunftsentscheidung erklärt, warum gemeinsame Interoperabilität keine einheitliche CA-Topologie verlangt.

Quellen