Die Einbindung eines im Fall A oder B übergebenen Datenobjekts in die XML-Signatur bzw. die Referenzierung auf dieses in die Signatur eingebundene Datenobjekt aus dem zugehörigen dsig:Reference Element der XML-Signatur muss so erfolgen, dass ausschließlich die im Request in sl10:DataObject übergebenen Daten signiert werden.

Wird beispielsweise das Datenobjekt als Inhalt eines dsig:Object Elements in die XML-Signatur eingebunden, darf dieses dsig:Object Containerelement nicht mitsigniert werden, sondern lediglich sein Inhalt.

Der letzte Satz im vierten Satz lässt nicht erkennen, dass sich die darin erwähnte Auflösung der Referenz auf den impliziten Transformationsparameter auf den Fall der Signaturprüfung bezieht. Er sollte also verbessert lauten:

"Das Attribut URI eines Referenzobjekts enthält dabei die Referenz auf den impliziten Transformationsparameter, und zwar in exakt gleicher Weise, wie sie von der Bürgerkarten-Umgebung im Falle der Signaturprüfung zur Auflösung verwendet werden würde."

Die Tabelle zeigt nur die gültigen Kombinationen aus dem Wert des Attributs Structure, dem Wert des Attributs Reference, sowie dem Inhalt des Element sl10:DataObject.

Alle anderen Kombinationen sind ungültig.

Um den Vorgaben des XML-Schemas für die ETSI-Attribute hinsichtlich des Elements etsi:SignedSignatureProperties zu genügen, müssen neben den eigentlich geforderten Attributen für die signierten Metainformationen sowie für die signierte Zertifikatsreferenz zwei weitere Attribute in die Signatur integriert werden:

• etsi:SigningTime: Dieses Attribut enthält den Zeitpunkt der Signaturerstellung.
• etsi:SignaturePolicyIdentifier: Dieses Attribut enthält Angaben über die Signatur-Policy, die der Signatur zu Grunde liegt. Es wird empfohlen, als Inhalt dieses Attributs das Element etsi:SignaturePolicyImplied zu verwenden, um anzuzeigen, dass die unterzeichneten Daten die Signatur-Policy implizieren.

Die Definition eines implizten Transformationsparameter lautet laut Absatz 2: "Ein impliziter Transformationsparameter ist in diesem Zusammenhang ein Datenobjekt, das von der Bürgerkarten-Umgebung zur Berechnung der Transformationen verwendet wurde, jedoch nicht explizit als Parameter im entsprechenden Transformationsobjekt (dsig:Transform) aufscheint."

Der erste Satz des Absatzes 3 ist deshalb als falsch einzustufen. Die Referenzeingangsdaten bilden die Eingangsdaten zur Berechnung der Transformationen, sind aber keine Parameter.

Die Referenzeingangsdaten brauchen daher nicht in das Signaturmanifest inkludiert zu werden.

Es wird nicht spezifiziert, wie das Datenobjekt in die Signatur eingebunden werden soll, wenn es als sl10:Base64Content vorliegt. Gerade für diesen Fall ist aber eine genaue Vorgabe angebracht, da es beim Einbinden des dekodierten Inhalts von sl10:Base64Content zu Fehlern kommen kann. Es wird also folgende Ergänzung vorgenommen:

"Ist das Datenobjekt Base64-kodiert (Verwendung des Elements sl10:Base64Content in sl10:DataObject), muss es in dieser Base64-kodierten Form in die Signaturstruktur eingebunden werden. Signiert werden muss jedoch das Base64-dekodierte Datenobjekt; es ist daher in der auf das eingebundene Datenobjekt verweisenden dsig:Reference eine Base64 Transformation zu verwenden."

Es wird nicht spezifiziert, wie das Datenobjekt in die Signatur eingebunden werden soll, wenn es sich beim referenzierten Datenobjekt nicht um XML-Daten handelt. Gerade für diesen Fall ist aber eine genaue Vorgabe angebracht, da es beim Einbinden von beliebigen Stream-Daten in die Signatur zu Fehlern kommen kann. Es wird also folgende Ergänzung vorgenommen:

