Zusammenfassung

  • RFC 9682 ersetzt die gesammelte CDDL-Grammatik und ergänzt \u{hex}. Die neue Schreibweise ist nicht automatisch mit älteren Prozessoren kompatibel.
  • Ein belastbarer Herkunftsnachweis verbindet Modellbytes, tatsächlichen Parser, semantische Darstellung, Erzeugungsbedingungen und geladenen Validator. Reproduzierbarkeit, korrekte Prüfung und beobachtete Nachrichtenannahme bleiben unterschiedliche Aussagen.

Die Wiederholung muss beim richtigen Artefakt beginnen

Wer einen Validator erneut erzeugen möchte, braucht zunächst einen eindeutig bestimmten Vergleichsgegenstand: nicht irgendeine freigegebene Datei, sondern genau die vom untersuchten Verbraucher geladene Fassung. Andernfalls kann eine perfekte Wiederholung am eigentlichen Betrieb vorbeigehen. Der Vergleich wäre sauber, seine Zuordnung falsch.

Daraus folgt eine betriebliche Empfehlung: Die Herkunft sollte in beide Richtungen rekonstruierbar sein. Vorwärts führt sie von den tatsächlich eingelesenen Modellbytes über Parser und semantische Darstellung zum erzeugten Validator. Rückwärts muss sich vom laufenden Verbraucher aus feststellen lassen, ob gerade dieses Ergebnis wirksam ist. Ein Build-Protokoll ohne Verbindung zum geladenen Artefakt schließt diese Lücke nicht.

Die Concise Data Definition Language (CDDL) beschreibt Strukturen für CBOR- und JSON-Nachrichten. Wie weit eine Anwendung die Beschreibung durchsetzt, überlässt RFC 8610, insbesondere Abschnitt 4.2 den Verantwortlichen für Entwurf und Implementierung. Die hier betrachtete Erzeugung eines Validators ist deshalb eine gewählte Werkzeugarchitektur, keine vom Standard vorgeschriebene Abfolge. Wo ein Werkzeug Schritte zusammenfasst, sollten die Nachweise trotzdem getrennt werden.

Was die Grammatikreparatur festlegt

Die normative Feststellung ist eng umrissen: Anhang A von RFC 9682 ersetzt die gesammelte ABNF in Anhang B von RFC 8610, nicht das gesamte Vorgängerdokument. Behandelt werden Erratum 6278 zu konsistenten Zeichenbereichen, 6526 zu verlorenen Backslashes, 6527 zu Textliteral-Escapes, 6543 zur Behandlung von Byte-Literalen und 6575 zur Bedeutung der Zahlenangaben bei Tags und einfachen Werten. Hinzu kommt \u{hex} für Unicode-Skalarwerte. Alte konforme Dateien bleiben erfasst; neue Syntax kann Aktualisierungen älterer Prozessoren erfordern. Maßgeblich sind RFC 9682, Abschnitte 1 bis 3 und Anhang A.

„Konform“ bedeutet dabei nicht: von irgendeinem toleranten Altwerkzeug angenommen. Sonst würde dessen Verhalten zum Maßstab für die Norm, an der dieses Verhalten erst geprüft werden soll. Ebenso wenig beschreibt „rückwärtskompatibel“ eine Fähigkeit, die durch Veröffentlichung nachträglich in ein altes Programm gelangt.

ABNF beschreibt zulässige Syntax durch Regeln, Terminalwerte und Operatoren; die Grundlage dafür liefert RFC 5234, Abschnitte 2 und 3. Daraus folgt keine Aussage darüber, welche Grammatik ein bestimmtes ausführbares Programm tatsächlich verwendet. Normbezug und Implementierungsnachweis beantworten verschiedene Fragen.

Modellbytes sind etwas anderes als angezeigter Text

Als erste Arbeitsgrundlage sollten die vollständigen Bytes aufbewahrt werden, die unmittelbar beim Parser ankamen. Eine freigegebene Quelldatei genügt dafür nur, wenn ihre unveränderte Übergabe nachvollziehbar ist. Wird vor dem Parse formatiert, umgeschrieben oder dekodiert, entsteht eine zusätzliche Nachweisaufgabe: Welche Fassung wurde geprüft, welche anschließend verarbeitet?

