für das E-Government
|
Open Interfaces für das E-Government |
|
Die österreichische Bürgerkarte
Applikationsschnittstelle Security-Layer
Dokumenteninformation
Bezeichnung |
Die Applikationsschnittstelle Security-Layer zur österreichischen Bürgerkarte |
Kurzbezeichnung |
Applikationsschnittstelle Security-Layer |
Version |
1.2.2 |
Datum |
01. 03. 2005 |
Dokumentklasse |
Konvention |
Dokumentstadium |
Empfehlung |
Kurzbeschreibung |
Das vorliegende Dokument spezifiziert die Schnittstelle zwischen Applikation und Bürgerkarten-Umgebung. |
Autoren |
Arno Hollosi |
Arbeitsgruppe |
Bundeskanzleramt, Stabsstelle IKT-Strategie des Bundes, Technik und Standards |
© |
Diese Spezifikation wird von A-SIT und dem Bundeskanzleramt 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
Dieses Dokument legt die Schnittstelle Security-Layer fest. Das ist jene Schnittstelle, über die eine Applikation auf Funktionen der Bürgerkarte zugreift, um beispielsweise eine elektronische Signatur zu erstellen oder vom Datenspeicher der Bürgerkarten-Umgebung zu lesen.
Für die Festlegung, welche der in diesem Dokument beschriebenen Schnittstellenbefehle von einer Bürgerkarten-Umgebung jedenfalls zur Verfügung gestellt werden müssen, siehe Minimale Umsetzung des Security-Layers.
Für Vorgaben an die Benutzer-Schnittstelle bei der Ausführung eines in diesem Dokument beschriebenen Schnittstellenbefehls siehe Anforderungen an die Benutzer-Schnittstelle.
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 Protokoll-Elemente für diese XML-Schnittstellenbefehle sind als [XML-Schema] in Core-1.2.xsd spezifiziert. Zusammen mit der vorliegenden Schnittstellenspezifikation bildet dieses XML-Schema die normative Quelle für die Protokoll-Elemente.
Zur besseren Lesbarkeit wurde in diesem Dokument auf geschlechtsneutrale Formulierungen verzichtet. Die verwendeten Formulierungen richten sich jedoch ausdrücklich an beide Geschlechter.
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] |
xenc |
http://www.w3.org/2001/04/xmlenc# |
Elemente aus [XMLEnc] |
etsi |
http://uri.etsi.org/01903/v1.2.2# |
Elemente aus [ETSIXML] |
sl |
http://www.buergerkarte.at/namespaces/securitylayer/1.2# |
Elemente dieser Spezifikation |
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.
Die Schnittstelle Security-Layer unterstützt zwei mögliche Formate für die Erzeugung einer elektronischen Signatur: [CMS] und [XMLDSIG].
Mit einer Signatur nach [CMS] kann genau ein Datenobjekt signiert werden.
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").
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.
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 in der Bürgerkarten-Umgebung enthält.
Jedenfalls an Metainformation spezifiziert werden muss der Mime-Type (siehe [MIME]) des zu signierenden Datenobjekts. Weiters darf eine verbale Beschreibung des Datenobjekts angegeben werden (sl:Description). Schließlich dürfen noch weitere beliebige Elemente zu diesen Metainformationen hinzugefügt werden.
Anmerkung: Soll das zu signierende Datenobjekt von der Bürgerkarten-Umgebung als Text interpretiert werden, muss die Applikation den Mime-Type text/plain verwenden; soll es im Sinne des Standard-Anzeigeformats des Security-Layer interpretiert werden, muss die Applikation den Mime-Type application/xhtml+xml verwenden. Siehe dazu auch Minimale Umsetzung des Security-Layers.
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.
Die Antwort besteht aus dem Element sl:CMSSignature, welches die erzeugte Signatur nach [CMS] in base64-kodierter Form enthält. Für detailierte Vorgaben für die zu erzeugende Signatur hinsichtlich Digest-Algorithmen, Signatur-Algorithen und Schlüsselinformationen siehe Minimale Umsetzung des Security-Layers.
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.
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.
Schließlich muss ein Signaturattribut SigningTime nach [ETSICMS] in die [CMS]-Signatur aufgenommen werden, das den vom Signator behaupteten Zeitpunkt der Signaturerstellung enthält.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.1.
Die Signatur nach [XMLDSIG] erlaubt im Gegensatz zur Signatur nach [CMS] auch die Signierung mehrerer Datenobjekte mittels einer einzigen Signatur.
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.
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 in der Bürgerkarten-Umgebung 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").
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 für Inhalt von sl:DataObject sowie sein Attribut Reference folgende Kombinationen zulässig (alle anderen Kombinationen sind ungültig):
| Struktur | Möglichkeit | Beschreibung |
"enveloping" |
A(1,2,3) | Das Attribut |
| B(2,4) | 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 Text oder 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 Text oder 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(1,5) | 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. |
(1) Soll der Inhalt von sl:Dataobject zur expliziten Angabe des Datenobjekts verwendet werden, stehen drei unterschiedliche Arten der Kodierung zur Verfügung:
sl:Base64Content: Enthält das Datenobjekt in base64-kodierter Form.sl:XMLContent: Enthält das Datenobjekt als XML kodiert. Wenn es aus Sicht der Applikation wichtig ist, dass die Bürgerkarten-Umgebung Whitespace innerhalb des übergebenen XML nicht verändert, kann für sl:XMLContent das Attribut xml:space mit dem Wert preserve versehen werden. Das Inhaltsmodell von sl:XMLContent ist so definiert, dass es eine beliebige Mischung aus Text und XML-Markup erlaubt. Das schließt ausdrücklich auch reinen Text mit ein. Eine gültige Instanz von sl:XMLContent ist also beispielsweise auch <sl:XMLContent>Text</sl:XMLContent>. sl:LocRefContent: Enthält eine Referenz auf das Datenobjekt, die von der Bürgerkarten-Umgebung aufzulösen ist, um das Datenobjekt zu erhalten.(2) Die Einbindung eines im Fall A oder B übergebenen Datenobjekts in die XML-Signatur bzw. die Referenzierung auf dieses in die Signatur eingebundene Datenobjekt aus dem zugehörigen dsig:Reference Element der XML-Signatur muss so erfolgen, dass ausschließlich die im Request in sl:DataObject übergebenen Daten signiert werden.Wird beispielsweise das Datenobjekt als Inhalt eines dsig:Object Elements in die XML-Signatur eingebunden, darf dieses dsig:Object Containerelement nicht mitsigniert werden, sondern lediglich sein Inhalt.
(3) Wenn das Datenobjekt base64-kodiert vorliegt (Verwendung des Elements sl:Base64Content in sl:DataObject), müssen jedenfalls die Base64-dekodierten Daten signiert werden. Kann die Bürgerkarten-Umgebung die Base64-dekodierten Daten nicht direkt in das dsig:Object integrieren (weil darin Zeichen enthalten sind, die nicht als XML-Text darstellbar sind), muss sie stattdessen die base64-kodierten Daten integrieren und eine Base64 Transformation als erste Transformation im zugehörigen dsig:Reference verwenden.
(4) Handelt es sich beim referenzierten Datenobjekt weder um Text noch um XML-Daten, oder wird das Datenobjekt entgegen der Empfehlung nicht auf Vorliegen von Text oder XML-Daten geprüft, muss es in base64-kodierter Form in die Signaturstruktur eingebunden werden. Signiert werden muss jedoch das ursprüngliche Datenobjekt; es ist daher in der auf das eingebundene Datenobjekt verweisenden dsig:Reference eine Base64 Transformation zu verwenden.
(5) Handelt es sich bei der in Reference übergebenen URI um eine interne URI gemäß [URI], Abschnitt 4.2 (Same-document Reference), so ist sie auf jenes XML-Dokument zu beziehen, in das die Signatur eingebettet werden soll (und welches in sl:SignatureEnvironment übergeben wird - vergleiche Abschnitt Informationen zum Signaturdokument).
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 in 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 eine verbale Beschreibung dieser Daten angegeben werden (sl:Description).
Anmerkung: Soll das zu signierende Datenobjekt von der Bürgerkarten-Umgebung als Text interpretiert werden, muss die Applikation den Mime-Type text/plain verwenden; soll es im Sinne des Standard-Anzeigeformats des Security-Layer interpretiert werden, muss die Applikation den Mime-Type application/xhtml+xml verwenden. Siehe dazu auch Minimale Umsetzung des Security-Layers.
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.
Optional werden schließlich im Behälter sl:DataObjectInfo Ergänzungsobjekte (sl:Supplements) angegeben. Solche können übergeben werden, damit Daten, die im Rahmen des Transformationsprozesses für das Datenobjekt oder für die Anzeige benötigt werden, nicht von der Bürgerkarten-Umgebung aufgelöst werden müssen. Das Datenobjekt selbst darf jedoch nicht als Ergänzungsobjekt übergeben werden.
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:
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.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.Soll die zu erstellende Signatur in ein bestehendes XML-Dokument eingebettet werden, findet sich in der Signaturanfrage schließlich der Behälter sl:SignatureInfo. Bei Fehlen dieses Behälters ist die Signatur nirgends einzubetten, sondern direkt als Ergebnis der Anfrage (siehe Abschnitt 2.2.2) zurückzuliefern.
sl:SignatureInfo enthält zunächst Angaben zum Signaturdokument, in das die Signatur eingebettet werden soll (sl: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 sl:SignatureEnvironment angegeben.
Die direkte Einbettung kann auf zwei Arten erfolgen: Entweder wird das XML-Dokument base64 kodiert und als Text des Kindelements sl:Base64Content integriert, oder aber das Wurzelelement des XML-Dokuments wird direkt als einziges Kind des Kindelements sl: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 sl: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.
Das darauffolgende Element sl: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 sl:SignatureEnvironment spezifizierten XML-Dokuments zu verwenden. Werden im XPath-Ausdruck Namespace-Prefixes verwendet, müssen die entsprechenden Namespace-Deklarationen im Kontext des Elements sl: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.
Zusätzlich können schließlich Ergänzungsobjekte (sl:Supplements) spezifiziert werden, die in Zusammenhang mit dem Signaturdokument stehen.
Beispielsweise könnte im Signaturdokument, das in sl: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 sl: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 sl:FinalDataMetaInfo in Abschnitt 2.2.1, Transformationswege), 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).
Die Antwort enthält die nach [XMLDSIG] kodierte elektronische Signatur. Wurde in der Anfrage ein sl:SignatureInfo Element angegeben, enthält die Antwort als einziges Kind das in sl:SignatureInfo angegebene Dokument mit der darin integrierten Signatur. Ansonsten enthält die Antwort direkt die erzeugte Signatur.
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.
Um den korrekten Zusammenhang zwischen den Referenz-Eingangsdaten sowie den Hash-Eingangsdaten später jederzeit überprüfen zu können, müssen die impliziten Transformationsparameter aller in die Signatur aufzunehmenden Datenobjekte in ein einziges Signaturmanifest aufgenommen werden. Liegen keine impliziten Transformationsparameter vor, darf das Signaturmanifest nicht erstellt werden.
Ein impliziter Transformationsparameter ist in diesem Zusammenhang ein Datum, das von der Bürgerkarten-Umgebung zur Berechnung der Transformationen für ein zu signierendes Datenobjekt verwendet wurde, jedoch nicht explizit als Parameter im entsprechenden Transformationsobjekt (dsig:Transform) aufscheint.
Als (derzeit einzig bekanntes) 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 im Falle der Signaturprüfung zur Auflösung verwendet werden würde.
Die Eingangsdaten für die Berechnung des Hash-Wertes über einen implizten Transformationsparameter ergeben sich wie folgt:
sl:Supplement/sl:Content/sl:Base64Content) vorliegen. Die Base64-dekodierten Daten bilden dann die Eingangsdaten für die Hash-Berechnung.sl:Supplement/sl:Content/sl:XMLContent) vorliegen. Aus diesen Daten ist entsprechend [XMLDSIG, Abschnitt 4.3.3.3] eine XPath-Knotenmenge zu erzeugen. Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung.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/securitylayer/20020225#SignatureManifest
Die nachfolgend angegebenen Informationen müssen in die Signatur unter Verwendung von Signaturattributen nach [ETSIXML] aufgenommen werden. Die Einbindung der Signaturattribute in die Signatur muss als als Direct Incorporation entsprechend den Hinweisen in den Abschnitten 6.3 und insbesondere 6.3.1 von [ETSIXML] erfolgen. Das in Abschnitt 6.3.1 erwähnte Attribut Type muss verwendet werden.
Für jedes in der Anfrage spezifizierte zu signierende Datenobjekt (sl:DataObject), istmuss ein Signaturattribut aufgenommen werden, 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.
Weiters muss ein Signaturattribut mitaufgenommen werden, 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.
Schließlich muss ein Signaturattribut mitaufgenommen werden, das den vom Signator behaupteten Zeitpunkt der Signaturerstellung enthält. Dazu ist das signierte Signaturattribut etsi:SigningTime nach [ETSIXML] zu verwenden.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.1.
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.
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.
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 (sl:DateTime). Fehlt diese Angabe, muss die Bürgerkarten-Umgebung wie folgt zur Bestimmung des Prüfzeitpunkts vorgehen:
SigningTime nach [ETSICMS], das den vom Signator behaupteten Zeitpunkt der Signaturerstellung enthält, ist die darin genannte Zeit als Prüfzeitpunkt zu verwenden.Nachfolgend enthält die Anfrage die zu überprüfende Signatur nach [CMS] (sl:CMSSignature) in base64-kodierter Form.
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 letztenFall, die in diesem Attribut angegebene URI aufzulösen, um so das signierte Datenobjekt zu erhalten.
Für jede in der Anfrage spezifizierte zu prüfende Signatur werden in der Antwort folgende Informationen zurückgeliefert:
Zunächst werden in in sl:SignerInfo Informationen zum X.509-Zertifikat des Signators angegeben. sl: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 sl:QualifiedCertificate enthalten, wenn das Signatorzertifikat als qualifiziert anzusehen ist. Dazu müssen folgende Bedingungen erfüllt sein:
qcStatements (siehe [QCert], 3.2.5) vorhanden sein.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 (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.
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. |
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. Die Prüfung der Signaturprüfdaten darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.
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 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. |
| 5 | 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. Kein Zertifikat dieser Kette ist zum Prüfzeitpunkt widerrufen. Zumindest ein Zertifikat ist zum Prüfzeitpunkt gesperrt. |
| 99 | Die Prüfung der Signaturprüfdaten wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. |
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.2.
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.
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, muss die Bürgerkarten-Umgebung wie folgt zur Bestimmung des Prüfzeitpunkts vorgehen:
etsi:SigningTime nach [ETSIXML], das den vom Signator behaupteten Zeitpunkt der Signaturerstellung enthält, ist die darin genannte Zeit als Prüfzeitpunkt zu verwenden.Nachfolgend enthält die Anfrage Angaben zur zu überprüfenden Signatur nach [XMLDSIG] (sl:SignatureInfo).
Zunächst enhält sl:SignatureInfo Angaben zum XML-Dokument, das die zu überprüfende Signatur inkludiert (sl: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 sl:SignatureEnvironment angegeben.
Die direkte Einbettung kann auf zwei Arten erfolgen: Entweder wird das XML-Dokument base64 kodiert und als Text des Kindelements sl:Base64Content integriert, oder aber das Wurzelelement des XML-Dokuments wird direkt als einziges Kind des Kindelements sl: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 sl: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 sl:SignatureInfo mit sl:SignatureLocation einen Ausdruck nach [XPath], mit dem anzugeben ist, wo sich die zu überprüfende Signatur innerhalb des mittels sl:SignatureEnvironment spezifizierten XML-Dokuments befindet. Als Kontext-Knoten für die Auswertung des XPath-Ausdrucks ist der Dokument-Knoten des in sl:SignatureEnvironment spezifizierten XML-Dokuments zu verwenden. Werden im XPath-Ausdruck Namespace-Prefixes verwendet, müssen die entsprechenden Namespace-Deklarationen im Kontext des Elements sl:SignatureLocation bekannt sein.
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:
dsig:Reference Elements der Signatur referenziert wird; dsig:Reference Elements der Signatur (z. B. ein Stylesheet, der im Basis-Stylesheet einer XSLT-Transformation 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.
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:
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 sl:QualifiedCertificate enthalten, wenn das Signatorzertifikat als qualifiziert anzusehen ist. Dazu müssen folgende Bedingungen erfüllt 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 (sl:SignatureCheck), für die Prüfung des Signaturmanifests (sl:SignatureManifestCheck), für die Überprüfung ggf. vorhandener weiterer Manifeste (sl:XMLDSIGManifestCheck), sowie für die Prüfung der Signaturprüfdaten (sl:CertificateCheck).
Alle vier Ergebnisse besitzen eine ähnliche Struktur: Das Element sl:Code enthält das Ergebnis der Prüfung in maschinenlesbarer Form, das Element sl:Info kann genauereZusatzinfomationen enthalten (siehe dazu die folgenden Unterabschnitte).
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. |
Das optionale Element sl: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 sl:Code den Wert 1, wird darüber hinaus empfohlen, ein sl:FailedReference-Elemente als Kind von sl:Info zur Kennzeichnung des ersten dsig:Reference-Elements anzugeben, bei dem die Überprüfung des Hash-Wertes einen Fehler ergeben hat. Der Inhalt von sl:FailedReference, eine positive Ganzzahl, gibt dabei die laufende Nummer der fehlerhaften dsig:Reference innerhalb von dsig:SignedInfo an. Zusätzliche sl:FailedReference-Elemente dürfen angegeben werden, um Fehler bei der Überprüfung weiterer dsig:Reference-Elemente anzuzeigen.
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. Die Prüfung der Signaturprüfdaten darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.
Folgende Werte sind für den Inhalt des Elements sl:Code in sl:SignatureManifestCheck definiert:
sl:Code |
Bedeutung |
| 0 | Dieser Code hat eine der folgenden Bedeutungen:
|
| 1 | Die Signatur enthält keine Referenz auf das notwendige 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. |
| 99 | Die Prüfung des Signaturmanifests wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. |
Das optionale Element sl: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 sl:Code den Wert 3, wird darüber hinaus empfohlen, ein bzw. mehrere sl:FailedReference-Elemente als Kinder von sl: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 sl:FailedReference-Elements, eine positive Ganzzahl, gibt dabei die laufende Nummer der fehlerhaften dsig:Reference innerhalb des Signaturmanifests an.
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 sl:XMLDSIGManifestCheck mit dem Ergebnis der Überprüfung des Manifests enthalten. Die Prüfung weiterer Manifeste darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.
Folgende Werte sind für den Inhalt des Elements sl:Code in sl:XMLDSIGManifestCheck definiert:
sl:Code |
Bedeutung |
| 0 | Für jede dsig:Reference des mittels sl:Info näher gekennzeichneten Manifests konnte der Hash-Wert erfolgreich überprüft werden. |
| 1 | Für zuminest eine dsig:Reference des mittels sl:Info näher gekennzeichneten Manifests konnte der Hash-Wert nicht erfolgreich überprüft werden. |
| 99 | Die Prüfung weiterer Manifeste wurde nicht durchgeführt, da bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist. |
Das verpflichtend anzugebende Element sl: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 sl:Code den Wert 1, müssen darüber hinaus ein bzw. mehrere sl:FailedReference-Elemente als Kinder von sl: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 sl:FailedReference-Elements, eine positive Ganzzahl, gibt dabei die laufende Nummer der fehlerhaften dsig:Reference innerhalb des Manifests an.
Weiters muss in sl:Info mittels des Elements sl:ReferringSignatureReference angegeben werden, auf welches in der Signatur referenzierte Manifest sich das Prüfungsergebnis bezieht. Der Inhalt von sl:ReferringSignatureReference, eine positive Ganzzahl, gibt dabei die laufende Nummer jener dsig:Reference innerhalb von dsig:SignedInfo an, welche auf das Manifest verweist.
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. Die Prüfung der Signaturprüfdaten darf unterbleiben, wenn bei der Prüfung der Gültigkeit der Signatur ein Fehler aufgetreten ist.
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 sl:Code in sl:CertificateCheck siehe Kapitel Prüfung der Signaturprüfdaten im Abschnitt über die Prüfung einer [CMS]-Signatur.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.2.
Die in diesem Abschnitt spezifizierten Befehle ermöglichen die Verschlüsselung eines der Bürgerkarten-Umgebung bekanntgegebenen Dokuments (oder auch mehrerer Dokumente, abhängig vom Nachrichtenformat). Die Verschlüsselung erfolgt je Empfänger mit einem von der Applikation angegebenen öffentlichen Schlüssel.
Dieser Befehl ermöglicht die Verschlüsselung von Daten als CMS-Nachricht mit EnvelopedData Inhalt nach dem Standard [CMS].
Zunächst enthält die Anfrage einen öffentlichen Schlüssel (sl:RecipientPublicKey) mit pro Empfänger, für den die Daten verschlüsselt werden sollen. Der öffentliche Schlüssel ist in sl:RecipientPublicKey als base64-kodiertes X.509-Zertifikat (sl:X509Certificate) enthalten.
Weiters werden mit sl:ToBeEncrypted die zu verschlüsselnden Daten sowie Metainformationen zu diesen Daten bekanntgegeben.
Jedenfalls an Metainformationen spezifiziert werden muss der Mime-Type (siehe [MIME]) der zu verschlüsselnden Daten (sl:ToBeEncrypted/sl:MetaInfo/sl:MimeType); diese Information benötigt die Bürgerkarten-Umgebung im Rahmen der gegebenenfalls vorzunehmenden Anzeige der zu verschlüsselnden Daten. Weiters darf eine verbale Beschreibung dieser Daten angegeben werden (sl:ToBeEncrypted/sl:MetaInfo/sl:Description).
Für die Angabe der eigentlichen zu verschlüsselnden Daten stehen zwei Möglichkeiten zur Verfügung:
sl:ToBeEncrypted/sl:Content/@Reference enthält die entsprechende URL, der Inhalt von sl:ToBeEncrypted bleibt leer.sl:ToBeEncrypted/sl:Content enthält die Daten in base64-kodierter Form, sl:ToBeEncrypted/sl:Content/@Reference wird nicht verwendet.Das Attribut sl:EncryptCMSRequest/@ReturnBinaryResult kann schlielich optional angegeben werden, um die Art der Antwort auf die Anfrage zu steuern (vgl. Abschnitt 4.1.2 Antwort).
Die Bürgerkarten-Umgebung erstellt aus den Angaben der Anfrage eine CMS-Nachricht mit EnvelopedData Inhalt. Dabei muss sie folgende Vorgaben einhalten:
Die so erzeugte CMS-Nachricht wird von der Bürgerkarten-Umgebung in der Antwort zurückgeschickt. Die grundsätzliche Gestalt der Antwort ist abhängig vom Attribut sl:EncryptCMSRequest/@ReturnBinaryResult der Anfrage.
Ist das Attribut sl:EncryptCMSRequest/@ReturnBinaryResult entweder nicht oder auf den Wert false gesetzt, liefert die Bürgerkarten-Umgebung eine XML-Antwort zurück.
sl:EncryptCMSResponse/sl:CMSMessage enthält die erzeugte CMS-Nachricht in base64-kodierter Form.
Ist das Attribut sl:EncryptCMSRequest/@ReturnBinaryResult hingegen auf den Wert true gesetzt, liefert die Bürgerkarten-Umgebung keine XML-Antwort, sondern direkt und ohne weitere Kodierung die CMS-Nachricht als Antwort auf die Anfrage zurück.
Bietet das Transportprotokoll die Möglichkeit, den Mime-Type zu spezifizieren, muss die Bürgerkarten-Umgebung den Mime-Type auf application/pkcs7-mime; smime-type=enveloped-data setzen.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.3.
Dieser Befehl ermöglicht die Verschlüsselung von Daten als XML-Dokument nach dem Standard [XMLEnc].
Zunächst enthält die Anfrage einen öffentlichen Schlüssel (sl:RecipientPublicKey) mit pro Empfänger, für den die Daten verschlüsselt werden sollen. Der öffentliche Schlüssel ist in sl:RecipientPublicKey entweder direkt (ds:KeyValue) oder als base64-kodiertes X.509-Zertifikat (sl:X509Certificate) enthalten.
Weiters werden mit sl:ToBeEncrypted die zu verschlüsselnden Daten bekanntgegeben. Dieses Element muss zumindest einmal vorhanden sein, und enthält Informationen über die zu verschlüsselnden Daten auf eine von drei möglichen Arten:
sl:Element: Ein Element eines bestehenden XML-Dokuments wird von der Bürgerkarten-Umgebung verschlüsselt und durch ein entsprechendes Element xenc:EncryptedData ersetzt. sl:Element/@Selector enthält einen Ausdruck nach [XPath], mit dem das zu verschlüsselnde Element innerhalb des bestehenden XML-Dokuments eindeutig ausgewählt wird. Der Kontextknoten für die Evaluierung des Ausdrucks ist dabei der Dokument-Knoten des XML-Dokuments. Namenraum-Präfixe, die im Ausdruck verwendet werden, müssen im Kontext von sl:Element/@Selector bekannt sein. Wird sl:Element/@EncDataReference angegeben, dürfen die verschlüsselten Daten von der Bürgerkarten-Umgebung nicht base64-kodiert in das entsprechende Element xenc:EncrpytedData aufgenommen, sondern müssen stattdessen referenziert werden. Als Referenz muss dabei die in sl:Element/@EncDataReference angegebene URI verwendet werden. sl:Element verwendet, muss ein bestehendes XML-Dokument angegeben werden (siehe unten).sl:ElementContent: Der Inhalt eines Elements eines bestehenden XML-Dokuments wird von der Bürgerkarten-Umgebung verschlüsselt und durch ein entsprechendes Element xenc:EncryptedData ersetzt. Die Bedeutung der Attribute sl:ElementContent/@Selector und sl:ElementContent/@EncDataReference ist die gleiche wie jene der entsprechenden Attribute in sl:Element.sl:ElementContent verwendet, muss ein bestehendes XML-Dokument angegeben werden (siehe unten). sl:New: Beliebige Daten sollen verschlüsselt und als Element xenc:EncryptedData in ein bestehendes oder neues XML-Dokument eingefügt werden. Der Ort, an dem das erzeugte xenc:EncryptedData in das XML-Dokument eingefügt werden soll, wird durch die Attribute sl:New/@ParentSelector und sl:New/@NodeCount angegeben. sl:New/@ParentSelector selektiert das Eltern-Element des zukünftigen xenc:EncryptedData mittels eines Ausdrucks nach [XPath]; der Kontextknoten für die Evaluierung des Ausdrucks ist dabei der Dokument-Knoten des XML-Dokuments. Namenraum-Präfixe, die im Ausdruck verwendet werden, müssen im Kontext von sl:New/@ParentSelector bekannt sein. sl:New/@NodeCount enthält die Angabe, als wievielter Knoten xenc:EncryptedData ins Eltern-Element einzufügen ist, wobei mit Null zu zählen begonnen wird. Die zu verschlüsselnden Daten sowie Metainformationen dazu werden als Inhalt von sl:New angegeben. Jedenfalls an Metainformationen spezifiziert werden muss der Mime-Type (siehe [MIME]) der zu verschlüsselnden Daten (sl:New/sl:MetaInfo/sl:MimeType); diese Information benötigt die Bürgerkarten-Umgebung im Rahmen der gegebenenfalls vorzunehmenden Anzeige der zu verschlüsselnden Daten. Weiters darf eine verbale Beschreibung dieser Daten angegeben werden (sl:New/sl:MetaInfo/sl:Description). Für die Angabe der eigentlichen zu verschlüsselnden Daten stehen drei Möglichkeiten zur Verfügung: sl:New/sl:Content/sl:Base64Content enthält die zu verschlüsselnden Daten in base64-kodierter Form; diese müssen von der Bürgerkarten-Umgebung dekodiert werden, bevor die Verschlüsselung durchgeführt wird. sl:New/sl:Content/sl:XMLContent enthält die zu verschlüsselnden Daten als XML-Fragment. sl:new/sl:Content/sl:LocRefContent enthält eine Referenz, die von der Bürgerkarten-Umgebung aufgelöst werden muss, um zu den zu verschlüsselnden Daten zu gelangen. Die Bedeutung des Attributs sl:New/sl:Content/@EncDataReference ist die gleiche wie jene des entsprechenden Attributs in sl:Element.sl:New verwendet, jedoch kein bestehendes XML-Dokument angegeben (siehe unten), muss die Bürgerkarten-Umgebung ein neues XML-Dokument erzeugen. sl:New/@ParentSelector muss in diesem Fall den Dokument-Knoten auswählen (z.B. mit /), sl:New/@NodeCount den Wert 0 enthalten. sl:EncryptionInfo kann verwendet werden, um Angaben zu einem bestehenden XML-Dokument zu machen, in das die erzeugten Elemente xenc:EncryptedData eingefügt werden sollen (siehe oben). Wird sl:EncryptionInfo nicht angegeben, darf die Anfrage nur ein einziges Element sl:ToBeEncrypted enthalten; der Inhalt dieses einzigen Elements muss sl:New sein.
Mit sl:EncryptionInfo/sl:EncryptionEnvironment wird das XML-Dokument spezifiziert. Dazu stehen drei Möglichkeiten zur Verfügung: Soll das XML-Dokument referenziert und diese Referenz durch die Bürgerkarten-Umgebung aufgelöst werden, ist das Attribut sl:EncryptionEnvironment/@Reference zu verwenden. Der Inhalt von sl:EncryptionEnvironment bleibt in diesem Fall leer. Soll das XML-Dokument explizit angegeben werden, ist als Inhalt von sl:EncryptionEnvironment entweder sl:Base64Content oder sl:XMLContent zu verwenden; das Attribut sl:EncryptionEnvironment/@Reference bleibt in diesem Fall leer. sl:Base64Content enthält das XML-Dokument in base64-kodierter Form. sl:XMLContent enthält das XML-Dokument direkt.
Wird das Element sl:EncryptionInfo/sl:EncryptedKeyLocation angegeben, muss die Bürgerkarten-Umgebung die Informationen zu allen in der Anfrage spezifizierten öffentlichen Schlüsseln der Empfänger (sl:RecipientPublicKey) in ein bzw. mehrere Elemente xenc:EncryptedKey zusammenfassen, die aus allen erzeugten Elementen xenc:EncryptedData referenziert werden müssen (für genauere Informationen zum Aufbau von xenc:EncryptedKey bzw. zur Referenzierung siehe Antwort). sl:EncryptedKeyLocation/@ParentSelector selektiert das Eltern-Element des einzufügenden bzw. der einzufügenden xenc:EncryptedKey Elemente. sl:EncryptedKeyLocation/@NodeCount enthält die Angabe, als wievielter Knoten das erste xenc:EncryptedKey Element ins Eltern-Element einzgefügt werden muss, wobei mit Null zu zählen begonnen wird. Weitere xenc:EncryptedKey Elemente müssen ggf. unmittelbar nach dem ersten Element eingefügt werden.
Wird das Element nicht angegeben, muss die Bürgerkarten-Umgebung die Informationen zu allen in der Anfrage spezifizierten öffentlichen Schlüsseln der Empfänger in jedes einzelne erzeugte Element xenc:EncryptedData direkt als xenc:EncrpytedKey kodieren (für genauere Informationen zum Aufbau von xenc:EncryptedKey siehe Antwort).
Zusätzlich können schließlich Ergänzungsobjekte (sl:EncryptedInfo/sl:Supplement) spezifiziert werden, die in Zusammenhang mit dem bestehenden XML-Dokument stehen.
Beispielsweise könnte im XML-Dokument, das in sl:EncryptionEnvironment 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 XML-Dokument, handelt.
Ein weiteres Beispiel für die Verwendung eines Ergänzungsobjekts könnte ein XML-Schema sein, das im mittels sl:EncryptionEnvironment spezifizierten XML-Dokument unter Verwendung der in [XML-Schema] vorgeschlagenen Mechanismen referenziert wird.
Ein Ergänzungsobjekt besteht dabei einerseits aus optionalen Metainformationen (vergleiche sl:FinalDataMetaInfo in Abschnitt 2.2.1, Transformationswege), andererseits aus dem eigentlichen Daten (sl:Content): Das verpflichtend zu verwendende Attribut sl:Content/@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).
Für jede in der Anfrage enthaltene Anweisung, Daten zu verschlüsseln (sl:ToBeEncrypted) muss die Bürgerkarten-Umgebung ein Element xenc:EncryptedData erzeugen. Folgende Bedingungen müssen eingehalten werden:
sl:ToBeEncrypted/sl:Element bzw. sl:ToBeEncrypted/sl:ElementContent), muss das Attribut xenc:EncryptedData/@Type auf den Wert http://www.w3.org/2001/04/xmlenc#Element bzw. http://www.w3.org/2001/04/xmlenc#Content gesetzt werden. Ansonsten darf dieses Attribut nicht verwendet werden.xenc:EncryptedData/xenc:EncryptionMethod muss einer der in Minimale Umsetzung des Security-Layers, Abschnitt 7.1.1 gelisteten Algorithmen zur Datenverschlüsselung angegeben werden.xenc:EncryptedData/ds:KeyInfo muss von der Bürgerkarten-Umgebung verwendet werden und alle in der Anfrage angegebenen öffentlichen Schlüssel für den Schlüsseltransport referenzieren (falls in der Anfrage das Element sl:EncryptionInfo/sl:EncryptedKeyLocation verwendet wurde) bzw. enthalten (sonst). ds:KeyInfo pro in der Anfrage angegebenen öffentlichen Schüssel ein xenc:EncrypedKey Element verwenden. Dabei müssen folgende Bedingungen eingehalten werden:
xenc:EncryptedKey/xenc:EncryptionMethod muss einer der in Minimale Umsetzung des Security-Layers, Abschnitt 7.1.1 gelisteten Algorithmen zum Schlüsseltransport angegeben werden.xenc:EncryptedData/ds:KeyInfo muss von der Bürgerkarten-Umgebung verwendet werden und genau ein ds:KeyValue Element mit der Kodierung des öffentlichen Schlüssels enthalten.xenc:EncryptedData/xenc:CipherData/xenc:CipherValue enthält den verschlüsselten symmetrischen Schlüssel zur Datenverschlüsselung.ds:KeyInfo pro in der Anfrage angegebenen öffentlichen Schüssel ein ds:RetrievalMethod Element verwenden. Dabei müssen folgende Bedingungen eingehalten werden:
ds:RetrievalMethod/@Type muss auf den Wert http://www.w3.org/2001/04/xmlenc#EncryptedKey gesetzt werden.ds:RetrievalMethod/@URI muss auf das referenzierte xenc:EncryptedKey Element verweisen.xenc:EncryptedKey Element gelten die Bedingungen für die direkte Beinhaltung.xenc:EncryptedData/xenc:CipherData muss die mit dem symmetrischen Verschlüsselungsschlüssel verschlüsselten Daten referenzieren (wenn im entsprechenden sl:ToBeEncrypted Element der Anfrage wurde in sl:Element bzw. sl:ElementContent bzw. sl:New das Attribut EncDataReference gesetzt wurde) bzw. direkt beinhalten (sonst).xenc:CipherData/xenc:CipherReference verwenden.Dabei müssen folgende Bedingungen eingehalten werden:.
xenc:CipherReference/@URI muss auf den in sl:Element/@EncDataReference bzw. sl:ElementContent/@EncDataReference bzw. sl:New/@EncDataReference angegebenen Wert gesetzt werden.sl:EncryptedData Element zurückzuliefern. sl:EncryptedData/@EncDataReference muss auf den in sl:Element/@EncDataReference bzw. sl:ElementContent/@EncDataReference bzw. sl:New/@EncDataReference angegebenen Wert gesetzt werden.Wurde in der Anfrage ein XML-Dokument angegeben (sl:EncryptionInfo/sl:EncryptionEnvironment), muss die Bürgerkarten-Umgebung dieses XML-Dokument mit den folgenden Modifikationen in der Antwort als Inhalt von sl:EncryptXMLResponse/sl:EncryptionEnvironment zurückliefern:
sl:ToBeEncrypted/sl:Element) muss die Bürgerkarten-Umgebung das angegebene Element des XML-Dokuments durch das entsprechend erzeugte xenc:EncryptedData Element ersetzen.sl:ToBeEncrypted/sl:ElementContent) muss die Bürgerkarten-Umgebung den Inhalt des angegebenen Elements des XML-Dokuments durch das entsprechend erzeugte xenc:EncryptedData Element ersetzen.sl:ToBeEncrypted/sl:New) muss die Bürgerkarten-Umgebung das entsprechend erzeugte xenc:EncryptedData Element an der spezifizierten Position (sl:New/@ParentSelector, sl:New/@NodeCount) in das XML-Dokument einfügen.sl:EncryptionInfo/sl:EncryptedKeyLocation verwendet, muss die Bürgerkarten-Umgebung an der darin spezifzizierten Position xenc:EncryptedKey Elemente für allen in der Anfrage spezifizierten öffentlichen Schlüsseln der Empfänger einfügen.Wurde in der Anfrage kein XML-Dokument angegeben, muss die Bürgerkarten-Umgebung als Inhalt von sl:EncryptXMLResponse/sl:EncryptionEnvironment das für den in der Anfrage spezifizierten, zu verschlüsselnden neuen Inhalt (sl:ToBeEncrypted/sl:New) erzeugte xenc:EncryptedData Element zurückliefern.
Kann die Bürgerkarten-Umgebung die Verschlüsselung für zumindest ein in der Anfrage spezifiziertes Datum (sl:ToBeEcnrypted) nicht durchführen, muss die Bürgerkarten-Umgebung eine Fehler-Antwort (sl:ErrorResponse) liefern.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.3.
Die in diesem Abschnitt spezifizierten Befehle ermöglichen die Entschlüsselung eines an die Bürgerkarten-Umgebung übermittelten, in verschlüsselter Form vorliegenden Dokuments mittels eines in der Bürgerkarten-Umgebung verwalteten privaten Schlüssels.
Dieser Befehl ermöglicht die Entschlüsselung von CMS-Nachrichten mit EnvelopedData Inhalt, die nach dem Standard [CMS] vorliegen. Der Entschlüsselungs-Schlüssel muss dazu ein privater Schlüssel sein, der von der Bürgerkarten-Umgebung verwaltet wird.
Zunächst enthält die Anfrage sl:DecryptCMSRequest im Element sl:CMSMessage die CMS-Nachricht mit Enveloped Data Inhalt, welche entschlüsselt werden soll.
Optional können im Element sl:EncryptedContent Angaben zu den in EnvelopedData verschlüsselten Daten gemacht werden:
sl:EncryptedContent/sl:MetaInfo/sl:MimeType kann die Applikation den Mime-Type der verschlüsselten Daten angeben; diese Information muss von der Bürgerkarten-Umgebung im Falle einer Binäranwort zur Angabe des Mime-Types verwendet werden, falls dies im verwendeten Transportprotokoll vorgesehen ist. sl:EncryptedContent/sl:Content muss die Applikation den Wert des Feldes encryptedContent (also die verschlüsselten Daten) angeben, wenn dieses in der zu entschlüsselnden CMS-Nachricht nicht enthalten ist. Sie kann dazu entweder sl:Content/@Reference oder slContent/sl:Base64Content verwenden. sl:Content/@Reference enthält eine URL, welche die Bürgerkarten-Umgebung zur Erlangung der verschlüsselten Daten auflösen muss. slContent/sl:Base64Content enthält die verschlüsselten Daten in base64-kodierter Form.Was die Kennzeichnung des Datenverschlüsselungsschlüssels betrifft, darf die Bürgerkarten-Umgebung von folgenden Voraussetzungen ausgehen, die von der Applikation eingehalten werden müssen:
Für detaillierte Informationen, welche Algorithmen und URL-Protokolle eine Bürgerkarten-Umgebung im Zusammenhang mit der Entschlüsselung einer CMS-Nachricht beherrschen muss, siehe Minimale Umsetzung des Security-Layers, Abschnitt 6.2.
Das Attribut sl:DecryptCMSRequest/@ReturnResult kann schlie lich optional angegeben werden, um die Art der Antwort auf die Anfrage zu steuern (vgl. Abschnitt 5.1.2 Antwort).
Die grundsätzliche Gestalt der Antwort ist abhängig vom Attribut sl:DecryptCMSRequest/@ReturnResult der Anfrage.
Ist das Attribut sl:DecryptCMSRequest/@ReturnResult entweder nicht oder auf den Wert xml gesetzt, liefert die Bürgerkarten-Umgebung eine XML-Antwort zurück.
sl:DecryptCMSResponse/sl:DecryptedData enthält die mit Hilfe des in der CMS-Nachricht bezeichneten und in der Bürgerkarten-Umgebung vorhandenen Schlüsselpaares entschlüsselten Daten in base64-kodierter Form.
Ist das Attribut sl:DecryptCMSRequest/@ReturnResult hingegen auf den Wert binary gesetzt, liefert die Bürgerkarten-Umgebung keine XML-Antwort, sondern direkt und ohne weitere Kodierung die entschlüsselten Daten als Antwort auf die Anfrage zurück.
Bietet das Transportprotokoll die Möglichkeit, den Mime-Type zu spezifizieren, muss die Bürgerkarten-Umgebung die gegebenenfalls in der Anfrage gemachten Angaben (sl:EncryptedContent/sl:MetaInfo/sl:MimeType) verwenden.
Ist das Attribut sl:DecryptCMSRequest/@ReturnResult schließlich auf den Wert none gesetzt, liefert die Bürgerkarten-Umgebung eine leere Antwort (Element sl:DecryptCMSResponse ohne Inhalt) zurück. Mit dieser Option hat der Bürger die Möglichkeit, sich die entschlüsselten Daten über die Benutzer-Schnittstelle anzusehen und/oder zu speichern, ohne das sie im weiteren auch an die Applikation übermittelt werden.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.4.
Dieser Befehl ermöglicht die Entschlüsselung von XML-Dokumenten, die entweder zur Gänze oder in Teilen nach dem Standard [XMLEnc] verschlüsselt vorliegen. Der Entschlüsselungs-Schlüssel muss dazu ein privater Schlüssel sein, der von der Bürgerkarten-Umgebung verwaltet wird.
Zunächst enthält die Anfrage sl:DecryptXMLRequest im Element sl:EncryptedContent Informationen zu dem nach [XMLEnc] verschlüsselten XML-Dokument, das entschlüsselt werden soll. Dieses Dokument kann entweder mittels Angabe einer URL referenziert, oder aber direkt in den Befehl eingebettet werden:
sl:EncryptedContent/@Reference zu verwenden. Reference muss eine von der Bürgerkarten-Umgebung auflösbare URL sein. Der Inhalt von sl:EncryptedContent bleibt leer.sl:EncryptedContent/sl:Base64Content bzw. sl:EncryptedContent/sl:XMLContent. Wird die erste Variante verwendet, enthält sl:Base64Content das base64-kodierte XML-Dokument, in der zweiten Variante enthält sl:XMLContent als einzigen Knoten das Wurzel-Element des XML-Dokuments. sl:EncryptedContent/@Reference findet in beiden Fällen keine Verwendung. Das zu entschlüsselnde XML-Dokument darf prinzipiell beliebig viele Elemente mit verschlüsseltem Inhalt (xenc:EncryptedData) enthalten. Welche dieser verschlüsselten Elemente von der Bürgerkarten-Umgebung tatsächlich entschlüsselt werden sollen, ist mit dem Element sl:EncrElemsSelector anzugeben. Sein Inhalt spezifiziert einen Ausdruck nach [XPath], dessen Auswertung eine Knotenmenge mit beliebig vielen Elementen xenc:EncryptedData ergeben muss. Als Kontextknoten für die Auswertung des Ausdrucks muss die Bürgerkarten-Umgebung den Dokument-Knoten des zu entschlüsselnden XML-Dokuments verwenden.
Was die Kennzeichnung des Datenverschlüsselungsschlüssels betrifft, darf die Bürgerkarten-Umgebung von folgenden Voraussetzungen ausgehen, die von der Applikation eingehalten werden müssen:
xenc:EncryptedData/ds:KeyInfo mittels ds:KeyName, ds:KeyValue oder ds:X509Data bezeichnet werden. ds:KeyName muss den Bezeichner eines in der Bürgerkarten-Umgebung verfügbaren Schlüssels enthalten. Bezeichner aller verfügbaren Schlüssel können mit Hilfe des Befehls GetProperties von der Bürgerkarten-Umgebung abgefragt werden. ds:KeyValue muss den zur Verschlüsselung verwendeten öffentlichen Schlüssel enthalten. ds:X509Data muss genau ein X.509-Zertifikat (ds:X509Certificate) enthalten, das den zur Verschlüsselung verwendeten öffentlichen Schlüssel zertifiziert.xenc:EncryptedData/ds:KeyInfo entweder ein Element xenc:EncryptedKey enthalten, oder aber zumindest ein Element ds:RetrievalMethod, das auf ein Element xenc:EncryptedKey verweist. xenc:EncryptedKey muss die Angaben zum verwendeten symmetrischen Schlüssel enthalten und in ds:KeyInfo auf einem der oben erwähnten Wege den zur Verschlüsselung des symmetrischen Schlüssels verwendeten, in der Bürgerkarten-Umgebung verfügbaren Schlüssel bezeichnen.Für detaillierte Informationen, welche Algorithmen, Schlüsselhinweise und URL-Protokolle eine Bürgerkarten-Umgebung im Zusammenhang mit der Entschlüsselung eines XML-Dokuments beherrschen muss, siehe Minimale Umsetzung des Security-Layers, Abschnitt 7.2.
Optional können Ergänzungsobjekte (sl:Supplements) spezifiziert werden; das sind Datenobjekte, auf die im Verschlüsselungsdokument verwiesen wird. Beispiele dafür sind
xenc:EncryptedData verwiesen wird;
xenc:EncryptedKey verwiesen wird;xenc:EncryptedKey, auf das in einem Element ds:RetrievalMethod verwiesen 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 im Verschlüsselungsdokument relative Verweise vorhanden sind.
Das Attribut sl:DecryptXMLRequest/@ReturnResult kann schlielich optional angegeben werden, um die Art der Antwort auf die Anfrage zu steuern (vgl. Abschnitt 5.2.2 Antwort).
Die grundsätzliche Gestalt der Antwort ist abhängig vom Attribut sl:DecryptXMLRequest/@ReturnResult der Anfrage.
Ist das Attribut sl:DecryptXMLRequest/@ReturnResult entweder nicht oder auf den Wert xml gesetzt, liefert die Bürgerkarten-Umgebung eine XML-Antwort zurück.
sl:DecryptXMLResponse/sl:CandidateDocument enthält dabei jenes XML-Dokument, das in der Anfrage entweder per Referenz oder direkt eingebettet an die Bürgerkarten-Umgebung übergeben wurde. Darin sind jedoch all jene verschlüsselten Elemente xenc:EncryptedData durch ihre entschlüsselten Inhalte ersetzt, für die alle nachfolgenden Bedingungen erfüllt sind:
sl:DecryptXMLRequest/sl:EncrElemsSelector in der Anfrage zur Entschlüsselung ausgewählt;
xenc:EncryptedData/@Type angegebene Typ des Verschlüsselungselements ist entweder http://www.w3.org/2001/04/xmlenc#Element oder http://www.w3.org/2001/04/xmlenc#Content.
Kaskadierte Verschlüsselungselemente werden von der Bürgerkarten-Umgebung nicht weiter behandelt, d. h. enthält der entschlüsselte Inhalt eines Verschlüsselungselements wiederum Verschlüsselungselemente, werden diese nicht weiter entschlüsselt.
Wählt sl:DecryptXMLRequest/@EncrElemsSelector auch Verschlüsselungselemente aus, deren Typ (xenc:EncryptedData/@Type) entweder nicht angegeben wurde, oder aber weder http://www.w3.org/2001/04/xmlenc#Element noch http://www.w3.org/2001/04/xmlenc#Content ist, ersetzen die entsprechenden entschlüsselten Inhalte nicht die Verschlüsselungselemente im XML-Dokument, sondern werden als eigene Elemente sl:DecryptXMLResponse/sl:DecryptedBinaryData retourniert:
sl:DecryptedBinaryData/@EncrElemSelector enthält als Ausdruck nach [XPath] den Bezug zum korrespondierenden Verschlüsselungselement im XML-Dokument der Anfrage; das Verschlüsselungselement muss dabei von diesem Ausdruck eindeutig selektiert werden, d. h. er muss eine Knotenmenge liefern, die genau ein Element xenc:EncryptedData enthält. Der Kontextknoten für die Evaluierung des Ausdrucks ist dabei der Dokument-Knoten des XML-Dokuments der Anfrage.sl:DecryptedBinaryData/@MimeType enthält optional den Mime-Type der entschlüsselten Daten; und zwar genau dann, wenn dieser bereits im Verschlüsselungselement mittels xenc:EncryptedData/@MimeType angegeben wurde; sl:DecryptedBinaryData/@Encoding enthält optional die Transport-Kodierung der entschlüsselten Daten; und zwar genau dann, wenn dieser bereits im Verschlüsselungselement mittels xenc:EncryptedData/@Encoding angegeben wurde; sl:DecryptedBinaryData schließlich bilden die entschlüsselten Daten, und zwar in base64-kodierter Form. Liegen die entschlüsselten Daten bereits von vorneherein base64-kodiert vor (d. h. weist das Attribut xenc:EncryptedData/@Encoding des Verschl sselungselements den Wert http://www.w3.org/2000/09/xmldsig#base64 auf), dürfen sie nicht noch einmal base64-kodiert werden.Kann auch nur ein einziges der mittels sl:DecryptXMLRequest/sl:EncrElemsSelector selektierten Verschlüsselungselemente nicht entschlüsselt werden, muss die Bürgerkarten-Umgebung eine Fehler-Antwort (sl:ErrorResponse) liefern. Liefert die Auswertung des XPaths in sl:DecryptXMLRequest/sl:EncrElemsSelector eine leere Knotenmenge, muss die Bürgerkarten-Umgebung das unveränderte XML-Dokument der Anfrage retournieren.
Ist das Attribut sl:DecryptXMLRequest/@ReturnResult hingegen auf den Wert binary gesetzt, liefert die Bürgerkarten-Umgebung keine XML-Antwort, sondern direkt Binärdaten. Zur Ermittlung dieser Binärdaten geht die Bürgerkarten-Umgebung wie folgt vor:
sl:DecryptXMLRequest/sl:EncrElemsSelector liefert; es gilt dabei die Reihenfolge des Auftretens im XML-Dokument (document-order);Bietet das Transportprotokoll die Möglichkeit, die Transport-Kodierung bzw. den Mime-Type zu spezifizieren, muss die Bürgerkarten-Umgebung die gegebenenfalls im Verschlüsselungselement gemachten Angaben (xenc:EncryptedData/@MimeType bzw. xenc:EncryptedData/@Encoding) verwenden.
Kann das zu untersuchende Verschlüsselungselement nicht entschlüsselt werden, oder liefert die Auswertung des XPaths in sl:DecryptXMLRequest/@EncrElemsSelector eine leere Knotenmenge, muss die Bürgerkarten-Umgebung eine Fehler-Antwort (sl:ErrorResponse) liefern.
Ist das Attribut sl:DecryptXMLRequest/@ReturnResult hingegen auf den Wert none gesetzt, liefert die Bürgerkarten-Umgebung eine leere Antwort (Element sl:DecryptXMLResponse ohne Inhalt) zurück. Mit dieser Option hat der Bürger die Möglichkeit, sich die entschlüsselten Daten über die Benutzer-Schnittstelle anzusehen und/oder zu speichern, ohne das sie im weiteren auch an die Applikation übermittelt werden.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.4.
Dieser Befehl dient zur Berechnung von Hashwerten für ein oder mehrere in der Anfrage spezifizierte Datenobjekte.
Das Anfrage-Element sl:CreateHashRequest enthält pro Datenobjekt, für das die Bürgerkarten-Umgebung einen Hashwert berechnen soll, ein Element sl:HashInfo, bestehend aus den Elementen sl:HashData, sl:HashAlgorithm und (optional) sl:FriendlyName.
Mit sl:HashData spezifiziert die Applikation entweder eine Lokation, von der die Bürgerkarten-Umgebung die zu hashenden Daten abrufen soll (Verwendung des Attributs sl:Content/@Reference, Inhalt bleibt leer), oder sie spezifiziert direkt die zu hashenden Daten (keine Verwendung des Attributs sl:Content/@Reference, als Inhalt entweder sl:Content/sl:Base64Content oder sl:Content/@sl:XMLContent).
Jedenfalls an Metainformationen spezifiziert werden muss der Mime-Type (siehe [MIME]) der zu hashenden Daten (sl:HashData/sl:MetaInfo/sl:MimeType); diese Information benötigt die Bürgerkarten-Umgebung im Rahmen der gegebenenfalls vorzunehmenden Anzeige der zu hashenden Daten. Weiters darf eine verbale Beschreibung dieser Daten angegeben werden (sl:HashData/sl:MetaInfo/sl:Description).
Wird sl:XMLContent zur direkten Spezifikation der zu hashenden Daten verwendet, muss die Bürgerkarten-Umgebung den XML-Inhalt unter Verwendung der Kanonisierung nach [C14N] in eine Folge von Bytes umwandeln, und diese dann der eigentlichen Hash-Berechnung zuführen. Vor der Kanonisierung muss die Bürgerkarten-Umgebung den XML-Inhalt aus dem Kontext des Anfrage-Elements herauslösen.
Mit sl:HashAlgorithm wählt die Applikation den Hash-Algorithmus, nach dem die Bürgerkarten-Umgebung die Hashwertberechnung durchführen soll. sl:FriendlyName schließlich kann sie dazu verwenden, um den zu hashenden Daten einen für den Bürger verständlichen Namen zu geben. Dieser Name wird gegebenenfalls von der Bürgerkarten-Umgebung an der Benutzer-Schnittstelle zur Benennung der zu hashenden Daten verwendet.
Das Attribut sl:HashInfo/@RespondHashData gibt an, ob das Element sl:HashData im Antwort-Element zurückgeliefert wird.
Anmerkung: Die von einer Bürgerkarten-Umgebung zu unterstützenden Algorithmen zur Hashwertberechnung sind in Minimale Umsetzung des Security-Layers, Abschnitt 8 spezifiziert.
Das Antwort-Element sl:CreateHashResponse enthält pro Datenobjekt, für das ein Hashwert zu bilden war, ein Element sl:HashInfo, bestehend aus den Elementen (gegebenenfalls) sl:HashData, sl:HashAlgorithm, (gegebenenfalls) sl:FriendlyName sowie sl:HashValue.
Die ersten drei Elemente entsprechen dabei exakt jenen aus dem korrespondierenden sl:HashInfo der Anfrage, wobei das Element sl:HashData nur dann aufscheint, wenn im korrespondierenden sl:HashInfo der Anfrage das Attribut RespondHashData den Wert true enthält. Das Element sl:HashValue beinhaltet den von der Bürgerkarten-Umgebung berechneten Hashwert über die per sl:HashInfo in der Anfrage angegebenen Daten, und zwar in base64-kodierter Form.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.5.
Dieser Befehl dient zur Verifikation von Hashwerten über ein oder mehrere in der Anfrage spezifizierte Datenobjekte.
Das Anfrage-Element sl:VerifyHashRequest enthält pro Datenobjekt, für das die Bürgerkarten-Umgebung einen darüber gerechneten Hashwert verifizieren soll, ein Element sl:HashInfo, bestehend aus den Elementen sl:HashData, sl:HashAlgorithm, ggf. sl:FriendlyName und sl:HashValue.
Mit sl:HashData spezifiziert die Applikation entweder eine Lokation, von der die Bürgerkarten-Umgebung die Daten abrufen soll, über die der zu verifizierende Hashwert gerechnet worden ist (Verwendung des Attributs sl:Content/@Reference, Inhalt bleibt leer), oder sie spezifiziert diese Daten direkt (keine Verwendung des Attributs sl:Content/@Reference, als Inhalt entweder sl:Content/sl:Base64Content oder sl:Content/sl:XMLContent).
Jedenfalls an Metainformationen spezifiziert werden muss der Mime-Type (siehe [MIME]) der zu verifizierenden Hash-Daten (sl:HashData/sl:MetaInfo/sl:MimeType); diese Information benötigt die Bürgerkarten-Umgebung im Rahmen der gegebenenfalls vorzunehmenden Anzeige der zu verifizierenden Hash-Daten. Weiters darf eine verbale Beschreibung dieser Daten angegeben werden (sl:HashData/sl:MetaInfo/sl:Description).
Wird sl:XMLContent zur direkten Spezifikation verwendet, muss die Bürgerkarten-Umgebung den XML-Inhalt unter Verwendung der Kanonisierung nach [C14N] in eine Folge von Bytes umwandeln, und diese dann der eigentlichen Hash-Verfikation zuführen. Vor der Kanonisierung muss die Bürgerkarten-Umgebung den XML-Inhalt aus dem Kontext des Anfrage-Elements herauslösen.
Mit sl:HashAlgorithm spezifiziert die Applikation den Hash-Algorithmus, nach dem der zu verifizierende Hashwert über die mittels sl:HashData angegebenen Daten gerechnet worden ist.
sl:FriendlyName kann sie dazu verwenden, um dem Datenobjekt, für das der Hashwert verifiziert werden soll, einen für den Bürger verständlichen Namen zu geben. Dieser Name wird gegebenenfalls von der Bürgerkarten-Umgebung an der Benutzer-Schnittstelle zur Benennung des Datenobjekts verwendet.
sl:HashValue schließlich enthält den zu verifizierenden Hashwert.
Das Antwort-Element sl:VerifyHashResponse enthält je Hashwert, der im Anfrage-Element zur Verifikation eingereicht worden ist, ein korrespondierendes Element sl:VerificationResult. Dieses enthält ggf. das im korrespondierenden sl:HashInfo der Anfrage angegebene Element sl:FriendlyName sowie in sl:Result das Resultat der Hashwert-Verifikation. Konnte die Bürgerkarten-Umgebung den im korrespondierenden sl:HashInfo der Anfrage angegebenen Hashwert verifizieren (d. h. aus den angegebenen Daten nach dem angegebenen Hash-Algorithmus den identen Hashwert berechnen), enthält sl:Result den Wert true, ansonsten false.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.6.
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:
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.7.
Nachfolgend sind jene zwei verschiedenen Typen definiert, die eine Infobox haben kann.
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.
Eine Binärdatei kann nur in ihrer Gesamtheit gelesen werden. Grundsätzlich werden daher keine Parameter in der Leseanfrage (siehe Abschnitt 7.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.
In welcher Form die Daten in der Antwort auf die Leseanfrage (siehe Abschnitt 7.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).
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.
In der entsprechenden Antwort auf die Update-Anfrage (siehe Abschnitt 7.4.2) werden keinerlei Daten zurückgeliefert.
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.
Auf ein assoziatives Array sind drei verschiedene Lesezugriffe erlaubt:
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. Für die Selektion aller verfügbaren Schlüssel ist der Wert ** als Suchstring anzugeben.
Wird zusätzlich das Attribut sl:ReadKeys/@UserMakesUnique angegeben, so muss der Bürger über die Benutzer-Schnittstelle der Bürgerkarten-Umgebung genau einen Schlüssel aus der Menge der mit dem spezifizierten Suchstring gefundenen Schlüssel auswählen. Dieser vom Bürger selektierte Schlüssel ist dann als einziger Schlüssel in der Antwort zurückzusenden. Ist die Menge der mit dem spezifizierten Suchstring gefundenen Schlüssel leer, muss sich die Bürgerkarten-Umgebung so verhalten, als wäre das Attribut sl:ReadKeys/@UserMakesUnique gar nicht angegeben worden. Für genauere Informationen über die Vorgaben an die Benutzer-Schnittstelle siehe Anforderungen an die Benutzer-Schnittstelle.
Anmerkung: Dieses Modell 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önnten dann etwa alle Werte der ersten Reihe ausgelesen werden.
Die Antwortdaten enthalten die gefundenen Schlüssel (Elemente sl:Key in sl:AssocArrayData).
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.
Wird das Attribut sl:ReadPairs/@UserMakesUnique angegeben, so muss der Bürger über die Benutzer-Schnittstelle der Bürgerkarten-Umgebung genau einen Schlüssel aus der Menge der mit dem spezifizierten Suchstring gefundenen Schlüssel auswählen. Dieser vom Bürger selektierte Schlüssel ist dann als einziger Schlüssel gemeinsam mit dem zugehörigen Wert in der Antwort zurückzusenden. Ist die Menge der mit dem spezifizierten Suchstring gefundenen Schlüssel leer, muss sich die Bürgerkarten-Umgebung so verhalten, als wäre das Attribut sl:ReadPairs/@UserMakesUnique gar nicht angegeben worden. Für genauere Informationen über die Vorgaben an die Benutzer-Schnittstelle siehe Anforderungen an die Benutzer-Schnittstelle.
Ähnlich wie bei den Leseparametern für eine Binärdatei (siehe Abschnitt 7.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.
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.
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: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).Für ein Assoziatives Array sind drei unterschiedliche Update-Anfragen vorgesehen:
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.
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. Existiert zum angegebenen Schlüssel kein Eintrag im Assoziativen Array, wird ein neuer Eintrag mit dem angegebenen Schlüssel und dem angegebenen Wert hinzugefügt.
Hinsichtlich der Kodierung des Wertes gelten die in Abschnitt 7.1.1, Updateparameter und Antwortdaten gemachten Aussagen.
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.
In der entsprechenden Antwort auf alle drei möglichen Update-Anfragen (siehe Abschnitt 7.4.2) werden keinerlei Daten zurückgeliefert.
Mit diesem Kommando erhält die Applikation von der Bürgerkarten-Umgebung die Auskunft, welche Infoboxen für Zugriffe zur Verfügung stehen.
Die Anfrage ist ein leeres Kommando ohne Parameter.
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.
Dieser Befehl dient zum Anlegen einer Infobox durch die Applikation.
Das Anfrage-Element sl:InfoboxCreateRequest enthält zunächst die beiden Elemente sl:InfoboxIdentifier und sl:InfoboxType. sl:InfoboxIdentifier gibt den Bezeichner an, unter dem die anzulegende Infobox zukünftig ansprechbar sein soll, während sl:InfoboxType den Typ der anzulegenden Infobox spezifziziert (entweder BinaryFile für eine binäre Infobox oder AssocArray für ein assoziatives Feld).
Es folgen zwei weitere obligatorische Elemente: sl:Creator enthält als Freitext Informationen zum Betreiber der Applikation, welche diese Infobox anlegen möchte. sl:Purpose gibt ebenfalls als Freitext Informationen zum Zweck der Infobox an, den diese für die Applikation erfüllt. Beide Elemente werden von der Bürgerkarten-Umgebung an der Benutzer-Schnittstelle zur Information des Bürgers verwendet.
Mit den nächsten beiden optionalen Elementen sl:ReadAccessAuthorization bzw. sl:UpdateAccessAuthorization kann die Applikation Angaben darüber machen, wem das Lesen bzw. Verändern der Infobox erlaubt ist. Je nachdem, ob das Attribut UserMayChange auf den Wert true oder false gesetzt ist, muss die Bürgerkarten-Umgebung diese Angaben als Empfehlung (Bürger darf die vorgeschlagenen Rechte verändern) oder als Vorschrift (Bürger darf die vorgeschlagenen Rechte nicht verändern) interpretieren. Fehlt eines der beiden Elemente, bleibt es dem Bürger überlassen, die entsprechenden Zugriffsrechte zu vergeben. Genauere Informationen über die Vorgaben an die Benutzer-Schnittstelle enthält Anforderungen an die Benutzer-Schnittstelle.
Jedes der beiden Elemente enthält ein ein oder mehrere Elemente sl:RequesterID. Der Inhalt von sl:RequesterID ist ein Pattern entweder für Domänennamen oder IP-Adressen zur Identifikation der zugriffsberechtigten Applikation. Für Domänennamen ist die einmalige Angabe einer Wildcard * für ein oder mehrere Domänenteile am Beginn des Patterns (z.B. * oder *.gv.at oder *.cio.gv.at, nicht aber *io.gv.at) erlaubt, für IP-Adressen die einmalige Angabe einer Wildcard * für ein oder mehrere Bytes der IP-Adresse am Ende des Patterns (z.B. 193.170.* oder 193.170.251.*, nicht aber 193.170.25*). Das Attribut AuthenticationClass gibt an, wie streng die Bürgerkarten-Umgebung diese Identifikation prüfen muss. Mögliche Werte für dieses Attribut sind anonym, pseudoanonym, certified sowie certifiedGovAgency. Für genaue Informationen über die Bedeutung dieser Authenitiserungsklassen siehe Zugriffsschutz, Abschnitt 2.1.
Die Prüfung eines bestimmten Domänennamens oder einer bestimmten IP-Adresse gegen die spezifizierten Patterns muss von der Bürgerkarten-Umgebung entsprechend der Reihenfolge der spezifizierten Elemente sl:RequesterID erfolgen. Sind beispielsweise die Patterns *.gv.at und *.cio.gv.at in dieser Reihenfolge spezifiziert, matched der Domänenname www.cio.gv.at das Pattern *.gv.at, da dieses in der Reihenfolge vor *.cio.gv.at kommt.
Schließlich kann die Applikation mit den letzten beiden optionalen Elementen sl:ReadUserConfirmation bzw. sl:UpdateUserConfirmation Angaben darüber machen, auf welche Weise der Bürger einen Lese- oder Schreibzugriff auf die Infobox bestätigen muss. Je nachdem, ob das Attribut UserMayChange auf den Wert true oder false gesetzt ist, muss die Bürgerkarten-Umgebung diese Angaben als Empfehlung (Bürger darf die vorgeschlagenen Angaben verändern) oder als Vorschrift (Bürger darf die vorgeschlagenen Angaben nicht verändern) interpretieren. Fehlt eines der beiden Elemente, bleibt es dem Bürger überlassen, die entsprechenden Zugriffsrechte zu vergeben. Genauere Informationen über die Vorgaben an die Benutzer-Schnittstelle enthält Anforderungen an die Benutzer-Schnittstelle.
Jedes der beiden Elemente kann als Textinhalt einen der vier Werte none, info, confirm oder confirmWithSecret haben. none bedeutet, dass der Zugriff auf die Infobox vom Bürger gar nicht bestätigt werden muss; info bedeutet, dass der Bürger über den erfolgen Zugriff über die Benutzer-Schnittstelle informiert werden muss (z.B. als Log-Eintrag); confirm bedeutet, dass der Bürger über die Benutzer-Schnittstelle die Erlaubnis für den Zugriff bestätigen muss; bei confirmWithSecret muss der Bürger die Erlaubnis für den Zugriff durch die Eingabe eines Passworts über die Benutzer-Schnittstelle erteilen.
Das Antwort-Element sl:InfoboxCreateResponse ist leer und bestätigt das erfolgreiche Anlegen der Infobox.
Dieser Befehl dient zum Löschen einer Infobox durch die Applikation.
Das Anfrage-Element sl:InfoboxDeleteRequest enthält nur das Element sl:InfoboxIdentifier; der Inhalt dieses Elements bezeichnet die zu löschende Infobox.
Das Antwort-Element sl:InfoboxDeleteResponse ist leer und bestätigt das erfolgreiche Löschen der Infobox.
Dieses Kommando erlaubt der Applikation das Lesen von Daten einer Infobox.
Die Anfrage sl:InfoboxReadRequest enthält zunächst den Bezeichner jener Infobox, deren Inhalt gelesen werden soll (Element sl:InfoboxIdentifier). Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem Befehl sl:InfoboxAvailableRequest abfragen.
Weiters müssen - abhängig vom Typ der Infobox - boxtypspezifische Parameter für die Lese-Anfrage spezifiziert werden; für eine binäre Infobox mit Hilfe des Element sl:BinaryFileParameters, für ein assoziatives Array mit Hilfe des Elements sl:AssocArrayParameters. Für weitere Informationen zu den boxtypspezifischen Parametern siehe Abschnitt 7.1.
Schließlich können optional noch boxspezifische Parameter angegeben werden; das sind Parameter, die nur im Kontext einer ganz bestimmten Infobox sinnvoll sind. Verwendung findet dazu das Element sl:BoxSpecificParameters; als Inhalt dieses Elements ist grundsätzlich eine beliebige Mischung aus Text und Elementen erlaubt.
Anmerkung: Die Festlegung der boxspezifischen Parameter für die im Konzept Bürgerkarte standardisierten Infoboxen befindet sich im Dokument Standardisierte Key- und Infoboxen.
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 7.1.
Dieses Kommando erlaubt der Applikation das Verändern von Daten einer Infobox.
Die Anfrage sl:InfoboxUpdateRequest enthält zunächst den Bezeichner jener Infobox, deren Inhalt verändert werden soll (Element sl:InfoboxIdentifier). Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem Befehl sl:InfoboxAvailableRequest abfragen.
Weiters müssen - abhängig vom Typ der Infobox - boxtypspezifische Parameter für die Update-Anfrage spezifiziert werden; für eine binäre Infobox mit Hilfe des Element sl:BinaryFileParameters, für ein assoziatives Array mit Hilfe des Elements sl:AssocArrayParameters. Für weitere Informationen zu den boxtypspezifischen Parametern siehe Abschnitt 7.1.
Schließlich können optional noch boxspezifische Parameter angegeben werden; das sind Parameter, die nur im Kontext einer ganz bestimmten Infobox sinnvoll sind. Verwendung findet dazu das Element sl:BoxSpecificParameters; als Inhalt dieses Elements ist grundsätzlich eine beliebige Mischung aus Text und Elementen erlaubt.
Anmerkung: Die Festlegung der boxspezifischen Parameter für die im Konzept Bürgerkarte standardisierten Infoboxen befindet sich im Dokument Standardisierte Key- und Infoboxen.
Die Antwort ist ein leeres Kommando ohne Parameter.
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.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.8.
Die Applikation benötigt für bestimmte Aufgaben gegebenenfalls zusätzliche Informationen über die Bürgerkarten-Umgebung. Dieses Kommando dient zur Abfrage solcher Eigenschafen.
Die Anfrage besteht aus dem leeren Element sl:GetPropertiesRequest.
Die Antwort besteht aus dem Element sl:GetPropertiesResponse und enthält als Kindelemente folgende Eigenschaften der Bürgerkarten-Umgebung:
sl:ViewerMediaType: Unterstützte Formate der Anzeige: Bei Kenntnis der Fähigkeiten der Anzeige der Bürgerkarten-Umgebung kann die Applikation bei Anfragen zur Erstellung einer Signatur auf diese Fähigkeiten Rücksicht nehmen.sl:XMLSignatureTransform: 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. sl:KeyboxIdentifier: Bezeichner aller in der Bürgerkarten-Umgebung zum Zeitpunkt der Anfrage 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. Für jedes Schlüsselpaar wird angegeben, ob es zur Verwendung im Kontext Signatur (Attribut Signature) bzw. Verschlüsselung (Attribut Encryption) geeignet ist.sl:Binding: 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. sl:ProtocolVersion: Unterstützte Protokollversionen des Security-Layer: Damit kann die Applikation ersehen, welche Protokollversionen des Security-Layer die Bürgerkarten-Umgebung unterstützt. Die Protokollversion, die durch dieses Spezifikationsdokument beschrieben wird, ist 1.2.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).
Enthält der Befehl, bestehend aus dem Element sl:GetStatusRequest, 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.
Die Antwort besteht aus dem Element sl:GetStatusResponse und enthält als Text des Kindelements sl:TokenStatus den aktuellen Status des Tokens (entweder ready oder removed).
Die Null-Operation ist ein Kommando, das die Bürgerkarten-Umgebung beantwortet, ohne dass dazu irgendwelche Berechnungen notwendig wären. Auf eine parameterlose Anfrage wird eine parameterlose Antwort gesendet.
Anmerkung: Eine sinnvolle Anwendung dieses Kommandos existiert in Zusammenhang mit der Authenifizierung gegenüber der Bürgerkarten-Umgebung bei Verwendung der HTTP- bzw. HTTPS-Bindung des Security-Layers: Die Authentifizierung funktioniert sinnvoll nur bei Verwendung der Data-URL; um jedoch mit der Data-URL operieren zu können, muss zumindest ein erster Befehl vom Browser des Bürgers an die Bürgerkarten-Umgebung gesendet werden, für den die Authentifizierung nicht sinnvoll möglich ist. Für diesen ersten Befehl kann die Null-Operation eingesetzt werden (für genauere Informationen zur Authentifizierung der Applikation gegenüber der Bürgerkarten-Umgebung vergleiche Zugriffsschutz auf Funktionen der Bürgerkarten-Umgebung).
Die Applikation sendet die parameterlose Anfrage bestehend aus dem Element sl:NullOperationRequest an die Bürgerkarten-Umgebung.
Die Bürgerkarten-Umgebung empfängt die parameterlose Anfrage und reagiert darauf mit der ebenfalls parameterlosen Antwort sl:NullOperationResponse.
Anmerkung: Für Beispiele zu diesem Befehl siehe Tutorium; für Anforderungen an die Benutzerschnittstelle siehe Anforderungen an die Benutzerschnittstelle, Abschnitt 3.9.
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:ErrorCode), 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.
Anmerkung: Für Beispiele zur Fehlerbehandlung siehe Tutorium.
Siehe eigenes Dokument Fehlercodes Security-Layer.
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.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.| Datum | Version | Änderungen |
|---|---|---|
| 01. 03. 2005 | 1.2.2 | |
| 29. 06. 2004 | 1.2.1 |
|
| 14. 05. 2004 | 1.2.0 |
|
| 31. 08. 2002 | 1.1.0 |
|
| 31. 08. 2002 |
1.0.2 |
|
| 1.0.1 |
|