Zusammenfassung

  • draft-tiloca-lake-private-use-ranges-01 schlägt Private-Use-Bereiche für drei EDHOC-Register vor; die neuen Werte beanspruchen als CBOR-Integer insgesamt fünf Byte.
  • 4294967295 und -4294967296 liegen im vorgeschlagenen Wertebereich, aber außerhalb eines vorzeichenbehafteten 32-Bit-Typs.
  • Private Use schafft lokale Koordination, keine globale Bedeutung. Authentifizierung beweist weder identische Interpretation beider Peers noch den Anwendungserfolg.

Der Fehlerbericht sagt -1. Der Netzwerk-Mitschnitt sagt 4294967295. Beide können wahr sein: Der CBOR-Decoder lieferte den richtigen Wert, anschließend schob ihn eine ältere API in int32. Genau dort verschwand die für die Diagnose wichtigste Tatsache.

Revision 01 des individuellen Internet-Drafts Additional Private Use Ranges in the IANA Registries of the Lightweight Authenticated Key Exchange Protocol legt neue Bereiche für Method Types, Error Codes und External Authorization Data fest. Sie beginnen jenseits der kurzen vorhandenen Bereiche und nutzen ein vier Byte langes CBOR-Argument. Einschließlich Initialbyte sind es fünf Byte auf der Leitung.

Argumentbreite ist nicht Anwendungsbreite

RFC 8949 kodiert mit Major Type 0 den Wert N und mit Major Type 1 den Wert -1-N. Das maximale Vier-Byte-Argument erreicht positiv 4294967295 und negativ -4294967296. Ein signiertes 32-Bit-Integer deckt keine dieser Grenzen ab.

Die vollständige Unterstützung verlangt deshalb etwa int64 oder eine getrennte Darstellung von Vorzeichen und Betrag. Die Breite muss Decoder, Bereichsprüfung, Dispatch, Speicherung und Telemetrie überleben. Ein breiter Parser vor einer schmalen Enumeration löst nichts.

Beim EAD ist das Vorzeichen eine Verarbeitungsregel

Nach RFC 9528 führt das IANA-Register den Absolutwert eines ead_label. Ein negatives Label ist critical, ein nichtnegatives non-critical. 65536 und -65536 benennen damit denselben privaten Gegenstand, aber nicht dieselbe Reaktion eines Empfängers, der ihn nicht kennt.

Auch die Länge unterscheidet sich: Positiv 65536 braucht vier Argumentbytes, negativ -65536 kodiert das Argument 65535 in zwei. Wer zu früh normalisiert, verliert das Vorzeichen. Wer am negativen Endpunkt erst verengt und dann den Absolutwert bildet, kann den ursprünglichen Wert nicht mehr darstellen. Empfangslabel, absoluter Registerschlüssel und Critical-Entscheidung gehören als drei Felder in den Beleg.

Privat heißt bereichsgebunden

RFC 8126 verspricht für Private Use keine allgemeine Interoperabilität und verhindert nicht, dass mehrere Parteien dieselbe Zahl verschieden verwenden. Das ist für proprietäre Versuche nützlich. Bei Fusionen, gemeinsamen Gateways oder wiederverwendeten SDKs wird es zum Kollisionsrisiko.

Eine private Zahl benötigt daher die Identität ihres Zuteilungsbereichs, eine Profilversion und ein Compatibility Set. Zwei Hersteller können 70000 intern konsistent und gemeinsam inkompatibel verwenden. Unbekannte Bereiche müssen erklärbar abgewiesen werden.

Drei Register, drei Schadenspfade

Ein Method Type wählt eine Authentisierungskonstruktion. Ein Error Code steuert Fehlerdeutung und Reaktion. Ein EAD Label wählt opaque Anwendungsdaten und trägt über sein Vorzeichen Criticality. Dieselbe Verengung kann somit eine falsche Methode, falsche Recovery oder falsches Weiterlaufen auslösen.

Der Entwurf meldet keinen Vorfall und keine Implementierungslücke. Er sagt, dass die Sicherheitsbetrachtungen von RFC 9528 fortgelten. Seine operative Aussage ist enger: Wer den gesamten Bereich unterstützt, muss jeden Wert erhalten.

Grenztests und Beleg

Testvektoren brauchen 65535/65536, 4294967295, -65536/-65537, -4294967296, die Werte unmittelbar außerhalb sowie positive und negative EAD-Formen. Zusätzlich sollten zwei private Profile derselben Zahl absichtlich verschiedene Bedeutungen geben. Geprüft werden Originalbytes, mathematischer Wert, Konvertierung, Bereich, Handler, Criticality, Log und Profilablehnung.

Das aktuelle IANA-EDHOC-Register ist die Baseline von RFC 9528. Der Datatracker-Eintrag beschreibt einen individuellen Entwurf, keine vollzogene Zuteilung, keinen Konsens und keinen Einsatz. Private Nachbarbereiche aus RFC 9668 belegen diese Codepfade ebenfalls nicht.

Der Betriebsbeleg enthält Register, CBOR-Bytes, Major Type, Argumentbreite, Wert vor jeder Verengung, geprüfte Konvertierungen, EAD-Vorzeichen/Absolutwert/Criticality, privaten Bereich und Version, Peer-Profile, Handler, Transcript-Verweis und Anwendungsergebnis. Er macht die Zahl nicht global; er bewahrt die Erklärung.

Dabei reichen getrennte Logdateien nicht. Ein Paketmitschnitt kennt die Originalbytes, aber nicht zwingend die aktive private Profilversion. Das Anwendungslog kennt den Handler, kann den Wert jedoch bereits verengt haben. Eine Metrik zählt Fehler, verliert aber den einzelnen Zusammenhang. Alle Ebenen benötigen deshalb dieselbe Sitzungsreferenz und den Digest des tatsächlich verwendeten lokalen Profils. Erst dann lässt sich belegen, an welcher Grenze die Bedeutung abwich.

Kompatibilität ist folglich bilateral und versioniert. Der Sender dokumentiert den privaten Zuteilungsbereich, den er verwendet hat; der Empfänger dokumentiert den Bereich, den er angewandt hat. Gleiche Zahl ohne gleichen Bereich erlaubt keinen Dispatch. Gleicher Bereich mit unterschiedlicher Version braucht eine ausdrückliche Evolutionsregel, niemals stilles Raten.

Quellen