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:

Die Schema-Definition für das Element sl:FriendlyName im Datentyp sl:VerificationResultType hat keinen Datentyp spezifiziert. Dieser wird nun mit xsd:string festgelegt. Somit lautet die korrigierte Schema-Definition:

<xsd:element name="FriendlyName" type="xsd:string" minOccurs="0"/>

Analoges gilt für das Element sl:FriendlyName im Datentyp sl:VerifyHashInfoRequestType. Dafür lautet die korrigierte Schema-Definition somit:

<xsd:element name="FriendlyName" type="xsd:string" minOccurs="0"/>

Der mit der Version 1.2.0 eingeführte Versionierungsmechanismus über das Attribut ProtocolVersion in den einzelnen Befehlsanfragen anstatt der bisherigen Versionierung über den XML-Namespace führt in der Praxis zu unnötig komplexen Abläufen beim Parsen der Befehlsanfragen.

Aus diesem Grund wird zum bisher verwendeten Versionierungsmechanismus über den XML-Namespace zurückgekehrt:

• Der XML-Namespace für die Schnittstellenbefehle wird auf folgenden Wert geändert:
  http://www.buergerkarte.at/namespaces/securitylayer/1.2#.
• Das in der Schnittstellenspezifikation verwendete Namenraum-Präfix sl steht somit für den Namenraum http://www.buergerkarte.at/namespaces/securitylayer/1.2#.
• Das Attribut ProtocolVersion wird aus sämtlichen Befehlsanfragen sowie aus der Befehlsantwort sl:GetPropertiesResponse entfernt.

Die Schema-Definitionen der Typen sl11:ReferencesCheckResultType, sl11:ReferencesCheckResultInfoType, sl11:ManifestRefsCheckResultType, sl11:ManifestRefsCheckResultInfoType sind fehlerhaft. Sie sind durch folgende Definitionen zu ersetzen:

<xsd:complexType name="ReferencesCheckResultType">
  <xsd:sequence>
    <xsd:element name="Code" type="xsd:nonNegativeInteger"/>
    <xsd:element name="Info" type="ReferencesCheckResultInfoType" minOccurs="0"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ReferencesCheckResultInfoType" mixed="true">
  <xsd:sequence>
    <xsd:element name="FailedReference" type="xsd:positiveInteger" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ManifestRefsCheckResultType">
  <xsd:sequence>
    <xsd:element name="Code" type="xsd:nonNegativeInteger"/>
    <xsd:element name="Info" type="ManifestRefsCheckResultInfoType"/>
  </xsd:sequence>
</xsd:complexType>
<xsd:complexType name="ManifestRefsCheckResultInfoType" mixed="true">
  <xsd:sequence>
    <xsd:element name="FailedReference" type="xsd:positiveInteger" minOccurs="0" maxOccurs="unbounded"/>
    <xsd:element name="ReferringSigReference" type="xsd:positiveInteger"/>
    <xsd:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
  </xsd:sequence>
</xsd:complexType>

Die Schema-Definition für das Element sl:GetPropertiesResponse schreibt vor, dass das Element sl:KeyboxIdentifier zumindest einmal vorkommen muss.

Nachdem die Semantik der Elemente diesen Namens in sl:GetPropertiesResponse jedoch jene ist, dass damit angegeben wird, welche Schlüsselpaare zum Zeitpunkt der Anfrage für Signatur bzw. Ver-/Entschlüsselung zur Verfügung stehen, muss es auch möglich sein, dass das Element sl:KeyboxIdentifier in sl:GetPropertiesResponse gar nicht vorkommt (z.B. wenn sich keine Karte im Kartenleser befindet).

Die entsprechende Definition des Datentyps für sl:GetPropertiesResponse wird daher wie folgt neu festgelegt:

  <xsd:complexType name="GetPropertiesResponseType">
    <xsd:sequence>
      <xsd:element name="ViewerMediaType" type="MimeTypeType" maxOccurs="unbounded"/>
      <xsd:element name="XMLSignatureTransform" type="xsd:anyURI" maxOccurs="unbounded"/>
      <xsd:element name="KeyboxIdentifier" type="QualifiedBoxIdentifierType" 
        minOccurs="0" maxOccurs="unbounded"/>
      <xsd:element name="Binding" type="BindingType" maxOccurs="unbounded"/>
      <xsd:element name="ProtocolVersion" type="xsd:token" maxOccurs="unbounded"/>
      <xsd:any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
    </xsd:sequence>
  </xsd:complexType>

Aus der Beschreibung des Elements sl:KeyboxIdentifier geht nicht klar genug hervor, dass die Semantik des Elements jene ist, dass damit angegeben wird, welche Schlüsselpaare zum Zeitpunkt der Anfrage für Signatur bzw. Ver-/Entschlüsselung zur Verfügung stehen.

Es wird daher im ersten Satz des Aufzählungspunktes nach dem Wort "Bürgerkarten-Umgebung" die Wortfolge "zum Zeitpunkt der Anfrage" eingefügt.

Durch die Streichung der Beispiele seit Version 1.2.0 des Dokuments werden für die Befehle von Kapitel 8 die Namen der zugehörigen XML-Elemente nicht mehr erwähnt. Es werden daher folgende Änderungen durchgeführt:

