Zusammenfassung

  • RFC 3741 macht Signaturen über extrahierte XML-Fragmente weniger abhängig von den Namespace-Deklarationen ihrer Vorfahren: Ausgegeben werden vor allem Präfixe, die in Element- oder Attributnamen sichtbar verwendet werden.
  • Kontextabhängigkeit verschwindet dadurch nicht vollständig. Geerbte xml:-Attribute und Präfixe, die nur in Werten vorkommen, können die Interpretation nach einer neuen Einbettung verändern.

Die Nachrichtenhülle sollte die Signatur des Inhalts nicht umschreiben

Ein Protokoll signiert ein kleines XML-Element innerhalb einer großen Nachricht. Ein Gateway entfernt die äußere Hülle; ein anderer Dienst setzt dasselbe Element in eine neue Nachricht ein. Bei inklusivem Canonical XML können Namespace-Deklarationen von Vorfahren und bestimmte xml:-Attribute in die kanonische Bytefolge eingehen, auch wenn das Fragment sie selbst nicht nutzt. Eine geänderte Hülle kann deshalb die Digest-Eingabe verändern und eine Signatur brechen, obwohl das Fragment unverändert blieb.

Die im März 2004 veröffentlichte RFC 3741 zielte genau auf diese Reibung. Sie definiert eine exklusive Serialisierung einer XPath-Knotenmenge. Statt den größten Teil des geerbten Namespace-Kontexts zu übernehmen, gibt sie eine Bindung aus, wenn das Präfix sichtbar in einem Element- oder Attributnamen verwendet wird. Über die optionale InclusiveNamespaces PrefixList lassen sich Präfixe nennen, die trotz dieser Regel inklusiv verarbeitet werden sollen. Ein signiertes Teildokument soll so aus seiner ursprünglichen Hülle gelöst und in eine andere eingesetzt werden können, ohne dass jede Transporthülle Teil seiner kanonischen Form wird.

Das ist eine Entscheidung über Grenzen, keine Garantie für kontextunabhängige Bedeutung. RFC 3741 nennt ihre Grenzen ausdrücklich. RFC 3075 fragt, welche Daten XML Signature tatsächlich abdeckt; RFC 3076 beschreibt, wie eine bereits geparste Knotenmenge kanonisiert wird. RFC 3741 fragt, welcher Kontext erhalten bleiben soll, wenn die ausgewählte Teilmenge den Ort wechselt.

„Sichtbar“ ist nützlich, aber eng gefasst

Die Regel richtet sich nach XML-Namen. Verwendet ein Element- oder Attributname das Präfix n1, muss dessen Bindung bei der Serialisierung erscheinen. Ein von einem Vorfahren deklariertes Präfix, das in solchen Namen nicht vorkommt, kann dagegen entfallen. Das entfernt oft Ballast: Eine SOAP- oder Protokollhülle kann Namespaces enthalten, die für die äußere Nachricht nötig, für das extrahierte Nutzdatum aber irrelevant sind. Exklusive Kanonisierung kann dann für dasselbe Nutzdatum in verschiedenen Hüllen dieselben kanonischen Bytes liefern.

Die Bedeutung für eine Anwendung kann jedoch von Informationen abhängen, die in den Namen der Knotenmenge nicht sichtbar sind. Ein Attributwert kann einen XPath-Ausdruck enthalten, dessen Präfixbindungen wichtig sind. Eine Anwendung kann eine Zeichenfolge wie xsi:type="xsd:decimal" als QName auswerten, obwohl XPath sie nur als Textwert sieht. Wird xsd weder sichtbar in einem Element- oder Attributnamen benutzt noch in der inklusiven Präfixliste genannt, kann seine Bindung entfallen. Im neuen Kontext kann der Empfänger den Wert anders deuten.

Die RFC nennt drei Gegenmaßnahmen: Die Präfixverwendung wird in der XML-Struktur sichtbar gemacht, dieselbe Bindung wird in jedem Interpretationskontext sichergestellt oder das Präfix wird in InclusiveNamespaces PrefixList aufgenommen. Jede Option erfordert eine Entwurfsentscheidung. Die Liste erkennt verborgene QName-Semantik nicht automatisch; die Anwendung muss wissen, welche Werte namespaceabhängig sind.

Was aus den Bytes verschwindet, kann die Lesart weiter steuern

Exklusive Kanonisierung kopiert auch geerbte Werte von xml:lang, xml:space oder xml:base nicht in verwaiste Knoten der Teilmenge. Sie können Sprache, Leerraumbehandlung oder die Auflösung relativer Referenzen beeinflussen. RFC 3741 verlangt daher, benötigte Werte in der Teilmenge selbst zu setzen oder in jedem Interpretationskontext einen gleichwertigen Wert sicherzustellen.

Der Hinweis zum Zielkontext ist noch deutlicher: Die kanonischen Oktette eines Fragments können gleich bleiben, wenn es unter einen neuen Vorfahren mit anderem Standard-Namespace verschoben wird. Die empfangende Anwendung kann das unpräfixierte Element dennoch einem anderen Namespace zuordnen und als einen anderen Objekttyp behandeln. Die Signatur ist gültig, weil sich die ausgewählten Bytes nicht änderten; die Anwendungsinterpretation kann sich ändern, weil der Zielkontext ein anderer ist.

RFC 3741 legt weder das Extrahieren und Einfügen noch eine Reparatur von Namespace-Deklarationen fest. Ebenso entscheidet sie nicht, ob die empfangende Anwendung dazu berechtigt ist. Das Protokoll muss bestimmen, welcher Kontext das Fragment begleitet und was ein Verbraucher mit dem resultierenden Knoten tun soll. Kryptografische Integrität ist nur ein Glied der Kette.

Eine engere Signaturgrenze vergrößert die Integrationspflicht

Exklusive Kanonisierung tauscht die zufällige Abhängigkeit von der Nachrichtenhülle gegen die ausdrückliche Pflicht, semantische Abhängigkeiten zu erfassen. Bei der Prüfung eines weitergeleiteten signierten Fragments reicht es nicht, nur die erfolgreiche Signaturprüfung festzustellen. Auch Präfixe, xml:-Attribute, QName-Werte und relative Referenzen müssen am Ziel dieselbe Bedeutung behalten. Ohne explizite Vereinbarung kann Signaturstabilität fälschlich als Bedeutungsstabilität erscheinen.

Das ist ein in der Spezifikation beschriebenes Risikomodell, kein Beleg für einen konkreten Angriff oder Implementierungsfehler. RFC 3741 ist Informational: Sie belegt Zweck und Grenzen des Algorithmus, aber weder die Verbreitung bestimmter Implementierungen noch einen Fehler eines benannten Dienstes. Die präzise Lehre lautet: Weniger Kontext in den signierten Bytes kann die Portabilität verbessern; nur die Anwendung kann jedoch bestimmen, welcher ausgelassene Kontext die Interpretation weiterhin steuert.

Quellen