"Handelt es sich beim referenzierten Datenobjekt nicht um XML-Daten, oder wird das Datenobjekt entgegen der Empfehlung nicht auf Vorliegen von XML-Daten geprüft, muss es in Base64-kodierter Form in die Signaturstruktur eingebunden werden. Signiert werden muss jedoch das ursprüngliche Datenobjekt; es ist daher in der auf das eingebundene Datenobjekt verweisenden dsig:Reference eine Base64 Transformation zu verwenden."

Durch die mittels Errata 7 eingeführte Änderung kann es nun vorkommen, dass keine impliziten Transformationsparameter vorliegen. In solchen Fällen ist überhaupt von der Erstellung eines Signaturmanifests Abstand zu nehmen. Der Abschnitt "Implizite Transformationsparameter" wird daher um folgenden Satz ergänzt:

"Liegen keine impliziten Transformationsparameter vor, darf das Signaturmanifest nicht erstellt werden."

Die Spezifikation lässt offen, was genau die Bürgerkarten-Umgebung als Eingangsdaten für die Berechnung des Hash-Wertes über einen impliziten Transformationsparameter verwenden muss. Der Abschnitt "Implizite Transformationsparameter" wird daher um folgenden Absatz ergänzt:

"Die Eingangsdaten für die Berechnung des Hash-Wertes über einen implizten Transformationsparameter ergeben sich wie folgt:

• Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung selbst aufzulösten ist, ist zwischen einer externen und einer internen Referenz zu unterscheiden:
  • Die Auflösung einer externen Referenz muss einen Byte-Stream liefern. Dieser Byte-Stream bildet die Eingangsdaten für die Hash-Berechnung.
  • Die Auflösung einer internen Referenz muss eine XPath-Knotenmenge liefern (vgl. [XMLDSIG, Abschnitt 4.3.3.3]). Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung.
• Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung nicht selbst aufzulösen ist, weil in der Anfrage ein entsprechendes Ergänzungsobjekt angegeben wurde, ist wiederum zwischen einer externen und einer internen Referenz zu unterscheiden:
  • Enthält das Ergänzungsobjekt Daten für eine externe Referenz, müssen diese Daten als Base64 (in sl10:Supplement/sl10:Content/sl10:Base64Content) vorliegen. Die Base64-dekodierten Daten bilden dann die Eingangsdaten für die Hash-Berechnung.
  • Enthält das Ergänzungsobjekt Daten für eine interne Referenz, müssen diese Daten als XML (in sl10:Supplement/sl10:Content/sl10:XMLContent) vorliegen. Aus diesen Daten ist entsprechend [XMLDSIG, Abschnitt 4.3.3.3] eine XPath-Knotenmenge zu erzeugen. Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung."

In Abschnitt 9 der Spezifikation ist weiters folgende Referenz aufzunehmen:

"C14N
Boyer, John: Canonical XML. W3C Recommendation, März 2001. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2001/REC-xml-c14n-20010315."

Die Spezifikation lässt offen, ob die Prüfung der Signaturprüfdaten durchgeführt werden muss, wenn die bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Die Prüfung der Signaturprüfdaten darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist."

Weiters wird die Tabelle in diesem Abschnitt um folgenden Eintrag erweitert:

Die Spezifikation lässt offen, ob die Prüfung des Signaturmanifests durchgeführt werden muss, wenn die bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Die Prüfung des Signaturmanifests darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist."

Weiters wird die Tabelle in diesem Abschnitt um folgenden Eintrag erweitert:

Die Spezifikation lässt offen, ob die Prüfung weiterer Manifeste durchgeführt werden muss, wenn die bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Die Prüfung weiterer Manifeste darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist."

Weiters wird die Tabelle in diesem Abschnitt um folgenden Eintrag erweitert:

Die Spezifikation macht zu wenig deutlich, dass das Datenobjekt selbst nicht als Ergänzungsobjekt übergeben werden darf, sondern dafür der Container sl10:DataObject zu verwenden ist. Der erste Absatz dieses Abschnittes wird daher um folgenden Satz ergänzt:

"Das Datenobjekt selbst darf jedoch nicht als Ergänzungsobjekt übergeben werden."

Das angeführte Beispiel für eine ErrorResponse entspricht nicht dem XML-Schema. Das Element, das als Inhalt den Fehlercode aufweist, wird im Beispiel irrtümlich mit <Code> bezeichnet, laut Schema müsste es aber <ErrorCode> heißen. Korrekter Weise sieht das Beispiel also wie folgt aus:

"

<sl10:ErrorResponse> <sl10:ErrorCode>1152</sl10:ErrorCode> <sl10:Info>Read Access denied.</sl10:Info> </sl10:ErrorResponse>

Beispiel: Fehler-Antwort auf die Anfrage zum Lesen des Inhalts einer Infobox

"

Das angeführte Beispiel für eine VerifyXMLSignatureResponse entspricht nicht dem XML-Schema. Für das Element CertificateCheck wurde mit sl10 irrtümlich der falsche Namenraum-Präfix verwendet. Der korrekte Namenraum-Präfix lautet sl11.

Durch die mittels Errata 7 eingeführte Änderung kann es nun vorkommen, dass keine impliziten Transformationsparameter vorliegen, und somit eine Signatur, die dieser Spezifikation genügt, kein Signaturmanifest beinhalten muss. Die Tabelle, welche die Bedeutung der Prüfcodes festschreibt, wird daher wie folgt geändert:

Der Befehl zur Erzeugung eines Sitzungszertifikats wurde mit der Version 1.1.0 abgeschafft. In dieser Tabelle existiert aber noch ein Eintrag, der diesen Befehl als optional klassifiziert. Dieser Tabelleneintrag ist also nicht mehr als Teil der Spezifikation anzusehen.

Der Punkt 5e im Ablauf ist missverständlich formuliert. Er wird daher durch folgende Formulierung ersetzt:

• "HTTP-Code 200, wobei die Kombination aus Content-Type und Inhalt nicht unter einen der Punkte 5a, 5b oder 5d fällt; HTTP-Code 307, wobei Content-type nicht unter Punkt 5c fällt; HTTP-Code 301, 302, 303: Die Daten werden als Response unverändert an die Browser-Verbindung weitergeleitet, die Browser-Verbindung wird geschlossen und die Verarbeitung beendet."

Der Punkt 5b, 5c und 5d sind hinsichtlich der weiteren Verwendung von Weitergabe-Feldern missverständlich formuliert. Sie werden daher durch folgende Formulierungen ersetzt:

• b) HTTP-Code 200, Content-type: text/xml: Die Daten werden als XML-Request ausgewertet und dem Formular-Parameter XMLRequest zugewiesen. Die anderen Formular-Parameter (StylesheetURL, RedirectURL und DataURL) sowie die Weitergabe-Felder bleiben unverändert. Die Verarbeitung setzt in Schritt 4 fort.
• c) HTTP-Code 307, Content-type: text/xml: Die Daten werden als XML-Request ausgewertet und dem Formular-Parameter XMLRequest zugewiesen. Die DataURL wird für die folgende Verarbeitung auf die im Location HTTP-Header enthaltene URL gesetzt. Die anderen Formular-Parameter (StylesheetURL und RedirectURL) sowie die Weitergabe-Felder bleiben unverändert. Die Verarbeitung setzt in Schritt 4 fort.
• d) HTTP-Code 200, Content-type: application/x-www-form-urlencoded oder multipart/form-data: Die Daten werden als HTTP-Request ausgewertet. Die bisherigen Formular-Parameter sowie Weitergabe-Felder werden verworfen. Ggf. werden die im neuen Request vorhandenen Formular-Parameter und Weitergabe-Felder verwendet. Die Verarbeitung setzt in Schritt 3 fort.