Open Interfaces für das eGovernment

Security-Layer für das Konzept Bürgerkarte

Schnittstellenspezifikation

Dokumenteninformation

Inhalt

1. Allgemeine Anmerkungen
   1. Protokollelemente
   2. Namenskonventionen
   3. Schlüsselwörter
2. Signaturerstellung
   1. Signatur nach CMS
      1. Anfrage
      2. Antwort
   2. Signatur nach XMLDSIG
      1. Anfrage
      2. Antwort
3. Signaturprüfung
   1. Signatur nach CMS
      1. Anfrage
      2. Antwort
   2. Signatur nach XMLDSIG
      1. Anfrage
      2. Antwort
4. Zugriff auf Infoboxen
   1. Typen von Infoboxen
      1. Binärdatei
      2. Assoziatives Array
   2. Abfrage der verfügbaren Infoboxen
      1. Anfrage
      2. Antwort
   3. Lesen von Daten in einer Infobox
      1. Anfrage
      2. Antwort
   4. Lesen von Daten in einer Infobox
      1. Anfrage
      2. Antwort
5. Aushandeln eines symmetrischen Geheimnisses
   1. Anfrage
   2. Antwort
   3. Anmerkungen zur Funktionsweise
6. Abfrage von Eigenschaften
   1. Abfrage der Umgebungseigenschaften
      1. Anfrage
      2. Antwort
   2. Abfrage des Tokenstatus
      1. Anfrage
      2. Antwort
7. Fehlerbehandlung
   1. Fehlercodes
8. Glossar
9. Referenzen
10. Historie

1 Allgemeine Anmerkungen

Dieses Dokument legt die Schnittstelle Security-Layer fest. Das ist jene Schnittstelle, über die eine Applikation auf Funktionalität aus dem Konzept Bürgerkarte zugreift, um beispielsweise eine elektronische Signatur zu erstellen oder vom Datenspeicher der Bürgerkarten-Umgebung zu lesen.

Für weitere Informationen zur Begriffsbildung (Security-Layer, Bürgerkarten-Umgebung und Bürgerkarten-Token) siehe Abschnitt 1.1 in [AnfBKU].

Für die Festlegung, welche der in diesem Dokument beschriebenen Schnittstellenbefehle von einer Implemenation jedenfalls zur Verfügung gestellt werden müssen, siehe Minimalanforderungen Security-Layer.

1.1 Protokollelemente

Das Protokoll besteht aus einfachen Anfrage/Antwort-Mustern. Die Applikation schickt eine in XML kodierte Anfrage an die Bürgerkarten-Umgebung. Diese schickt eine entsprechende in XML kodierte Antwort zurück an die Applikation.

Die einzelnen Protokollelemente für diese XML-Schnittstellenbefehle sind in zwei XML-Schemata [XML-Schema] spezifiziert. Das Schema Core.20020225.xsd enthält dabei all jene Schnittstellenbefehle, die sich beim Übergang dieses Dokuments von der Version 1.0.3 in die Version 1.1.0 nicht verändert haben. All jene Schnittstellenbefehle, die eine Änderung bei diesem Übergang erfahren haben, sind im Schema Core.20020831.xsd neu spezifiziert.

Zusammen mit der vorliegenden Schnittstellenspezifikation bilden diese beiden XML-Schema die normative Quelle für die Protokoll-Elemente.

1.2 Namenskonventionen

Die einzelnen Protokoll-Elemente wurden mit aussagekräfigen Namen belegt, wobei Abkürzungen so weit wie möglich vermieden worden sind. Anfragen enden stets mit dem Suffix Request, die korrespondierenden Antworten enden stets mit dem Suffix Response.

Folgende Namenraum-Präfixe werden in dieser Spezifikation zur Kennzeichnung der Namenräume von XML-Elementen verwendet:

1.3 Schlüsselwörter

Dieses Dokument verwendet die Schlüsselwörter muss, darf nicht, erforderlich, sollte, sollte nicht, empfohlen, darf, und optional zur Kategorisierung der Anforderungen. Diese Schlüsselwörter sind analog zu ihren englischsprachigen Entsprechungen must, must not, required, should, should not, recommended, may, und optional zu handhaben, deren Interpretation in [Keywords] festgelegt ist.

2 Signaturerstellung

Die Schnittstelle Security-Layer unterstützt zwei mögliche Formate für die Erzeugung einer elektronischen Signatur: [CMS] und [XMLDSIG].

2.1 Signatur nach CMS

2.1.1 Anfrage

Mit einer Signatur nach [CMS] kann genau ein Datenobjekt signiert werden.

Struktur der Signatur

Zunächst muss im Attribut Structure der Signaturanfrage (sl10:CreateCMSSignatureRequest) angegeben werden, ob das nachfolgend spezifizierte Datenobjekt in die Signaturstruktur eingebunden werden soll (Wert "enveloping"), oder nicht (Wert "detached").

Bezeichnung des Signaturschlüssels

Weiters muss in der Signaturanfrage der Bezeichner des für die Signaturerstellung zu verwendenden Schlüssels (sl10:KeyboxIdentifier) angegeben werden. Bezeichner aller verfügbaren Schlüssel können mit Hilfe des Befehls sl10:GetPropertiesRequest von der Bürgerkarten-Umgebung abgefragt werden.

Informationen zum Datenobjekt

Schließlich enthält die Signaturanfrage einen Behälter sl10:DataObject, der das zu signierende Datenobjekt (sl10:Content), sowie Metainformationen (sl10:MetaInfo) für die Anfertigung der Signatur sowie für die gegebenenfalls notwendige Anzeige im Trusted Viewer enthält.

Jedenfalls an Metainformation spezifiziert werden muss der Mime-Type (siehe [MIME]) des zu signierenden Datenobjekts. Weiters darf ein Hinweis (sl10:Description) in Form einer URI gegeben werden. Schließlich dürfen noch weitere beliebige Elemente zu diesen Metainformationen hinzugefügt werden.

Die Angabe des zu signierenden Datenobjekts kann auf zwei Arten erfolgen: Entweder enthält das Element sl10:Content die base64-kodierten Daten, oder das Element sl10:Content ist leer, hat aber sein Attribut Reference gesetzt. Die Bürgerkarten-Umgebung muss im letzten Fall versuchen, die in diesem Attribut angegebene URI aufzulösen, um so die zu signierenden Daten zu erhalten.

<sl10:CreateCMSSignatureRequest Structure="enveloping">
  <sl10:KeyboxIdentifier>Bezeichner der Key-Box</sl10:KeyboxIdentifier>
  <sl10:DataObject>
    <sl10:MetaInfo>
      <sl10:MimeType>text/plain</sl10:MimeType>
    </sl10:MetaInfo>
    <sl10:Content Reference="http://examples.org/myText.txt">
      <!--Entweder base64-codierter Inhalt oder gesetztes Reference-Attribut-->
    </sl10:Content>
  </sl10:DataObject>
</sl10:CreateCMSSignatureRequest>

2.1.2 Antwort

Die Antwort besteht aus dem Element sl10:CMSSignature, welches die erzeugte Signatur nach [CMS] in base64-kodierter Form enthält.

Signierte Metainformationen

In die [CMS]-Signatur muss ein signiertes Signaturattribut ContentHints nach [ESS-S/MIME], Abschnitt 2.9 aufgenommen werden. Zur Anfertigung dieses Signaturattributs sind jene Metainformationen (sl10:MetaInfo) zu verwenden, die in der Anfrage im Behälter für das Datenobjekt (sl10:DataObject) angegeben wurden.

Für das Element sl10:MimeType aus sl10:MetaInfo muss ein erstes Feld contentDescription in ContentHints verwendet werden; ist das Element sl10:Description aus sl10:MetaInfo vorhanden, muss es in einem weiteren Feld contentDescription in ContentHints codiert werden. Das Feld contentType muss jedenfalls mit dem Wert des Object Identifiers für id-data (siehe [CMS], Abschnitt 4) belegt werden.

Signierte Zertifikatsreferenz

Weiters muss ein signiertes Signaturattribut OtherSigningCertificate nach [ETSICMS] in die [CMS]-Signatur aufgenommen werden, mit dem das für die Verifikation der Signatur zu verwendende Signatorzertifikat eindeutig identifiziert wird.

Zertifikatskette

Darüber hinaus wird empfohlen, die gesamte Kette an Zertifikaten, die zur Prüfung der Signatur benötigt wird (Signatorzertifikat bis zu einer vertrauenswürdigen Wurzelinstanz), in die [CMS]-Signatur aufzunehmen. Dazu eignen sich das Feld CertificateSet nach [CMS, Abschitt 5.1].

<sl10:CreateCMSSignatureResponse>
  <sl10:CMSSignature>
    <!--CMS-Signatur in base64-kodierter Form-->
    </sl10:CMSSignature>
</sl10:CreateCMSSignatureResponse>

2.2 Signatur nach XMLDSIG

2.2.1 Anfrage

Die Signatur nach [XMLDSIG] erlaubt im Gegensatz zur Signatur nach [CMS] auch die Signierung mehrerer Datenobjekte mittels einer einzigen Signatur.

Bezeichnung des Signaturschlüssels

In der Signaturanfrage muss der Bezeichner des für die Signaturerstellung zu verwendenden Schlüssels (sl11:KeyboxIdentifier) angegeben werden. Bezeichner aller verfügbaren Schlüssel können mit Hilfe des Befehls sl10:GetPropertiesRequest von der Bürgerkarten-Umgebung abgefragt werden.

Informationen zum Datenobjekt

In der Folge enthält die Signaturanfrage für jedes Datenobjekt, das von der Signatur unterschrieben werden soll, einen Behälter (sl11:DataObjectInfo) , der Informationen für die Anfertigung der Signatur sowie für die gegebenenfalls notwendige Anzeige im Trusted Viewer enthält. sl11:DataObjectInfo ist mit einem Attribut Structure ausgestattet, das angibt, ob das im Behälter spezifizierte Datenobjekt in die Signaturstruktur eingebunden werden soll (Wert "enveloping"), oder ob die Signatur dieses Datenobjekt nur referenzieren soll (Wert "detached").

Datenobjekt

Ein solcher Behälter besteht zunächst aus Informationen zu jenem Datenobjekt, das gegebenenfalls transformiert und nachfolgend signiert wird (sl10:DataObject). In Abhängigkeit des oben besprochenen Attributs Structure) sind der Inhalt von sl10:DataObject sowie sein Attribut Reference wie folgt zu verwenden:

Hinweis: Soll der Inhalt von sl10:Dataobject zur expliziten Angabe des Datenobjekts verwendet werden, stehen zwei unterschiedliche Arten der Kodierung zur Verfügung: Das Datenobjekt kann entweder in base64-kodierter Form (sl10:Base64Content) oder als XML kodiert (sl10:XMLContent) angegeben werden. Bei der Kodierung als XML kann für sl10:XMLContent das Attribut xml:space mit dem Wert preserve versehen werden, wenn es aus Sicht der Applikation wichtig ist, dass die Bürgerkarten-Umgebung Whitespace innerhalb des übergebenen XML nicht verändert.

Transformationswege

Weiters enthält der Behälter sl11:DataObjectInfo einen oder mehrere Transformationswege für das Datenobjekt (sl10:TransformsInfo).

Ein Transformationsweg beschreibt dabei eine Kette von auszuführenden Transformationen (dsig:Transforms), um vom Datenobjekt zu jenen Daten zu gelangen, die in die Hashberechnung und in weiterer Folge in die Signaturberechnung einfließen (nachfolgend als Hash-Eingangsdaten bezeichnet).

Die Hash-Eingangsdaten sind gleichzeitig jene Daten, die gegebenenfalls im Trusted Viewer der Bürgerkarten-Umgebung dem Benutzer angezeigt werden müssen. Damit die Bürgerkarten-Umgebung weiß, welcher Natur die Hash-Eingangsdaten sind, enthält der Transformationsweg andererseits Metainformationen darüber (sl10:FinalDataMetaInfo). Jedenfalls ist der Mime-Type (siehe [MIME]) anzugeben (sl10:MimeType), zusätzlich darf eine Referenz auf eine Beschreibung dieser Daten angegeben werden (sl10:Description).

Soll das Datenobjekt direkt unterzeichnet werden, wird ebenfalls ein Transformationsweg spezifiziert, jedoch unterbleibt die Angabe der Kette von Transformationen. Bei Angabe mehrerer Transformationswege wählt die Bürgerkarten-Umgebung einen Weg frei aus.

Bei der Angabe eines Transformationsweges muss die Applikation sicherstellen, dass alle Namenräume, die innerhalb der Struktur der spezifizierten Transformationen (dsig:Transforms) verwendet werden, innerhalb dieser Struktur explizit deklariert werden. Die Bürgerkarten-Umgebung darf nicht Namenraum-Deklarationen innerhalb von dsig:Transforms hinzufügen, wenn Sie die Struktur in die zu erzeugende Signatur übernimmt.

Ergänzungsobjekte

Optional werden schließlich im Behälter sl11:DataObjectInfo Ergänzungsobjekte (sl10:Supplements) angegeben. Solche können übergeben werden, damit Daten, die im Rahmen des Transformationsprozesses für das Datenobjekt oder im Trusted Viewer benötigt werden, nicht von der Bürgerkarten-Umgebung aufgelöst werden müssen.

Als Beispiel sei hier eine Stylesheet-Transformation angeführt, die sich verschachtelter Stylesheets bedient: Nur der Basis-Stylesheet ist tatsächlich im Transformationsobjekt (dsig:Transform) als Parameter angeführt; im Basis-Stylesheet referenzierte weitere Stylesheets müssten von der Bürgerkarten-Umgebung selbst aufgelöst werden. Dies kann vermieden werden, indem solche referenzierte Stylesheets als Ergänzungsobjekte übergeben werden.

Ein Ergänzungsobjekt besteht dabei einerseits aus optionalen Metainformationen (vergleiche sl10:FinalDataMetaInfo), andererseits aus dem eigentlichen Daten (sl10:Content): Das verpflichtend zu verwendende Attribut Reference enthält dabei als URI die Referenz auf die Ergänzungsdaten, und zwar so, wie sie von der Bürgerkarten-Umgebung zur Auflösung verwendet werden würde. Der Inhalt von sl10:Content repräsentiert die Ergänzungsdaten (siehe auch Hinweis in Abschnitt 2.2.1, Datenobjekt).

Stößt die Bürgerkarten-Umgebung während der Berechnung des Transformationsprozesses auf aufzulösende Daten, muss Sie folgenden Ablauf für die Auflösung einhalten:

1. Prüfung, ob die aufzulösende Referenz in einem sl10:Supplement innerhalb jenes sl11:DataObjectInfo vorkommt, das den gerade berechneten Transformationsprozess spezifiziert. Ist diese Prüfung erfolgreich, sind die in diesem sl10:Supplement angegebenen Daten als Ergebnis der Auflösung zu verwenden. Ansonsten ist mit Schritt 2 fortzufahren.
2. Prüfung, ob die aufzulösende Referenz in einem sl10:Supplement eines anderen sl11:DataObjectInfo vorkommt, das im Befehl zur Erzeugung der XML-Signatur spezifiziert wurde. Die einzelnen sl11:DataObjectInfo-Elemente sind dabei in jener Reihenfolge zu untersuchen, in der Sie im Befehl angegeben wurden. Die im ersten so gefundenen sl10:Supplement angegebenen Daten sind als Ergebnis der Auflösung zu verwenden. Wird kein sl10:Supplement gefunden, ist mit Schritt 3 fortzufahren.
3. Auflösung der Referenz.

Informationen zum Signaturdokument

Soll die zu erstellende Signatur in ein bestehendes XML-Dokument eingebettet werden, findet sich in der Signaturanfrage schließlich der Behälter sl11:SignatureInfo. Bei Fehlen dieses Behälters ist die Signatur nirgends einzubetten, sondern direkt als Ergebnis der Anfrage (siehe Abschnitt 2.2.2) zurückzuliefern.

Das Signaturdokument

sl11:SignatureInfo enthält zunächst Angaben zum Signaturdokument, in das die Signatur eingebettet werden soll (sl11:SignatureEnvironment). Entweder enthält das Attribut Reference einen Verweis auf dieses Dokument, der von der Bürgerkarten-Umgebung aufzulösen ist, oder das Dokument selbst ist als Inhalt von sl11:SignatureEnvironment angegeben.

Die direkte Einbettung kann auf zwei Arten erfolgen: Entweder wird das XML-Dokument base64 kodiert und als Text des Kindelements sl10:Base64Content integriert, oder aber das Wurzelelement des XML-Dokuments wird direkt als einziges Kind des Kindelements sl10:XMLContent angegeben. Siehe dazu auch den Hinweis in Abschnitt 2.2.1, Datenobjekt.

Anmerkung: Wird ein XML-Dokument als Signaturdokument verwendet, das eine Document Type Declaration (siehe [XML]) verwendet, soll die erste Variante der direkten Einbettung (base64 Kodierung) verwendet werden, damit die dort enthaltenen Informationen vom XML-Parser der Bürgerkarten-Umgebung ausgewertet werden können. Bei der Einbettung des Wurzelelements in sl10:XMLContent können diese Informationen nicht angegeben werden.

Anmerkung: Für das Parsen des Signaturdokuments wird folgende Vorgangsweise empfohlen: In einem ersten Schritt versucht die Bürgerkarten-Umgebung das Dokument validierend zu parsen. Informationen über die Grammatik des Dokuments liefern dazu eine ggf. im Dokument vorhandene Document Type Declaration (siehe [XML]), oder XML-Schemata, die mit den in [XML-Schema], Abschnitt 2.6.3 angegebenen Mechanismen referenziert werden. Sollte dieser erste Versuch scheitern, parst die Bürgerkarten-Umgebung das Dokument in einem zweiten Anlauf nichtvalidierend, d. h. ohne Auswertung von Grammatikinformationen.

Position der Signatur

Das darauffolgende Element sl11:SignatureLocation enthält Informationen, an welcher Position im Signaturdokument die zu erstelltende Signatur von der Bürgerkarten-Umgebung eingefügt werden soll.

Der Textinhalt des Elements enthält einen Ausdruck nach [XPath], mit dem das Eltern-Element der einzufügenden Signatur ausgewählt wird. Als Kontext-Knoten für die Auswertung des XPath-Ausdrucks ist der Dokument-Knoten des in sl11:SignatureEnvironment spezifizierten XML-Dokuments zu verwenden. Werden im XPath-Ausdruck Namespace-Prefixes verwendet, müssen die entsprechenden Namespace-Deklarationen im Kontext des Elements sl10:SignatureLocation bekannt sein.

Das Attribut Index selektiert die Position der Signatur innerhalb des Elternelements. Hat Index den Wert 0, wird die Signatur als erster Kindknoten des Elternelements eingefügt, hat Index den Wert n, wird die Signatur unmittelbar nach dem n-ten Kindknoten des Elternelements eingefügt.

Ergänzungsobjekte

Zusätzlich können schließlich Ergänzungsobjekte (sl11:Supplements) spezifiziert werden, die in Zusammenhang mit dem Signaturdokument stehen. Die auf diese Weise übergebenen Objekte brauchen von der Bürgerkarten-Umgebung dann nicht selbst aufgelöst zu werden.

Beispielsweise könnte im Signaturdokument, das in sl11:SignatureEnvironment spezifiziert wurde, ein Verweis auf die Dokumenttypdefinition enthalten sein. Das auf diese Weise referenzierte Dokument kann von der Applikation als Ergänzungsobjekt übergeben werden, wenn die Bürgerkarten-Umgebung den Verweis nicht selbst auflösen soll, oder wenn die Bürgerkarten-Umgebung den Verweis gar nicht auflösen kann, weil es sich etwa um einen relativen Veweis, bezogen auf das Signaturdokument, handelt.

Ein weiteres Beispiel für die Verwendung eines Ergänzungsobjekts könnte ein XML-Schema sein, das im mittels sl11:SignatureEnvironment spezifizierten Signaturdokument unter Verwendung der in [XML-Schema] vorgeschlagenen Mechanismen (siehe Anmerkung im vorangegangenen Abschnitt Das Signaturdokument) referenziert wird.

Ein Ergänzungsobjekt besteht dabei einerseits aus optionalen Metainformationen (vergleiche sl10:FinalDataMetaInfo in Abschnitt 2.2.1, Transformationswege), andererseits aus dem eigentlichen Daten (sl10:Content): Das verpflichtend zu verwendende Attribut Reference enthält dabei als URI die Referenz auf die Ergänzungsdaten, und zwar so, wie sie von der Bürgerkarten-Umgebung zur Auflösung verwendet werden würde. Der Inhalt von sl10:Content repräsentiert die Ergänzungsdaten (siehe auch Hinweis in Abschnitt 2.2.1, Datenobjekt).

