Zusammenfassung

  • Der LAKE-Arbeitsgruppenentwurf vom 2. November beantragt für EDHOC zwei Kennungen für externe Autorisierungsdaten: BG für das Background-Check-Modell und PP für das Passport-Modell. Die Julifassung beantragte zusätzlich je eine eigene Auslöserkennung.
  • Ein Relying Party kann mit CBOR true (0xF5) unter der jeweiligen Modellkennung in message_1 beginnen. Der Attester muss in message_2 unter derselben Kennung mit einem Vorschlag antworten.
  • Die vorgesehenen Kennungen heißen weiter TBD1 und TBD2. Im IANA-Register sind sie bislang nicht vergeben.

Die Klingel trägt nun dieselbe Nummer wie die Akte

Die Fassung 06 reservierte im Antrag vier Zeilen: Material für BG und PP sowie zwei getrennte Trigger. In Fassung 07 fallen die Trigger-Zeilen weg. Unter BG oder PP laufen nun Startsignal, Vorschlag, Anforderung und anschließend Nachweis beziehungsweise Prüfergebnis. Ein Parser, der nur die Kennung liest, kennt den Zustand dieses Gesprächs nicht.

Das Startsignal ist der CBOR-Wahrheitswert 0xF5. Die Relying Party sendet ihn in der ersten EDHOC-Nachricht; die attestierende Seite antwortet in der zweiten mit einem Vorschlag. Bei BG leitet die Relying Party Gerätebelege an einen Verifier weiter. Bei PP bringt der Attester ein Ergebnis mit, das ein Verifier bereits ausgestellt hat. Dieselbe Kennung deckt in beiden Fällen mehrere Handlungen ab, deren Verwechslung das spätere Zugriffsprotokoll verfälscht.

Der Entwurf vertraut der Relying Party außerdem die Auswahl eines Belegtyps nach Einsatzrichtlinie an. Das Gerät liefert Messwerte, der Verifier bewertet sie, die Relying Party entscheidet über Zugriff. Keine Einsparung im Kennungsregister entscheidet diese Frage für sie.

Im LAKE-Dokumentenverzeichnis steht der Text als Arbeitsgruppen-Internet-Draft mit Status I-D Exists. Das IANA-Register führt die beiden RA-Kennungen nicht. Für einen Implementierungsbefund fehlen endgültige Nummern und ein nachprüfbarer Interoperabilitätstest dieser Fassung.