Zusammenfassung

  • Die HPKE-Arbeitsgruppe reichte Revision 05 am 25. September ein. Am 26. September eröffnete die IESG die Billigungsabstimmung und setzte den Entwurf auf die Tagesordnung für den 8. Oktober. Er befindet sich in der Bewertung, nicht im Rang einer veröffentlichten Nachfolge-RFC.
  • Die vorgeschlagene Modustabelle definiert Base 0x00 und PSK 0x01; die in RFC 9180 für Auth und AuthPSK verwendeten Werte 0x02 und 0x03 sind reserviert. Schon Revision 04 enthielt diese Abgrenzung.
  • Im KEM-Register soll das Feld Auth für die ältere RFC-9180-Schnittstelle bleiben, obwohl der neue Entwurf es nicht verwendet. Es ist kein Nachweis dafür, ob eine konkrete Anwendung Auth benutzt oder ihre Identitätsanforderung migriert hat.

Der gefährliche Kurzschluss liegt im Wort „obsolet“. Wird RFC 9180 durch eine spätere Norm ersetzt, kann ein Register seine Referenz aktualisieren und ein Produkt seine Dokumentation ebenfalls. Beides beantwortet noch nicht, ob die Gegenstelle eine authentisierte Nachricht nach dem älteren Modus verarbeiten kann. Der HPKE-Nachfolgeentwurf macht diese Lücke sichtbar, während er nun eine IESG-Abstimmung durchläuft. Er will einen bestehenden Standard ablösen, ohne alle darin beschriebenen Funktionen erneut festzuschreiben.

RFC 9180 kennt vier Modi. Base verschlüsselt zum Empfänger; PSK fügt ein vorab geteiltes Geheimnis hinzu. Auth und AuthPSK nutzen zusätzlich die alte senderseitige Authentisierungsschnittstelle. Ihre Werte 0x02 und 0x03 sind in der neuen Modustabelle reserviert. Der Anhang des Entwurfs nennt die Entfernung beider Modi ausdrücklich und verlangt Kompatibilität nur für Verhalten, das beide Dokumente beschreiben. Das ist ein brauchbares Versprechen für die gemeinsame Schnittmenge, kein Versprechen für jede frühere API. PSK bleibt eine Form der Authentisierung eines gemeinsamen Geheimnisses; der Besitz dieses Geheimnisses ist aber nicht dieselbe Aussage wie der Besitz des asymmetrischen privaten Senderschlüssels bei den früheren Auth-Modi.

Die September-Chronologie darf nicht zur erfundenen technischen Zäsur werden. Revision 04 führte die beiden Werte bereits als reserviert. Revision 05 wurde am 25. September hochgeladen. Die IESG eröffnete einen Tag später eine Billigungsabstimmung, verschob den Status auf „IESG Evaluation“ und plante die Besprechung für den 8. Oktober. Im Datatracker fehlten noch notwendige Stimmpositionen; IANA sollte die geänderte Fassung erneut prüfen. Die Angabe, der Entwurf werde RFC 9180 ablösen, ist an Billigung und Veröffentlichung gebunden. Eine bereits eingetretene Ablösung lässt sich daraus nicht ableiten.

Wie absichtlich diese Lücke ist, zeigt die Stellungnahme des Dokumentenbegleiters Martin Thomson vom März. Er beschreibt begrenzte Nutzung der alten authentisierten Modi und fehlende passende Post-Quanten-Unterstützung für ihre derzeitige Bauart. Die Arbeitsgruppe habe die Modi deshalb zögernd aus dieser Fassung herausgenommen. Zugleich sagt er, dass einige Nutzer darauf angewiesen sind; es gehe eher um Aufschub als um Abwertung, mit möglicher Wiederaufnahme später. Diese Einschätzung liefert weder eine belastbare Installationszahl noch einen Befund, dass bisherige Implementierungen verwundbar seien.

Auch die geplanten IANA-Schritte sind zweigeteilt. Die Verweise in den HPKE-Registern sollen bei Annahme auf die Nachfolgespezifikation umgestellt werden, bestehende KEM-Kennungen bleiben sonst bestehen. Im Anmeldeschema für einen KEM steht weiterhin ein boolesches Auth-Feld für AuthEncap() und AuthDecap() aus RFC 9180. Der neue Text erklärt ausdrücklich, dass er dieses Feld nicht nutzt. Damit kann das Register eine Eigenschaft für alte Schnittstellen weiter bezeichnen. Es sagt nichts darüber, welcher Dienst sie aufruft, welche Modi ein Kommunikationspartner akzeptiert oder welche Identität die Anwendung tatsächlich überprüft.

Eine überprüfbare Entscheidung beginnt daher beim einzelnen Einsatzfall. Daniel Kade empfiehlt, die referenzierte Fassung, den tatsächlich aufgerufenen Modus, die erwartete Identitätsaussage, Fähigkeiten der Gegenstelle und Testergebnisse nebeneinander festzuhalten. Ein RFC-9180-spezifischer Pfad könnte nötig bleiben; alternativ kann das Anwendungsprotokoll eine andere Authentisierung festlegen. Die Wahl trifft der verantwortliche Betreiber beziehungsweise Protokollautor, nicht ein umgestellter Registereintrag.

Diese Bestandsaufnahme ist redaktionelle Betriebsempfehlung, keine neue IETF-Pflicht und kein Bericht über einen beobachteten Ausfall.

Quellen