<sl11:CreateXMLSignatureRequest>
  <sl11:KeyboxIdentifier>Bezeichner der Keybox</sl11:KeyboxIdentifier>
  <sl11:DataObjectInfo Structure="detached">
    <sl10:DataObject Reference="http://examples.org/myDataObject.xml"/>
    <!--Erster Transformationsweg: Keine Transformationen-->
    <sl10:TransformsInfo>
      <sl10:FinalDataMetaInfo>
        <sl10:MimeType>text/xml</sl10:MimeType>
      </sl10:FinalDataMetaInfo>
    </sl10:TransformsInfo>
    <!--Zweiter Transformationsweg:Stylesheet-Transformation in eine HTML-Datei-->
    <sl10:TransformsInfo>
      <dsig:Transforms>
        <dsig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116 ">
          <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
            <!--Das Stylesheet-->
          </xsl:stylesheet>
        </dsig:Transform>
      </dsig:Transforms>
      <sl10:FinalDataMetaInfo>
        <sl10:MimeType>text/html</sl10:MimeType>
      </sl10:FinalDataMetaInfo>
    </sl10:TransformsInfo>
  </sl11:DataObjectInfo>
  <sl11:SignatureInfo>
    <sl11:SignatureEnvironment Reference="http://examples.org/mySigContainer.xml"/>
    <sl11:SignatureLocation Index="0">/Envelope</sl11:SignatureLocation>
  </sl11:SignatureInfo>
</sl11:CreateXMLSignatureRequest>

2.2.2 Antwort

Die Antwort enthält die nach [XMLDSIG] kodierte elektronische Signatur. Wurde in der Anfrage ein sl11:SignatureInfo Element angegeben, enthält die Antwort als einziges Kind das in sl11:SignatureInfo angegebene Dokument mit der darin integrierten Signatur. Ansonsten enthält die Antwort direkt die erzeugte Signatur.

Signierte Daten

Für jedes in der Anfrage mittels Behälter (sl11:DataObjectInfo) übergebene Datenobjekt enthält die XML-Signatur ein dsig:Reference Element. In dessen dsig:Transforms Element ist jene Transformationskette anzugeben, die in der Bürgerkarten-Umgebung durchlaufen wurde, um aus dem übergebenen Datenobjekt jene Daten zu erhalten, die für die Berechnung des Hash-Wertes sowie gegebenenfalls für die Anzeige im Secure Viewer verwendet worden sind.

Implizite Transformationsparameter

Um den korrekten Zusammenhang zwischen den Referenz-Eingangsdaten sowie den Hash-Eingangsdaten später jederzeit überprüfen zu können, müssenfür jedes in die Signatur aufzunehmende Datenobjekt alle impliziten Transformationsparameter in ein einziges Signaturmanifest aufgenommen werden.

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.

Die Referenz-Eingangsdaten sind jedenfalls als impliziter Transformationsparameter zu betrachten. Als weiteres Beispiel soll hier wiederum die bereits in Abschnitt 2.2.1 erwähnte Stylesheet-Transformation erwähnt werden, die sich verschachtelter Stylesheets bedient. Die im Basis-Stylesheet referenzierten weiteren Stylesheets sind implizite Transformationsparameter im obigen Sinne.

Das Signaturmanifest (dsig:Manifest) enthält für jeden impliziten Transformationsparameter ein eigenes Referenzobjekt (dsig:Reference), das einen Hash-Wert für den impliziten Transformationsparameter inkludiert. Transformationen in den Referenzobjekten des Signaturmanifests dürfen nicht verwendet werden. 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 zur Auflösung verwendet werden würde.

Die Einbindung des Signaturmanifests in die Signatur erfolgt durch ein eigenes Referenzobjekt der Signatur (dsig:Reference in dsig:SignedInfo). Dabei ist die Verwendung des Attributs Type im Referenzobjekt zur Kennzeichnung des referenzierten Datums als Signaturmanifest erforderlich. Das Attribut muss folgenden Wert aufweisen:

http://www.buergerkarte.at/specifications/Security-Layer/20020225#SignatureManifest

Signaturattribute

Die nachfolgend angegebenen Informationen müssen in die Signatur unter Verwendung von Signaturattributen nach [ETSIXML] aufgenommen werden. Die Einbindung der Signaturattribute in die Signatur hat als als Direct Incorporation entsprechend den Hinweisen in den Abschnitten 6.3 und insbesondere 6.3.1 von [ETSIXML] zu erfolgen. Das in Abschnitt 6.3.1 erwähnte Attribut Type erforderlich.

Signierte Metainformationen

Für jedes in der Anfrage spezifizierte zu signierende Datenobjekt (sl10:DataObject), ist ein Signaturattribut aufzunehmen, das die dazu spezifizierten Metainformationen (sl10:FinalDataMetaInfo) enthält.

Dazu ist das signierte Signaturattribut etsi:DataObjectFormat nach [ETSIXML] zu verwenden. Das Element sl10:MimeType aus sl10:FinalDataMetaInfo entspricht dabei dem Element etsi:MimeType aus etsi:DataObjectFormat, das optional vorhandene Element sl10:Description aus sl10:FinalDataMetaInfo dem Element etsi:Description aus etsi:DataObjectFormat.

Signierte Zertifikatsreferenz

Weiters ist ein Signaturattribut mitaufzunehmen, mit dem das für die Verifikation der Signatur zu verwendende Signatorzertifikat eindeutig identifiziert wird. Dazu ist das signierte Signaturattribut etsi:SigningCertificate nach [ETSIXML] zu verwenden.

Zertifikatskette

Schließlich wird empfohlen, die gesamte Kette an Zertifikaten, die zur Prüfung der Signatur benötigt wird (Signatorzertifikat bis zu einer vertrauenswürdigen Wurzelinstanz), in die XML-Signatur aufzunehmen. Dazu eignen sich die XML-Elemente dsig:X509Data sowie dsig:RetrievalMethod innerhalb von dsig:KeyInfo.

<sl11:CreateXMLSignatureResponse>
  <Envelope>
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      <!-- Signatur nach XMLDSIG und ETSIXML -->
    </dsig:Signature>
  </Envelope>
</sl11:CreateXMLSignatureResponse>

3 Signaturprüfung

3.1 Signatur nach CMS

3.1.1 Anfrage

Mit dieser Anfrage wird eine beliebige Signatur nach [CMS], die nicht notwendigerweise das Profil dieser Spezifikation einhält, an die Bürgerkarten-Umgebung zur Überprüfung übergeben.

Signatoren

Im Attribut Signatories enthält die Anfrage zunächst Angaben über jene in der CMs-Signatur angegebenen Signatoren, deren Unterschriften überprüft werden sollen. Der Wert dieses Attributs enthält eine Aufzählung von positiven Ganzzahlen, wobei eine Ganzzahl jeweils die Position des Signators enthält, so wie er in der CMS-Signatur (Strukturelement SignerInfo) vorkommt. Wird dieses Attribut nicht spezifiziert, so ist es mit dem Wert 1 anzunehmen, d. h. es ist nur die Signatur des ersten in SignerInfo spezifizierten Signators zu überprüfen.

Prüfzeitpunkt

Als nächstes enthält die Anfrage zur Signaturüberprüfung optional die Angabe jenes Zeitpunktes, der zur Feststellung der Gültigkeit der zu überprüfenden Signatur verwendet werden soll (sl11:DateTime). Fehlt diese Angabe, ist als Prüfzeitpunkt der Zeitpunkt des Einlangens der Überprüfungsanfrage bei der Bürgerkarten-Umgebung anzunehmen.

Signatur

Nachfolgend enthält die Anfrage die zu überprüfende Signatur nach [CMS] (sl11:CMSSignature) in base64-kodierter Form.

Datenobjekt

Falls das signierte Datenobjekt in der zu prüfenden [CMS]-Signatur nicht mitkodiert ist, muss es in der Anfrage im Element sl11:DataObject mitübergeben werden.

In sl11:DataObject können zunächst Metainformationen (sl10:MetaInfo) angegeben werden (Mime-Type sowie eine Referenz auf eine Beschreibung des signierten Datenobjekts). Danach folgt die Angabe der Daten auf eine von zwei Arten: Entweder enthält das Element sl10:Content die base64-kodierten Daten, oder das Element sl10:Content ist leer, hat aber sein Attribut Reference gesetzt. Die Bürgerkarten-Umgebung versucht im letztenFall, die in diesem Attribut angegebene URI aufzulösen, um so das signierte Datenobjekt zu erhalten.

Beispiel

<sl11:VerifyCMSSignatureRequest>
  <sl11:DateTime>2001-12-31T10:00:00</sl11:DateTime>
  <sl11:CMSSignature>
    <!--CMS-Signatur in base64-kodierter Form-->
  </sl11:CMSSignature>
  <sl11:DataObject>
    <sl10:Content Reference="http://examples.org/myText.txt">
      <!--Entweder base64-codierter Inhalt oder gesetztes Reference-Attribut-->
    </sl10:Content>
  </sl11:DataObject>
</sl11:VerifyCMSSignatureRequest>

3.1.2 Antwort

Für jede in der Anfrage spezifizierte zu prüfende Signatur werden in der Antwort folgende Informationen zurückgeliefert:

Zunächst werden in in sl11:SignerInfo Informationen zum X.509-Zertifikat des Signators angegeben. sl11:SignerInfo mussaus genau einem Element dsig:X509Data< bestehen, das mindestens folgende zwei Elemente enthalten muss:

• dsig:SubjectName enthält den Namen des Signators aus dem Signatorzertifikat. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren.  In dsig:X509Data muss genau ein solches Element vorkommen.
  
• dsig:IssuerSerial enthält den Namen des Austellers und die Seriennummer des Signatorzertifikats. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren. In dsig:X509Data muss genau ein solches Element vorkommen.

Weiters muss dieses dsig:X509Data das leere Element sl11:QualifiedCertificate enthalten, wenn das Signatorzertifikat als qualifiziert anzusehen ist. Dazu müssen folgende Bedingungen erfüllt sein:

1. Es muss die Zertifikatserweiterung qcStatements (siehe [QCert], 3.2.5) vorhanden sein.
2. Innerhalb dieses Zertifikatserweiterung muss das Statement esi4-qcStatement-1 (siehe [ETSIQCert], 4.2.1) vorhanden sein.
   

Ob weitere Elemente - wie beispielsweise das Signatorzertifikat selbst - zurückgeliefert werden, bleibt der Bürgerkarten-Umgebung überlassen. Konnte bei der Überprüfung kein Signatorzertifikat nach X.509 identifiziert werden, bleibt es ebenfalls der Bürgerkarten-Umgebung überlassen, welche Informationen über den öffentlichen Schlüssel sie zurückliefert.

