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:

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:

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>

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:

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:

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:

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

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

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

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 korrekterweisehttp://www.buergerkarte.at/namespaces/securitylayer/1.2# anstatthttp://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.