Zusammenfassung

  • Die am 23. September eingereichte Fassung -05 des CCF-Profils für COSE-Belege verlangt neben einem Datenstruktur-Algorithmus auch zwei Einträge im IANA-Register für Beweise.
  • Fassung -04 enthielt nur den Algorithmusantrag. Jetzt werden für CCF_LEDGER_SHA256 der Wert 2 sowie darunter die Beweistypen -1 für Inklusion und -2 für Konsistenz beantragt.
  • Das sind beantragte, nicht vergebene Kennungen. Die öffentlichen COSE-Register enthalten weiterhin nur Struktur 1 mit zwei zugehörigen Beweisen.

Eine Kennzahl im Protokoll ist erst dann hilfreich, wenn verschiedene Prüfprogramme dasselbe darunter verstehen. Genau an dieser Stelle war der ältere Entwurf unvollständig: Er wollte eine CCF-Datenstruktur in das gemeinsame Register aufnehmen, ließ aber die Registrierungen der Beweise aus, die ein Empfänger zu dieser Struktur verarbeiten müsste. Ein IANA-Fachgutachter benannte die Lücke am 12. September. Die neue Fassung des IETF-Arbeitskreises SCITT beantwortet sie mit zwei ausdrücklich gekoppelten Anträgen.

Der erste betrifft das Register für Algorithmen verifizierbarer Datenstrukturen: CCF_LEDGER_SHA256 soll dort die Nummer 2 erhalten. Der zweite betrifft ein eigenes Register, in dem Beweistypen einer bestimmten Struktur zugeordnet werden. Für die beantragte CCF-Struktur sollen Inklusionsbeweise das Label -1 und Konsistenzbeweise -2 tragen. Zwar stehen diese beiden negativen Labels bereits im öffentlichen Register. Dort gehören sie aber zur Struktur 1, RFC9162_SHA256. Wer nur -1 liest und den Strukturkontext ignoriert, kann daraus keine CCF-Definition ableiten.

Auch die Nachrichtenform ist in -05 genauer ausgeführt. Ein geschützter vds-Header benennt die Struktur; die ungeschützte vdp-Abbildung ordnet die Belege ihren Typen zu. Das entspricht dem COSE-Receipts-Rahmen der RFC 9942. Der Entwurf beschreibt für beide Beweisarten die Verifikation. Er dokumentiert damit eine technische Absicht und keine bereits erfolgte Registrierung oder Installation bei einem bestimmten Betreiber.

Besonders leicht lässt sich der Verwaltungsstand missverstehen. Das ältere Dokument war mit IANA - Not OK gekennzeichnet. Nach dem Hochladen von -05 wechselte die Anzeige auf Version Changed - Review Needed — ein erneuter Prüfbedarf, keine Freigabe. Der sichtbare Expertenstatus lautet weiterhin Issues identified. In den IANA-Tabellen fehlen CCF-Algorithmus und CCF-Beweise weiterhin; selbst der Entwurf spricht bei Nummer 2 von einer gewünschten Zuweisung und verwendet bis dahin einen Platzhalter. Die Veröffentlichung einer neuen Internet-Draft-Fassung schafft keine neue Registerzeile.

Die inhaltliche Reichweite bleibt ebenfalls begrenzt. Ein Konsistenzbeleg muss anhand einer älteren Wurzel geprüft werden, die der Prüfer bereits unabhängig bestätigt hat. Eine Wurzel, die mit demselben Beleg geliefert wird, genügt nicht. Nach dem Entwurf belegt Konsistenz weder den Inhalt des Ledgers für sich noch die korrekte Anwendung einer Registrierungspolitik. Der aktuelle Vorgang schließt zunächst eine Lücke in der gemeinsamen technischen Beschreibung, nicht in der gesamten Vertrauenskette.

Quellen