Zusammenfassung

  • Die sloppy-Varianten der Base64-Kontrollen in RFC 9741 verzichten auf die Nullprüfung ungenutzter Bits. .json beschreibt den dekodierten Wert, nicht eine einzige zulässige Serialisierung.
  • Eine zusätzliche Schreibweise wirkt nur über die tatsächlichen Schlüssel und Verknüpfungen auf Freigaben, Caches oder Abrechnung. Wertgleichheit allein belegt weder eine Umgehung noch eine falsche Rechnung.
  • Annahmeprofil, Geschäftsidentität und kryptografische Eingabe benötigen getrennte Regeln. Neue Zuordnungen dürfen historische Entscheidungen nicht stillschweigend neu interpretieren.

Die Umstellung trifft nicht nur neue Anfragen

Ein Dienst kann seine Eingangsprüfung ändern, ohne dass eine alte Rechnung dadurch eine andere Bedeutung erhält. Diese scheinbar einfache Grenze wird schwierig, wenn mehrere bisher getrennte Textschlüssel unter der neuen Regel zum selben dekodierten Wert gehören.

Betrachten wir einen hypothetischen Dienst für Inhaltsreferenzen. Die Annahme prüft die aus einem Text gewonnenen Bytes. Ein Freigabesystem speichert die ursprüngliche Schreibweise, Ressourcenverwaltung und Kontingent besitzen eigene Schlüssel, und die Abrechnung verwendet einen Teil dieser Datensätze. Es geht nicht um ein nachgewiesenes Produktverhalten oder einen bekannten Vorfall.

Wird die Annahme toleranter, können zwei Texte dieselbe zugelassene Bytefolge bezeichnen. Damit ist noch nicht entschieden, ob zwei Datensätze zusammengeführt werden sollen. Sie können zwei kostenpflichtige Anfragen, eine Ressource mit zwei Namen oder unterschiedliche Freigaben für unterschiedliche Zwecke darstellen. Die neue Dekodierregel weiß nicht, welche dieser Bedeutungen das Geschäft gewählt hat.

Gerade bei einer Migration ist die Frage deshalb größer als ein sauberer Index. Früher getrennte Schlüssel können kollidieren. Eine technische Gleichheit erklärt die neue Zuordnung; sie gibt dem Betreiber des Dekoders aber keinen Auftrag, eine alte Freigabe oder Forderung umzudeuten. Bevor man Datensätze zusammenlegt, braucht man die betreffende Geschäftsregel und die Zuständigkeit für ihre Anwendung.

Eine zusätzliche Schreibweise aus vier ungenutzten Bits

RFC 9741 von Carsten Bormann erschien im März 2025 als RFC im Standardisierungsprozess der IETF und ergänzt CDDL um Kontrollen zur Textkonvertierung und -verarbeitung. .b64u und .b64u-sloppy betreffen Base64url ohne Auffüllung, .b64c und .b64c-sloppy klassisches Base64 mit Auffüllung. Die sloppy-Varianten lassen die Prüfung weg, ob zusätzliche ungenutzte Bits null sind. Andere Regeln verschwinden dadurch nicht. .json legt ebenfalls weder bedeutungslose Leerzeichen noch die Serialisierungsreihenfolge von Map-Einträgen fest. Die Veröffentlichung belegt keine konkrete Implementierung.

Die Zeichenfolgen Zg und Zh machen den ersten Unterschied sichtbar. Ihre ersten acht Bits lauten jeweils 01100110, also 0x66. Die übrigen vier Bits der zweiten Sechsergruppe sind 0000 beziehungsweise 0001. Das ist eine manuelle Ableitung aus der Bitanordnung, kein ausgeführter Konformitätstest eines CDDL-Prüfers. Bei demselben Kontrollwert, der dieses Byte erlaubt, liegt der betreffende Unterschied zwischen strikter und sloppy-Prüfung in diesen ungenutzten Bits. Die klassischen Formen mit Auffüllung sind Zg== und Zh==.

