Zusammenfassung

  • Die SCITT-Vorsitzenden haben am 25. September zur Stellungnahme aufgerufen: Soll ein individueller Entwurf über COSE-Belege für Merkle Mountain Ranges in die Arbeitsgruppe übernommen werden? Frist ist der 9. Oktober.
  • Die Befragung bei IETF 126 erfasste lediglich die Bereitschaft zur Durchsicht; sie war kein Beschluss über die Übernahme.
  • RFC 9942 schafft einen gemeinsamen Belegrahmen, warnt aber ausdrücklich vor der Annahme, unterschiedliche verifizierbare Datenstrukturen seien deshalb interoperabel.

Bei einem kryptografischen Beleg sind zwei Fragen leicht zu verwechseln: Kann ein Programm das äußere Format lesen, und kann es die konkrete Beweisführung prüfen? Der erste Schritt ist für einen MMR-Beleg nicht hinreichend. Genau deshalb verdient der SCITT-Aufruf vom 25. September mehr Aufmerksamkeit als eine Meldung über einen weiteren Entwurf. Die Vorsitzenden bitten um begründete Rückmeldungen zur Übernahme von draft-bryce-cose-receipts-mmr-profile-03 als Grundlage weiterer Gruppenarbeit.

Der Aufruf macht seinen begrenzten Gegenstand deutlich. Interessierte sollen Zustimmung oder Ablehnung begründen und angeben, ob sie prüfen, beitragen oder implementieren würden. Eine mögliche Übernahme sage nichts darüber aus, ob das Papier fertig oder veröffentlichungsreif sei. Der 9. Oktober beendet zunächst nur die Rückmeldefrist. Im Datatracker bleibt die Fassung -03 ein aktiver individueller Internet-Draft ohne formelle Billigung durch die IETF.

Auch der Blick auf IETF 126 beseitigt einen möglichen Kurzschluss. Im Juli erklärten vier von 34 Anwesenden ihre Bereitschaft zur Begutachtung; niemand lehnte eine Durchsicht ab, drei äußerten keine Meinung. Die Abstimmung betraf nicht die Übernahme als Arbeitsgruppendokument. Das Protokoll sah die Fortsetzung auf der Mailingliste vor. Der September-Aufruf ist ein gesonderter Verfahrensschritt und kein nachträgliches Zertifikat für das Juli-Ergebnis.

Technisch arbeitet der Vorschlag mit binären Bäumen in Postorder-Reihenfolge, deren Gipfel einen Akkumulator bilden. Ein Inklusionsbeweis bindet einen Eintrag an einen signierten Zustand. Ein Konsistenzbeweis soll einen älteren und einen jüngeren Zustand verbinden. Der Strukturkennwert steht im geschützten COSE-Header; die Beweisdaten haben eine profilspezifische Form. Weil die Nutzlast abgetrennt ist, muss ein Prüfer die Wurzel aus dem Beweis rekonstruieren, bevor er die Signatur kontrolliert. Ein COSE-Decoder allein leistet das nicht.

RFC 9942 benennt genau diese Trennlinie: Verschiedene verifizierbare Datenstrukturen können verschiedene Darstellungen und Sicherheitsannahmen haben; automatische Interoperabilität ist nicht zu erwarten. SCITT bearbeitet bereits ein separates CCF-Profil. Die vorgeschlagene MMR-Arbeit würde bei Übernahme einen weiteren Belegtyp unter gemeinsamer Koordination stellen, ohne beide Baumverfahren gleichzusetzen. Der Entwurf erklärt zudem, dass Inklusion keine Aussage über die Berechtigung eines Eintrags trifft und ursprünglich ausgelassene Einträge damit nicht aufgedeckt werden.

Diese allgemeine Beweisgrenze ist bekannt; die neue Governance-Frage ist, wer die spezifische Prüfsprache weiterentwickelt und wie ihr Einsatz nachweisbar wird.

Wer solche Belege einkauft oder nutzt, sollte daher nicht nur nach „COSE-Unterstützung“ fragen, sondern nach dem unterstützten Strukturkennwert, den Beweistypen, der Regelversion und reproduzierbaren Tests für Inklusion und Konsistenz. Das ist eine redaktionelle Prüffrage, keine bereits beschlossene SCITT-Vorgabe. Eine Arbeitsgruppe kann Verantwortung für ein Dokument übernehmen; der Nachweis funktionierender Verifikation muss danach gesondert geführt werden.

Quellen