Diese Genauigkeit ist keine Einladung zur pauschalen Textbereinigung. RFC 8610, Abschnitt 3.1 legt UTF-8 als CDDL-Kodierung fest und sieht keine Unicode-Normalisierung bei der Verarbeitung vor. Die betriebliche Schlussfolgerung lautet deshalb: Eine vermeintlich hilfreiche Umformung darf nicht unsichtbar bleiben. Sichtbare Gleichheit ist für den Herkunftsnachweis kein Ersatz für die ursprüngliche Eingabe.

Zur Eingabe gehört die Identität des tatsächlich ausgeführten Parsers einschließlich seiner Version und wirksamen Optionen. Eine Versionsangabe im Projekttext sollte nicht als Beleg dafür gelten, welches Programm einen konkreten Erzeugungslauf ausgeführt hat. Eine Prüfsumme kann beim Zuordnen helfen; sie ersetzt weder die erhaltene Datei noch eine vertrauenswürdige Dokumentation ihrer Verwendung.

Auch die Fähigkeit zur Klammer-Syntax braucht einen eigenen Nachweis. Dass ein Werkzeug allgemein CDDL unterstützt, beantwortet nicht die engere Frage, ob es die konkret verwendete Schreibweise vollständig und mit der vorgesehenen Bedeutung verarbeitet. Eine Ablehnung durch ein älteres Werkzeug wäre zunächst ein Kompatibilitätsbefund, nicht schon ein Gegenbeweis zur gültigen Grammatik.

Ein Rebuild braucht zwei verschiedene Vergleiche

Für die Untersuchung empfiehlt sich, Wiederholung und Änderung auseinanderzuhalten. Bei der Wiederholung bleiben Modellbytes, Parser, Generator, Optionen und relevante Build-Bedingungen festgelegt. Gesucht wird, ob daraus dasselbe Artefakt entsteht. Bei einer gezielten Änderung wird dagegen etwa die Parser-Version ausgetauscht. Gesucht wird, an welcher Stelle sich das Ergebnis verändert. Beide Fragen zugleich zu stellen, erschwert die Ursachenzuordnung.

Zu den empfohlenen Angaben über die Erzeugung gehören auch die verwendete Compilerfassung, Zielumgebung und benötigten Bibliotheken, soweit sie beteiligt sind. Welche Bedingungen das Ergebnis beeinflussen können, sollte ausdrücklich festgehalten werden. Eine Wiederholung mit unbekannten Einflussgrößen wäre keine kontrollierte Gegenprobe.

Ein erfolgreicher Parse belegt zunächst nur, dass der konkret eingesetzte Parser die konkrete Eingabe unter seinen Bedingungen angenommen hat. Er beweist weder vollständige Normkonformität dieses Parsers noch die Korrektheit der nachfolgenden Verarbeitung. Für die Schema-Kompilierung ist deshalb gesondert festzuhalten, welche semantische Darstellung sie erhalten hat: insbesondere Literalwerte, Typzuordnungen und aufgelöste Einschränkungen, soweit das Werkzeug diese offenlegt.

Dabei zählt nicht nur der sichtbare Zeicheninhalt. RFC 8610, Abschnitt 3.1 unterscheidet Text- und Byte-Literale. Für den Vergleich folgt daraus: Der dekodierte Inhalt und sein Typ müssen erhalten bleiben. Eine bloß gleich aussehende Ausgabe kann diesen Nachweis nicht ersetzen.

Fehlt ein zugängliches Zwischenformat, sollte diese Grenze ausdrücklich bestehen bleiben. Dann lässt sich die Bedeutung nicht einfach aus einer Erfolgsmeldung rekonstruieren. Beobachtungen am erzeugten Validator können die Untersuchung ergänzen, aber nicht nachträglich eine nie aufgezeichnete interne Darstellung dokumentieren.

Auch erfolgreiche Schema-Kompilierung beweist noch keine fehlerfreie Validator-Generierung. Die betriebliche Prüfung sollte die Stufen deshalb nicht unter einem gemeinsamen Erfolgsstatus verstecken. Welche Eingabe wurde jeweils verarbeitet, welches Ergebnis entstand und welche Bedingungen galten? Ein Generator kann seine Arbeit erfolgreich abschließen, ohne dass damit bereits die Übereinstimmung seines Ergebnisses mit allen Modellanforderungen bewiesen wäre.

