Zusammenfassung

  • RFC 3075 ließ SignatureValue über kanonisiertem SignedInfo prüfen; dessen Reference-Einträge verpflichteten auf Hashwerte von Daten nach einer geordneten Transformationskette.
  • Erfolgreiche Kernvalidierung bewies weder den gesamten XML-Quellbaum noch die sichtbare Darstellung, die Vertrauenswürdigkeit von KeyInfo, alle Manifest-Mitglieder oder die Anwendungsfreigabe.

Als die XMLDSIG-Arbeitsgruppe RFC 3075 im März 2001 veröffentlichte, definierte sie kein Siegel für Dateien. Sie definierte ein Verfahren, das XML- und Nicht-XML-Daten innerhalb, außerhalb oder um eine Signature-Struktur herum adressieren konnte. Die Reichweite entstand aus Referenzen und Verarbeitung, nicht aus dem äußeren Dokumentrand.

Das Kernergebnis setzte zwei Prüfungen zusammen

Bei der Referenzvalidierung beschaffte der Prüfer für jeden Eintrag in SignedInfo das Datenobjekt, erzeugte den vorgesehenen Digest-Eingang und verglich den berechneten Wert mit DigestValue. Bei der Signaturvalidierung kanonisierte er SignedInfo und prüfte SignatureValue mit ausgewähltem Schlüssel und Verfahren.

Eine korrekte Signatur über falschen Referenz-Hashes war kein Erfolg. Passende Hashwerte authentisierten die Liste nicht von selbst. Erst beide Prüfungen verbanden einen Schlüssel mit genau diesen Digest-Zusagen und Methoden. Umliegende XML-Knoten, später geladene Ressourcen und geschäftliche Folgerungen kamen nicht automatisch hinzu.

Für eine nachvollziehbare Prüfung mussten daher sowohl das kanonische SignedInfo als auch die tatsächlichen Bytes vor jeder Digest-Funktion erhalten bleiben. Das einzelne Bibliotheksergebnis beschrieb den Endzustand, nicht seine Entstehung.

Der Ausgang der Transformation war der signierte Gegenstand

XPath konnte Teilmengen wählen, XSLT eine neue Darstellung erzeugen, Base64 kodierte Inhalte zurückführen und Kanonisierung Knotenmengen serialisieren. Der Digest galt dem Ergebnis dieser Reihenfolge. Ausgeschlossene Information blieb veränderbar, ohne die Signatur ungültig zu machen.

Das war beabsichtigte Ausdruckskraft. Ein Formular konnte unveränderliche Klauseln schützen und Eingabefelder offenlassen. Eine enveloped Signature musste ihren eigenen Wert aus der Berechnung entfernen. Ein XML-Container konnte die dekodierten Binärdaten statt seiner Tags schützen. Falsch wurde es erst, wenn eine Oberfläche Teilschutz als Schutz des gesamten Ursprungs ausgab.

RFC 3075 trennte außerdem die beschriebene Kette von ihrer frischen Ausführung. Kernvalidierung musste nicht beweisen, dass die URI gerade neu aufgelöst und jede Transformation erneut ausgeführt worden war. Eine Anwendung durfte bereits transformierte Cache-Daten akzeptieren; eine andere konnte frische Beschaffung verlangen. Derselbe Hashwert beantwortete die Herkunftsfrage nicht.

Kanonisierung stabilisierte Bytes, nicht Bedeutung

XML-Parser normalisieren Zeilenenden und Attributwerte, expandieren Entitäten und ordnen Namespace-Deklarationen Knoten zu. DOM und SAX verlieren Oberflächendetails wie Attributreihenfolge. Eine kanonische Serialisierung ermöglichte beiden Seiten, denselben Recheneingang wiederherzustellen.

Sie bestätigte weder ein Schema noch eine visuelle Aussage oder institutionelle Bedeutung. Sie erklärte auch keinen entfernten Knoten für belanglos. Canonical XML 1.1 behielt diese Grenze bei: anwendungsspezifische Gleichheit geht über eine allgemeine kanonische Form hinaus.

