Zusammenfassung

  • draft-ietf-emu-pqc-eap-tls-02 erlaubt nach authentisiertem EST-Abruf während der Bereitstellung, Zwischenzertifikate im späteren EAP-Handshake wegzulassen.
  • Endzertifikat und CertificateVerify bleiben erhalten; nur die Zwischenzertifikate werden zu vorausgesetztem Zustand.
  • Revision 02 ist ein Arbeitsentwurf und definiert kein TLS-Signal, mit dem Peers die Auslassung live aushandeln.

Der kurze Austausch hat eine lange Vorgeschichte

Post-Quanten-Ketten wachsen, bevor ein Gerät normalen Netzzugang besitzt. Fragmentierung und Wiederholungen können EAP-TLS praktisch scheitern lassen. Der Entwurf verlagert die Last: Clients holen Server-Zwischenzertifikate über /.well-known/est/eapservercertchain; Server können Client-Ketten über /.well-known/est/eapclientcertchain im selben Verwaltungsbereich beziehen.

Der schlanke Handshake setzt damit einen installierten Vertrauensanker, einen authentisierten EST-Server, gespeicherte Zertifikatbytes, einen weiterhin passenden Ausstellerpfad und eine richtig begrenzte Administratorkonfiguration voraus. Das ist Verlagerung, keine Kompression.

Der Text vom 23. September 2026 läuft am 27. März 2027 ab. Datatracker zeigt WG Document und I-D Exists. Der Kopf nennt Standards Track, die Übersicht aber keinen angestrebten RFC-Status. Keines davon belegt Konsens oder Einsatz.

Offener Abruf ist keine anonyme Autorität

Die Ressourcen müssen ohne Client-Authentisierung lesbar sein. Der Abrufende muss jedoch den EST-Server per HTTPS mit einem durch BRSKI, EST oder außerhalb des Bandes eingerichteten Anker authentisieren. Unvertrauenswürdige Ketten dürfen nicht zur TLS-Prüfung dienen.

Auch HTTP 200 baut keinen Zertifizierungspfad. Bei mehreren CAs kann die Antwort alle Zwischenzertifikate enthalten. Der Client wählt weiterhin jene aus, die das live gezeigte Endzertifikat mit seinem Anker verbinden. Gelingt dies nicht, scheitert die Authentisierung. Der Download beweist weder Aktualität noch Sperrstatus, Schlüsselbesitz oder Netzzugang.

Der Cache trägt nun Verfügbarkeit

Periodischer Neuabruf, Cache-Control, ETag und Gültigkeitsprüfung beantworten verschiedene Fragen. Ein ETag verfolgt eine Darstellung an einer Quelle; die Laufzeit begrenzt ein Zertifikat. Beides beweist nicht, dass ein neues Endzertifikat mit dem alten Satz verkettet oder ein offline gebliebenes Gerät aktualisiert wurde.

Zwei Uhren müssen zusammenpassen: Die Kette ändert sich im Bereitstellungsplan, Verbindungen entstehen im EAP-Plan. Ein schlafendes Gerät, ein CA-Wechsel oder ein altes Verwaltungsabbild kann die Byte-Ersparnis in eine Zugangsstörung verwandeln.

Auslassung wird konfiguriert, nicht ausgehandelt

Ohne ausdrückliche Konfiguration muss die vollständige Kette übertragen werden. Ein Server darf erst auslassen, wenn der Administrator den Vorabruf bei den Clients sichergestellt hat. Ein TLS-Erweiterungssignal bleibt eine zukünftige, ausdrücklich ausgeschlossene Möglichkeit.

Darum darf die Funktion kein globaler Schalter nach Softwareversion sein. Sie gehört an Peer-Gruppe, Ausstellersatz, Bereitstellungsgeneration und Aktualitätsregel. Der sichere Rückweg sendet wieder die vollständige Kette.

Post-Quanten-Schutz endet nicht am Blatt

Langfristige Vertraulichkeit braucht TLS 1.3 und postquantenfähige oder hybride Schlüsselvereinbarung. Authentisierung braucht passende Signaturen bis zum vorinstallierten Anker. Ein PQ-Endzertifikat verwandelt keinen klassischen Zwischenknoten. Vorabruf entfernt weder Endzertifikat noch CertificateVerify.

Getrennte Nachweise müssen Anker, EST-Identität, Antwort und Hashes, Aktualität, Ausstellerpfad, Aktivierung, Live-Prüfung, EAP-Abschluss und Zugang abbilden.

Quellen und Grenzen

Einsatzzahl, gemessene Fehlerrate, garantierte Ersparnis, Aktualisierungsintervall und Rückfall-SLA fehlen. Es wird kein Produkt oder Vorfall behauptet.