Weiters enthalten sind getrennte Ergebnisse für die kryptographische Überprüfung der Signatur (sl11:SignatureCheck) sowie für die Prüfung der Signaturprüfdaten (sl11:CertificateCheck).

Beide Ergebnisse besitzen die gleiche Struktur: Das Element sl10:Code enthält das Ergebnis der Prüfung in maschinenlesbarer Form, das optionale Element sl10:Info enthält genauere, nicht näher spezifizierte Zusatzinfomationen. Vorstellbar ist etwa eine vom Menschen lesbare Klartext-Interpretation des Prüfungsergebnises.

Prüfung der Gültigkeit der Signatur

Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation erstellt, so enthält sie ein Signaturattribut ContentHints nach [ESS-S/MIME], Abschnitt 2.9, das Metainformationen zum signierten Datenobjekt enthält. Dieses Signaturattribut kann von der Bürgerkarten-Umgebung bei Bedarf ausgewertet werden.

Folgende Werte sind für den Inhalt des Elements sl10:Code in sl11:SignatureCheck definiert:

Prüfung der Signaturprüfdaten

Diese umfaßt die Konstruktion der Zertifikatskette vom Signatorzertifikat bis zu einem vertrauenswürdigen Wurzelzertifikat, sowie die Statusprüfung für jedes Zertifikat der konstruierten Zertifikatskette.

Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation erstellt, so enthält sie ein Signaturattribut OtherSigningCertificate nach [ETSICMS], das Informationen zum Signatorzertifikat enthält. Diese Informationen müssen von der Bürgerkarten-Umgebung in einem solchen Fall als Ausgangspunkt zur Konstruktion der Zertifikatskette verwendet werden.

Bei der Überprüfung älterer Signaturen kann es vorkommen, dass vom Zertifizierungsdiensteanbieter, der das Signatorzertifikat ausgestellt hat, keinerlei Online-Informationen mehr angeboten werden, die die Bildung der Zertifikatskette bzw. die Statusprüfung der Zertifikate in dieser Kette ermöglichen. Damit solche Signaturen trotzdem überprüft werden können, wird empfohlen, dass die Bürgerkarten-Umgebung in solchen Fällen die ggf. vorhandenen unsignierten Signaturattribute CompleteCertificateRefs, CompleteRevocationRefs, CertificateValues und RevocationValues nach [ETSICMS] auswertet.

Folgende Werte sind für den Inhalt des Elements sl10:Code in sl11:CertificateCheck definiert:

Beispiel

<sl11:VerifyCMSSignatureResponse>
  <sl11:SignerInfo>
    <dsig:X509Data>
      <dsig:X509SubjectName>CN=Hermann Muster</dsig:X509SubjectName>
      <dsig:X509IssuerSerial>
        <dsig:X509IssuerName>O=CSP XY,OU=Personal Certificates,C=AT</dsig:X509IssuerName>
        <dsig:X509SerialNumber>12345</dsig:X509SerialNumber>
      </dsig:X509IssuerSerial>
    </dsig:X509Data>
  </sl11:SignerInfo>
  <sl11:SignatureCheck>
    <sl10:Code>0</sl10:Code>
  </sl11:SignatureCheck>
  <sl11:CertificateCheck>
    <sl10:Code>3</sl10:Code>
    <sl10:Info>Der Status des Signaturzertifikats konnte nicht geprüft werden.</sl10:Info>
  </sl11:CertificateCheck>
</sl11:VerifyCMSSignatureResponse>

3.2 Signatur nach XMLDSIG

3.2.1 Anfrage

Mit dieser Anfrage wird eine beliebige Signatur nach [XMLDSIG], die nicht notwendigerweise das Profil dieser Spezifikation einhält, an die Bürgerkarten-Umgebung zur Überprüfung übergeben.

Prüfzeitpunkt

Die Anfrage zur Signaturüberprüfung enthält zunächst optional die Angabe jenes Zeitpunktes, der zur Feststellung der Gültigkeit der zu überprüfenden Signatur verwendet werden soll (sl11:DateTime). Fehlt diese Angabe, ist als Prüfzeitpunkt der Zeitpunkt des Einlangens der Überprüfungsanfrage bei der Bürgerkarten-Umgebung anzunehmen.

Signatur

Nachfolgend enthält die Anfrage Angaben zur zu überprüfenden Signatur nach [XMLDSIG] (sl11:SignatureInfo).

Zunächst enhält sl11:SignatureInfo Angaben zum XML-Dokument, das die zu überprüfende Signatur inkludiert (sl11:SignatureEnvironment). Entweder enthält das Attribut Reference einen Verweis auf dieses Dokument, der von der Bürgerkarten-Umgebung aufzulösen ist, oder das Dokument selbst ist als Inhalt von sl11:SignatureEnvironment angegeben.

Die direkte Einbettung kann auf zwei Arten erfolgen: Entweder wird das XML-Dokument base64 kodiert und als Text des Kindelements sl10:Base64Content integriert, oder aber das Wurzelelement des XML-Dokuments wird direkt als einziges Kind des Kindelements sl10:XMLContent angegeben. Siehe dazu auch den Hinweis in Abschnitt 2.2.1, Datenobjekt.

Anmerkung: Wird ein XML-Dokument angegeben, das eine Document Type Declaration (siehe [XML]) verwendet, soll die erste Variante der direkten Einbettung (base64 Kodierung) verwendet werden, damit die dort enthaltenen Informationen vom XML-Parser der Bürgerkarten-Umgebung ausgewertet werden können. Bei der Einbettung des Wurzelelements in sl10:XMLContent können diese Informationen nicht angegeben werden.

Anmerkung: Für das Parsen des XML-Dokuments, das die zu überprüfende Signatur beinhaltet, siehe die Emfehlung in Abschnitt 2.2.1.

Weiters enthält sl11:SignatureInfo mit sl11:SignatureLocation einen Ausdruck nach [XPath], mit dem anzugeben ist, wo sich die zu überprüfende Signatur innerhalb des mittels sl11:SignatureEnvironment spezifizierten XML-Dokuments befindet. Als Kontext-Knoten für die Auswertung des XPath-Ausdrucks ist der Dokument-Knoten des in sl11:SignatureEnvironment spezifizierten XML-Dokuments zu verwenden. Werden im XPath-Ausdruck Namespace-Prefixes verwendet, müssen die entsprechenden Namespace-Deklarationen im Kontext des Elements sl11:SignatureLocation bekannt sein.

Ergänzungsobjekte

Optional können in der Anfrage schließlich Ergänzungsobjekte übergeben werden. Das sind Datenobjekte, auf die innerhalb der Signaturstruktur verwiesen wird. Beispiele dafür sind:

• ein Datenobjekt, das im URI Attribut eines dsig:Reference Elements der Signatur referenziert wird;
• referenzierte Parameter für die Transformationen in einem dsig:Reference Elements der Signatur (z. B. ein Stylesheet, der im Basis-Stylesheet einer XSLT-Transformation referenziert wird);
• referenzierte Informationen für die Validierung des Dokuments, das die Signatur beinhaltet (Verweis in der Document Type Declaration, Verweise auf XML-Schemata mittels der in [XML-Schema], Abschnitt 2.6.3 angegebenen Mechanismen);
• referenzierte Informationen für die Aufindung des für die Signaturprüfung zu verwendenden Zertifikats (vergleiche [XMLDSIG], Abschnitt 4.4.3).

Für ein Ergänzungsobjekt (sl11:Supplement) dürfen zunächst Metainformationen (sl10:MetaInfo) angegeben werden (Mime-Type sowie eine Referenz auf eine Beschreibung des Ergänzungsobjekts). Danach folgen die verpflichtenden Angaben zum Inhalt des Objekts (sl10:Content): Das Attribut Reference enthält dabei als URI die Referenz auf das Ergänzungsobjekt, und zwar in exakt gleicher Weise, wie sie von der Bürgerkarten-Umgebung zur Auflösung verwendet werden würde. Der Inhalt von sl10:Content repräsentiert das Ergänzungsobjekt (siehe auch Hinweis in Abschnitt 2.2.1, Datenobjekt).

Werden in der Anfrage Ergänzungsobjekte übergeben, muss die Bürgerkarten-Umgebung diese verwenden, anstatt die entsprechenden Referenzen selbst aufzulösen.

Anmerkung: Notwendig ist die Angabe von Ergänzungsobjekten, wenn in der Signaturstruktur Verweise relativ zum Signaturdokument vorhanden sind.

Beispiel

<sl11:VerifyXMLSignatureRequest>
  <sl11:DateTime>2001-12-31T10:00:00</sl11:DateTime>
  <sl11:SignatureInfo>
    <sl11:SignatureEnvironment>
      <sl10:XMLContent>
        <Envelope>
          <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
            <dsig:SignedInfo>
              <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
              <dsig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
              <dsig:Reference URI="http://www.example.org/myDataObject.xml">
                <dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                <dsig:DigestValue>3RGQeH5eHK+jJ2GxGYPhwnzbBBc=</dsig:DigestValue>
              </dsig:Reference>
            </dsig:SignedInfo>
            <dsig:SignatureValue>
              <!--Signaturwert-->
            </dsig:SignatureValue>
            <dsig:KeyInfo>
              <!--Informationen zum öffentlichen Schlüssel-->
            </dsig:KeyInfo>
          </dsig:Signature>
        </Envelope>
      </sl10:XMLContent>
    </sl11:SignatureEnvironment>
    <sl11:SignatureLocation xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
      /Envelope/dsig:Signature
    </sl11:SignatureLocation>
  </sl11:SignatureInfo>
  <sl11:Supplement>
    <!--Wert des Attributs "Reference" entspricht dem Wert des Attributs "URI"-->
    <!--im Element "Reference" der Signatur-->
    <sl10:Content Reference="http://www.example.org/myDataObject.xml">
      <!--Base64-Kodierung des referenzierten Datenobjekts (symbolischer Wert)-->
      <sl10:Base64Content>deiOeHbGRdjh</sl10:Base64Content>
    </sl10:Content>
  </sl11:Supplement>
</sl11:VerifyXMLSignatureRequest>

3.2.2 Antwort

Die Antwort auf die Anfrage zur Prüfung einer Signatur nach XML enthält zunächst Informationen zum öffentlichen Schlüssel des Signators (sl11:SignerInfo). Konnte bei der Überprüfung ein dem öffentlichen Schlüssel entsprechendes Signatorzertifikat nach X.509 identifiziert werden, muss sl11:SignerInfo zumindest folgende Informationen enthalten:

• Genau ein dsig:X509Data Element, das wiederum mindestens drei Elemente enthalten muss:
  • dsig:SubjectName enthält den Namen des Signators aus dem Signatorzertifikat. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren. In dsig:X509Data muss genau ein solches Element vorkommen.
    
  • dsig:IssuerSerial enthält den Namen des Austellers und die Seriennummer des Signatorzertifikats. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren. In dsig:X509Data muss genau ein solches Element vorkommen.

  • Weiters muss dsig:X509Data das leere Element sl11:QualifiedCertificate enthalten, wenn das Signatorzertifikat als qualifiziert anzusehen ist. Dazu müssen folgende Bedingungen erfüllt sein:

    1. Es muss die Zertifikatserweiterung qcStatements (siehe [QCert], 3.2.5) vorhanden sein.
    2. Innerhalb dieses Zertifikatserweiterung muss das Statement esi4-qcStatement-1 (siehe [ETSIQCert], 4.2.1) vorhanden sein.
       

Ob weitere Elemente - wie beispielsweise das Signatorzertifikat selbst - zurückgeliefert werden, bleibt der Bürgerkarten-Umgebung überlassen. Konnte bei der Überprüfung kein Signatorzertifikat nach X.509 identifiziert werden, bleibt es ebenfalls der Bürgerkarten-Umgebung überlassen, welche Informationen über den öffentlichen Schlüssel sie zurückliefert.

Weiters enthält die Antwort getrennte Ergebnisse für die kryptographische Überprüfung der Signatur (sl11:SignatureCheck), für die Prüfung des Signaturmanifests (sl11:SignatureManifestCheck), für die Überprüfung ggf. vorhandener weiterer Manifeste (sl11:XMLDSIGManifestCheck), sowie für die Prüfung der Signaturprüfdaten (sl11:CertificateCheck).

Alle vier Ergebnisse besitzen eine ähnliche Struktur: Das Element sl11:Code enthält das Ergebnis der Prüfung in maschinenlesbarer Form, das Element sl11:Info kann genauereZusatzinfomationen enthalten (siehe dazu die folgenden Unterabschnitte).

Prüfung der Gültigkeit der Signatur

Diese hat wie in [XMLDSIG] spezifiziert zu erfolgen. Das bedeutet, das sowohl der Hash-Wert jedes dsig:Reference Elements als auch der Wert der Signatur (dsig:SignatureValue) zu überprüfen sind. Nicht zu überprüfen sind die Hash-Werte der Referenzelemente (dsig:Reference) in gegebenenfalls vorhandenen Manifesten (dsig:Manifest).

Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation erstellt, so enthält sie für jedes signierte Datenobjekt ein Signaturattribut etsi:DataObjectFormat nach [ETSIXML], das Metainformationen zum jeweiligen Datenobjekt enthält. Diese Signaturattribute können von der Bürgerkarten-Umgebung bei Bedarf ausgewertet werden.

Folgende Werte sind für den Inhalt des Elements sl11:Code in sl11:SignatureCheck definiert:

Das optionale Element sl11:Info bietet zunächst Platz für nicht näher spezifizierte Zusatzinformationen, etwa eine vom Menschen lesebare Klartext-Interpretation des Prüfungsergebnisses.

Enthält das zuvor erwähnte Element sl11:Code den Wert 1, wird darüber hinaus empfohlen, ein sl11:FailedReference-Elemente als Kind von sl11:Info zur Kennzeichnung des ersten dsig:Reference-Elements anzugeben, bei dem die Überprüfung des Hash-Wertes einen Fehler ergeben hat. Der Inhalt von sl11:FailedReference, eine positive Ganzzahl, gibt dabei die laufende Nummer der fehlerhaften dsig:Reference innerhalb von dsig:SignedInfo an. Zusätzliche sl11:FailedReference-Elemente dürfen angegeben werden, um Fehler bei der Überprüfung weiterer dsig:Reference-Elemente anzuzeigen.

Prüfung des Signaturmanifests

Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation erstellt, muß eine dsig:Reference in dsig:SignedInfo auf das Signaturmanifest verweisen. In einem solchen Fall ist der Hash-Wert jeder dsig:Reference des Signaturmanifests zu überprüfen.

Folgende Werte sind für den Inhalt des Elements sl11:Code in sl11:SignatureManifestCheck definiert:

Das optionale Element sl11:Info bietet zunächst Platz für nicht näher spezifizierte Zusatzinformationen, etwa eine vom Menschen lesebare Klartext-Interpretation des Prüfungsergebnisses.

Enthält das zuvor erwähnte Element sl11:Code den Wert 3, wird darüber hinaus empfohlen, ein bzw. mehrere sl11:FailedReference-Elemente als Kinder von sl11:Info zur Kennzeichnung all jener dsig:Reference-Elemente anzugeben, bei denen die Überprüfung des Hash-Wertes einen Fehler ergeben hat. Der Inhalt des jeweiligen sl11:FailedReference-Elements, eine positive Ganzzahl, gibt dabei die laufende Nummer der fehlerhaften dsig:Reference innerhalb des Signaturmanifests an.

Prüfung weiterer Manifeste