Anzeige und signierte Form mussten zusammenpassen

Wenn eine Signatur Urteil oder Zustimmung ausdrücken sollte, verlangten die Sicherheitshinweise eine möglichst genaue Verbindung zur präsentierten Information. Ein Bildschirmbild konnte direkt signiert werden, war aber schwer weiterzuverarbeiten. Alternativ mussten Daten zusammen mit Filtern, Stylesheets, Clientprofilen und anderen darstellungsbestimmenden Eingaben geschützt werden.

Die vertrauende Seite sollte umgekehrt auf der transformierten, signierten Form arbeiten. Wer stattdessen den Ursprung oder einen Zwischenstand anzeigte, legte der Signatur einen anderen Gegenstand unter. Ein unsigniertes externes Stylesheet konnte die Erscheinung verändern, ohne den Daten-Digest zu brechen.

Die Spezifikation machte daraus keine automatische Personenidentität oder Einwilligung. Sie verband Schlüssel und referenzierte Oktette. Darstellung, organisatorische Zuordnung und Anwendungssemantik benötigten zusätzliche Regeln.

KeyInfo lieferte Schlüsselinformation, nicht Vertrauen

Das optionale KeyInfo konnte Schlüssel, Zertifikate, Namen oder Abrufmethoden enthalten. War der Schlüssel aus dem Kontext bekannt, durfte es fehlen. In der Grundstruktur lag es außerhalb von SignedInfo; eine zusätzliche Reference konnte es binden.

Auch gebundene Bytes entschieden keine Berechtigung. Ein echtes Zertifikat konnte für die gewünschte Handlung ungeeignet sein, ein korrekter Schlüsselname nur lokalen Indexwert besitzen. RFC 2807 hatte allgemeine Vertrauens- und Behauptungssemantik bewusst der Anwendung überlassen.

Ein authentisches Manifest war noch keine geprüfte Sammlung

Manifest bündelte Referenzen, deren Fehlerbehandlung anwendungsspezifisch sein durfte. Verwies SignedInfo auf das Manifest, prüfte die Kernlogik dessen Digest. Welche inneren Referenzen tatsächlich überprüft wurden und was bei Nichterreichbarkeit oder Abweichung geschah, legte die Anwendung fest.

Damit unterschied sich die Echtheit der Liste vom Erfolg jedes Eintrags. Ein belastbarer Bericht musste Mitglied für Mitglied zeigen, was beschafft, transformiert und verglichen worden war. Der grüne Außenrahmen ersetzte diese Belege nicht.

Spätere Praxis setzte engere Leitplanken

RFC 3275 löste RFC 3075 im März 2002 nach Interoperabilitätserfahrung ab und änderte mehrere Strukturen. XML Signature 1.1 und spätere W3C-Empfehlungen hielten am Kernmodell fest, verlangten aber deutlicher: SignedInfo vor riskanten Referenzoperationen authentisieren, Schlüsselvertrauen separat herstellen, XPath, XSLT, RetrievalMethod, Transformationszahl und externe URI begrenzen und prüfen, ob die von der Anwendung genutzten Elemente wirklich geschützt sind.

Das belegt keinen konkreten Angriff auf eine damalige Implementierung. Es zeigt, warum eine ausführbare Signaturbeschreibung ein engeres lokales Profil um die Kryptografie benötigt.

Lu Hengs spätere Texte über Running-Code Primacy und Reality Layers dienen als offengelegte Analyse, nicht als Aussage der RFC-Autoren. Sie helfen, Syntax, ausgeführte Bytes, kryptografisches Ergebnis, Ansicht, Vertrauen und Wirkung auseinanderzuhalten. RFC 3075 selbst lieferte die entscheidende Disziplin: Die Signatur war nur für ihren exakt konstruierten Gegenstand autoritativ.

Quellen

Lu Heng verfasste oder billigte weder RFC 3075, RFC 3275 noch die W3C-Empfehlungen. Seine Texte sind ausdrücklich als spätere analytische Perspektiven gekennzeichnet.