Summary

  • Das SFrame-Verzeichnis der IANA trägt als letztes Änderungsdatum den 5. Mai 2026. Die Tabelle enthält inzwischen Nh, Nka, Nk, Nn und Nt sowie die Kennungen 0x0006 bis 0x0008 für AES-256-CTR/HMAC-SHA512. Alle drei haben den Empfehlungswert Y und einen vorläufigen Verweis auf Entwurfsfassung 06.
  • Der IETF Datatracker führt die Fassung noch in der Warteschlange des RFC Editor. Die öffentliche Eintragung belegt Kennungen und Parameter. Ein fertiges RFC und die Nutzung durch eine Anwendung sind weitere, getrennt nachzuweisende Schritte.

Ein Registereintrag wird messbar

RFC 9605 schuf das SFrame Cipher Suites Register ursprünglich mit Wert, Name, Empfehlungsstatus, Referenz und Änderungszuständigkeit. Für Schlüssellängen, Nonce und Tag musste der Leser die technische Spezifikation heranziehen. Der neue Entwurf will fünf Längen in die Tabelle selbst holen. Nh gibt die Hash-Ausgabelänge an, Nka die Länge des zugrunde liegenden Verschlüsselungsschlüssels in der zusammengesetzten Konstruktion, Nk die Schlüssellänge, Nn die Nonce-Länge und Nt den zusätzlichen Platzbedarf, meist für den Tag. Ein Hersteller kann dann eine konkrete Implementierung gegen die öffentliche Zeile prüfen.

Die aktuelle IANA-Tabelle ist bereits so aufgebaut. Für die neuen drei Suiten stehen jeweils 64 Byte bei Nh, 32 bei Nka, 96 bei Nk und 12 bei Nn. Die drei Nt-Werte betragen 10, 8 und 4 Byte. Der Entwurf erläutert die technische Verschiebung: Intern abgeleitetes Material wächst gegenüber AES-128-CTR/HMAC-SHA256 von 48 auf 96 Byte, der anfängliche Tag-Wert von 32 auf 64. Testvektoren im Anhang decken die AEAD-Konstruktion und vollständige SFrame-Frames ab. Genau solche Details machen aus einem Kennungsregister ein brauchbares Prüfblatt.

Die Empfehlungsspalte ist ebenfalls kein Schmuck. RFC 9605 setzt für normale Zuweisungen nach Specification Required standardmäßig N. Ein Y oder D und Änderungen solcher Werte verlangen Standards Action. In der Entwurfshistorie ist eine Debatte vom April sichtbar, in der der Standards-Track-Status mit den neuen empfohlenen Einträgen abgestimmt wurde. Das Verfahren erklärt die Y-Markierung. Ob ein Produkt eine dieser Suiten aktiviert, entscheidet das Verfahren nicht.

Der Platzhalter steht offen im Register

Die Referenz der drei neuen IANA-Zeilen lautet RFC-barnes-sframe-iana-256-06. Sie benennt den Entwurf, noch keine endgültige RFC-Nummer. Fassung 06 ist auf den 4. Mai datiert, die IANA-Seite auf den 5. Mai aktualisiert. Am 28. Oktober verzeichnete der Datatracker weiterhin die RFC-Redaktionsschlange und den IANA-Aktionsstatus RFC-Ed-Ack. Das ist ein gut sichtbarer Zwischenzustand: Die Kennungen sind öffentlich beschreibbar, während die endgültige Veröffentlichung ihrem eigenen Ablauf folgt.

Für die Medienverbindung entscheidet eine andere Stelle. RFC 9605 verlangt, dass die Anwendung festlegt, wann SFrame greift und welche Chiffre verwendet wird. Seine Sicherheitsanalyse warnt vor Fälschungsversuchen bei kurzen Authentifizierungs-Tags und beschreibt volle Tag-Längen in vielen Fällen als einfachere Wahl. Die neuen Kennungen bieten 10, 8 und 4 Byte. Die Tabelle kann die Länge angeben; ein Anbieter muss die Schutzmaßnahmen für seine gewählte Länge konstruieren und nachweisen.

Die herangezogenen Originaldokumente nennen keine konkrete Produktinstallation und keinen Anruf mit den neuen Codes. Ein nummeriertes RFC, überprüfbare Einstellungen und Betriebstests würden diese Aussage verändern. Heute lässt sich präzise feststellen, was im Register steht und wer seine Zeilen ändern darf.