Die Rebuild-Differenz verlangt anschließend eine doppelte Bewertung. Abweichende Artefaktbytes beweisen eine Abweichung der Erzeugnisse, aber nicht automatisch veränderte Validierungsentscheidungen. Zunächst wäre zu klären, ob sich lediglich Begleitinformationen oder tatsächlich die prüfenden Bestandteile unterscheiden. Ohne Untersuchung bleibt die Bedeutung der Differenz offen.

Umgekehrt beweisen identische Artefaktbytes keine richtige Interpretation des Modells: Ein identisch wiederholter Fehler bleibt ein Fehler. Reproduzierbarkeit ist hier ein Konsistenznachweis, kein Korrektheitsbeweis. Selbst übereinstimmende Ergebnisse an ausgewählten Nachrichten würden nur diese Auswahl abdecken. Für eine darüber hinausgehende Behauptung semantischer Gleichwertigkeit wäre eine entsprechend stärkere Begründung nötig.

Zwischen Erzeugung und Wirkung liegt der Verbraucher

Für das Deployment sollte daher ein eigener Nachweis verlangt werden: Welcher Verbraucher hat welchen Validator tatsächlich geladen? Die erfolgreiche Bereitstellung einer Datei beantwortet diese Frage noch nicht. Ebenso wenig genügt die Versionsbezeichnung einer Anwendung, wenn ihre Verbindung zum geladenen Prüfprogramm ungeklärt ist. Laden ist zudem nicht gleich Ausführen: Für einen Nachrichtenbefund wäre gesondert nachzuweisen, dass der betreffende Validator tatsächlich zur Entscheidung herangezogen wurde.

Besonders wichtig ist eine Unterscheidung für ältere Verbraucher. Erhält ein Verbraucher ausschließlich einen bereits erzeugten Validator und verarbeitet selbst keine CDDL-Quelle, lässt sich aus seinem Alter allein keine Ablehnung von \u{hex} ableiten. Die Syntaxgrenze liegt dann zunächst beim quellverarbeitenden Werkzeug. Ob das erzeugte Artefakt mit dem Verbraucher zusammenarbeitet, ist gesondert zu untersuchen.

Das ist eine Schlussfolgerung aus den unterschiedlichen Eingaben, keine behauptete Eigenschaft eines bestimmten Produkts. Sie verhindert zwei gegensätzliche Fehlschlüsse: Ein neuer Parser macht nicht automatisch jeden Verbraucher kompatibel; ein älterer Verbraucher ist nicht automatisch inkompatibel, nur weil zuvor neue Quellsyntax verwendet wurde.

Die Nachricht ist eine weitere Beweisgrenze

Auf der Nachrichtenseite unterscheidet RFC 8949, Abschnitt 1.2 zwischen syntaktisch wohlgeformten, darüber hinaus CBOR-gültigen und von der Anwendung erwarteten Daten. Diese Abstufung betrifft CBOR-Nachrichten, nicht die Annahme des CDDL-Quelltextes. Wer beide Prüfgegenstände vermischt, kann einen erfolgreichen Modell-Parse fälschlich als Nachrichtenvalidierung ausgeben.

Die betriebliche Empfehlung lautet: Laufzeitbefunde sollten empfangene Nachrichtenbytes, zuständigen Verbraucher, tatsächlich verwendeten Validator und beobachtete Annahme oder Ablehnung zusammenführen. Eine Meldung „erfolgreich“ braucht ihren Gegenstand. Meldet sie das Laden, das Dekodieren, die Schema-Prüfung oder die weitere Verarbeitung?

Ein dokumentiertes Ergebnis kann einer vorherigen Annahme widersprechen. Es erklärt dadurch aber noch nicht, ob Parser, Kompilierung, Erzeugung oder Verwendung die Abweichung verursacht haben. Ebenso wenig beweist eine angenommene Nachricht allgemeine Interoperabilität. Dafür müssten die beteiligten Implementierungen und die untersuchten Nachrichtenanforderungen benannt werden.

Diese Vorsicht hat einen normativen Anknüpfungspunkt: RFC 9682, Abschnitt 4 warnt vor unterschiedlich aktualisierten Werkzeugen und ausnutzbaren Interpretationsunterschieden. Er betont die notwendige Absicherung von Herkunft, Authentizität, Integrität und Anwendbarkeit der Modelle sowie Sorgfalt wie bei anderem Quellcode. Das beschreibt ein Risiko, keinen hier nachgewiesenen Angriff.