RFC 4648, Abschnitt 3.5, verlangt von konformen Kodierern Nullbits an diesen Stellen und beschreibt die Ablehnung durch Dekoder im Verhältnis zur jeweils referenzierenden Spezifikation. Vier veränderbare ungenutzte Bits ergeben in dieser Ein-Byte-Anordnung sechzehn Schreibweisen mit denselben Nutzbits. Die Zahl gilt nicht pauschal für jedes Token jeder Länge.

Ein strikter Eingang kann die nichtkanonische Schreibweise zurückweisen. Ein definierter Kompatibilitätseingang kann diese begrenzte Abweichung akzeptieren. sloppy bedeutet aber nicht, beliebige Leerzeichen, gemischte Alphabete oder abgeschnittene Daten zu reparieren. Wer den Namen als allgemeine Toleranzzusage liest, erweitert die Regel ohne Grundlage.

Das Formular besteht die Prüfung, der Schlüssel bleibt verschieden

Auch JSON kann denselben Wert in unterschiedlichen Texten transportieren:

{"account":"team-a","units":1}

{ "units": 1, "account": "team-a" }

Die Texte enthalten dieselben festen Zeichenketten und die kleine Ganzzahl 1, ohne doppelte Namen. Nur Leerzeichen ohne Bedeutungswirkung und die Reihenfolge der Objektmitglieder ändern sich. RFC 8259 liefert die JSON-Syntax. I-JSON in RFC 7493 schließt unter anderem doppelte Namen aus und erklärt, dass die Mitgliederreihenfolge die Bedeutung einer Nachricht nicht verändert.

Die .json-Kontrolle verwendet die standardmäßige JSON-zu-CBOR-Konvertierung aus RFC 8949, Abschnitt 6.2. Sie beschreibt den resultierenden Wert, nicht eine einzige Textausgabe. Ein erfolgreich geprüftes Formular ist damit nicht automatisch ein stabiler Freigabe- oder Abrechnungsschlüssel.

Das Beispiel umgeht bewusst schwierigere Gleichheitsannahmen. Numerische Präzision, Repräsentationsentscheidungen und Anwendungsmodelle mit Zahlen als Zeichenketten müssen gesondert betrachtet werden. Umgeordnete Arrays oder doppelte Schlüssel sind keine austauschbaren Varianten dieses Falls. Die Anwendung muss ihre Einschränkungen im Kontrollwert abbilden; der Konverter erfindet sie nicht.

Andere Kontrollen zeigen ebenfalls gezielte Entscheidungen statt allgemeiner Bereinigung. Hexadezimale Formen unterscheiden flexible und feste Großschreibung, die Dezimalform lässt keine beliebigen führenden Nullen zu. Ein Datenfeld kann eine andere erlaubte Textbeziehung benötigen als ein anderes. Daraus folgt keine einheitliche Geschäftsidentität für das gesamte System.

Die Signatur kann genau die ursprüngliche Darstellung binden

Bevor ein Betreiber Textschlüssel vereinheitlicht, muss er auch die Authentifizierungsgrenze kennen. Im gewöhnlichen JWS mit Base64url-kodierter Nutzlast definiert RFC 7515 die Signiereingabe aus dem kodierten geschützten Header, einem Punkt und der kodierten Nutzlast. Gleiche Werte nach JSON-Analyse erlauben nicht, diese Eingabe durch eine neue Serialisierung zu ersetzen.

Eine Anwendung kann ausdrücklich eine kanonische Darstellung ihres Datenmodells für kryptografische Operationen wählen. JCS nach RFC 8785 stellt innerhalb seiner Eingabebeschränkungen eine deterministische Repräsentation bereit. Es ist ein informativer RFC aus dem unabhängigen Veröffentlichungsweg, keine versteckte Pflicht der .json-Kontrolle. Erweiterungen mit unkodierter Nutzlast und andere Signaturhüllen werden hier nicht verallgemeinert.