• Der erste Satz in Abschnitt 8.1.1 lautet nun neu: "Die Anfrage besteht aus dem leeren Element sl:GetPropertiesRequest."
• Der erste Satz in Abschnitt 8.1.2 lautet nun neu: "Die Antwort besteht aus dem Element sl:GetPropertiesResponse und enthält als Kindelemente folgende Eigenschaften der Bürgerkarten-Umgebung:"
• In den ersten Satz in Abschnitt 8.2.1 wird nach dem Wort Befehl die Wortfolge ", bestehend aus dem Element sl:GetStatusRequest," eingefügt.
• Der erste Satz in Abschnitt 8.2.2 lautet nun neu: "Die Antwort besteht aus dem Element sl:GetStatusResponse und enthält als Text des Kindelements sl:TokenStatus den aktuellen Status des Tokens (entweder ready oder removed)."

In der Schema-Definition für das Element sl:DecryptedBinaryResponse fehlen die im Spezifikationstext erwähnten Attribute MimeType und Encoding.

Die entsprechende Definition des Datentyps für sl:DecryptXMLResponse wird daher wie folgt neu festgelegt:

  <xsd:complexType name="DecryptXMLResponseType">
    <xsd:sequence minOccurs="0">
      <xsd:element name="CandidateDocument" type="XMLContentType"/>
      <xsd:element name="DecryptedBinaryData" minOccurs="0" maxOccurs="unbounded">
        <xsd:complexType>
          <xsd:simpleContent>
            <xsd:extension base="xsd:base64Binary">
              <xsd:attribute name="EncrElemSelector" type="xsd:string" use="required"/>
              <xsd:attribute name="MimeType" type="xsd:string" use="optional"/>
              <xsd:attribute name="Encoding" type="xsd:anyURI" use="optional"/>
            </xsd:extension>
          </xsd:simpleContent>
        </xsd:complexType>
      </xsd:element>
    </xsd:sequence>
  </xsd:complexType>

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.

Die Erläuterungen zur Kodierung der Formularfelder im HTTP-Request an den DataURL-Server sind nicht schlüssig:

1. Es ist nicht festgelegt, dass die Kodierung immer multipart/mime sein muss. Die Erläuterungen für XMLResponse und BinaryResponse gehen jedoch davon aus.
2. In den Erläuterungen für XMLResponse und BinaryResponse entsteht der Eindruck, dass Content-Type ein Feld von Content-Disposition sei. Tatsächlich sind beides jedoch unabhängige Header.

Es werden daher folgende Änderungen am Spezifikationstext durchgeführt:

1. Der erste Absatz des Unterkapitels Kodierung des HTTP-Requests lautet nun wie folgt: "Der HTTP-Request an den mittels DataURL bezeichneten Server muss nach der Methode POST (vgl. [HTTP 1.1], Abschnitt 9.5) erfolgen, als multipart/form-data kodiert sein, und folgende Formularfelder enthalten:".
2. Der zweite Satz des Unterkapitels Kodierung des HTTP-Requests, Weitergabe-Parameter wird gestrichen.
3. Der zweite Satz des Unterkapitels Kodierung des HTTP-Requests, Formular-Parameter XMLResponse lautet nun wie folgt: "Der Header Content-Type muss für diesen Mime Part verwendet werden und ist fix mit dem Wert text/xml zu belegen (siehe auch Anmerkung 2 in Abschnitt 3.2.3).".
4. Der zweite Satz des Unterkapitels Kodierung des HTTP-Requests, Formular-Parameter BinaryResponse lautet nun wie folgt: "Der Header Content-Type muss für diesen Mime Part verwendet werden, um den Content-Type der Binär-Response zu bezeichnen. Ist der Content-Type nicht bekannt, so muss der Feldwert mit application/octet-stream angegeben werden (siehe auch Anmerkung 2 in Abschnitt 3.2.3).".

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 Namenraum der Elemente der Schnittstellenspezifikation lautet korrekterweise
http://www.buergerkarte.at/namespaces/securitylayer/1.2#
anstatt
http://www.buergerkarte.at/namespaces/securitylayer#.

Aus den Erläuterungen zur Authentisierungsklasse certifiedGovAgency geht nicht hervor, dass es sich beim Ursprung bzw. Ziel anstatt um eine Behörde auch um einen Dienstleister der Behörde handeln darf.

Der Erläuterungstext wird daher wie folgt neu festgesetzt:

"Die Bürgerkarten-Umgebung hat gesicherte (zertifikatsbasierende) Informationen über den Ursprung der Befehlsanfrage und/oder das Ziel der Befehlsantwort. Aus diesen Informationen geht hervor, dass es sich bei Ursprung bzw. Ziel um eine Behörde oder einen Dienstleister der Behörde handelt, d.h. der Domainname, auf den das Zertifikat ausgestellt ist, matched das Pattern *.gv.at, oder das Zertifikat enthält entweder die Zertifikatserweiterung Verwaltungseigenschaft oder die Zertifikatserweiterung Dienstleistereigenschaft [VerwEig]."

Der drittletzten Absatz definiert jene Marker, die in einem anzuzeigenden JPEG JFIF Bild nicht vorkommen dürfen. Unter anderem wird dort auch der Marker APPn ausgeschlossen. Für das Format JPEG JFIF ist jedoch die Verwendung des Markers APP0 verpflichtend vorgeschrieben. Der letzte Satz dieses Absatzes wird daher wie folgt geändert:

"Enhält eine [JPEG]-Datei jedoch Marker vom Typ TEM, JPG, JPGn (n >= 0), RSTn (n >= 0) oder APPn (n > 0), muss das Instanzdokument von der Bürgerkarten-Umgebung zurückgewiesen werden."

Das Inhaltsmodell für den Content Set Inline lautet korrekterweise br|cite|code|em|span|strong und nicht wie fälschlich angegeben abbr|acronym|br|cite|code|em|span|strong.

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."