Logo BMÖLS Open Interfaces
für das eGovernment
Logo A-SIT

Security-Layer für das Konzept Bürgerkarte

Schnittstellenspezifikation


Dokumenteninformation

Bezeichnung Schnittstellenspezifikation des Security-Layers der Bürgerkarte
Kurzbezeichnung Schnittstellenspezifikation Security-Layer
Version 1.0.3
Datum 31. 08. 2002
Dokumentklasse Konvention
Dokumentstadium Öffentlicher Entwurf
Kurzbeschreibung Das vorliegende Dokument spezifiziert die Schnittstelle zwischen einer Implementation des Security-Layers (Bürgerkarten-Umgebung) und einer darauf zugreifenden Applikation.
Autoren Arno Hollosi (arno.hollosi@cio.gv.at)
Gregor Karlinger (gregor.karlinger@cio.gv.at)
Arbeitsgruppe BMÖLS, CIO des Bundes, Operative Unit
© Diese Spezifikation wird von A-SIT und dem BMÖLS zur Verfügung gestellt. Die Verwendung ohne Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. Eine Erweiterung der Spezifikation ist erlaubt, jedoch muss dies eindeutig gekennzeichnet sein, und es muss die erweiterte Spezifikation frei zur Verfügung gestellt werden.

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. Erzeugen eines Sitzungszertifikats
    1. Anfrage
    2. Antwort
  6. Aushandeln eines symmetrischen Geheimnisses
    1. Anfrage
    2. Antwort
    3. Anmerkungen zur Funktionsweise
  7. Abfrage von Eigenschaften
    1. Abfrage der Umgebungseigenschaften
      1. Anfrage
      2. Antwort
    2. Abfrage des Tokenstatus
      1. Anfrage
      2. Antwort
  8. Fehlerbehandlung
    1. Fehlercodes
  9. Glossar
  10. Referenzen
  11. 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.

Zusammen mit der vorliegenden Schnittstellenspezifikation bildet das zugehörige 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:

Präfix
Namenraum
Erläuterung
dsig http://www.w3.org/2000/09/xmldsig# Elemente aus [XMLDSIG]
etsi http://uri.etsi.org/01903/v1.1.1# Elemente aus [ETSIXML]
sl http://www.buergerkarte.at/namespaces/securitylayer/20020225# Elemente dieser Spezifikation

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 (sl: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 (sl:KeyboxIdentifier) angegeben werden. Bezeichner aller verfügbaren Schlüssel können mit Hilfe des Befehls sl:GetPropertiesRequest von der Bürgerkarten-Umgebung abgefragt werden.

Informationen zum Datenobjekt

Schließlich enthält die Signaturanfrage einen Behälter sl:DataObject, der das zu signierende Datenobjekt (sl:Content), sowie Metainformationen (sl: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 (sl: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 sl:Content die base64-kodierten Daten, oder das Element sl: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.

<sl:CreateCMSSignatureRequest Structure="enveloping">
<sl:KeyboxIdentifier>Bezeichner der Key-Box</sl:KeyboxIdentifier>
<sl:DataObject>
<sl:MetaInfo>
<sl:MimeType>text/plain</sl:MimeType>
</sl:MetaInfo>
<sl:Content Reference="http://examples.org/myText.txt">
<!--Entweder base64-codierter Inhalt oder gesetztes Reference-Attribut-->
</sl:Content>
</sl:DataObject>
</sl:CreateCMSSignatureRequest>
Beispiel: Anfrage zur Erzeugung einer Signatur nach [CMS]

2.1.2 Antwort

Die Antwort besteht aus dem Element sl: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 (sl:MetaInfo) zu verwenden, die in der Anfrage im Behälter für das Datenobjekt (sl:DataObject) angegeben wurden.

Für das Element sl:MimeType aus sl:MetaInfo muss ein erstes Feld contentDescription in ContentHints verwendet werden; ist das Element sl:Description aus sl: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] sowie das unsignierte Signaturattribut CompleteCertificateRefs nach [ETSICMS].

<sl:CreateCMSSignatureResponse>
<sl:CMSSignature>
<!--CMS-Signatur in base64-kodierter Form-->
</sl:CMSSignature>
</sl:CreateCMSSignatureResponse>
Beispiel: Antwort auf die Anfrage zur Erzeugung einer Signatur nach [CMS]

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 (sl:KeyboxIdentifier) angegeben werden. Bezeichner aller verfügbaren Schlüssel können mit Hilfe des Befehls sl: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 (sl:DataObjectInfo) , der Informationen für die Anfertigung der Signatur sowie für die gegebenenfalls notwendige Anzeige im Trusted Viewer enthält. sl: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 (sl:DataObject). In Abhängigkeit des oben besprochenen Attributs Structure) sind der Inhalt von sl:DataObject sowie sein Attribut Reference wie folgt zu verwenden:

Struktur Möglichkeit Beschreibung
"enveloping" A

Das Attribut Reference wird nicht verwendet, der Inhalt von sl:DataObject repräsentiert das Datenobjekt. Ist das Datenobjekt XML-kodiert (Verwendung des Elements sl:XMLContent in sl:DataObject), muss es als geparstes XML in die Signaturstruktur eingebunden werden.

B Das Attribut Reference enthält eine URI, die von der Bürgerkarten-Umgebung aufgelöst werden muss, um das Datenobjekt zu erhalten. Der Inhalt von sl:DataObject bleibt leer. Handelt es sich bei dem so referenzierten Datenobjekt um XML-Daten, ist es sinnvoll, das Datenobjekt als geparstes XML in die Signaturstruktur einzubinden. Die Bürgerkarten-Umgebung soll daher bei der Auflösung Informationen des Transportprotokolls auswerten, um das eventuelle Vorliegen von XML-Daten herauszufinden. Für eine URI, die als Protokoll http oder https aufweist, muss dazu die Information im HTTP-Header (Content-type) ausgewertet werden.
"detached" C Das Attribut Reference enthält eine URI, die von der Bürgerkarten-Umgebung aufgelöst werden muss, um das Datenobjekt zu erhalten. Darüber hinaus wird diese URI auch für die Kodierung der Referenz auf das Datenobjekt als Bestandteil der XML-Signatur verwendet (Attribut URI im Element dsig:Reference). Der Inhalt von sl:DataObject bleibt leer.
D Das Attribut Reference enthält eine URI, die von der Bürgerkarten-Umgebung für die Kodierung der Referenz auf das Datenobjekt als Bestandteil der XML-Signatur verwendet wird (Attribut URI im Element dsig:Reference). Der Inhalt von sl:DataObject repräsentiert das Datenobjekt.

Hinweis: Soll der Inhalt von sl: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 (sl:Base64Content) oder als XML kodiert (sl:XMLContent) angegeben werden. Bei der Kodierung als XML kann für sl: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 sl:DataObjectInfo einen oder mehrere Transformationswege für das Datenobjekt (sl: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 (sl:FinalDataMetaInfo). Jedenfalls ist der Mime-Type (siehe [MIME]) anzugeben (sl:MimeType), zusätzlich darf eine Referenz auf eine Beschreibung dieser Daten angegeben werden (sl: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 können schließlich im Behälter sl:DataObjectInfo Ergänzungsobjekte (sl:Supplements) angegeben werden. 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 sl:FinalDataMetaInfo), andererseits aus dem eigentlichen Daten (sl: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 sl: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 sl:Supplement innerhalb jenes sl:DataObjectInfo vorkommt, das den gerade berechneten Transformationsprozess spezifiziert. Ist diese Prüfung erfolgreich, sind die in diesem sl: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 sl:Supplement eines anderen sl:DataObjectInfo vorkommt, das im Befehl zur Erzeugung der XML-Signatur spezifiziert wurde. Die einzelnen sl:DataObjectInfo-Elemente sind dabei in jener Reihenfolge zu untersuchen, in der Sie im Befehl angegeben wurden. Die im ersten so gefundenen sl:Supplement angegebenen Daten sind als Ergebnis der Auflösung zu verwenden. Wird kein sl:Supplement gefunden, ist mit Schritt 3 fortzufahren.
  3. Auflösung der Referenz.
<sl:CreateXMLSignatureRequest>
<sl:KeyboxIdentifier>Bezeichner der Keybox</sl:KeyboxIdentifier>
<sl:DataObjectInfo Structure="detached">
<sl:DataObject Reference="http://examples.org/myDataObject.xml"/>
<!--Erster Transformationsweg: Keine Transformationen-->
<sl:TransformsInfo>
<sl:FinalDataMetaInfo>
<sl:MimeType>text/xml</sl:MimeType>
</sl:FinalDataMetaInfo>
</sl:TransformsInfo>
<!--Zweiter Transformationsweg:Stylesheet-Transformation in eine HTML-Datei-->
<sl: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>
<sl:FinalDataMetaInfo>
<sl:MimeType>text/html</sl:MimeType>
</sl:FinalDataMetaInfo>
</sl:TransformsInfo>
</sl:DataObjectInfo>
</sl:CreateXMLSignatureRequest>
Beispiel: Anfrage zur Erzeugung einer Signatur nach [XMLDSIG]

2.2.2 Antwort

Die Antwort enthält die nach [XMLDSIG] kodierte elektronische Signatur.

Signierte Daten

Für jedes in der Anfrage mittels Behälter (sl: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üssen fü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 Signaturmanifestsdü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 (sl:DataObject), ist ein Signaturattribut aufzunehmen, das die dazu spezifizierten Metainformationen (sl:FinalDataMetaInfo) enthält.

Dazu ist das signierte Signaturattribut etsi:DataObjectFormat nach [ETSIXML] zu verwenden. Das Element sl:MimeType aus sl:FinalDataMetaInfo entspricht dabei dem Element etsi:MimeType aus etsi:DataObjectFormat, das optional vorhandene Element sl:Description aus sl: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 unsignierten Signaturattribute etsi:CompleteCertificateRefs und etsi:CertificateValues nach [ETSIXML].

<sl:CreateXMLSignatureResponse>
  <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
    <!-- Signatur nach XMLDSIG und ETSIXML -->
  </dsig:Signature>
</sl:CreateXMLSignatureResponse>
Beispiel: Antwort auf die Anfrage zur Erzeugung einer Signatur nach [XMLDSIG]

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.

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 (sl: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] (sl: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 sl:DataObject mitübergeben werden.

In sl:DataObject können zunächst Metainformationen (sl: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 sl:Content die base64-kodierten Daten, oder das Element sl:Content ist leer, hat aber sein Attribut Reference gesetzt. Die Bürgerkarten-Umgebung versucht im letzten Fall, die in diesem Attribut angegebene URI aufzulösen, um so das signierte Datenobjekt zu erhalten.

Beispiel

<sl:VerifyCMSSignatureRequest>
<sl:DateTime>2001-12-31T10:00:00</sl:DateTime>
<sl:CMSSignature>
<!--CMS-Signatur in base64-kodierter Form-->
</sl:CMSSignature>
<sl:DataObject>
<sl:Content Reference="http://examples.org/myText.txt">
<!--Entweder base64-codierter Inhalt oder gesetztes Reference-Attribut-->
</sl:Content>
</sl:DataObject>
</sl:VerifyCMSSignatureRequest>
Beispiel: Anfrage zur Prüfung einer Signatur nach [CMS]

3.1.2 Antwort

Enthält die zu überprüfende Signatur mehrere Signatoren (Strukturelement SignerInfo), muss die Signatur des ersten Signators geprüft werden.

Die Antwort auf die Anfrage zur Prüfung einer Signatur nach [CMS] enthält zunächst in sl:SignerInfo Informationen zum X.509-Zertifikat des Signators. sl:SignerInfo muss aus genau einem Element dsig:X509Data bestehen, das mindestens folgende zwei Elemente enthalten muss :

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 (sl:SignatureCheck) sowie für die Prüfung der Signaturprüfdaten (sl:CertificateCheck).

Beide Ergebnisse besitzen die gleiche Struktur: Das Element sl:Code enthält das Ergebnis der Prüfung in maschinenlesbarer Form, das optionale Element sl: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 sl:Code in sl:SignatureCheck definiert:

sl:Code Bedeutung
0 Die Überprüfung des Werts der Signatur konnte erfolgreich durchgeführt werden.
1 Bei der Überprüfung des Werts der Signatur ist ein Fehler aufgetreten.

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.

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

sl:Code Bedeutung
0 Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Jedes Zertifikat dieser Kette ist zum in der Anfrage angegebenen Prüfzeitpunkt gültig.
1 Es konnte keine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konstruiert werden.
2 Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Für zumindest ein Zertifikat dieser Kette fällt der Prüfzeitpunkt nicht in das Gültigkeitsintervall.
3 Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Für alle Zertifikate dieser Kette fällt der Prüfzeitpunkt in das jeweilige Gültigkeitsintervall. Für zumindest ein Zertifikat konnte der Zertifikatstatus nicht festgestellt werden.
4 Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Für alle Zertifikate dieser Kette fällt der Prüfzeitpunkt in das jeweilige Gültigkeitsintervall. Zumindest ein Zertifikat ist zum Prüfzeitpunkt widerrufen oder gesperrt.

Beispiel

<sl:VerifyCMSSignatureResponse>
<sl: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>
</sl:SignerInfo>
<sl:SignatureCheck>
<sl:Code>0</sl:Code>
</sl:SignatureCheck>
<sl:CertificateCheck>
<sl:Code>3</sl:Code>
<sl:Info>Der Status des Signaturzertifikats konnte nicht geprüft werden.</sl:Info>
</sl:CertificateCheck>
</sl:VerifyCMSSignatureResponse>
Beispiel: Antwort auf die Anfrage zur Prüfung einer Signatur nach [CMS]

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 (sl: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] (sl:SignatureInfo).

Zunächst enthält SignatureInfo einen Container, indem ein einzelnes XML-Element zu übergeben ist, das die zu überprüfende Signatur enthält (SignatureEnvironment). Soll ein ganzes XML-Dokument übergeben werden, entspricht der Inhalt von SignatureEnvironment dem Wurzelelement des Dokuments.

Weiters enthält SignatureInfo mit SignatureLocation einen Ausdruck nach [XPath], mit dem anzugeben ist, wo sich innerhalb von SignatureEnvironment die zu überprüfende Signatur befindet. Als Kontext-Knoten für die Auswertung des XPath-Ausdrucks ist das in SignatureEnvironment angegebene Element zu verwenden. Der XPath-Ausdruck darf nicht absolut sein, also nicht mit "/" beginnen. Werden im XPath-Ausdruck Namespace-Prefixes verwendet, müssen die entsprechenden Namespace-Deklarationen im Kontext des Elements SignatureLocation bekannt sein.

Ergänzungsobjekte

Optional können in der Anfrage schließlich Ergänzungsobjekte übergeben werden. Ein Ergänzungsobjekt ist ein Datenobjekt, das entweder in einem dsig:Reference Element der Signatur selbst (in dsig:SignedInfo) oder in einem dsig:Reference Element eines Signaturmanifests (dsig:Manifest) referenziert wird.

Für ein Ergänzungsobjekt (sl:Supplement) dürfen zunächst Metainformationen (sl:MetaInfo) angegeben werden (Mime-Type sowie eine Referenz auf eine Beschreibung des Ergänzungsobjekts). Danach folgen die verpflichtenden Angaben zum Inhalt des Objekts (sl: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 sl: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

<sl:VerifyXMLSignatureRequest>
<sl:DateTime>2001-12-31T10:00:00</sl:DateTime>
<sl:SignatureInfo>
<sl:SignatureEnvironment>
<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>
</sl:SignatureEnvironment>
<sl:SignatureLocation xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"> ./dsig:Signature </sl:SignatureLocation>
</sl:SignatureInfo>
<sl:Supplement>
<!--Wert des Attributs "Reference" entspricht dem Wert des Attributs "URI"-->
<!--im Element "Reference" der Signatur-->
<sl:Content Reference="http://www.example.org/myDataObject.xml">
<!--Base64-Kodierung des referenzierten Datenobjekts (symbolischer Wert)-->
<sl:Base64Content>deiOeHbGRdjh</sl:Base64Content>
</sl:Content>
</sl:Supplement>
</sl:VerifyXMLSignatureRequest>

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

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 (sl:SignerInfo). Konnte bei der Überprüfung ein dem öffentlichen Schlüssel entsprechendes Signatorzertifikat nach X.509 identifiziert werden, muss sl:SignerInfo zumindest folgende Informationen enthalten:

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 (sl:SignatureCheck), für die Prüfung des Signaturmanifests (sl:SignatureManifestCheck) sowie für die Prüfung der Signaturprüfdaten (sl:CertificateCheck).

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

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 sl:Code in sl:SignatureCheck definiert:

sl:Code Bedeutung
0 Die Überprüfung der Hash-Werte und des Werts der Signatur konnte erfolgreich durchgeführt werden.
1 Bei der Überprüfung des Hash-Werts zumindest einer dsig:Reference der Signatur ist ein Fehler aufgetreten. Der Wert der Signatur (dsig:SignatureValue) wurde nicht überprüft.
2 Die Überprüfung der Hash-Werte konnte erfolgreich durchgeführt werden. Beim Überprüfen des Werts der Signatur (dsig:SignatureValue) ist jedoch ein Fehler aufgetreten.

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 sl:Code in sl:SignatureManifestCheck definiert:

sl:Code Bedeutung
0 Die Signatur enthält eine Referenz auf das Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Für jede dsig:Reference des Signaturmanifests konnte der Hash-Wert erfolgreich überprüft werden.
1 Die Signatur enthält keine Referenz auf ein Signaturmanifest.
2 Die Signatur enthält zwar eine Referenz auf das Signaturmanifest, dieses entspricht vom Umfang her jedoch nicht den Anforderungen dieser Spezifikation. Die Hash-Werte der im Signaturmanifest vorhandenen dsig:Reference-Elemente wurden nicht überprüft.
3 Die Signatur enthält eine Referenz auf das Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Bei der Überprüfung des Hash-Werts zumindest einer dsig:Reference des Signaturmanifests ist jedoch ein Fehler aufgetreten.

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.

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

Beispiel

<sl:VerifyXMLSignatureResponse>
<sl: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>
</sl:SignerInfo>
<sl:SignatureCheck>
<sl:Code>0</sl:Code>
</sl:SignatureCheck>
<sl:SignatureManifestCheck>
<sl:Code>1</sl:Code>
<sl:Info>Die Signatur enthält keine Referenz auf ein Signaturmanifest.</sl:Info>
</sl:SignatureManifestCheck>
<sl:CertificateCheck>
<sl:Code>3</sl:Code>
<sl:Info>Der Status des Signaturzertifikats konnte nicht geprüft werden.</sl:Info>
</sl:CertificateCheck>
</sl: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:

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 sl:BinaryFileParameters bleibt leer. Die Applikation kann jedoch mit Hilfe des boolschen Attributs sl:ContentIsXMLEntity in sl:BinaryFileParameters der Bürgerkarten-Umgebung einen Hinweis geben, ob die in der Binärdatei gespeicherten Daten als XML interpretierbar sind.

<sl:BinaryFileParameters ContentIsXMLEntity="true"/>
Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Binärdatei

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

<sl:BinaryFileData>
<sl:XMLContent>
<FirstName>Hermann</FirstName>
<LastName>Muster</LastName>
</sl:XMLContent>
</sl:BinaryFileData>
Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Binärdatei

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 (sl:BinaryFileParameters/sl:Base64Content), oder als geparstes XML (sl:BinaryFileParameters/sl:XMLContent). Bei der Kodierung als XML kann für sl: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.

<sl:BinaryFileParameters>
<sl:Base64Content>f3G7Tw9hH</sl:Base64Content>
</sl:BinaryFileParameters>
Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Binärdatei

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 sl:ReadKeys in sl:AssocArrayParameters) liefert die Menge jener Schlüssel, die einem spezifizierten Suchstring (Attribut SearchString in sl: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.

<sl:AssocArrayParameters>
<sl:ReadKeys SearchString="*"/>
</sl:AssocArrayParameters>
Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Assoziatives Array - Schlüsselabfrage

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

<sl:AssocArrayData>
<sl:Key>MyFirstCertificate</sl:Key>
<sl:Key>MySecondCertificate</sl:Key>
<sl:Key>AnotherCertificate</sl:Key>
</sl:AssocArrayData>
Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Assoziative Array - Schlüsselabfrage
Lesen von Schlüsseln und Werten

Der zweite Lesezugriff (Element sl:ReadPairs in sl:AssocArrayParameters) ist ähnlich dem ersten, jedoch werden nicht nur die dem Suchausdruck (Attribut SearchString in sl: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 sl: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.

<sl:AssocArrayParameters>
<sl:ReadPairs SearchString="My*Certificate"/>
</sl:AssocArrayParameters>
Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Assoziatives Array - Abfrage von Schlüssel/Wert-Paaren

Die Antwortdaten (sl:AssocArrayData) enthalten die gefundenen Schlüssel/Wert-Paare (Elemente sl:Pair). In sl:Pair befindet sich der Schlüssel als Attribut Key, sowie der zugehörige Wert als geparstes XML (sl:XMLContent) oder base64-kodiert (sl: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.

<sl:AssocArrayData>
<sl:Pair Key="MyFirstCertificate">
<sl:Base64Content>aD3Hrt3dv</sl:Base64Content>
</sl:Pair>
<sl:Pair Key="MySecondCertificate">
<sl:Base64Content>4Gzt73Dcnf</sl:Base64Content>
</sl:Pair>
</sl:AssocArrayData>
Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Assoziative Array - Abfrage von Schlüssel/Wert-Paaren
Lesen des Werts zu einem Schlüssel

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

<sl:AssocArrayParameters>
<sl:ReadValue Key="MyFirstCertificate"/>
</sl:AssocArrayParameters>
Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Assoziatives Array - Wertabfrage
Die Antwortdaten (sl:AssocArrayData) enthalten den angegebenen Schlüssel (Attribut Key in sl:Pair) sowie den dazugehörigen Wert (Inhalt von sl:Pair). Die Kodierung des Werts hängt vom oben besprochenen Attribut ValueIsXMLEntity ab. Sie erfolgt entweder als geparstes XML (sl:XMLContent) oder als base64 (sl:Base64Content).
<sl:AssocArrayData>
<sl:Pair Key="MyFirstCertificate">
<sl:Base64Content>4Gzt73Dcnf</sl:Base64Content>
</sl:Pair>
</sl:AssocArrayData>
Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Assoziative Array - Wertabfrage

Update-Parameter und Antwortdaten

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

Änderung eines Schlüssels

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

<sl:AssocArrayParameters>
<sl:UpdateKey Key="OldKeyname" NewKey="NewKeyname"/> </sl:AssocArrayParameters>
Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Assoziatives Array - Schlüssel verändern
Änderung eines Wertes

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

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

<sl:AssocArrayParameters>
<sl:UpdateValue Key="AnotherCertificate">
<sl:Base64Content>45G3DFV6dfde</sl:Base64Content>
</sl:UpdateValue>
</sl:AssocArrayParameters>
Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Assoziatives Array - Wert verändern
Löschen eines Schlüssel/Wert-Paares

Die dritte mögliche Anfrage (Element sl:DeletePair in sl: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 sl:DeletePair angegeben werden.

<sl:AssocArrayParameters>
<sl:DeletePair Key="AnotherCertificate"/>
</sl:AssocArrayParameters>
Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Assoziatives Array - Wertepaar löschen

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.

<sl:InfoboxAvailableRequest/>
Beispiel: Anfrage zur Abfrage der verfügbaren Infoboxen

4.2.2 Antwort

Die Antwort enthält eine Liste von Bezeichnern (Elemente sl: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.

<sl:InfoboxAvailableResponse>
<sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
<sl:InfoboxIdentifier>IdentityLink</sl:InfoboxIdentifier>
<sl:InfoboxIdentifier>Mandates</sl:InfoboxIdentifier>
</sl:InfoboxAvailableResponse>
Beispiel: Antwort auf die Abfrage der verfügbaren Infoboxen

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 (Elementsl:InfoboxIdentifier). Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem Kommando sl: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.

<sl:InfoboxReadRequest>
<sl:InfoboxIdentifier>IdentityLink</sl:InfoboxIdentifier>
<sl:BinaryFileParameters/>
</sl:InfoboxReadRequest>
Beispiel: Anfrage zum Lesen von Daten einer Infobox vom Typ Binärdatei

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.

<sl:InfoboxReadResponse>
<sl:BinaryFileData>
<sl:Base64Content>dkfEFGNdedd543r</sl:Base64Content>
</sl:BinaryFileData>
</sl:InfoboxReadResponse>
Beispiel: Antwort auf die Anfrage zum Lesen von Daten einer Infobox vom Typ Binärdatei

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 (Elementsl:InfoboxIdentifier). Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem Kommando sl: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.

<sl:InfoboxUpdateRequest>
<sl:InfoboxIdentifier>Certificates</sl:InfoboxIdentifier>
<sl:AssocArrayParameters>
<sl:UpdateValue Key="AnotherCertificate">
<sl:Base64Content>45G3DFV6dfde</sl:Base64Content>
</sl:UpdateValue>
</sl:AssocArrayParameters>
</sl:InfoboxUpdateRequest>
Beispiel: Anfrage zur Veränderung von Daten einer Infobox vom Typ Assoziatives Array - Wert verändern

4.4.2 Antwort

Die Antwort ist ein leeres Kommando ohne Parameter.

<sl:InfoboxUpdateResponse/>
Beispiel: Antwort auf die Anfrage zur Änderung von Daten in einer Infobox

5 Erzeugen eines Sitzungszertifikats

Zur Unterstützung des Aufbaus einer vertraulichen und authentifizierten Kommunikation bietet die Bürgerkarten-Umgebung die Möglichkeit, ein Schlüsselpaar zusammen mit einem zugehörigen Zertifikat zu generieren. Der öffentliche Schlüssel dieses Schlüsselpaares wird mit Signaturerstellungsdaten der Bürgerkarte zertifiziert, um Authentifikation zu ermöglichen.

5.1 Anfrage

Die Anfrage enthält zunächst den Bezeichner jener Keybox, in der die zur Zertifizierung zu verwendenden Signaturerstellungsdaten abgelegt sind. Weiters ist ein Passwort anzugeben, mit dem die in der Antwort zurückgelieferte, nach [PKCS#12] kodierte Datenstruktur verschlüsselt werden soll. Schließlich wird in der Anfrage noch die Gültigkeitsdauer des zu erzeugenden Zertifikats spezifiziert.

<sl:CreateSessionKeyRequest>
  <sl:KeyboxIdentifier>Bezeichner der Keybox</sl:KeyboxIdentifier>
<sl:Password>PKCS#12 Passwort</sl:Password>
<sl:Minutes>Gültigkeitsdauer des Zertifikates in Minuten</sl:Minutes> </sl:CreateSessionKeyRequest>
Beispiel: Anfrage zur Erzeugung von Session-Keys und Session-Zertifikat

5.2 Antwort

Die Antwort enthält eine Datenstruktur nach [PKCS#12], welche das generierte Schlüsselpaar zusammen mit dem erzeugten Zertifikat passwortgeschützt kapselt. Zusätzlich ist das Zertifikat auch ohne Passwortschutz als DER-kodiertes X509 Zertifikat ein zweites Mal enthalten.

<sl:CreateSessionKeyResponse>
  <sl:PKCS12Object>PKCS#12 Datenstruktur (Base64 kodiert)</sl:PKCS12Object>
<sl:Certificate>Session-Zertifikat (Base64 kodiert)</sl:Certificate> </sl:CreateSessionKeyResponse>
Beispiel: Antwort auf die Anfrage zur Erzeugung von Session-Keys und Session-Zertifikat

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 sl:KeyboxIdentifier).

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

<sl:GetSymmetricSecretRequest>
  <sl:KeyboxIdentifier>Bezeichner der Keybox</sl: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> </sl:GetSymmetricSecretRequest>
Beispiel: Anfrage zur Berechnung eines symmetrischen Geheimnisses basierend auf Diffie-Hellman

5.2 Antwort

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

<GetSymmetricSecretResponse>
  <SymmetricSecretValue>Mastersecret (Base64 kodiert)</SymmetricSecretValue>
</GetSymmetricSecrectResponse>
Beispiel: Antwort auf die Anfrage zur Berechnung eines symmetrischen Geheimnisses

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 sl: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 sl: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.

<sl:GetPropertiesRequest/>
Beispiel: Anfrage zu Umgebungseigenschaften

6.1.2 Antwort

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

<sl:GetPropertiesResponse>
<sl:ViewerMediaType>text/plain</sl:ViewerMediaType>
<sl:ViewerMediaType>text/html+truml</sl:ViewerMediaType>
<sl:XMLSignatureTransform>http://www.w3.org/TR/2001/REC-xml-c14n-20010315</sl:XMLSignatureTransform>
<sl:XMLSignatureTransform>http://www.w3.org/2000/09/xmldsig#base64</sl:XMLSignatureTransform>
<sl:XMLSignatureTransform>http://www.w3.org/TR/1999/REC-xpath-19991116</sl:XMLSignatureTransform>
<sl:XMLSignatureTransform>http://www.w3.org/2000/09/xmldsig#enveloped-signature</sl:XMLSignatureTransform>
<sl:XMLSignatureTransform>http://www.w3.org/TR/1999/REC-xslt-19991116</sl:XMLSignatureTransform>
<sl:KeyboxIdentifier>SecureSignatureKeypair</sl:KeyboxIdentifier>
<sl:KeyboxIdentifier>CertifiedKeypair</sl:KeyboxIdentifier>
<sl:Binding Identifier="TCP/IP"/>
<sl:Binding Identifier="HTTP"/>
</sl:GetPropertiesResponse>
Beispiel: Antwort auf die Anfrage zu Umgebungseigenschaften

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 sl:TokenStatus und sl:MaxDelay enthalten. In einem solchen Fall gibt sl:TokenStatus den von der Applikation gewünschten Status des Bürgerkarten-Tokens an, und sl: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.

<sl:GetStatusRequest>
<sl:TokenStatus>ready</sl:TokenStatus>
<sl:MaxDelay>60</sl:MaxDelay>
</sl:GetStatusRequest>
Beispiel: Anfrage zum Tokenstatus

6.2.2 Antwort

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

<sl:GetStatusResponse>
<sl:TokenStatus>removed</sl:TokenStatus>
</sl:GetStatusResponse>
Beispiel: Antwort auf die Anfrage zum Tokenstatus

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 (sl:Code), sowie optional aus weiterführender Information (sl: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.

<sl:ErrorResponse>
  <sl:Code>1152</sl:Code>
  <sl:Info>Read Access denied.</sl:Info>
</sl:ErrorResponse>
Beispiel: Fehler-Antwort auf die Anfrage zum Lesen des Inhalts einer Infobox

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.0.3 vom 31.08.2002

Version 1.0.1 vom 24.04.2002