Die Anweisung „vor der Nutzung normalisieren“ braucht deshalb einen Zweck und eine Reihenfolge. Eine Abbildung für den Ressourcenindex darf die vom gewählten Authentifizierungsverfahren benötigte Eingabe nicht nach eigenem Ermessen umschreiben. Der Cache kann eine Differenz ignorieren, die der Absender ausdrücklich authentifiziert hat. Beide Regeln können sachgerecht sein, solange ihre Grenze erhalten bleibt.

Gleiche Inhalte sind keine gemeinsame Rechnungseinheit

Auch ohne Migration braucht der Dienst eine Definition dessen, was er verkauft. Eine Anfrage kostet Annahme, Dekodierung, Warteschlange und Protokollierung möglicherweise erneut, selbst wenn der Cache nur eine Ressource hält. Ein Ressourcenpreis kann dagegen vorsehen, dass ein Alias keine zusätzliche abrechenbare Ressource erzeugt. Ein Preis pro Geschäftsaktion verlangt die Identität der Aktion und ihren Zustandswechsel.

Diese Einheiten dürfen sich unterscheiden. Speicherdeduplizierung beseitigt nicht zwangsläufig Anfragearbeit. Inhaltliche Gleichheit überträgt keine Rechte zwischen Mandanten. Derselbe Mandant kann denselben Inhalt für verschiedene Zwecke oder Operationen verwenden. Ein globaler Nutzlast-Hash kann deshalb Beziehungen zusammenführen, die fachlich getrennt bleiben müssen.

Für eine Abrechnungsprüfung braucht man Vertragseinheit, Zählbereich, Datensatzverknüpfung und tatsächliche Rechnung. Zwei Texte mit gleichen Bytes liefern keinen fertigen Befund. Für die Behauptung einer Freigabeumgehung braucht man die Regel, die eine Aktion verhindern sollte, und den Nachweis, wie der Alias ihre Entscheidung oder Verknüpfung veränderte. Eine verbotene Wiederholung setzt ebenfalls Belege zur Aktion und ihrem Zustand voraus.

Das hypothetische Modell benennt also eine Untersuchungsstelle, keinen Schaden. RFC-Konformität kann eine Darstellung erklären. Sie ersetzt weder den Vertrag noch den Beweis, dass ein bestimmter Prozess das erwartete Ergebnis hatte.

Ein gemeinsamer Prüfpunkt ist keine gemeinsame Entscheidungsinstanz

Lu Hengs Überlegungen zu einer minimalen gemeinsamen Spezifikation trennen deterministische gemeinsame Regeln von Geschäftsvereinbarungen und späteren Betriebsentscheidungen. Als analytische Perspektive bedeutet das hier: Die Annahmeregel soll überprüfbar sein, ohne stillschweigend über Freigabe und Preis zu entscheiden. Es ist weder seine Begutachtung von RFC 9741 noch eine Abrechnungsanforderung der IETF.

Sein Argument zum Vorrang laufenden Codes trennt Veröffentlichung und tatsächliche Übernahme. Im hypothetischen Dienst muss man die ausgeführten Verknüpfungen beobachten, nicht nur ein Konformitätslabel lesen. Die Diskussion über Realitätsebenen und symbolische Macht dient ebenfalls als Perspektive: Ein Prüfbeleg steht für einen Prüfschritt, nicht für die ganze Geschäftsaktion.

RFC 8610, Abschnitt 5, warnt bereits davor, allein auf die Korrektheit einer CDDL-Spezifikation und ihres Matchers ohne weitere Schutzmaßnahmen zu vertrauen. Je präziser eine Text-Wert-Beziehung ist, desto klarer wird, welche Entscheidungen außerhalb von ihr liegen. Kompatibilität kann Arbeit sparen. Ohne Verantwortlichen für den verbleibenden Abgleich verlagert sie diese Arbeit lediglich.