Enthält die zu überprüfende Signatur in dsig:SignedInfo dsig:Reference-Elemente, die auf gewöhnliche Manifeste entsprechend [XMLDSIG] verweisen (d. h. das Attribut Type in dsig:Reference ist auf den Wert http://www.w3.org/2000/09/xmldsig#Manifest gesetzt), muss die Antwort für jedes auf diese Weise identifizierte Manifest ein Element sl11:XMLDSIGManifestCheck mit dem Ergebnis der Überprüfung des Manifests enthalten.

Folgende Werte sind für den Inhalt des Elements sl11:Code in sl11:XMLDSIGManifestCheck definiert:

Das verpflichtend anzugebende Element sl11:Info bietet zunächst Platz für nicht näher spezifizierte Zusatzinformationen, etwa eine vom Menschen lesebare Klartext-Interpretation des Prüfungsergebnisses.

Enthält das zuvor erwähnte Element sl11:Code den Wert 1, müssen darüber hinaus ein bzw. mehrere sl11:FailedReference-Elemente als Kinder von sl11:Info zur Kennzeichnung all jener dsig:Reference-Elemente des Manifests angeben werden, bei denen die Überprüfung des Hash-Wertes einen Fehler ergeben hat. Der Inhalt des jeweiligen sl11:FailedReference-Elements, eine positive Ganzzahl, gibt dabei die laufende Nummer der fehlerhaften dsig:Reference innerhalb des Manifests an.

Weiters muss in sl11:Info mittels des Elements sl11:ReferringSignatureReference angegeben werden, auf welches in der Signatur referenzierte Manifest sich das Prüfungsergebnis bezieht. Der Inhalt von sl11:ReferringSignatureReference, eine positive Ganzzahl, gibt dabei die laufende Nummer jener dsig:Reference innerhalb von dsig:SignedInfo an, welche auf das Manifest verweist.

Prüfung der Signaturprüfdaten

Diese umfaßt die Konstruktion der Zertifikatskette vom Signatorzertifikat bis zu einem vertrauenswürdigen Wurzelzertifikat, sowie die Statusprüfung für jedes Zertifikat der konstruierten Zertifikatskette.

Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation erstellt, so enthält sie ein Signaturattribut etsi:SigningCertificate nach [ETSIXML], das Informationen zum Signatorzertifikat enthält. Diese Informationen müssen von der Bürgerkarten-Umgebung in einem solchen Fall als Ausgangspunkt zur Konstruktion der Zertifikatskette verwendet werden.

Bei der Überprüfung älterer Signaturen kann es vorkommen, dass vom Zertifizierungsdiensteanbieter, der das Signatorzertifikat ausgestellt hat, keinerlei Online-Informationen mehr angeboten werden, die die Bildung der Zertifikatskette bzw. die Statusprüfung der Zertifikate in dieser Kette ermöglichen. Damit solche Signaturen trotzdem überprüft werden können, wird empfohlen, dass die Bürgerkarten-Umgebung in solchen Fällen die ggf. vorhandenen unsignierten Signaturattribute etsi:CompleteCertificateRefs, etsi:CompleteRevocationRefs, etsi:CertificateValues und etsi:RevocationValues nach [ETSIXML] auswertet.

Für die definierten Werte für den Inhalt des Elements sl10:Code in sl11:CertificateCheck siehe Kapitel Prüfung der Signaturprüfdaten im Abschnitt über die Prüfung einer [CMS]-Signatur.

Beispiel

<sl11:VerifyXMLSignatureResponse> <sl11:SignerInfo> <dsig:X509Data> <dsig:X509SubjectName>CN=Hermann Muster</dsig:X509SubjectName> <dsig:X509IssuerSerial> <dsig:X509IssuerName>O=CSP XY,OU=Personal Certificates,C=AT</dsig:X509IssuerName> <dsig:X509SerialNumber>12345</dsig:X509SerialNumber> </dsig:X509IssuerSerial> </dsig:X509Data> </sl11:SignerInfo> <sl11:SignatureCheck> <sl11:Code>0</sl11:Code> </sl11:SignatureCheck> <sl11:SignatureManifestCheck> <sl11:Code>1</sl11:Code> <sl11:Info>Die Signatur enthält keine Referenz auf ein Signaturmanifest.</sl11:Info> </sl11:SignatureManifestCheck> <sl10:CertificateCheck> <sl10:Code>3</sl10:Code> <sl10:Info>Der Status des Signaturzertifikats konnte nicht geprüft werden.</sl10:Info> </sl10:CertificateCheck> </sl11:VerifyXMLSignatureResponse>

Beispiel: Antwort auf die Anfrage zur Prüfung einer Signatur nach [XMLDSIG]

4 Zugriff auf Infoboxen

Die Bürgerkarten-Umgebung stellt der Applikation einen Datenspeicher zur Verfügung, der logisch in sogenannte Infoboxen gegliedert ist. Eine Infobox ist dabei als Datencontainer für eine Menge zusammengehöriger Daten zu sehen.

Physikalisch können sich solche Infoboxen entweder direkt auf dem Bürgerkarten-Token befinden, oder aber auch an einem anderen Platz, der unter Kontrolle der Bürgerkarten-Umgebung steht; beispielsweise auf der Festplatte des lokalen Hosts, auf dem die Bürgerkarten-Umgebung ausgeführt wird. Für die Applikation ist diese Unterteilung aber nicht sichtbar; ihr ist lediglich die logische Sicht der Infobox als Datencontainer in der Bürgerkarten-Umgebung bekannt.

Es obliegt der Bürgerkarten-Umgebung, den Zugriff auf Daten in einer Infobox gegebenenfalls durch geeignete Maßnahmen zu schützen. Für Daten, die auf dem Bürgerkarten-Token abgelegt werden, können etwa die dort vorhanden Schutzmechanismen (PIN, Schlüssel) verwendet werden. Ähnliche Mechanismen sind auch zum Schutz von sensiblen Daten denkbar, die von der Bürgerkarten-Umgebung auf der Festplatte verwaltet werden.

Die Schnittstelle Security-Layer bietet folgende Kommandos für den Zugriff auf Daten in Infoboxen:

• Abfrage von verfügbaren Infoboxen
• Lesen von Daten in einer Infobox
• Verändern von Daten in einer Infobox

4.1 Typen von Infoboxen

Nachfolgend sind jene zwei verschiedenen Typen definiert, die eine Infobox haben kann.

4.1.1 Binärdatei

Eine Binärdatei ist im Wesentlichen als eine Folge von Bytes anzusehen, die in ihrer Gesamtheit über den Security-Layer gelesen bzw. geschrieben werden kann. Lesen bzw. Veränderung einer Teilfolge von Bytes der Binärdatei ist nicht vorgesehen.

Leseparamter und Antwortdaten

Eine Binärdatei kann nur in ihrer Gesamtheit gelesen werden. Grundsätzlich werden daher keine Parameter in der Leseanfrage (siehe Abschnitt 4.3.1) übergeben, das Parameterelement sl10:BinaryFileParameters bleibt leer. Die Applikation kann jedoch mit Hilfe des boolschen Attributs sl10:ContentIsXMLEntity in sl10:BinaryFileParameters der Bürgerkarten-Umgebung einen Hinweis geben, ob die in der Binärdatei gespeicherten Daten als XML interpretierbar sind.

<sl10:BinaryFileParameters ContentIsXMLEntity="true"/>

In welcher Form die Daten in der Antwort auf die Leseanfrage (siehe Abschnitt 4.3.2) geliefert werden, hängt vom Attribut sl10:ContentIsXMLEntity in der Leseanfrage ab. Wurde dieses Attribut auf true gesetzt, enthält sl10:BinaryFileData den Inhalt der Binärdatei als geparstes XML (als Kinder von sl10:XMLContent), ansonsten in base64-kodierter Form (sl10:Base64Content).

<sl10:BinaryFileData>
  <sl10:XMLContent>
    <FirstName>Hermann</FirstName>
    <LastName>Muster</LastName>
  </sl10:XMLContent>
</sl10:BinaryFileData>

Update-Parameter und Antwortdaten

Da eine Binärdatei nur in ihrer Gesamtheit verändert werden kann, ist in der Update-Anfrage als einziger Parameter der gesamte neue Inhalt der Infobox anzugeben, und zwar entweder in base64-kodierter Form (sl10:BinaryFileParameters/sl10:Base64Content), oder als geparstes XML (sl10:BinaryFileParameters/sl10:XMLContent). Bei der Kodierung als XML kann für sl10:XMLContent das Attribut xml:space mit dem Wert preserve versehen werden, wenn es aus Sicht der Applikation wichtig ist, dass die Bürgerkarten-Umgebung Whitespace innerhalb des übergebenen XML nicht verändert.

<sl10:BinaryFileParameters>
  <sl10:Base64Content>f3G7Tw9hH</sl10:Base64Content>
</sl10:BinaryFileParameters>

In der entsprechenden Antwort auf die Update-Anfrage (siehe Abschnitt 4.4.2) werden keinerlei Daten zurückgeliefert.

4.1.2 Assoziatives Array

Ein assoziatives Array ist als eine Menge von Schlüsseln zu verstehen, wobei jedem Schlüssel ein entsprechender Wert zugeordnet ist. Als wichtige Einschränkung muss stets gelten, dass sämtliche Schlüssel paarweise verschieden sind. Ein Schlüssel ist stets ein XML-String, während für den zugeordneten Wert keine Einschränkungen gelten.

Leseparamter und Antwortdaten

Auf ein assoziatives Array sind drei verschiedene Lesezugriffe erlaubt:

Lesen von Schlüsseln

Der erste Lesezugriff (Element sl10:ReadKeys in sl10:AssocArrayParameters) liefert die Menge jener Schlüssel, die einem spezifizierten Suchstring (Attribut SearchString in sl10:Readkeys) entsprechen. Mehrere Schlüssel sind als Ergebnis möglich, da im Suchstring die Angabe einer Wildcard "*" möglich ist. Diese Wildcard steht für eine beliebig lange Folge von Zeichen, mit Ausnahme des Zeichens "/". Im gleichen Suchstring können auch mehrere Wildcards vorkommen, jedoch muss zwischen zwei Wildcards zumindest einmal das Zeichen "/" vorkommen.

Hinweis: Dieses Model für den Einsatz der Wildcard wurde gewählt, um die Nachbildung mehrdimensionaler Arrays durch das assoziative Array zu ermöglichen. So könnte etwa ein zweidimensionales Array durch Schlüssel der Form "<Zahl> '/' <Zahl>" nachgebildet werden. Mit Hilfe des Suchstrings "1/*" könnte dann etwa alle Werte der ersten Reihe ausgelesen werden.

<sl10:AssocArrayParameters>
  <sl10:ReadKeys SearchString="*"/>
</sl10:AssocArrayParameters>

Die Antwortdaten enthalten die gefundenen Schlüssel (Elemente sl10:Key in sl10:AssocArrayData).

<sl10:AssocArrayData>
  <sl10:Key>MyFirstCertificate</sl10:Key>
  <sl10:Key>MySecondCertificate</sl10:Key>
  <sl10:Key>AnotherCertificate</sl10:Key>
</sl10:AssocArrayData>

Lesen von Schlüsseln und Werten

Der zweite Lesezugriff (Element sl10:ReadPairs in sl10:AssocArrayParameters) ist ähnlich dem ersten, jedoch werden nicht nur die dem Suchausdruck (Attribut SearchString in sl10:ReadPairs) entsprechenden Schlüssel als Resultat geliefert, sondern zu jedem Schlüssel wird gleichzeitig auch der zugeordnete Wert retourniert.

Ähnlich wie bei den Leseparametern für eine Binärdatei (siehe Abschnitt 4.1.1, Leseparameter und Antworten) kann die Applikation Hilfe des boolschen Attributs ValuesAreXMLEntities im Element sl10:ReadPairs der Bürgerkarten-Umgebung einen Hinweis geben, ob die zu den gesuchten Schlüsseln zugeordneten Werte als XML interpretierbar sind. Sind nicht alle Werte als XML interpretierbar, darf das Attribut nicht auf true gesetzt werden.

<sl10:AssocArrayParameters>
  <sl10:ReadPairs SearchString="My*Certificate"/>
</sl10:AssocArrayParameters>

Die Antwortdaten (sl10:AssocArrayData) enthalten die gefundenen Schlüssel/Wert-Paare (Elemente sl10:Pair). In sl10:Pair befindet sich der Schlüssel als Attribut Key, sowie der zugehörige Wert als geparstes XML (sl10:XMLContent) oder base64-kodiert (sl10:Base64Content). Die Kodierung der Werte hängt vom oben besprochenen Attribut ValuesAreXMLEntities ab. Sie erfolgt entweder für alle Werte als geparstes XML oder für alle Werte base64.

<sl10:AssocArrayData>
  <sl10:Pair Key="MyFirstCertificate">
    <sl10:Base64Content>aD3Hrt3dv</sl10:Base64Content>
  </sl10:Pair>
  <sl10:Pair Key="MySecondCertificate">
    <sl10:Base64Content>4Gzt73Dcnf</sl10:Base64Content>
  </sl10:Pair>
</sl10:AssocArrayData>

Lesen des Werts zu einem Schlüssel

Der dritte Lesezugriff (Element sl10:ReadValue in sl10:AssocArrayParameters) erlaubt das Lesen jenes Wertes, der einem spezifizierten Schlüssel (Attribut Key in sl10:ReadValue) zugeordnet ist. Wie beim Lesen von Schlüsseln und Werten kann die Applikation auch hier mit Hilfe des boolschen Attributs ValueIsXMLEntity im Element sl10:ReadValue der Bürgerkarten-Umgebung einen Hinweis geben, ob der auszulesende Wert als XML interpretierbar ist.

<sl10:AssocArrayParameters>
  <sl10:ReadValue Key="MyFirstCertificate"/>
</sl10:AssocArrayParameters>

<sl10:AssocArrayData>
  <sl10:Pair Key="MyFirstCertificate">
    <sl10:Base64Content>4Gzt73Dcnf</sl10:Base64Content>
  </sl10:Pair>
</sl10:AssocArrayData>

Update-Parameter und Antwortdaten

Für ein Assoziatives Array sind drei unterschiedliche Update-Anfragen vorgesehen:

Änderung eines Schlüssels

Die erste Anfrage (Element sl10:UpdateKey in sl10:AssocArrayParameters) erlaubt die Änderung des Schlüssels eines im Assoziativen Array gespeicherten Schlüssel/Wert-Paares. In sl10:UpdateKey sind dabei als Attribute der derzeitige (Key) sowie der neue Schlüssel (NewKey) anzugeben.

<sl10:AssocArrayParameters>
  <sl10:UpdateKey Key="OldKeyname" NewKey="NewKeyname"/>
</sl10:AssocArrayParameters>

Änderung eines Wertes

Mittels der zweiten Anfrage (Element sl10:UpdateValue in sl10:AssocArrayParameters) kann der Wert eines im Assoziativen Array gespeicherten Schlüssel/Wert-Paares geändert werden. In sl10:UpdateValue sind dabei der Schlüssel der zu ändernden Assoziation (Attribut Key) sowie der neue Wert (Inhalt von sl10:UpdateValue) zu spezifizieren.

Hinsichtlich der Kodierung des Wertes gelten die in Abschnitt 4.1.1, Updateparameter und Antwortdaten gemachten Aussagen.

<sl10:AssocArrayParameters>
  <sl10:UpdateValue Key="AnotherCertificate">
    <sl10:Base64Content>45G3DFV6dfde</sl10:Base64Content>
  </sl10:UpdateValue>
</sl10:AssocArrayParameters>

Löschen eines Schlüssel/Wert-Paares

Die dritte mögliche Anfrage (Element sl10:DeletePair in sl10:AssocArrayParameters) gestattet schließlich das Löschen eines Schlüssel/Wert-Paares aus dem Assoziativen Array. Dazu muß der Schlüssel des Paares als Attribut Key in sl10:DeletePair angegeben werden.

<sl10:AssocArrayParameters>
  <sl10:DeletePair Key="AnotherCertificate"/>
</sl10:AssocArrayParameters>

In der entsprechenden Antwort auf alle drei möglichen Update-Anfragen (siehe Abschnitt 4.4.2) werden keinerlei Daten zurückgeliefert.

4.2 Abfrage der verfügbaren Infoboxen

Mit diesem Kommando erhält die Applikation von der Bürgerkarten-Umgebung die Auskunft, welche Infoboxen für Zugriffe zur Verfügung stehen.

4.2.1 Anfrage

Die Anfrage ist ein leeres Kommando ohne Parameter.

<sl10:InfoboxAvailableRequest/>

4.2.2 Antwort

Die Antwort enthält eine Liste von Bezeichnern (Elemente sl10:InfoboxIdentifier). Jeder Bezeichner entspricht einer Infoxbox, die der Applikation für Zugriffe zur Verfügung steht. Die Bezeichner werden in den nachfolgend beschriebenen Kommandos zum Lesen bzw. zum Verändern von Daten einer Infobox zur Identifikation der Infobox verwendet.

<sl10:InfoboxAvailableResponse>
  <sl10:InfoboxIdentifier>Certificates</sl10:InfoboxIdentifier>
  <sl10:InfoboxIdentifier>IdentityLink</sl10:InfoboxIdentifier>
  <sl10:InfoboxIdentifier>Mandates</sl10:InfoboxIdentifier>
</sl10:InfoboxAvailableResponse>

4.3 Lesen von Daten einer Infobox

Dieses Kommando erlaubt der Applikation das Lesen von Daten einer Infobox.

4.3.1 Anfrage

Die Anfrage enthält zunächst den Bezeichner jener Infobox, deren Inhalt gelesen werden soll (Elementsl10:InfoboxIdentifier). Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem Kommando sl10:InfoboxAvailableRequest abfragen.

Weiters sind - abhängig vom Typ der Infobox - Parameter für die Lese-Anfrage zu spezifizieren. Für weitere Informationen zu diesen Parametern siehe Abschnitt 4.1.

<sl10:InfoboxReadRequest>
  <sl10:InfoboxIdentifier>IdentityLink</sl10:InfoboxIdentifier>
  <sl10:BinaryFileParameters/>
</sl10:InfoboxReadRequest>

4.3.2 Antwort

Die Antwort besteht aus den abgefragten Daten der bezeichneten Infobox. Für weitere Informationen zu diesen vom Typ der Infobox sowie von der Art der Lese-Anfrage abhängigen Daten siehe Abschitt Abschnitt 4.1.

<sl10:InfoboxReadResponse>
  <sl10:BinaryFileData>
    <sl10:Base64Content>dkfEFGNdedd543r</sl10:Base64Content>
  </sl10:BinaryFileData>
</sl10:InfoboxReadResponse>

4.4 Verändern von Daten einer Infobox

Dieses Kommando erlaubt der Applikation das Verändern von Daten einer Infobox.

4.4.1 Anfrage

Die Anfrage enthält zunächst den Bezeichner jener Infobox, deren Inhalt verändert werden soll (Elementsl10:InfoboxIdentifier). Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem Kommando sl10:InfoboxAvailableRequest abfragen.

Die Parameter für die Update-Anfrage sind abhängig vom Typ der zu verändernden Infobox sowie von der Art der Anfrage. Für genauere Informationen siehe Abschnitt 4.1.

<sl10:InfoboxUpdateRequest>
  <sl10:InfoboxIdentifier>Certificates</sl10:InfoboxIdentifier>
  <sl10:AssocArrayParameters>
    <sl10:UpdateValue Key="AnotherCertificate">
      <sl10:Base64Content>45G3DFV6dfde</sl10:Base64Content>
    </sl10:UpdateValue>
  </sl10:AssocArrayParameters>
</sl10:InfoboxUpdateRequest>

4.4.2 Antwort

Die Antwort ist ein leeres Kommando ohne Parameter.

<sl10:InfoboxUpdateResponse/>

5 Aushandeln eines symmetrischen Geheimnisses

Der Security-Layer bietet Anwendungen, die symmetrische Kryptographie benötigen, die Möglichkeit ein symmetrisches Geheimnis basierend auf einem asymmetrischen Schlüsselpaar zu berechnen. Das gemeinsame Geheimnis (Master-Secret) wird mit Hilfe des Diffie-Hellman-Algorithmus (siehe Abschnitt 5.3) berechnet und basiert auf den asymmetrischen Schlüsselpaaren der beiden Kommunikationspartner.

5.1 Anfrage

Die Anfrage enthält zunächst den Bezeichner jener Keybox, in der die zur Berechnung zu verwendenden Signaturerstellungsdaten abgelegt sind (Element sl10:KeyboxIdentifier).

Weiters ist der öffentliche Schlüssel des Kommunikationspartners mittels des Elements dsig:KeyInfo anzugeben.

<sl10:GetSymmetricSecretRequest>
  <sl10:KeyboxIdentifier>Bezeichner der Keybox</sl10:KeyboxIdentifier>
  <dsig:KeyInfo xmlns:dsig="xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
    <!-- XML-Struktur des öffentlichen Schlüssels des Kommunikationspartners, -->
    <!-- basierend auf XMLDSIG-Standard -->
  </dsig:KeyInfo>
</sl10:GetSymmetricSecretRequest>

5.2 Antwort

Die Antwort enthält das symmetrische Geheimnis als Base64-kodierte Binärzahl.

<GetSymmetricSecretResponse>
  <SymmetricSecretValue>Mastersecret (Base64 kodiert)</SymmetricSecretValue>
</GetSymmetricSecrectResponse>

5.3 Anmerkungen zur Funktionsweise

Bei Verwendung von (EC)DSA-basierten Schlüsseln erfolgt die Berechnung grundsätzlich nach dem Schema in [IEEE1363], Abschnitt 9.2. Für DSA-basierte Schlüssel ist dabei zur Berechnung des symmetrischen Geheimnisses die Methode aus [IEEE1363], Abschnitt 6.2.1 zu verwenden, für ECDSA-basierte Schlüssel jene aus [IEEE1363], Abschnitt 7.2.1. Im Element sl10:SymmetricSecretValue der Antwort zurückgeliefert wird der base64 kodierte Oktettstring, wie er in Punkt 6 der Aufzählung in [IEE1363], Abschnitt 9.2.2 beschrieben ist.

Bei Verwendung von RSA-basierten Schlüsseln erfolgt die Berechnung nach [DH-RSA], Abschnitt 2.1.1. Im Element sl10:SymmetricSecretValue der Antwort zurückgeliefert wird die base64 kodierte Zahl ZZ, deren Brechung im genannten Abschnitt ausgeführt ist.

Üblicherweise wird dieses Geheimnis nicht direkt zur Verschlüsselung benutzt, sondern dient als Mastersecret zur Verschlüsselung eines temporären Schlüssels (z. B. eine Zufallszahl) mit dem die eigentliche Verschlüsselung der Kommunikation stattfindet.

6 Abfrage von Eigenschaften

Die Schnittstelle Security-Layer bietet die Möglichkeit, eine Reihe von Eigenschaften der Bürgerkarten-Umgebung sowie den Status des verwendeten Bürgerkarten-Tokens abzufragen.

6.1 Abfrage der Umgebungseigenschaften

Die Applikation benötigt für bestimmte Aufgaben gegebenenfalls zusätzliche Informationen über die Bürgerkarten-Umgebung. Dieses Kommando dient zur Abfrage solcher Eigenschafen.

6.1.1 Anfrage

Die Anfrage ist ein leeres Kommando ohne Parameter.

<sl10:GetPropertiesRequest/>

6.1.2 Antwort

Die Antwort enthält folgende Eigenschaften der Bürgerkarten-Umgebung:

• Unterstützte Anzeigeformate des Trusted Viewer: Bei Kenntnis der Fähigkeiten des Trusted Viewer der Bürgerkarten-Umgebung kann die Applikation bei Anfragen zur Erstellung einer Signatur auf diese Fähigkeiten Rücksicht nehmen.
  
  
• Unterstützte Transformationen für Erstellung/Überprüfung einer XML-Signatur: Bei Kenntnis der Fähigkeiten der Transformationsunterstützung der Bürgerkarten-Umgebung kann die Applikation bei Anfragen zur Erstellung einer Signatur auf diese Fähigkeiten Rücksicht nehmen.
   
• Bezeichner aller in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaare: Diese Bezeichner werden für all jene Kommandos benötigt, deren Ausführung der Verwendung eines bestimmten Schlüsselpaares durch die Bürgerkarten-Umgebung bedarf (beispielsweise Erstellung einer Signatur nach CMS oder [XMLDSIG]).
  
  
• Unterstützte Bindungen an Transportprotokolle: Damit kann die Applikation in Erfahrung bringen, über welche Transportprotokolle die Bürgerkarten-Umgebung angesprochen werden kann. Für jede implementierte Bindung wird ein Bezeichner sowie optional eine Menge von bindungsspezifischen Parametern zurückgeliefert. Für Bezeichner und mögliche Parameter siehe Dokument Bindung an Transportprotokolle.
   
• Unterstützte Protokollversionen des Security-Layer: Damit kann die Applikation ersehen, welche Protokollversionen des Security-Layer die Bürgerkartenumgebung unterstützt. Als Bezeichner einer Protokollversion sind dabei die ersten beiden Ziffern der Version der jeweils zu Grunde liegenden Schnittstellenspezifikation zu verwenden; für die durch diese Spezifikation beschriebene Protokollversion als etwa "1.1".

<sl11:GetPropertiesResponse>
  <sl11:ViewerMediaType>text/plain</sl11:ViewerMediaType>
  <sl11:ViewerMediaType>text/html+truml</sl11:ViewerMediaType>
  <sl11:XMLSignatureTransform>http://www.w3.org/TR/2001/REC-xml-c14n-20010315</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/2001/10/xml-exc-c14n#</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/2001/10/xml-exc-c14n#WithComments</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/2000/09/xmldsig#base64</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/TR/1999/REC-xpath-19991116</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/2002/06/xmldsig-filter2</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/2000/09/xmldsig#enveloped-signature</sl11:XMLSignatureTransform>
  <sl11:XMLSignatureTransform>http://www.w3.org/TR/1999/REC-xslt-19991116</sl11:XMLSignatureTransform>
  <sl11:KeyboxIdentifier>SecureSignatureKeypair</sl11:KeyboxIdentifier>
  <sl11:KeyboxIdentifier>CertifiedKeypair</sl11:KeyboxIdentifier>
  <sl11:Binding Identifier="TCP/IP"/>
  <sl11:Binding Identifier="HTTP"/>
  <sl11:ProtocolVersion>1.0</sl11:ProtocolVersion>
  <sl11:ProtocolVersion>1.1</sl11:ProtocolVersion>
</sl11:GetPropertiesResponse>

6.2 Abfrage des Tokenstatus

Der Security-Layer sieht die Möglichkeit vor, den Status des verwendeten Bürgerkarten-Tokens abzufragen. Mögliche Stati sind dabei ready (Token vorhanden und initialisiert) oder removed (kein Token vorhanden).

6.2.1 Anfrage

Enthält der Befehl keine Parameter, liefert die Bürgerkarten-Umgebung in der Antwort sofort den aktuellen Status des verwendeten Bürgerkarten-Tokens zurück.

Optional kann die Anfrage jedoch die beiden Elemente sl10:TokenStatus und sl10:MaxDelay enthalten. In einem solchen Fall gibt sl10:TokenStatus den von der Applikation gewünschten Status des Bürgerkarten-Tokens an, und sl10:MaxDelay die längste Zeitspanne in Sekunden, um die die Bürgerkarten-Umgebung die Antwort auf diese Anfrage bis zum Eintritt des gewünschten Zustandes verzögern soll.

<sl10:GetStatusRequest>
  <sl10:TokenStatus>ready</sl10:TokenStatus>
  <sl10:MaxDelay>60</sl10:MaxDelay>
</sl10:GetStatusRequest>

6.2.2 Antwort

Die Antwort enthält den aktuellen Status des Tokens (entweder ready oder removed).

<sl10:GetStatusResponse>
  <sl10:TokenStatus>removed</sl10:TokenStatus>
</sl10:GetStatusResponse>

7 Fehlerbehandlung

Sollte innerhalb der Bürgerkarten-Umgebung ein Fehler auftreten, der die korrekte Beantwortung einer Anfrage verhindert, wird anstatt der zur Anfrage gehörenden Antwort eine Fehler-Antwort an die Applikation zurückgeschickt.

Die Datenstruktur der Fehler-Antwort besteht aus einem maschinenlesbaren Fehlercode (sl10:Code), sowie optional aus weiterführender Information (sl10:Info), die an dieser Stelle nicht näher spezifiziert wird. Vorstellbar wäre etwa eine klartextliche Erläuterung des Fehlers, oder eine XML-Struktur mit nähren Informationen zum aufgetretenen Fehler.

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

7.1 Fehlercodes

Siehe eigenes Dokument " Security-Layer zur Bürgerkarte - Fehlercodes".

8. Glossar

Referenz-Eingangsdaten

Jene Daten, die sich aus der Auflösung der im Attribut URI der dsig:Reference angegebenen URI ergeben. Sind für die dsig:Reference Transformationen angegeben, werden diese Daten als Eingangsdaten zur Berechnung der ersten Transformation verwendet. Sind keine Transformationen spezifiziert, gleichen die Referenz-Eingangsdaten den Hash-Eingangsdaten.

Hash-Eingangsdaten

Jene Daten, die für die Berechnung des Hash-Wertes für eine dsig:Reference verwendet werden. Sind für die dsig:Reference Transformationen angegeben, entsprechen diese Daten dem Ergebnis der letzten Transformation. Sind keine Transformationen spezifiziert, gleichen die Hash-Eingangsdaten den Referenz-Eingangsdaten.

Signaturmanifest

Siehe Beschreibung im Spezifikationstext.

Impliziter Transformationsparameter

Siehe Beschreibung im Spezifikationstext.

9. Referenzen

AnfBKU

Karlinger, Gregor: Anforderungen an die Bürgerkarten-Umgebung nach dem Konzept Bürgerkarte.Konvention zum e-Government Austria erarbeitet vom CIO des Bundes, Operative Unit. Öffentlicher Entwurf, Version 1.0.0, 12. Arpil 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.buergerkarte.at/konzept/spezifikation/20020412/.

CMS

Hously, R.: RFC 2630: Cryptographic Message Syntax (CMS). IETF Request For Comment, Juni 1999. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/rfc/rfc2630.txt.

DH-RSA

Rescorla, E.: RFC 2631: Diffie-Hellman Key Agreement Method. IETF Request For Comment, Juni 1999. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/rfc/rfc2631.txt

ESS-S/MIME

Hoffman, P.: RFC 2634: Enhanced Security Services for S/MIME. IETF Request For Comment, Juni 1999. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/rfc/rfc2634.txt.

ETSIXML

European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.1.1. Technical Specification, Februar 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://pda.etsi.org/pda/home.asp?wki_id=12532.

ETSICMS

European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signature Formats, v1.3.1. Technical Specification, Februar 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://pda.etsi.org/pda/home.asp?wki_id=12533.

IEEE1363

IEEE: IEEE Standard P1363: Standard Specifications for Public Key Cryptography, 2000.

KEYWORDS

Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment, März 1997. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/rfc/rfc2119.txt.

MIME

Freed, N. und Borenstein, N.: RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types. IETF Request For Comment, November 1996. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/rfc/rfc2046.txt.

MEDIATYPE

Internet Assigned Numbers Authority (IANA): Protocol Numbers and Assignment Services: Media Types Directory. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.isi.edu/in-notes/iana/assignments/media-types/.

PKCS#12

RSA Laboratories: PKCS#12 v1.0: Personal Information Exchange Syntax, Juni 1999. Abgerufen aus dem World Wide Web am 31. August 2002 unter ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf

XMLDSIG

Eastlake, Donald, Reagle, Joseph und Solo, David: XML-Signature Syntax and Processing. W3C Recommendation, Februar 2002. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.

XML

Bray, Tim, Paoli, Jean, Sperberg-McQueen, C.M. und Maler, Eve: Extensible Markup Language (XML) 1.0 (Second Edition). W3C Recommendation, Oktober 2000. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2000/REC-xml-20001006.

XMLTYPE

Murata, M., St.Laurent, S., und Kohn, D.: RFC 3023: XML Media Types. IETF Request For Comment, Jänner 2001. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.ietf.org/rfc/rfc3023.txt.

XMLNS

Bray, Tim, Hollander, Dave und Layman, Andrew: Namespaces in XML. W3C Recommendation, January 1999. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/1999/REC-xml-names-19990114/.

XPath

Clark, James und DeRose, Steven: XML Path Language. W3C Recommendation, November 1999. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/1999/REC-xpath-19991116.

XML-Schema

Thompson, Henry S., Beech, David, Maloney, Murray und Mendelson, Noah: XML Schema Part 1: Structures. W3C Recommendation, Mai 2001. Abgerufen aus dem World Wide Web am 31. August 2002 unter http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/.

10. Historie

Version 1.1.0 vom 31.08.2002: Veränderungen zu Version 1.0.3

• sl10:CreateCMSSignatureResponse:
  • Empfehlung für die Kodierung der Zertifikatskette auf CertificateSet eingeschränkt.
• sl11:VerifyCMSSignatureRequest:
  • Attribut Signatories zur Spezifizierung der zu prüfenden Signaturen bei mehreren in der CMS-Signatur angegebene Signatoren hinzugefügt.
• sl11:VerifyCMSSignatureResponse:
  • Erweiterung der Kardinalität der Sequenz (SignerInfo, SignatureCheck, CertificateCheck) auf 1..oo, um CMS-Signaturen mit mehreren Signatoren zu unterstützen.
  • Hinzufügen der Empfehlung, dass die Bürgerkarten-Umgebung zur Überprüfung älterer Signaturen die ggf. vorhandenen Signaturattribute CompleteCertificateRefs, CompleteRevocationRefs, CertificateValues, RevocationsValues nach [ETSICMS] auswerten können soll.
  • Beim Ergebnis der Prüfung der Signaturprüfdaten wird nun zwischen der Sperre und dem Widerruf eines Zertifkats der Zertifikatskette unterschieden (Fehlercodes 4 und 5).
  • Bei den Informationen zum Signator wird nun auch zurückgeliefert, ob das Signatorzertifikat qualifiziert ist.
  • Empfehlung für die Kodierung der Zertifikatskette auf die Mechanismen von XMLDSIG geändert (X509Data, RetrievalMethod).
• sl11:CreateXMLSignatureRequest:
  • Element sl11:SignatureInfo hinzugefügt, um das Erstellen von Enveloped Signatures zu ermöglichen.
  • Beispiel entsprechend korrigiert.
• sl11:CreateXMLSignatureResponse:
  • Beispiel entsprechend des geänderten Anfragebeispiels abgeändert.
• sl11:VerifyXMLSignatureRequest:
  • Grammatik für Element sl11:SignatureEnvironment verallgemeinert, um auch XML-Dokumente mit DTDs angeben zu können.
  • Beschreibung der Ergänzungsobjekte verallgemeinert.
  • Beispiel entsprechend den Änderungen in sl11:SignatureEnvironment korrigiert.
• sl11:VerifyXMLSignatureResponse:
  • Erweiterung des Resultats für die Signaturprüfung um die Angabe, welche Referenzen der Signatur gegebenenfalls nicht validiert werden konnten.
  • Erweiterung des Resultats für die Prüfung des Signaturmanifests, welche Referenzen des Manifests gegebenenfalls nicht validiert werden konnten.
  • Einführung der Prüfung von gewöhnlichen Manifesten, die in der zu prüfenden Signatur referenziert werden.
  • Hinzufügen der Empfehlung, dass die Bürgerkarten-Umgebung zur Überprüfung älterer Signaturen die ggf. vorhandenen Signaturattribute etsi:CompleteCertificateRefs, etsi:CompleteRevocationRefs, etsi:CertificateValues, etsi:RevocationsValues nach [ETSIXML] auswerten können soll.
  • Beim Ergebnis der Prüfung der Signaturprüfdaten wird nun zwischen der Sperre und dem Widerruf eines Zertifkats der Zertifikatskette unterschieden (Fehlercodes 4 und 5).
  • Bei den Informationen zum Signator wird nun auch zurückgeliefert, ob das Signatorzertifikat qualifiziert ist.
• sl10:CreateSessionKeyRequest, sl10:CreateSessionkeyResponse:
  • Befehle entfernt.
• sl11:GetPropertiesResponse:
  • Kardinalitäten der einzelnen Umgebungsparameter im Schema auf 1..oo gelockert, um bei zukünftigen Änderungen nicht den Namespace des Befehls ändern zu müssen.
  • Any-Platzhalter für zukünftige Umgebungsparameter aufgenommen, um bei zukünftigen Änderungen nicht den Namespace des Befehls ändern zu müssen.
  • Neuen Umgebungsparamter sl11:ProtocolVersion aufgenommen