Die Applikationsschnittstelle Security-Layer zur österreichischen
Bürgerkarte | Konvention | |
| 1.2.8 | ||
| Empfehlung | ||
| Kurzbeschreibung | Das vorliegende Dokument spezifiziert die Schnittstelle zwischen Applikation und Bürgerkarten-Umgebung. | |
| Autoren: | et al. | Projektteam/Arbeitsgruppe |
| AG Bürgerkarte | ||
| Datum: | 26.5.2015 | |
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:
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] ([CAdES]) und [XMLDSIG] ([XAdES]).
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 MUSS die Signaturanfrage einen Behälter
sl:DataObject enthalten, 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. Optional DARF noch ein Bereich des
Datenobjekts spezifiziert werden (sl:ExcludedByteRange),
der von der Signatur ausgenommen wird.
Jedenfalls an Metainformation spezifiziert werden MUSS der Mime-Type (siehe [MIME]) des zu signierenden Datenobjekts. Schließlich DÜRFEN noch weitere beliebige Elemente zu diesen Metainformationen hinzugefügt werden.
Die Angabe des zu signierenden Datenobjekts kann auf zwei
Arten erfolgen: Entweder enthält das Element sl:Content
die base64-kodierten Daten, oder das Element sl:Content
ist leer, hat aber sein Attribut Reference gesetzt. Die
Bürgerkarten-Umgebung
MUSS im letzten Fall versuchen, die in
diesem Attribut angegebene URI aufzulösen, um so die zu signierenden
Daten zu erhalten.
Wird ein Bereich aus der Signatur ausgenommen, so MUSS die Bürgerkarten-Umgebung diesen Bereich, der mittels zweier Byte-Offsets "From" und "To" angegeben wird, für die Anzeige mit Null-Bytes (0x00) ausfüllen. Die Offsets sind 0-basiert und inklusive (d.h. sowohl das (From+1)te als auch das (To+1)te Byte zählen zu diesem Bereich). Für den Signaturvorgang selbst wird dieser Bereich ausgenommen - die Null-Bytes werden nicht mitsigniert.
Zudem DARF in der Signaturanfrage das
boolsche Attribut PAdESCompatibility vorhanden sein.
Der Standardwert dieses Attributs ist false.
Wird es auf true gesetzt, so MUSS
die Bürgerkarten-Umgebung
sicherstellen, dass die resultierende Signatur, eingebettet in ein PDF,
den Anforderungen von [PAdES] genügt.
PAdES spezifiziert, dass die CMS-Signatur das Attribut
SigningTime NICHT beinhalten
DARF, wenn PAdES-Kompatibilität
erwünscht ist.
Die Antwort besteht aus dem Element
sl:CMSSignature, welches die erzeugte Signatur nach
[CAdES] in base64-kodierter Form enthält. Für
detailierte Vorgaben für die zu erzeugende Signatur hinsichtlich
Digest-Algorithmen, Signatur-Algorithmen und Schlüsselinformationen
siehe Minimale Umsetzung des Security-Layers.
In die [CMS]-Signatur
MUSS ein signiertes Signaturattribut
mime-type nach [CAdES],
Abschnitt 5.11.5 aufgenommen werden. Zur Anfertigung dieses
Signaturattributs ist jene Metainformation
(sl:MimeType aus sl:MetaInfo) zu verwenden,
die in der Anfrage im Behälter für das Datenobjekt
(sl:DataObject) angegeben wurde.
Das Feld
contentType MUSS
mit dem Wert des Object Identifiers für id-data (siehe
[CMS], Abschnitt 4) belegt werden.
Weiters MUSS
ein signiertes Signaturattribut ESS signing-certificate
nach [ESS-S/MIME] (falls SHA-1 zum Berechnen der
Signatur verwendet wird) bzw. ESS signing-certificate-v2
nach [RFC 5035] (für andere Hash-Algorithmen) 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 signiertes Signaturattribut SigningTime nach
[CMS] in die [CMS]-Signatur
aufgenommen werden, das den vom Signator behaupteten Zeitpunkt der
Signaturerstellung enthält, sofern nicht das
PAdESCompatibility-Attribut auf true
gesetzt wurde - in diesem Fall DARF dieses
Signaturattribut NICHT gesetzt werden.
Stattdessen SOLLTE das unsignierte
Signaturattribut signature-time-stamp gesetzt werden.
Anmerkung
Für Beispiele zu diesem Befehl siehe Tutorium; für
Anforderungen an die Benutzerschnittstelle siehe Abschnitt 3.1, „Signaturerstellung“ in
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ürsl:XMLContentdas Attributxml:spacemit dem Wertpreserveversehen werden. Das Inhaltsmodell vonsl:XMLContentist 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 vonsl:XMLContentist 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. Dazu kann die Bürgerkarten-Umgebung
entweder
Im Fall (a) ist zu beachten, dass,
falls die base64-dekodierten Daten nicht direkt in das
dsig:Object aufgenommen werden können (weil darin
Zeichen enthalten sind, die nicht als XML-Text darstellbar sind),
jedenfalls wie im Fall (b) beschrieben
vorgegangen werden MUSS.
(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 2.2.1.3, „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-Anzeigeformat 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 Content in „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:
Prüfung, ob die aufzulösende Referenz in einem
sl:Supplementinnerhalb jenessl:DataObjectInfovorkommt, das den gerade berechneten Transformationsprozess spezifiziert. Ist diese Prüfung erfolgreich, sind die in diesemsl:Supplementangegebenen Daten als Ergebnis der Auflösung zu verwenden. Ansonsten ist mit Schritt 2 fortzufahren.Prüfung, ob die aufzulösende Referenz in einem
sl:Supplementeines anderensl:DataObjectInfovorkommt, das im Befehl zur Erzeugung der XML-Signatur spezifiziert wurde. Die einzelnensl:DataObjectInfo-Elemente sind dabei in jener Reihenfolge zu untersuchen, in der Sie im Befehl angegeben wurden. Die im ersten so gefundenensl:Supplementangegebenen Daten sind als Ergebnis der Auflösung zu verwenden. Wird keinsl:Supplementgefunden, ist mit Schritt 3 fortzufahren.Auflösung der Referenz.
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, „Antwort“)
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 Content in „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, hat Index den Wert -1, wird die Signatur
nach dem letzten 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 „Das Signaturdokument“) referenziert wird.
Ein Ergänzungsobjekt besteht dabei einerseits aus
OPTIONALEN Metainformationen (vergleiche
sl:FinalDataMetaInfo in „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 Content in „Datenobjekt“).
Die Antwort enthält die nach [XAdES]
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 „Transformationswege“ 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:
Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung selbst aufzulösten ist, ist zwischen einer externen und einer internen Referenz zu unterscheiden:
Die Auflösung einer externen Referenz MUSS einen Byte-Stream liefern. Dieser Byte-Stream bildet die Eingangsdaten für die Hash-Berechnung.
Die Auflösung einer internen Referenz MUSS eine XPath-Knotenmenge liefern (vgl. [XMLDSIG], Abschnitt 4.3.3.3]). Diese Knotenmenge ist nach [C14N] zu kanonisieren, um einen eindeutigen Byte-Stream zu erhalten. Dieser Byte-Stream bildet dann die Eingangsdaten für die Hash-Berechnung.
Wird der implizite Transformationsparameter als Referenz angegeben, die von der Bürgerkarten-Umgebung nicht selbst aufzulösen ist, weil in der Anfrage ein entsprechendes Ergänzungsobjekt angegeben wurde, ist wiederum zwischen einer externen und einer internen Referenz zu unterscheiden:
Enthält das Ergänzungsobjekt Daten für eine externe Referenz, MÜSSEN diese Daten als base64 (in
sl:Supplement/sl:Content/sl:Base64Content) vorliegen. Die Base64-dekodierten Daten bilden dann die Eingangsdaten für die Hash-Berechnung.Enthält das Ergänzungsobjekt Daten für eine interne Referenz, MÜSSEN diese Daten als XML (in
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
[XAdES] 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
[XAdES] 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)
MUSS ein Signaturattribut aufgenommen
werden, das die dazu spezifizierten Metainformationen
(sl:FinalDataMetaInfo) enthält.
Dazu ist das signierte Signaturattribut
etsi:DataObjectFormat nach
[XAdES] 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
[XAdES] 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
[XAdES] zu verwenden.
Anmerkung
Für Beispiele zu diesem Befehl siehe Tutorium; für
Anforderungen an die Benutzerschnittstelle siehe Abschnitt 3.1, „Signaturerstellung“ in
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:
Enthält die Signatur ein Signaturattribut
SigningTimenach [CAdES], das den vom Signator behaupteten Zeitpunkt der Signaturerstellung enthält, ist die darin genannte Zeit als Prüfzeitpunkt zu verwenden.Existiert kein solches Signaturattribut, ist als Prüfzeitpunkt der Zeitpunkt des Einlangens der Überprüfungsanfrage bei der Bürgerkarten-Umgebung 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). Danach folgt die Angabe der Daten auf eine von zwei
Arten: Entweder enthält das Element sl:Content die
base64-kodierten Daten, oder das Element sl:Content ist
leer, hat aber sein Attribut Reference gesetzt. Die
Bürgerkarten-Umgebung
versucht im letzten Fall die in diesem Attribut angegebene URI
aufzulösen, um so das signierte Datenobjekt zu erhalten.
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 MUSS aus genau
einem Element dsig:X509Data bestehen, das mindestens
folgende zwei Elemente enthalten MUSS:
dsig:SubjectNameenthält den Namen des Signators aus dem Signatorzertifikat. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren. Indsig:X509DataMUSS genau ein solches Element vorkommen.dsig:IssuerSerialenthält den Namen des Austellers und die Seriennummer des Signatorzertifikats. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren. Indsig:X509Datamuss 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:
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.
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 entweder ein Signaturattribut
ESS signing-certificate nach [ESS-S/MIME] (falls SHA-1 zum Berechnen der
Signatur verwendet wurde), oder ein Signaturattribut ESS signing-certificate-v2 nach
[RFC 5035] (für andere Hash-Algorithmen), das Informationen zum
Signatorzertifikat enthält. Vorgängerversionen dieser Spezifikation verwenden stattdessen ein Signaturattribut
OtherSigningCertificate nach [ETSICMS]. 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 [CAdES]
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 Abschnitt 3.2, „Signaturprüfung“ in
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:
Enthält die Signatur ein Signaturattribut
etsi:SigningTimenach [XAdES], das den vom Signator behaupteten Zeitpunkt der Signaturerstellung enthält, ist die darin genannte Zeit als Prüfzeitpunkt zu verwenden.Existiert kein solches Signaturattribut, ist als Prüfzeitpunkt der Zeitpunkt des Einlangens der Überprüfungsanfrage bei der Bürgerkarten-Umgebung 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 Content in „Transformationswege“, 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 Anmerkung in Abschnitt 2.2.1.3, „Informationen zum Signaturdokument“.
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:
ein Datenobjekt, das im URI Attribut eines
dsig:ReferenceElements der Signatur referenziert wird;referenzierte Parameter für die Transformationen in einem
dsig:ReferenceElements der Signatur (z. B. ein Stylesheet, der im Basis-Stylesheet einer XSLT-Transformation referenziert wird);referenzierte Informationen für die Validierung des Dokuments, das die Signatur beinhaltet (Verweis in der Document Type Declaration, Verweise auf XML-Schemata mittels der in [XML-Schema], Abschnitt 2.6.3 angegebenen Mechanismen);
referenzierte Informationen für die Aufindung des für die Signaturprüfung zu verwendenden Zertifikats (vergleiche [XMLDSIG], Abschnitt 4.4.3).
Für ein Ergänzungsobjekt (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 Content in „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:
Genau ein
dsig:X509DataElement, das wiederum mindestens drei Elemente enthalten MUSS:dsig:SubjectNameenthält den Namen des Signators aus dem Signatorzertifikat. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren. Indsig:X509DataMUSS genau ein solches Element vorkommen.dsig:IssuerSerialenthält den Namen des Austellers und die Seriennummer des Signatorzertifikats. Das Element ist wie in [XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren. Indsig:X509DataMUSS genau ein solches Element vorkommen.Weiters muss
dsig:X509Datadas leere Elementsl:QualifiedCertificateenthalten, 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 [XAdES], 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
[XAdES], 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 [XAdES]
auswertet.
Für die definierten Werte für den Inhalt des Elements
sl:Code in sl:CertificateCheck siehe
Kapitel Abschnitt 3.1.2.2, „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 Abschnitt 3.2, „Signaturprüfung“ in
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:
Die Bürgerkarten-Umgebung soll die zu verschlüsselnden Daten von einem angegebenen Ort auflösen:
sl:ToBeEncrypted/sl:Content/@Referenceenthält die entsprechende URL, der Inhalt vonsl:ToBeEncryptedbleibt leer.Die zu verschlüsselnden Daten werden direkt an die Bürgerkarten-Umgebung übergeben:
sl:ToBeEncrypted/sl:Contententhält die Daten in base64-kodierter Form,sl:ToBeEncrypted/sl:Content/@Referencewird 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:
Pro in der Anfrage angegebenen öffentlichem Schlüssel ist ein Feld vom Typ KeyTransRecipientInfo zu erzeugen. Es muss also immer Key Transport als Technik zum Schlüssel-Management verwendet werden.
Die verschlüsselten Daten sind mittels des Feldes encryptedContent im Typ EncryptedContentInfo in die CMS-Nachricht zu integrieren. Eine Trennung von Nachricht und Daten ist nicht vorgesehen.
Die verschlüsselten Daten sind mittels des Feldes contentType im Typ EncryptedContentInfo als Data (siehe [CMS], Abschnitt 4) zu kennzeichnen.
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 Abschnitt 3.3, „Verschlüsselung“ in
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) 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 Elementxenc:EncryptedDataersetzt.sl:Element/@Selectorenthä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 vonsl:Element/@Selectorbekannt sein. Wirdsl:Element/@EncDataReferenceangegeben, DÜRFEN die verschlüsselten Daten von der Bürgerkarten-Umgebung NICHT base64-kodiert in das entsprechende Elementxenc:EncrpytedDataaufgenommen, sondern MÜSSEN stattdessen referenziert werden. Als Referenz MUSS dabei die insl:Element/@EncDataReferenceangegebene URI verwendet werden.Anmerkung
Wird
sl:Elementverwendet, 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 Elementxenc:EncryptedDataersetzt. Die Bedeutung der Attributesl:ElementContent/@Selectorundsl:ElementContent/@EncDataReferenceist die gleiche wie jene der entsprechenden Attribute insl:Element.Anmerkung
Wird diese
sl:ElementContentverwendet, muss ein bestehendes XML-Dokument angegeben werden (siehe unten).sl:New: Beliebige Daten sollen verschlüsselt und als Elementxenc:EncryptedDatain ein bestehendes oder neues XML-Dokument eingefügt werden. Der Ort, an dem das erzeugtexenc:EncryptedDatain das XML-Dokument eingefügt werden soll, wird durch die Attributesl:New/@ParentSelectorundsl:New/@NodeCountangegeben.sl:New/@ParentSelectorselektiert das Eltern-Element des zukünftigenxenc:EncryptedDatamittels 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 vonsl:New/@ParentSelectorbekannt sein.sl:New/@NodeCountenthält die Angabe, als wievielter Knotenxenc:EncryptedDatains Eltern-Element einzufügen ist, wobei mit Null zu zählen begonnen wird. Die zu verschlüsselnden Daten sowie Metainformationen dazu werden als Inhalt vonsl:Newangegeben. 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:Base64Contententhä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:XMLContententhält die zu verschlüsselnden Daten als XML-Fragment.sl:new/sl:Content/sl:LocRefContententhä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 Attributssl:New/sl:Content/@EncDataReferenceist die gleiche wie jene des entsprechenden Attributs insl:Element.Anmerkung
Wird 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 Abschnitt 4.2.2, „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 Abschnitt 4.2.2, „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 „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 Content in „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:
Soll laut Anfrage ein Element eines bestehenden XML-Dokuments oder der Inhalt eines solchen Elements verschlüsselt werden (
sl:ToBeEncrypted/sl:Elementbzw.sl:ToBeEncrypted/sl:ElementContent), MUSS das Attributxenc:EncryptedData/@Typeauf den Werthttp://www.w3.org/2001/04/xmlenc#Elementbzw.http://www.w3.org/2001/04/xmlenc#Contentgesetzt werden. Ansonsten DARF dieses Attribut NICHT verwendet werden.In
xenc:EncryptedData/xenc:EncryptionMethodMUSS einer der in Abschnitt 7.1.1, „Algorithmen“ inDie österreichische Bürgerkarte - Minimale Umsetzung des Security-Layers gelisteten Algorithmen zur Datenverschlüsselung angegeben werden.Das Element
xenc:EncryptedData/ds:KeyInfoMUSS von der Bürgerkarten-Umgebung verwendet werden und alle in der Anfrage angegebenen öffentlichen Schlüssel referenzieren (falls in der Anfrage das Elementsl:EncryptionInfo/sl:EncryptedKeyLocationverwendet wurde) bzw. enthalten (sonst).Im Falle der direkten Beinhaltung MUSS die Bürgerkarten-Umgebung in
ds:KeyInfopro in der Anfrage angegebenen öffentlichen Schüssel einxenc:EncrypedKeyElement verwenden. Dabei müssen folgende Bedingungen eingehalten werden:In
xenc:EncryptedKey/xenc:EncryptionMethodMUSS einer der in Abschnitt 7.2.1.2, „Algorithmen fürxenc:EncryptedKey“ inDie österreichische Bürgerkarte - Minimale Umsetzung des Security-Layers gelisteten Algorithmen angegeben werden.Das Element
xenc:EncryptedData/ds:KeyInfoMUSS von der Bürgerkarten-Umgebung wie folgt verwendet werden:Enthält
xenc:EncryptedKey/xenc:EncryptionMethodeinen Algorithmus zur asymmetrischen Verschlüsselung (Schlüsseltransport), so MUSSxenc:EncryptedData/ds:KeyInfogenau einds:KeyValueElement mit der Kodierung des öffentlichen Schlüssels enthalten.Enthält
xenc:EncryptedKey/xenc:EncryptionMethodeinen Algorithmus zur symmetrischen Verschlüsselung (Symetric Key Wrap), so MUSSxenc:EncryptedData/ds:KeyInfogenau einxenc:AgreementMethodElement mit einem der in Abschnitt 7.2.1.3, „Algorithmen fürxenc:KeyAgreement“ inDie österreichische Bürgerkarte - Minimale Umsetzung des Security-Layers gelisteten Algorithmen zur Schlüsselvereinbarung enthalten. Das Elementxenc:AgreementMethod/ds:DigestMethodMUSS einen unter Abschnitt 5.1.1, „Digest-Algorithmen“ inDie österreichische Bürgerkarte - Minimale Umsetzung des Security-Layers angegebenen Algorithmus enthalten. Das Elementxenc:AgreementMethod/xenc:RecipientKeyInfoMUSS genau ein Elementds:KeyValuemit der Kodierung des öffentlichen Schlüssels enthalten. Das Elementxenc:AgreementMethod/xenc:OriginatorKeyInfoMUSS genau ein Elementds:KeyValuemit der Kodierung des öffentlichen Schlüssels enthalten.
xenc:EncryptedData/xenc:CipherData/xenc:CipherValueenthält den verschlüsselten symmetrischen Schlüssel zur Datenverschlüsselung.
Im Falle der Referenzierung MUSS die Bürgerkarten-Umgebung in
ds:KeyInfopro in der Anfrage angegebenen öffentlichen Schüssel einds:RetrievalMethodElement verwenden. Dabei müssen folgende Bedingungen eingehalten werden:Das Attribut
ds:RetrievalMethod/@Typemuss auf den Werthttp://www.w3.org/2001/04/xmlenc#EncryptedKeygesetzt werden.Das Attribut
ds:RetrievalMethod/@URImuss auf das referenziertexenc:EncryptedKeyElement verweisen.Für das referenzierte
xenc:EncryptedKeyElement gelten die Bedingungen für die direkte Beinhaltung.
Das Element
xenc:EncryptedData/xenc:CipherDatamuss die mit dem symmetrischen Verschlüsselungsschlüssel verschlüsselten Daten referenzieren (wenn im entsprechendensl:ToBeEncryptedElement der Anfrage wurde insl:Elementbzw.sl:ElementContentbzw.sl:Newdas AttributEncDataReferencegesetzt wurde) bzw. direkt beinhalten (sonst). Im Falle der Referenzierung muss die Bürgerkarten-Umgebung das Elementxenc:CipherData/xenc:CipherReferenceverwenden.Dabei müssen folgende Bedingungen eingehalten werden:Transformationen dürfen nicht verwendet werden.
xenc:CipherReference/@URImuss auf den insl:Element/@EncDataReferencebzw.sl:ElementContent/@EncDataReferencebzw.sl:New/@EncDataReferenceangegebenen Wert gesetzt werden.Die verschlüsselten Daten sind in der Antwort in einem
sl:EncryptedData Elementzurückzuliefern.sl:EncryptedData/@EncDataReferencemuss auf den insl:Element/@EncDataReferencebzw.sl:ElementContent/@EncDataReferencebzw.sl:New/@EncDataReferenceangegebenen 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:
Für jedes in der Anfrage spezifizierte, zu verschlüsselnde XML-Element (
sl:ToBeEncrypted/sl:Element) MUSS die Bürgerkarten-Umgebung das angegebene Element des XML-Dokuments durch das entsprechend erzeugtexenc:EncryptedDataElement ersetzen.Für jeden in der Anfrage spezifzierten, zu verschlüsselnden Inhalt eines XML-Elements (
sl:ToBeEncrypted/sl:ElementContent) MUSS die Bürgerkarten-Umgebung den Inhalt des angegebenen Elements des XML-Dokuments durch das entsprechend erzeugtexenc:EncryptedDataElement ersetzen.Für jeden in der Anfrage spezifizierten, zu verschlüsselnden neuen Inhalt (
sl:ToBeEncrypted/sl:New) MUSS die Bürgerkarten-Umgebung das entsprechend erzeugtexenc:EncryptedDataElement an der spezifizierten Position (sl:New/@ParentSelector,sl:New/@NodeCount) in das XML-Dokument einfügen.Wurde in der Anfrage das Element
sl:EncryptionInfo/sl:EncryptedKeyLocationverwendet, MUSS die Bürgerkarten-Umgebung an der darin spezifzizierten Positionxenc:EncryptedKeyElemente 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 Abschnitt 3.3, „Verschlüsselung“ in
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:
In
sl:EncryptedContent/sl:MetaInfo/sl:MimeTypekann 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.In
sl:EncryptedContent/sl:ContentMUSS 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 entwedersl:Content/@ReferenceoderslContent/sl:Base64Contentverwenden.sl:Content/@Referenceenthält eine URL, welche die Bürgerkarten-Umgebung zur Erlangung der verschlüsselten Daten auflösen muss.slContent/sl:Base64Contententhä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:
Der öffentliche Schlüssel eines in der Bürgerkarten-Umgebung vorhandenen und zur Verschlüsselung geeigneten Schlüsselpaares wurde zur Verschlüsselung eines symmetrischen Schlüssels verwendet, mit dem dann die eigentliche Verschlüsselung durchgeführt wurde.
Dieser öffentliche Schlüssel ist im Feld KeyTransRecipientInfo in der CMS-Nachricht bezeichnet, und zwar entweder mittels Kombination aus Issuer und SerialNumber oder mittels SubjectKeyIdentifier des zugehörigen Zertifikats.
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
Abschnitt 6.2, „Entschlüsselung“ in
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 Abschnitt 3.4, „Entschlüsselung“ in
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:
Soll das zu entschlüsselnde XML-Dokument referenziert werden, ist für die Referenzierung das Attribut
sl:EncryptedContent/@Referencezu verwenden.Referencemuss eine von der Bürgerkarten-Umgebung auflösbare URL sein. Der Inhalt vonsl:EncryptedContentbleibt leer.Soll das zu entschlüsselnde XML-Dokument hingegen eingebettet werden, geschieht dies direkt als Inhalt von
sl:EncryptedContent/sl:Base64Contentbzw.sl:EncryptedContent/sl:XMLContent. Wird die erste Variante verwendet, enthältsl:Base64Contentdas base64-kodierte XML-Dokument, in der zweiten Variante enthältsl:XMLContentals einzigen Knoten das Wurzel-Element des XML-Dokuments.sl:EncryptedContent/@Referencefindet 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 einer folgenden Voraussetzungen ausgehen, die von der Applikation eingehalten werden MUSS:
Als Datenverschlüsselungsschlüssel wurde direkt der öffentliche Schlüssel eines in der Bürgerkarten-Umgebung vorhandenen und zur Verschlüsselung geeigneten Schlüsselpaares verwendet (direkte Datenverschlüsselung).
Der verwendete öffentliche Schlüssel muss in
xenc:EncryptedData/ds:KeyInfomittelsds:KeyName,ds:KeyValueoderds:X509Databezeichnet werden.ds:KeyNamemuss 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 Abschnitt 8.1, „Abfrage der Umgebungseigenschaften“ von der Bürgerkarten-Umgebung abgefragt werden.ds:KeyValuemuss den zur Verschlüsselung verwendeten öffentlichen Schlüssel enthalten.ds:X509Datamuss genau ein X.509-Zertifikat (ds:X509Certificate) enthalten, das den zur Verschlüsselung verwendeten öffentlichen Schlüssel zertifiziert.Ein in der Bürgerkarten-Umgebung vorhandener öffentlicher Schlüssel wurde zur Verschlüsselung eines symmetrischen Schlüssels verwendet, mit dem dann die eigentliche Verschlüsselung durchgeführt wurde (Schlüsseltransport / indirekte Datenverschlüsselung).
xenc:EncryptedData/ds:KeyInfomuss entweder ein Elementxenc:EncryptedKeyenthalten, oder aber zumindest ein Elementds:RetrievalMethod, das auf ein Elementxenc:EncryptedKeyverweist.xenc:EncryptedKeymuss die Angaben zum verwendeten symmetrischen Schlüssel enthalten und inds:KeyInfoauf 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.Ein in der Bürgerkarten-Umgebung vorhandener öffentlicher Schlüssel wurde zur Vereinbarung eines symmetrischen Schlüssels verwendet, mit dem dann die eigentliche Verschlüsselung durchgeführt wurde (Schlüsselvereinbarung / indirekte Datenverschlüsselung).
xenc:EncryptedData/ds:KeyInfomuss ein Elementxenc:AgreementMethodenthalten, oder aber zumindest ein Elementds:RetrievalMethod, das auf ein Elementxenc:AgreementMethodverweist.xenc:AgreementMethod/xenc:RecipientKeyInfomuss auf einem der oben erwähnten Wege den zur Schlüsselvereinbarung verwendeten, in der Bürgerkarten-Umgebung verfügbaren Schlüssel bezeichnen.Ein in der Bürgerkarten-Umgebung vorhandener öffentlicher Schlüssel wurde zur Vereinbarung eines symmetrischen Schlüssels verwendet, mit dem der symmetrische Schlüssel, mit dem die eigentliche Verschlüsselung durchgeführt wurde, verschlüsselt ist (Schlüsselvereinbarung / Symmetric Key Wrap / indirekte Datenverschlüsselung).
xenc:EncryptedData/ds:KeyInfomuss entweder ein Elementxenc:EncryptedKeyenthalten, oder aber zumindest ein Elementds:RetrievalMethod, das auf ein Elementxenc:EncryptedKeyverweist.xenc:EncryptedKeymuss ein Element xenc:AgreementMethod enthalten, das im Elementxenc:AgreementMethod/xenc:RecipientKeyInfo, auf einem der oben erwähnten Wege, den zur Schlüsselvereinbarung verwendeten, in der Bürgerkarten-Umgebung verfügbaren Schlüssel, bezeichnet.
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 Abschnitt 7.2, „Entschlüsselung“ in
Optional KÖNNEN Ergänzungsobjekte
(sl:Supplements) spezifiziert werden; das sind
Datenobjekte, auf die im Verschlüsselungsdokument verwiesen wird.
Beispiele dafür sind
verschlüsselte Daten, auf die in einem Element
xenc:EncryptedDataverwiesen wird;ein verschlüsselter symmetrischer Schlüssel, auf den in einem Element
xenc:EncryptedKeyverwiesen wird;ein Element
xenc:EncryptedKey, auf das in einem Elementds:RetrievalMethodverwiesen 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 Content in „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:
das verschlüsselte Element wurde mittels
sl:DecryptXMLRequest/sl:EncrElemsSelectorin der Anfrage zur Entschlüsselung ausgewählt;der im Attribut
xenc:EncryptedData/@Typeangegebene Typ des Verschlüsselungselements ist entwederhttp://www.w3.org/2001/04/xmlenc#Elementoderhttp://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/@EncrElemSelectorenthä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 Elementxenc:EncryptedDataenthält. Der Kontextknoten für die Evaluierung des Ausdrucks ist dabei der Dokument-Knoten des XML-Dokuments der Anfrage.sl:DecryptedBinaryData/@MimeTypeenthält optional den Mime-Type der entschlüsselten Daten; und zwar genau dann, wenn dieser bereits im Verschlüsselungselement mittelsxenc:EncryptedData/@MimeTypeangegeben wurde;sl:DecryptedBinaryData/@Encodingenthält optional die Transport-Kodierung der entschlüsselten Daten; und zwar genau dann, wenn dieser bereits im Verschlüsselungselement mittelsxenc:EncryptedData/@Encodingangegeben wurde;den Inhalt von
sl:DecryptedBinaryDataschließ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 Attributxenc:EncryptedData/@Encodingdes Verschl sselungselements den Werthttp://www.w3.org/2000/09/xmldsig#base64auf), 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:
Untersucht wird nur das erste Verschlüsselungselement, welches die Auswertung des XPath-Ausdrucks in
sl:DecryptXMLRequest/sl:EncrElemsSelectorliefert; es gilt dabei die Reihenfolge des Auftretens im XML-Dokument (document-order);das so ermittelte Verschlüsselungselement wird entschlüsselt; die sich ergebenden Binärdaten werden anstatt einer XML-Antwort direkt und ohne weitere Kodierung als Antwort auf die Anfrage zurückgeschickt.
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/@MimeTypebzw.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 Abschnitt 3.4, „Entschlüsselung“ in
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 Abschnitt 8, „Profil für Hashwerte“ in
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 Abschnitt 3.5, „Hashwert-Berechnung“ in
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 Abschnitt 3.6, „Hashwert-Verifikation“ in
Die Bürgerkarten-Umgebung stellt der Applikation einen Datenspeicher zur Verfügung, der logisch in sogenannte Infoboxen gegliedert ist. Eine Infobox ist dabei als Datencontainer für eine Menge zusammengehöriger Daten zu sehen.
Physikalisch können sich solche Infoboxen entweder direkt auf dem Bürgerkarten-Token befinden, oder aber auch an einem anderen Platz, der unter Kontrolle der Bürgerkarten-Umgebung steht; beispielsweise auf der Festplatte des lokalen Hosts, auf dem die Bürgerkarten-Umgebung ausgeführt wird. Für die Applikation ist diese Unterteilung aber nicht sichtbar; ihr ist lediglich die logische Sicht der Infobox als Datencontainer in der Bürgerkarten-Umgebung bekannt.
Es obliegt der Bürgerkarten-Umgebung, den Zugriff auf Daten in einer Infobox gegebenenfalls durch geeignete Maßnahmen zu schützen. Für Daten, die auf dem Bürgerkarten-Token abgelegt werden, können etwa die dort vorhanden Schutzmechanismen (PIN, Schlüssel) verwendet werden. Ähnliche Mechanismen sind auch zum Schutz von sensiblen Daten denkbar, die von der Bürgerkarten-Umgebung auf der Festplatte verwaltet werden.
Die Schnittstelle Security-Layer bietet folgende Kommandos für den Zugriff auf Daten in Infoboxen:
Abfrage von verfügbaren Infoboxen
Lesen von Daten in einer Infobox
Verändern von Daten in einer Infobox
Anmerkung
Für Beispiele zu diesem Befehl siehe Tutorium; für
Anforderungen an die Benutzerschnittstelle siehe Abschnitt 3.7, „Infoboxen“ in
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.5.1, „Anfrage“) ü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.5.2, „Antwort“) 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.6.2, „Antwort“) 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.1, „Leseparameter und Antwortdaten“) 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.
Die Antwortdaten (sl:AssocArrayData) enthalten
den angegebenen Schlüssel (Attribut Key in sl:Pair)
sowie den dazugehörigen Wert (Inhalt von sl:Pair).
Die Kodierung des Werts hängt vom oben besprochenen Attribut
ValueIsXMLEntity ab. Sie erfolgt entweder als
geparstes XML (sl:XMLContent) oder als base64
(sl:Base64Content).
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.2, „Update-Parameter 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.2.2, „Antwort“) 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 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
Abschnitt 2.1, „Authentisierungsklassen“ in 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.
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.
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 Abschnitt 7.2, „Abfrage der verfügbaren Infoboxen“ 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, „Typen von Infoboxen“.
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, „Typen von Infoboxen“.
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 Abschnitt 7.2, „Abfrage der verfügbaren Infoboxen“ 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, „Typen von Infoboxen“.
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 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 Abschnitt 3.8, „Abfrage von Eigenschaften“ in
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 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.Anmerkung
Für jedenfalls von einer Bürgerkarte zu unterstützende Anzeigeformate siehe das Spezifikationsdokument Minimale Umsetzung des Security-Layers.
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.Anmerkung
Für jedenfalls von einer Bürgerkarte zu unterstützende Transformationen siehe das Spezifikationsdokument Minimale Umsetzung des Security-Layers.
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 (AttributSignature) bzw. Verschlüsselung (AttributEncryption) geeignet ist.Anmerkung
Für jedenfalls von einer Bürgerkarte zu unterstützende Schlüsselpaarbezeichner siehe das Spezifikationsdokument Standardisierte Key- und Infoboxen.
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.Anmerkung
Für Bezeichner und mögliche Parameter siehe Dokument Transportprotokolle Security-Layer. Für jedenfalls von einer Bürgerkarte zu unterstützende Transportprotokolle siehe das Spezifikationsdokument Minimale Umsetzung des Security-Layers.
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, ist1.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 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 vergleicheZugriffschutz).
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 Abschnitt 3.9, „Null-Operation“ in
Stapelsignaturen sind einzelne von einander unabhängige Signaturen, die auf dem gleichen Schlüsselpaar beruhen, und deren Erzeugung durch die einmalige Eingabe des Autorisierungscodes (PIN-Code) ausgelöst wird.
Bei einer Bulk-Anfrage werden mehrere einzelne Anfragen vom gleichen Typ zu einer Anfrage zusammengefasst. Bulk-Anfragen sind nur dann sinnvoll, wenn die Zusammenfassung mehrere Einzelanfragen eine Auswirkung auf die Interaktion mit dem Benutzer hat. In allen anderen Fällen können mehrere sequentielle Einzelanfragen verwendet werden.
Die Bulk-Anfrage enthält pro Einzelanfrage ein optionales Attribut, mit dem ein Name zur Anzeige durch die Bürgerkartensoftware übergeben werden kann.
Bulk-Anfragen werden durch entsprechende Bulk-Antworten beantwortet,
wobei für jede in der Bulk-Anfrage enthaltene Einzelanfrage eine
entsprechende Einzelantwort in der Bulk-Antwort vorhanden sein muss. Die
Zuordnung von Einzelanfragen zur Einzelantworten basiert auf der
Reihenfolge in der Bulk-Anfrage bzw. Bulk-Antwort. Um die Zuordnung von
Einzelanfragen zu Einzelantworten zu erleichtern und die Selektion von
einzelnen Anfragen oder Antworten in einer Bulk-Anfrage bzw. einer
Bulk-Antwort über XML-Mechanimen zu vereinfachen, kann für jede
Einzelanfrage ein Id-Attribut (vom Typ xsd:ID) gesetzt werden.
Die Einzelantwort einer Bulk-Antwort enthält dann die Id der
entsprechenden Einzelanfrage. Die Reihenfolge der Einzelantworten muss
jedoch auch bei gesetztem Id-Attribut der Reihenfolge der Einzelanfragen
entsprechen.
Bei der Fehlerbehandlung von Bulk-Anfragen ist zwischen Fehlern die Bulk-Anfrage selbst oder Einzelanfragen aus der Bulk-Anfrage betreffen zu unterscheiden. Tritt im Zuge der Abarbeitung einer Bulk-Anfrage ein Fehler bei der Bearbeitung einer Einzelanfrage auf, dann wird eine Fehler-Antwort an die entsprechende Position in die Bulk-Antwort aufgenommen. Kann die gesamte Bulk-Anfrage nicht korrekt verarbeitet werden, dann wird anstelle einer Bulk-Antwort eine Fehler-Antwort mit einem entsprechenden Fehlercode (3xxx) zurückgegeben.
Signatur-Bulk-Anfragen bestehen aus einzelnen Signatur-Anfragen,
wobei CMS- und XML-Signatur-Anfragen gemeinsam verwendet werden können.
Die einzelnen Signatur-Anfragen MÜSSEN sich jedoch auf denselben
Signaturschlüssel beziehen. Daher MUSS bei Bulk-Anfragen der Bezeichner
des für die Signaturerstellung zu verwendenden Schlüssels
(sl:KeyboxIdentifier) bei allen Einzelanfragen gleich sein. Stimmt der
Bezeichner nicht bei allen Einzelanfragen überein, wird anstelle der
Bulk-Antwort eine Fehlerantwort mit dem Fehlercode 3003 (XML-Struktur
der Befehlsanfrage enthält eine unerlaubte Kombination aus optionalen
Elementen oder Attributen) zurückgegeben.
Bei einer Signatur-Bulk-Anfrage MUSS durch die Bürgerkartensoftware eine Liste der zu signierenden Daten angezeigt werden. Die Bürgerkartensoftware MUSS die Möglichkeit bieten, einzelne zu signierende Daten wie bei einer einzelnen Signatur-Anfrage darzustellen. Mit der Eingabe des PIN-Codes wird die Signatur für alle zu signierenden Daten ausgelöst. Die Bürgerkartensoftware DARF dem Signator zusätzlich die Möglichkeit bieten, einzelne Daten von der Signatur auszunehmen. Anstelle der Signatur-Antwort MUSS in der Bulk-Antwort dann eine Fehler-Antwort mit dem Fehlercode 6001 (Abbruch durch den Bürger über die Benutzerschnittstelle) an entsprechender Stelle übermittelt werden.
Als Antwort auf eine Signatur-Bulk-Anfrage wird eine Signatur-Bulk-Antwort zurückgegeben. Die Reihenfolge der Einzelantworten in der Signatur-Bulk-Antwort MUSS der Reihenfolge der Einzelanfragen in der Signatur-Bulk-Antwort entsprechen.
Eine Signaturprüfungs-Bulk-Anfrage fasst mehrere CMS- und XML-Signaturprüfungsanfragen zu einer Anfrage zusammen. Bei einer Bulk-Anfrage MUSS das Ergebnis der Signaturprüfung für jede einzelne Signatur in einer Liste angezeigt werden. Der Benutzer erhält so die Möglichkeit, das Ergebnis und die signierten Daten jeder einzelnen Signatur zu überprüfen.
Mittels der CardMangement-Anfrage kann der PIN-Status einer Chipkarte abgefragt bzw. geändert werden.
Die Anfrage sl:CardManagementRequest enthält
einen oder mehrere sl:CardAction-Einträge. Deren Parameter
Action kann folgende Werte einnehmen:
ActivatePIN: PIN aktivierenChangePIN: PIN ändernUnblockPIN: PIN-Sperre aufhebenReadPINStatus: PIN-Status auslesen
Auf welche Smartcard-Applikation die angegebene Action
angewendet werden soll, wird über den Parameter
ApplicationIdentifier angegeben. Dafür sind folgende Werte
erlaubt:
SecureSignatureApplicationCertifiedApplicationInfoboxApplication
Die Reihenfolge der Abarbeitung dieser Befehle bleibt der Bürgerkarten-Umgebung überlassen; somit darf sich die aufrufende Applikation nicht darauf verlassen, dass die Befehle in der angegebenen Reihenfolge ausgeführt werden.
Die Antwort sl:CardManagementResponse enthält die
selben sl:CardAction-Einträge wie die Anfrage. Im Parameter
Result wird das Ergebnis angegeben. Dabei sind folgende
Werte möglich:
OKErrorBlocked: PIN ist gesperrt, zu viele FehleingabenActiveInactive
Der Parameter ApplicationIdentifier entspricht der
Anfrage.
Über den Parameter RetryCount kann die Anzahl der
übrigen Versuche (z.B. bei PIN-Änderung) übergeben werden.
Mit der CardChannel-Anfrage sl:CardChannelRequest
können CardChannel-Scripte an die Karte übertragen und ausgeführt
werden.
Der Eintrag sl:Script enthält das auszuführende
CardChannel-Script. Dieses besteht aus folgenden Einträgen, die beliebig
oft vorkommen dürfen:
sl:Resetmit dem optionalen Parametercold. Führt einen warm reset, bzw., wenn der Parametercoldauf true gesetzt ist, einen cold reset der Karte durch.sl:CommandAPDUmit den Parameternsequenceundof, sowie dem optionalen ParameterexpectedSW. Dieser Eintrag enthält eine Command-APDU, die auf der Karte ausgeführt werden soll. Dabei gibt der Parametersequencean, an welcher Stelle dieses Kommando ausgeführt werden soll, und der Parameterof, wieviele Kommandos insgesamt enthalten sind. Hierbei dürfen keine Zahlen ausgelassen werden, jedersl:CommandAPDU-Eintrag muss den selben Parameterofbesitzen, und ebensoviele durchnummerierte Einträge müssen vorhanden sein. Der ParameterexpectedSWkann die von der Karte erwarteten Status-Antwort auf die jeweilige Anfrage enthalten.
Die Antwort sl:CardChannelResponse enthält im
Eintrag sl:Response das Resultat des ausgeführten
Scripts.
Auf jede sl:Reset-Anfrage wird mit der entsprechenden
"Answer to reset" (ATR) im Element ATR geantwortet. Der
Parameter rc enthält einen Resultat-Code, der bei
fehlerfreier Bearbeitung auf 0 gesetzt wird.
Auf jede sl:CommandAPDU-Anfrage wird mit einer
sl:ResponseAPDU geantwortet. Diese enthält den selben
sequence-Parameter wie die entsprechende Anfrage. Weiters
enthält der Parameter rc einen Resultat-Code, der wiederum
bei fehlerfreier Bearbeitung auf 0 gesetzt wird.
Schließlich enthät der Parameter SW die Status-Bytes SW1 und
SW2 mit denen die Karte auf das APDU-Kommando geantwortet hat.
Wurde bei der sl:CommandAPDU der Parameter
expectedSW angegeben, so wird dieser Status mit dem
erwarteten verglichen - sollten diese nicht übereinstimmen, so wird die
Ausführung abgebrochen, und es dürfen keine weiteren APDU-Kommandos mehr
gesendet werden. Die sl:CardChannelResponse enthält alle
Einträge bis zu (inklusive) dem Kommando mit der unerwarteten Antwort.
Sollte innerhalb der Bürgerkarten-Umgebung ein Fehler auftreten der die korrekte Beantwortung einer Anfrage verhindert, MUSS anstatt der zur Anfrage gehörenden Antwort eine Fehler-Antwort an die Applikation zurückgeschickt werden.
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.
Glossar
- Applikation
Jenes Programm, das Anfragen an die Bürgerkarten-Umgebung über den Security-Layer richtet und die entsprechenden Antworten entgegennimmt und auswertet.
- Benutzer-Schnittstelle
Jene Schnittstelle, über die der Bürger mit der Bürgerkarten-Umgebung kommuniziert. Über diese Schnittstelle wird einerseits die Benutzerinteraktion abgewickelt, die gegebenenfalls zur Abwicklung eines Befehls des Security-Layers notwendig ist (z.B. die Anzeige eines zu signierenden Dokuments beim Befehl zur Erzeugung einer XML-Signatur); andererseits kann der Bürger über diese Schnittstelle seine Bürgerkarten-Umgebung nach seinen persönlichen Bedürfnissen konfigurieren (z.B. kann er Einstellungen zum Zugriffsschutz auf seine Infoboxen verändern). Die Vorgaben an die Benutzer-Schnittstelle sind in Minimale Umsetzung des Security-Layers geregelt.
- Bürger
Jene Person, die die Funktionen der Bürgerkarten-Umgebung für die sichere Abwicklung von E-Government oder E-Commerce verwenden möchte. Die Ansteuerung der Bürgerkarten-Umgebung erfolgt in der Regel nicht durch den Bürger selbst, sondern durch die Applikation, welche die E-Government oder E-Commerce Anwendung repräsentiert.
- Bürgerkarte
Laut [E-GovG], §10 ZI 10 ist die Bürgerkarte „die unabhängig von der Umsetzung auf unterschiedlichen technischen Komponenten gebildete logische Einheit, die eine elektronische Signatur mit einer Personenbindung (§ 4 Abs. 2) und den zugehörigen Sicherheitsdaten und -funktionen sowie mit allenfalls vorhandenen Vollmachtsdaten verbindet“. Im Sinne der in den Spezifikationen zur österreichischen Bürgerkarte gebrauchten Terminologie ist die Bürgerkarten-Umgebung die Implementierung der logischen Einheit Bürgerkarte.
- Bürgerkarten-Umgebung
Jenes Programm bzw. jener Dienst, der die Funktionalität der Bürgerkarte zur Verfügung stellt. Grundsätzlich vorstellbar ist die Ausführung als Programm, das lokal am Rechner des Bürgers läuft (lokale Bürgerkarten-Umgebung), oder als serverbasierter Dienst, der über das Internet angesprochen wird (serverbasierte Bürgerkarten-Umgebung). Die Interaktion mit diesem Programm bzw. Dienst wird über zwei Schnittstellen abgewickelt: Über die Benutzer-Schnittstelle sowie über den Security-Layer.
- Hash-Eingangsdaten
Jene Daten, die für die Berechnung des Hash-Wertes für eine
dsig:Referenceverwendet werden. Sind für diedsig:ReferenceTransformationen angegeben, entsprechen diese Daten dem Ergebnis der letzten Transformation. Sind keine Transformationen spezifiziert, gleichen die Hash-Eingangsdaten den Referenz-Eingangsdaten.- Impliziter Transformationsparameter
Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“
- Referenz-Eingangsdaten
Jene Daten, die sich aus der Auflösung der im Attribut
URIderdsig:Referenceangegebenen URI ergeben. Sind für diedsig:ReferenceTransformationen angegeben, werden diese Daten als Eingangsdaten zur Berechnung der ersten Transformation verwendet. Sind keine Transformationen spezifiziert, gleichen die Referenz-Eingangsdaten den Hash-Eingangsdaten.- Security-Layer
Jene Schnittstelle, über die die Applikation mit der Bürgerkarten-Umgebung kommuniziert. Das genaue Protokoll, das über diese Schnittstelle gesprochen werden kann, wird in Applikationsschnittstelle Security-Layer spezifiziert. Die möglichen Bindungen dieses Protokolls an Transportschichten wie HTTP oder TCP wird in Transportprotokolle Security-Layer geregelt.
- Signaturmanifest
Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“ .
[BSI TR-03111] Bundesamt für Sicherheit in der Informationstechnik: Technical Guideline TR-03111: Elliptic Curve Cryptography, Technical Guideline, Juni 2012
[CAdES] European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES) v2.2.1 , Technical Specification, April 2013
[CAdES-Baseline] European Telecommunications Standards Institute: ETSI TS 103173: Electronic Signatures and Infrastructures (ESI); CAdES Baseline Profile v2.2.1 , Technical Specification, April 2013
[CMS] Housley, R.: RFC 5652: Cryptographic Message Syntax (CMS) , IETF Request For Comment, September 2009
[CMS-AES] chaad, J.: RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS) . IETF Request For Comment, Juli 2003.
[CMS-Alg] Housley, R.: RFC 3370: Cryptographic Message Syntax (CMS) Algorithms . IETF Request For Comment, August 2002.
[CMS-RSAES-OAEP] Housley, R.: RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS) . IETF Request For Comment, Juli 2003.
[CSS 2] Bert Bos, Håkon Wium Lie, Chris Lilley und Ian Jacobs: Cascading Style Sheets, level 2 . W3C Recommendation, Mai 1998.
[EC14N] Boyer, John, Eastlake, Donald und Reagle, Joseph: Exclusive XML Canonicalization. W3C Recommendation, Juli 2002 .
[ECDSA-CMS] Turner, S., Brown, D.: RFC 5753: Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) . IETF Request For Comment, Jänner 2010.
[ECDSA-XML] Blake-Wilson, S., Karlinger, G. und Wang, Y.: ECDSA with XML-Signature Syntax . Internet-Draft, Jänner 2004.
[ESS-S/MIME] Hoffman, P.: RFC 2634: Enhanced Security Services for S/MIME , IETF Request For Comment, Juni 1999
[ETSICMS] European Telecommunications Standards Institute: ETSI TS 101733: Electronic Signature Formats, v1.5.1 , Technical Specification, Dezember 2003
[ETSIQCert] European Telecommunications Standards Institute: ETSI TS 101 862: Qualified certificate profile, v1.2.1 , Technical Specification, Juni 2001
[ETSIXML] European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.2.2 , Technical Specification, April 2004
[GIF] Graphics Interchange Format, Version 89a . CompuServe Incorporated, Juli 1990.
[HTML4] Dave Ragget, Arnaud Le Hors und Ian Jacobs: HTML 4.01 Specification . W3C Recommendation, Dezember 1999.
[HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leech und T. Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1. IETF Request For Comment, Juni 1999.
[HTTPS] E. Rescorla HTTP over TLS. IETF Request For Comment, Mai 2000
[ISO-8859-1] ISO/IEC 8859-1:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1.
[ISO-8859-10] ISO/IEC 8859-10:1998: Information technology -- 8-bit single-byte coded graphic character sets -- Part 10: Latin alphabet No. 6.
[ISO-8859-15] ISO/IEC 8859-15:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 15: Latin alphabet No. 9.
[ISO-8859-2] ISO/IEC 8859-2:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 2: Latin alphabet No. 2.
[ISO-8859-3] ISO/IEC 8859-3:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 3: Latin alphabet No. 3.
[ISO-8859-9] ISO/IEC 8859-9:1999: Information technology -- 8-bit single-byte coded graphic character sets -- Part 9: Latin alphabet No. 5.
[JPEG] Eric Hamilton: JPEG File Interchange Format, Version 1.02 . C-Cube Microsystems, September 1992.
[KEYWORDS] Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels , IETF Request For Comment, März 1997
[MIME] Freed, N. und Borenstein, N.: RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types , IETF Request For Comment, November 1996
[PAdES] European Telecommunications Standards Institute: ETSI TS 102778: Electronic Signatures and Infrastructures (ESI); PDF Advanced Electronic Signature Profiles v1.2.1 , Technical Specification, Juli 2010
[PersBin] Hollosi, Arno und Karlinger, Gregor: XML-Definition der Personenbindung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.2.2, 14. Februar 2005.
[PersonData] Naber, Larissa: PersonData Struktur - XML Spezifikation . Konvention zum E-Government Austria erarbeitet von der Arbeitsgruppe Kommunikationsarchitekturen. Öffentlicher Entwurf, Version 2.0.0, 14. Oktober 2004.
[PKCS#12] RSA Laboratories: PKCS#12 v1.0: Personal Information Exchange Syntax , Juni 1999.
[port-numbers] Internet Assigned Numbers Authority: Port Numbers
[QCert] Santesson, S. und Nystrom M.: RFC 3739: Internet X.509 Public Key Infrastructure: Qualified Certificates Profile , IETF Request For Comment, März 2004
[RFC 5035] Schaad, J.: RFC 5035: Enhanced Security Services (ESS) Update: Adding CertID Algorithm Agility , IETF Request For Comment, August 2007
[SHA2-CMS] Turner, S.: RFC 5754: Using SHA2 Algorithms with Cryptographic Message Syntax , IETF Request For Comment, Jänner 2010
[Stammzahl] Hollosi, Arno und Hörbe, Rainer: Bildung von Stammzahl und bereichsspezifischem Personenkennzeichen (bPK) . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards sowie vom Bundesminsterium für Inneres. Öffentlicher Entwurf, Version 1.0, 2. Februar 2004.
[TLS] T. Dierks und C. Allen: The TLS Protocol Version 1.0 . IETF Request For Comment, Januar 1999.
[Unicode] The Unicode Consortium. The Unicode Standard, Version 4.0.0 , defined by: The Unicode Standard, Version 4.0 (Boston, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1).
[URI] Berners-Lee, T. , Fielding, R. und Masinter, L.: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax , IETF Request For Comment, August 1998
[VerwEig] Hollosi, Arno: X.509 Zertifikatserweiterungen für die Verwaltung . Konvention zum E-Government Austria erarbeitet von der Stabsstelle IKT-Strategie des Bundes, Technik und Standards. Öffentlicher Entwurf, Version 1.0.3, 21. Februar 2005.
[X509] Polk, W., Ford, W., Solo, D.: RFC 3280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile . IETF Request For Comment, April 2002.
[XAdES] European Telecommunications Standards Institute: ETSI TS 101903: XML Advanced Electronic Signatures (XAdES), v1.4.2 , Technical Specification, Dezember 2010
[XHTML 1.1] Murray Altheim, Frank Boumphrey, Sam Dooley, Shane McCarron, Sebastian Schnitzenbaumer und Ted Wugofski: Modularization of XHTML . W3C Recommendation, April 2001.
[XHTML MOD] Daniel Austin, Subramanian Peruvemba, Shane McCarron, Masayasu Ishikawa: Modularization of XHTML in XML Schema . W3C Working Draft, Oktober 2003.
[XML] Bray, Tim, Paoli, Jean, Sperberg-McQueen, C.M. und Maler, Eve: Extensible Markup Language (XML) 1.0 (Second Edition) , W3C Recommendation, Oktober 2000.
[XMLDecTF] Hughes, Merlin, Imamura, Takeshi und Maruyama, Hiroshi: Decryption Transform for XML Signature . W3C Recommendation, Dezember 2002.
[XMLDSIG] Eastlake, Donald, Reagle, Joseph und Solo, David: XML-Signature Syntax and Processing , W3C Recommendation, Februar 2002
[XMLDSIG-URI] Eastlake, Donald: RFC 4051: Additional XML Security Uniform Resource Identifiers (URIs) , IETF Request For Comments, April 2005
[XMLEnc] Eastlake, Donald und Reagle, Joseph: XML Encryption Syntax and Processing , W3C Recommendation, Dezember 2002
[XML-Schema] Thompson, Henry S., Beech, David, Maloney, Murray und Mendelson, Noah: XML Schema Part 1: Structures , W3C Recommendation, Mai 2001
[XMLTYPE] Murata, M., St.Laurent, S., und Kohn, D.: RFC 3023: XML Media Types , IETF Request For Comment, Jänner 2001.
[XPath] Clark, James und DeRose, Steven: XML Path Language , W3C Recommendation, November 1999
[XPF2] Boyer, John, Hughes, Merlin und Reagle, Joseph: XML-Signature XPath Filter 2.0 . W3C Candidate Recommendation, Juli 2002.
[XPointer] Grosso, Paul, Maler, Eve, Marsh, Jonathan und Walsh, Norman: XPointer Framework . W3C Recommendation, März 2003.
[XSS-FAQ] Cgisecurity.com: The Cross Site Scripting FAQ .
A. Historie
| Datum | Version | Änderungen |
|---|---|---|
| 26.05.2015 | 1.2.8 |
|
| 22.07.2013 | 1.2.7 |
|
| 22.04.2013 | 1.2.6 |
|
| 15.04.2013 | 1.2.5 |
|
| 20.08.2009 | 1.2.4 |
|
| 20.02.2008 | 1.2.3 |
|
| 01.03.2005 | 1.2.2 |
|
| 29.06.2004 | 1.2.1 |
|
| 14.05.2004 |
| |
| 31.08.2002 |
| |
| ||
| 24.04.2002 |
|