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.
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ür sl:XMLContent
das Attribut
xml:space
mit dem Wert preserve
versehen werden. Das Inhaltsmodell von
sl:XMLContent
ist so definiert, dass es eine
beliebige Mischung aus Text und XML-Markup erlaubt. Das
schließt ausdrücklich auch reinen Text mit ein. Eine gültige
Instanz von sl:XMLContent
ist also beispielsweise
auch
<sl:XMLContent>Text</sl:XMLContent>
.
sl:LocRefContent
: Enthält eine Referenz auf
das Datenobjekt, die von der Bürgerkarten-Umgebung
aufzulösen ist, um das Datenobjekt zu erhalten.
(2) Die Einbindung eines im Fall
A oder B übergebenen Datenobjekts in die XML-Signatur bzw. die
Referenzierung auf dieses in die Signatur eingebundene Datenobjekt
aus dem zugehörigen dsig:Reference
Element der
XML-Signatur muss so erfolgen, dass ausschließlich die im Request
in sl:DataObject
übergebenen Daten signiert
werden.Wird beispielsweise das Datenobjekt als Inhalt eines
dsig:Object
Elements in die XML-Signatur eingebunden,
darf dieses dsig:Object
Containerelement nicht
mitsigniert werden, sondern lediglich sein Inhalt.
(3) Wenn das
Datenobjekt base64-kodiert vorliegt (Verwendung des Elements
sl:Base64Content
in sl:DataObject
),
MÜSSEN jedenfalls die base64-dekodierten
Daten signiert werden. 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
).
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:Supplement
s) 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:Supplement
innerhalb jenes
sl:DataObjectInfo
vorkommt, das den gerade
berechneten Transformationsprozess spezifiziert. Ist diese
Prüfung erfolgreich, sind die in diesem
sl:Supplement
angegebenen Daten als Ergebnis der
Auflösung zu verwenden. Ansonsten ist mit Schritt 2
fortzufahren.
Prüfung, ob die aufzulösende Referenz in einem
sl:Supplement
eines anderen
sl:DataObjectInfo
vorkommt, das im Befehl zur
Erzeugung der XML-Signatur spezifiziert wurde. Die einzelnen
sl:DataObjectInfo
-Elemente sind dabei in jener
Reihenfolge zu untersuchen, in der Sie im Befehl angegeben
wurden. Die im ersten so gefundenen sl:Supplement
angegebenen Daten sind als Ergebnis der Auflösung zu
verwenden. Wird kein sl:Supplement
gefunden, ist
mit Schritt 3 fortzufahren.
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“.
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.
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:Supplement
s) 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.
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
SigningTime
nach [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:SubjectName
enthält den Namen des
Signators aus dem Signatorzertifikat. Das Element ist wie in
[XMLDSIG], Kapitel 4.4.4 angegeben zu kodieren.
In dsig:X509Data
MUSS genau
ein solches Element vorkommen.
dsig:IssuerSerial
enthält den Namen des
Austellers und die Seriennummer des Signatorzertifikats. Das
Element ist wie in [XMLDSIG], Kapitel 4.4.4
angegeben zu kodieren. In dsig:X509Data
muss genau
ein solches Element vorkommen.
Weiters muss dieses dsig:X509Data
das leere Element
sl:QualifiedCertificate
enthalten, wenn das
Signatorzertifikat als qualifiziert anzusehen ist. Dazu müssen
folgende Bedingungen erfüllt sein:
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. |
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:SigningTime
nach [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.
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.
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:Reference
Elements der Signatur referenziert
wird;
referenzierte Parameter für die Transformationen in einem
dsig:Reference
Elements der Signatur (z. B. ein
Stylesheet, der im Basis-Stylesheet einer XSLT-Transformation
referenziert wird);
referenzierte Informationen für die Validierung des Dokuments, das die Signatur beinhaltet (Verweis in der Document Type Declaration, Verweise auf XML-Schemata mittels der in [XML-Schema], Abschnitt 2.6.3 angegebenen Mechanismen);
referenzierte Informationen für die Aufindung des für die Signaturprüfung zu verwendenden Zertifikats (vergleiche [XMLDSIG], Abschnitt 4.4.3).
Für ein Ergänzungsobjekt (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.
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:X509Data
Element, das wiederum
mindestens drei Elemente enthalten
MUSS:
dsig:SubjectName
enthält den Namen des
Signators aus dem Signatorzertifikat. Das Element ist wie in
[XMLDSIG], Kapitel 4.4.4 angegeben zu
kodieren. In dsig:X509Data
MUSS genau ein solches Element
vorkommen.
dsig:IssuerSerial
enthält den Namen des
Austellers und die Seriennummer des Signatorzertifikats. Das
Element ist wie in [XMLDSIG], Kapitel 4.4.4
angegeben zu kodieren. In dsig:X509Data
MUSS genau ein solches Element
vorkommen.
Weiters muss dsig:X509Data
das leere
Element sl:QualifiedCertificate
enthalten, wenn
das Signatorzertifikat als qualifiziert anzusehen ist. Dazu
müssen folgende Bedingungen erfüllt sein:
Ob weitere Elemente - wie beispielsweise das Signatorzertifikat selbst - zurückgeliefert werden, bleibt der Bürgerkarten-Umgebung überlassen. Konnte bei der Überprüfung kein Signatorzertifikat nach X.509 identifiziert werden, bleibt es ebenfalls der Bürgerkarten-Umgebung überlassen, welche Informationen über den öffentlichen Schlüssel sie zurückliefert.
Weiters enthält die Antwort getrennte Ergebnisse für die
kryptographische Überprüfung der Signatur
(sl:SignatureCheck
), für die Prüfung des Signaturmanifests
(sl:SignatureManifestCheck
), für die Überprüfung ggf.
vorhandener weiterer Manifeste (sl:XMLDSIGManifestCheck
),
sowie für die Prüfung der Signaturprüfdaten
(sl:CertificateCheck
).
Alle vier Ergebnisse besitzen eine ähnliche Struktur: Das
Element sl:Code
enthält das Ergebnis der Prüfung in
maschinenlesbarer Form, das Element sl:Info
kann
genauereZusatzinfomationen enthalten (siehe dazu die folgenden
Unterabschnitte).
Diese hat wie in [XMLDSIG] spezifiziert zu
erfolgen. Das bedeutet, das sowohl der Hash-Wert jedes
dsig:Reference
Elements als auch der Wert der Signatur
(dsig:SignatureValue
) zu überprüfen sind. Nicht zu
überprüfen sind die Hash-Werte der Referenzelemente
(dsig:Reference
) in gegebenenfalls vorhandenen
Manifesten (dsig:Manifest
).
Wurde die in der Anfrage spezifizierte Signatur konform zu
dieser Spezifikation erstellt, so enthält sie für jedes signierte
Datenobjekt ein Signaturattribut etsi:DataObjectFormat
nach [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.
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/@Reference
enthält die entsprechende URL, der Inhalt von
sl:ToBeEncrypted
bleibt leer.
Die zu verschlüsselnden Daten werden direkt an die
Bürgerkarten-Umgebung
übergeben: sl:ToBeEncrypted/sl:Content
enthält die
Daten in base64-kodierter Form,
sl:ToBeEncrypted/sl:Content/@Reference
wird nicht
verwendet.
Das Attribut
sl:EncryptCMSRequest/@ReturnBinaryResult
kann schlielich
optional angegeben werden, um die Art der Antwort auf die Anfrage zu
steuern (vgl. Abschnitt 4.1.2, „Antwort“).
Die Bürgerkarten-Umgebung erstellt aus den Angaben der Anfrage eine CMS-Nachricht mit EnvelopedData Inhalt. Dabei MUSS sie folgende Vorgaben einhalten:
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.
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 Element
xenc:EncryptedData
ersetzt.
sl:Element/@Selector
enthält einen Ausdruck nach
[XPath], mit dem das zu verschlüsselnde Element
innerhalb des bestehenden XML-Dokuments eindeutig ausgewählt wird.
Der Kontextknoten für die Evaluierung des Ausdrucks ist dabei der
Dokument-Knoten des XML-Dokuments. Namenraum-Präfixe, die im
Ausdruck verwendet werden, müssen im Kontext von
sl:Element/@Selector
bekannt sein. Wird
sl:Element/@EncDataReference
angegeben,
DÜRFEN die verschlüsselten Daten von der
Bürgerkarten-Umgebung
NICHT base64-kodiert in das entsprechende
Element xenc:EncrpytedData
aufgenommen, sondern
MÜSSEN stattdessen referenziert werden.
Als Referenz MUSS dabei die in
sl:Element/@EncDataReference
angegebene URI verwendet
werden.
Wird sl:Element
verwendet, muss ein
bestehendes XML-Dokument angegeben werden (siehe unten).
sl:ElementContent
: Der Inhalt eines Elements
eines bestehenden XML-Dokuments wird von der Bürgerkarten-Umgebung
verschlüsselt und durch ein entsprechendes Element
xenc:EncryptedData
ersetzt. Die Bedeutung der
Attribute sl:ElementContent/@Selector
und
sl:ElementContent/@EncDataReference
ist die gleiche
wie jene der entsprechenden Attribute in
sl:Element
.
Wird diese sl:ElementContent
verwendet, muss
ein bestehendes XML-Dokument angegeben werden (siehe
unten).
sl:New
: Beliebige Daten sollen verschlüsselt
und als Element xenc:EncryptedData
in ein bestehendes
oder neues XML-Dokument eingefügt werden. Der Ort, an dem das
erzeugte xenc:EncryptedData
in das XML-Dokument
eingefügt werden soll, wird durch die Attribute
sl:New/@ParentSelector
und
sl:New/@NodeCount
angegeben.
sl:New/@ParentSelector
selektiert das Eltern-Element
des zukünftigen xenc:EncryptedData
mittels eines
Ausdrucks nach [XPath]; der Kontextknoten für
die Evaluierung des Ausdrucks ist dabei der Dokument-Knoten des
XML-Dokuments. Namenraum-Präfixe, die im Ausdruck verwendet
werden, müssen im Kontext von sl:New/@ParentSelector
bekannt sein. sl:New/@NodeCount
enthält die Angabe,
als wievielter Knoten xenc:EncryptedData
ins
Eltern-Element einzufügen ist, wobei mit Null zu zählen begonnen
wird. Die zu verschlüsselnden Daten sowie Metainformationen dazu
werden als Inhalt von sl:New
angegeben. Jedenfalls an
Metainformationen spezifiziert werden
MUSS der Mime-Type (siehe
[MIME]) der zu verschlüsselnden Daten
(sl:New/sl:MetaInfo/sl:MimeType
); diese Information
benötigt die Bürgerkarten-Umgebung
im Rahmen der gegebenenfalls vorzunehmenden Anzeige der zu
verschlüsselnden Daten. Weiters DARF eine
verbale Beschreibung dieser Daten angegeben werden
(sl:New/sl:MetaInfo/sl:Description
). Für die Angabe
der eigentlichen zu verschlüsselnden Daten stehen drei
Möglichkeiten zur Verfügung:
sl:New/sl:Content/sl:Base64Content
enthält die zu
verschlüsselnden Daten in base64-kodierter Form; diese
MÜSSEN von der Bürgerkarten-Umgebung
dekodiert werden, bevor die Verschlüsselung durchgeführt wird.
sl:New/sl:Content/sl:XMLContent
enthält die zu
verschlüsselnden Daten als XML-Fragment.
sl:new/sl:Content/sl:LocRefContent
enthält eine
Referenz, die von der Bürgerkarten-Umgebung
aufgelöst werden MUSS, um zu den zu
verschlüsselnden Daten zu gelangen. Die Bedeutung des Attributs
sl:New/sl:Content/@EncDataReference
ist die gleiche
wie jene des entsprechenden Attributs in
sl:Element
.
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:Element
bzw.
sl:ToBeEncrypted/sl:ElementContent
),
MUSS das Attribut
xenc:EncryptedData/@Type
auf den Wert
http://www.w3.org/2001/04/xmlenc#Element
bzw.
http://www.w3.org/2001/04/xmlenc#Content
gesetzt
werden. Ansonsten DARF dieses Attribut
NICHT verwendet werden.
In xenc:EncryptedData/xenc:EncryptionMethod
MUSS einer der in Abschnitt 7.1.1, „Algorithmen“ in
Das Element xenc:EncryptedData/ds:KeyInfo
MUSS von der Bürgerkarten-Umgebung
verwendet werden und alle in der Anfrage angegebenen öffentlichen
Schlüssel referenzieren (falls in der Anfrage das Element
sl:EncryptionInfo/sl:EncryptedKeyLocation
verwendet
wurde) bzw. enthalten (sonst).
Im Falle der direkten Beinhaltung
MUSS die Bürgerkarten-Umgebung
in ds:KeyInfo
pro in der Anfrage angegebenen
öffentlichen Schüssel ein xenc:EncrypedKey
Element
verwenden. Dabei müssen folgende Bedingungen eingehalten
werden:
In xenc:EncryptedKey/xenc:EncryptionMethod
MUSS einer der in Abschnitt 7.2.1.2, „Algorithmen für xenc:EncryptedKey
“ in
Das Element xenc:EncryptedData/ds:KeyInfo
MUSS von der Bürgerkarten-Umgebung
wie folgt verwendet werden:
Enthält
xenc:EncryptedKey/xenc:EncryptionMethod
einen
Algorithmus zur asymmetrischen Verschlüsselung
(Schlüsseltransport), so MUSS
xenc:EncryptedData/ds:KeyInfo
genau ein
ds:KeyValue
Element mit der Kodierung des
öffentlichen Schlüssels enthalten.
Enthält
xenc:EncryptedKey/xenc:EncryptionMethod
einen
Algorithmus zur symmetrischen Verschlüsselung (Symetric
Key Wrap), so MUSS
xenc:EncryptedData/ds:KeyInfo
genau ein
xenc:AgreementMethod
Element mit einem der in
Abschnitt 7.2.1.3, „Algorithmen für xenc:KeyAgreement
“ in xenc:AgreementMethod/ds:DigestMethod
MUSS einen unter Abschnitt 5.1.1, „Digest-Algorithmen“ in xenc:AgreementMethod/xenc:RecipientKeyInfo
MUSS genau ein Element
ds:KeyValue
mit der Kodierung des
öffentlichen Schlüssels enthalten. Das Element
xenc:AgreementMethod/xenc:OriginatorKeyInfo
MUSS genau ein Element
ds:KeyValue
mit der Kodierung des
öffentlichen Schlüssels enthalten.
xenc:EncryptedData/xenc:CipherData/xenc:CipherValue
enthält den verschlüsselten symmetrischen Schlüssel zur
Datenverschlüsselung.
Im Falle der Referenzierung MUSS
die Bürgerkarten-Umgebung
in ds:KeyInfo
pro in der Anfrage angegebenen
öffentlichen Schüssel ein ds:RetrievalMethod
Element
verwenden. Dabei müssen folgende Bedingungen eingehalten
werden:
Das Attribut ds:RetrievalMethod/@Type
muss
auf den Wert
http://www.w3.org/2001/04/xmlenc#EncryptedKey
gesetzt werden.
Das Attribut ds:RetrievalMethod/@URI
muss
auf das referenzierte xenc:EncryptedKey
Element
verweisen.
Für das referenzierte xenc:EncryptedKey
Element gelten die Bedingungen für die direkte
Beinhaltung.
Das Element xenc:EncryptedData/xenc:CipherData
muss die mit dem symmetrischen Verschlüsselungsschlüssel
verschlüsselten Daten referenzieren (wenn im entsprechenden
sl:ToBeEncrypted
Element der Anfrage wurde in
sl:Element
bzw. sl:ElementContent
bzw.
sl:New
das Attribut EncDataReference
gesetzt wurde) bzw. direkt beinhalten (sonst). Im Falle der
Referenzierung muss die Bürgerkarten-Umgebung
das Element xenc:CipherData/xenc:CipherReference
verwenden.Dabei müssen folgende Bedingungen eingehalten
werden:
Transformationen dürfen nicht verwendet werden.
xenc:CipherReference/@URI
muss auf den in
sl:Element/@EncDataReference
bzw.
sl:ElementContent/@EncDataReference
bzw.
sl:New/@EncDataReference
angegebenen Wert gesetzt
werden.
Die verschlüsselten Daten sind in der Antwort in einem
sl:EncryptedData Element
zurückzuliefern.
sl:EncryptedData/@EncDataReference
muss auf den
in sl:Element/@EncDataReference
bzw.
sl:ElementContent/@EncDataReference
bzw.
sl:New/@EncDataReference
angegebenen Wert gesetzt
werden.
Wurde in der Anfrage ein XML-Dokument angegeben
(sl:EncryptionInfo/sl:EncryptionEnvironment
),
MUSS die Bürgerkarten-Umgebung
dieses XML-Dokument mit den folgenden Modifikationen in der Antwort
als Inhalt von
sl:EncryptXMLResponse/sl:EncryptionEnvironment
zurückliefern:
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
erzeugte xenc:EncryptedData
Element 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 erzeugte xenc:EncryptedData
Element
ersetzen.
Für jeden in der Anfrage spezifizierten, zu verschlüsselnden
neuen Inhalt (sl:ToBeEncrypted/sl:New
)
MUSS die Bürgerkarten-Umgebung
das entsprechend erzeugte xenc:EncryptedData
Element
an der spezifizierten Position
(sl:New/@ParentSelector
,
sl:New/@NodeCount
) in das XML-Dokument
einfügen.
Wurde in der Anfrage das Element
sl:EncryptionInfo/sl:EncryptedKeyLocation
verwendet,
MUSS die Bürgerkarten-Umgebung
an der darin spezifzizierten Position
xenc:EncryptedKey
Elemente für allen in der Anfrage
spezifizierten öffentlichen Schlüsseln der Empfänger
einfügen.
Wurde in der Anfrage kein XML-Dokument angegeben,
MUSS die Bürgerkarten-Umgebung
als Inhalt von
sl:EncryptXMLResponse/sl:EncryptionEnvironment
das für
den in der Anfrage spezifizierten, zu verschlüsselnden neuen Inhalt
(sl:ToBeEncrypted/sl:New
) erzeugte
xenc:EncryptedData
Element zurückliefern.
Kann die Bürgerkarten-Umgebung
die Verschlüsselung für zumindest ein in der Anfrage spezifiziertes
Datum (sl:ToBeEcnrypted
) nicht durchführen,
MUSS die Bürgerkarten-Umgebung
eine Fehler-Antwort (sl:ErrorResponse
) liefern.
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:MimeType
kann die Applikation den
Mime-Type der verschlüsselten Daten angeben;
diese Information MUSS von der Bürgerkarten-Umgebung
im Falle einer Binäranwort zur Angabe des
Mime-Types verwendet werden, falls dies im
verwendeten Transportprotokoll vorgesehen ist.
In sl:EncryptedContent/sl:Content
MUSS die Applikation den Wert des
Feldes encryptedContent (also die
verschlüsselten Daten) angeben, wenn dieses in der zu
entschlüsselnden CMS-Nachricht nicht enthalten ist. Sie kann dazu
entweder sl:Content/@Reference
oder
slContent/sl:Base64Content
verwenden.
sl:Content/@Reference
enthält eine URL, welche die
Bürgerkarten-Umgebung
zur Erlangung der verschlüsselten Daten auflösen muss.
slContent/sl:Base64Content
enthält die
verschlüsselten Daten in base64-kodierter Form.
Was die Kennzeichnung des Datenverschlüsselungsschlüssels betrifft, darf die Bürgerkarten-Umgebung von folgenden Voraussetzungen ausgehen, die von der Applikation eingehalten werden MÜSSEN:
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.
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/@Reference
zu verwenden.
Reference
muss eine von der Bürgerkarten-Umgebung
auflösbare URL sein. Der Inhalt von sl:
EncryptedContent
bleibt leer.
Soll das zu entschlüsselnde XML-Dokument hingegen
eingebettet werden, geschieht dies direkt als Inhalt von
sl:EncryptedContent/sl:Base64Content
bzw.
sl:EncryptedContent/sl:XMLContent
. Wird die erste
Variante verwendet, enthält sl:Base64Content
das
base64-kodierte XML-Dokument, in der zweiten Variante enthält
sl:XMLContent
als einzigen Knoten das Wurzel-Element
des XML-Dokuments. sl:EncryptedContent/@Reference
findet in beiden Fällen keine Verwendung.
Das zu entschlüsselnde XML-Dokument
DARF prinzipiell beliebig viele Elemente mit
verschlüsseltem Inhalt (xenc:EncryptedData
) enthalten.
Welche dieser verschlüsselten Elemente von der Bürgerkarten-Umgebung
tatsächlich entschlüsselt werden sollen, ist mit dem Element
sl:EncrElemsSelector
anzugeben. Sein Inhalt spezifiziert
einen Ausdruck nach [XPath], dessen Auswertung eine
Knotenmenge mit beliebig vielen Elementen
xenc:EncryptedData
ergeben MUSS.
Als Kontextknoten für die Auswertung des Ausdrucks
MUSS die Bürgerkarten-Umgebung
den Dokument-Knoten des zu entschlüsselnden XML-Dokuments
verwenden.
Was die Kennzeichnung des Datenverschlüsselungsschlüssels betrifft, darf die Bürgerkarten-Umgebung von 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:KeyInfo
mittels
ds:KeyName
, ds:KeyValue
oder
ds:X509Data
bezeichnet werden.
ds:KeyName
muss den Bezeichner eines in der
Bürgerkarten-Umgebung
verfügbaren Schlüssels enthalten. Bezeichner aller verfügbaren
Schlüssel können mit Hilfe des Befehls Abschnitt 8.1, „Abfrage der Umgebungseigenschaften“ von der Bürgerkarten-Umgebung
abgefragt werden. ds:KeyValue
muss den zur
Verschlüsselung verwendeten öffentlichen Schlüssel enthalten.
ds:X509Data
muss genau ein X.509-Zertifikat
(ds:X509Certificate
) enthalten, das den zur
Verschlüsselung verwendeten öffentlichen Schlüssel
zertifiziert.
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:KeyInfo
muss entweder ein
Element xenc:EncryptedKey
enthalten, oder aber
zumindest ein Element ds:RetrievalMethod
, das auf ein
Element xenc:EncryptedKey
verweist.
xenc:EncryptedKey
muss die Angaben zum verwendeten
symmetrischen Schlüssel enthalten und in ds:KeyInfo
auf einem der oben erwähnten Wege den zur Verschlüsselung des
symmetrischen Schlüssels verwendeten, in der Bürgerkarten-Umgebung
verfügbaren Schlüssel bezeichnen.
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:KeyInfo
muss ein Element
xenc:AgreementMethod
enthalten, oder aber zumindest
ein Element ds:RetrievalMethod
, das auf ein Element
xenc:AgreementMethod
verweist.
xenc:AgreementMethod/xenc:RecipientKeyInfo
muss 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:KeyInfo
muss entweder ein
Element xenc:EncryptedKey
enthalten, oder aber
zumindest ein Element ds:RetrievalMethod
, das auf ein
Element xenc:EncryptedKey
verweist.
xenc:EncryptedKey
muss ein Element
xenc:AgreementMethod enthalten, das im Element
xenc: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:Supplement
s) 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:EncryptedData
verwiesen wird;
ein verschlüsselter symmetrischer Schlüssel, auf den in
einem Element xenc:EncryptedKey
verwiesen
wird;
ein Element xenc:EncryptedKey
, auf das in einem
Element ds:RetrievalMethod
verwiesen wird.
Für ein Ergänzungsobjekt (sl:Supplement
)
DÜRFEN zunächst Metainformationen
(sl:MetaInfo
) angegeben werden (Mime-Type sowie eine
Referenz auf eine Beschreibung des Ergänzungsobjekts). Danach folgen
die verpflichtenden Angaben zum Inhalt des Objekts
(sl:Content
): Das Attribut Reference
enthält
dabei als URI die Referenz auf das Ergänzungsobjekt, und zwar in exakt
gleicher Weise, wie sie von der Bürgerkarten-Umgebung
zur Auflösung verwendet werden würde. Der Inhalt von
sl:Content
repräsentiert das Ergänzungsobjekt (siehe auch
Hinweis Content in „Datenobjekt“).
Werden in der Anfrage Ergänzungsobjekte übergeben,
MUSS die Bürgerkarten-Umgebung
diese verwenden, anstatt die entsprechenden Referenzen selbst
aufzulösen.
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:EncrElemsSelector
in der
Anfrage zur Entschlüsselung ausgewählt;
der im Attribut xenc:EncryptedData/@Type
angegebene Typ des Verschlüsselungselements ist entweder
http://www.w3.org/2001/04/xmlenc#Element
oder
http://www.w3.org/2001/04/xmlenc#Content
.
Kaskadierte Verschlüsselungselemente werden von der Bürgerkarten-Umgebung nicht weiter behandelt, d. h. enthält der entschlüsselte Inhalt eines Verschlüsselungselements wiederum Verschlüsselungselemente, werden diese nicht weiter entschlüsselt.
Wählt sl:DecryptXMLRequest/@EncrElemsSelector
auch Verschlüsselungselemente aus, deren Typ
(xenc:EncryptedData/@Type
) entweder nicht angegeben
wurde, oder aber weder
http://www.w3.org/2001/04/xmlenc#Element
noch
http://www.w3.org/2001/04/xmlenc#Content
ist, ersetzen
die entsprechenden entschlüsselten Inhalte nicht die
Verschlüsselungselemente im XML-Dokument, sondern werden als eigene
Elemente sl:DecryptXMLResponse/sl:DecryptedBinaryData
retourniert:
sl:DecryptedBinaryData/@EncrElemSelector
enthält als Ausdruck nach [XPath] den Bezug
zum korrespondierenden Verschlüsselungselement im XML-Dokument
der Anfrage; das Verschlüsselungselement muss dabei von diesem
Ausdruck eindeutig selektiert werden, d. h. er muss eine
Knotenmenge liefern, die genau ein Element
xenc:EncryptedData
enthält. Der Kontextknoten für
die Evaluierung des Ausdrucks ist dabei der Dokument-Knoten des
XML-Dokuments der Anfrage.
sl:DecryptedBinaryData/@MimeType
enthält
optional den Mime-Type der entschlüsselten Daten; und zwar genau
dann, wenn dieser bereits im Verschlüsselungselement mittels
xenc:EncryptedData/@MimeType
angegeben
wurde;
sl:DecryptedBinaryData/@Encoding
enthält
optional die Transport-Kodierung der entschlüsselten Daten; und
zwar genau dann, wenn dieser bereits im Verschlüsselungselement
mittels xenc:EncryptedData/@Encoding
angegeben
wurde;
den Inhalt von sl:DecryptedBinaryData
schließlich bilden die entschlüsselten Daten, und zwar in
base64-kodierter Form. Liegen die entschlüsselten Daten bereits
von vorneherein base64-kodiert vor (d. h. weist das Attribut
xenc:EncryptedData/@Encoding
des Verschl
sselungselements den Wert
http://www.w3.org/2000/09/xmldsig#base64
auf),
DÜRFEN sie
NICHT noch einmal base64-kodiert
werden.
Kann auch nur ein einziges der mittels
sl:DecryptXMLRequest/sl:EncrElemsSelector
selektierten
Verschlüsselungselemente nicht entschlüsselt werden,
MUSS die Bürgerkarten-Umgebung
eine Fehler-Antwort (sl:ErrorResponse
) liefern. Liefert
die Auswertung des XPaths in
sl:DecryptXMLRequest/sl:EncrElemsSelector
eine leere
Knotenmenge, MUSS die Bürgerkarten-Umgebung
das unveränderte XML-Dokument der Anfrage retournieren.
Ist das Attribut
sl:DecryptXMLRequest/@ReturnResult
hingegen auf den
Wert binary
gesetzt, liefert die Bürgerkarten-Umgebung
keine XML-Antwort, sondern direkt Binärdaten. Zur Ermittlung dieser
Binärdaten geht die Bürgerkarten-Umgebung
wie folgt vor:
Untersucht wird nur das erste Verschlüsselungselement,
welches die Auswertung des XPath-Ausdrucks in
sl:DecryptXMLRequest/sl:EncrElemsSelector
liefert;
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/@MimeType
bzw.
xenc:EncryptedData/@Encoding
) verwenden.
Kann das zu untersuchende Verschlüsselungselement nicht
entschlüsselt werden, oder liefert die Auswertung des XPaths in
sl:DecryptXMLRequest/@EncrElemsSelector
eine leere
Knotenmenge, MUSS die Bürgerkarten-Umgebung
eine Fehler-Antwort (sl:ErrorResponse
) liefern.
Ist das Attribut
sl:DecryptXMLRequest/@ReturnResult
hingegen auf den
Wert none
gesetzt, liefert die Bürgerkarten-Umgebung
eine leere Antwort (Element sl:DecryptXMLResponse
ohne
Inhalt) zurück. Mit dieser Option hat der Bürger die Möglichkeit, sich
die entschlüsselten Daten über die
Benutzer-Schnittstelle anzusehen und/oder zu speichern,
ohne das sie im weiteren auch an die Applikation übermittelt
werden.
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.
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.
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
.
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
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.
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.
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.
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.
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.
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.
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 (Attribut Signature
)
bzw. Verschlüsselung (Attribut Encryption
) geeignet
ist.
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.
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, ist
1.2
.
Der Security-Layer sieht die
Möglichkeit vor, den Status des verwendeten Bürgerkarten-Tokens
abzufragen. Mögliche Stati sind dabei ready
(Token
vorhanden und initialisiert) oder
removed
(kein Token vorhanden).
Enthält der Befehl, bestehend aus dem Element
sl:GetStatusRequest
, keine Parameter, liefert die
Bürgerkarten-Umgebung
in der Antwort sofort den aktuellen Status des verwendeten
Bürgerkarten-Tokens zurück.
Optional kann die Anfrage jedoch die beiden Elemente
sl:TokenStatus
und sl:MaxDelay
enthalten. In
einem solchen Fall gibt sl:TokenStatus
den von der
Applikation
gewünschten Status des Bürgerkarten-Tokens an, und
sl:MaxDelay
die längste Zeitspanne in Sekunden, um die
die Bürgerkarten-Umgebung
die Antwort auf diese Anfrage bis zum Eintritt des gewünschten
Zustandes verzögern soll.
Die 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.
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
.
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 aktivieren
ChangePIN
: PIN ändern
UnblockPIN
: PIN-Sperre aufheben
ReadPINStatus
: 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:
SecureSignatureApplication
CertifiedApplication
InfoboxApplication
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:
OK
Error
Blocked
: PIN ist gesperrt, zu viele Fehleingaben
Active
Inactive
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:Reset
mit dem optionalen Parameter
cold
. Führt einen warm reset, bzw., wenn der Parameter
cold
auf true gesetzt ist, einen cold reset der Karte
durch.
sl:CommandAPDU
mit den Parametern
sequence
und of
, sowie dem optionalen
Parameter expectedSW
.
Dieser Eintrag enthält eine Command-APDU, die auf der Karte
ausgeführt werden soll. Dabei gibt der Parameter sequence
an, an welcher Stelle dieses Kommando ausgeführt werden soll, und der
Parameter of
, wieviele Kommandos insgesamt enthalten
sind. Hierbei dürfen keine Zahlen ausgelassen werden, jeder
sl:CommandAPDU
-Eintrag muss den selben Parameter
of
besitzen, und ebensoviele durchnummerierte Einträge
müssen vorhanden sein. Der Parameter expectedSW
kann
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.
Für Beispiele zur Fehlerbehandlung siehe Tutorium.
Siehe eigenes Dokument Fehlercodes Security-Layer.
Jenes Programm, das Anfragen an die Bürgerkarten-Umgebung über den Security-Layer richtet und die entsprechenden Antworten entgegennimmt und auswertet.
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.
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.
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.
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.
Jene Daten, die für die Berechnung des Hash-Wertes für eine
dsig:Reference
verwendet werden. Sind für die
dsig:Reference
Transformationen angegeben, entsprechen
diese Daten dem Ergebnis der letzten Transformation. Sind keine
Transformationen spezifiziert, gleichen die Hash-Eingangsdaten den
Referenz-Eingangsdaten.
Siehe Abschnitt 2.2.2.2, „Implizite Transformationsparameter“
Jene Daten, die sich aus der Auflösung der im Attribut
URI
der dsig:Reference
angegebenen URI
ergeben. Sind für die dsig:Reference
Transformationen
angegeben, werden diese Daten als Eingangsdaten zur Berechnung der
ersten Transformation verwendet. Sind keine Transformationen
spezifiziert, gleichen die Referenz-Eingangsdaten den Hash-Eingangsdaten.
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.
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 .
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 |
|