für das eGovernment
|
Open Interfaces für das eGovernment |
|
Security-Layer für das Konzept Bürgerkarte
Schnittstellenspezifikation
Dokumenteninformation
| Bezeichnung | Schnittstellenspezifikation des Security-Layers der Bürgerkarte |
| Kurzbezeichnung | Schnittstellenspezifikation Security-Layer |
| Version | 1.0.3 |
| Datum | 31. 08. 2002 |
| Dokumentklasse | Konvention |
| Dokumentstadium | Öffentlicher Entwurf |
| Kurzbeschreibung | Das vorliegende Dokument spezifiziert die Schnittstelle zwischen einer Implementation des Security-Layers (Bürgerkarten-Umgebung) und einer darauf zugreifenden Applikation. |
| Autoren | Arno Hollosi (arno.hollosi@cio.gv.at) Gregor Karlinger (gregor.karlinger@cio.gv.at) |
| Arbeitsgruppe | BMÖLS, CIO des Bundes, Operative Unit |
| © | Diese Spezifikation wird von A-SIT und dem BMÖLS zur Verfügung gestellt. Die Verwendung ohne Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. Eine Erweiterung der Spezifikation ist erlaubt, jedoch muss dies eindeutig gekennzeichnet sein, und es muss die erweiterte Spezifikation frei zur Verfügung gestellt werden. |
Inhalt
Dieses Dokument legt die Schnittstelle Security-Layer fest. Das ist jene Schnittstelle, über die eine Applikation auf Funktionalität aus dem Konzept Bürgerkarte zugreift, um beispielsweise eine elektronische Signatur zu erstellen oder vom Datenspeicher der Bürgerkarten-Umgebung zu lesen.
Für weitere Informationen zur Begriffsbildung (Security-Layer, Bürgerkarten-Umgebung und Bürgerkarten-Token) siehe Abschnitt 1.1 in [AnfBKU].
Für die Festlegung, welche der in diesem Dokument beschriebenen Schnittstellenbefehle von einer Implemenation jedenfalls zur Verfügung gestellt werden müssen, siehe Minimalanforderungen Security-Layer.
Das Protokoll besteht aus einfachen Anfrage/Antwort-Mustern. Die Applikation schickt eine in XML kodierte Anfrage an die Bürgerkarten-Umgebung. Diese schickt eine entsprechende in XML kodierte Antwort zurück an die Applikation.
Zusammen mit der vorliegenden Schnittstellenspezifikation bildet das zugehörige XML-Schema die normative Quelle für die Protokoll-Elemente.
Die einzelnen Protokoll-Elemente wurden mit aussagekräfigen Namen belegt, wobei
Abkürzungen so weit wie möglich vermieden worden sind. Anfragen enden
stets mit dem Suffix Request, die korrespondierenden Antworten
enden stets mit dem Suffix Response.
Folgende Namenraum-Präfixe werden in dieser Spezifikation zur Kennzeichnung der Namenräume von XML-Elementen verwendet:
|
Präfix
|
Namenraum
|
Erläuterung
|
dsig |
http://www.w3.org/2000/09/xmldsig# |
Elemente aus [XMLDSIG] |
etsi |
http://uri.etsi.org/01903/v1.1.1# |
Elemente aus [ETSIXML] |
sl |
http://www.buergerkarte.at/namespaces/securitylayer/20020225# |
Elemente dieser Spezifikation |
Dieses Dokument verwendet die Schlüsselwörter muss, darf nicht, erforderlich, sollte, sollte nicht, empfohlen, darf, und optional zur Kategorisierung der Anforderungen. Diese Schlüsselwörter sind analog zu ihren englischsprachigen Entsprechungen must, must not, required, should, should not, recommended, may, und optional zu handhaben, deren Interpretation in [Keywords] festgelegt ist.
Die Schnittstelle Security-Layer unterstützt zwei mögliche Formate für die Erzeugung einer elektronischen Signatur: [CMS] und [XMLDSIG].
Mit einer Signatur nach [CMS] kann genau ein Datenobjekt signiert werden.
Zunächst muss im Attribut Structure der Signaturanfrage (sl:CreateCMSSignatureRequest)
angegeben werden, ob das nachfolgend spezifizierte Datenobjekt in die Signaturstruktur
eingebunden werden soll (Wert "enveloping"), oder nicht
(Wert "detached").
Weiters muss in der Signaturanfrage der Bezeichner des für die Signaturerstellung
zu verwendenden Schlüssels (sl:KeyboxIdentifier)
angegeben werden. Bezeichner aller verfügbaren Schlüssel können
mit Hilfe des Befehls sl:GetPropertiesRequest
von der Bürgerkarten-Umgebung
abgefragt werden.
Schließlich enthält die Signaturanfrage einen Behälter sl:DataObject,
der das zu signierende Datenobjekt (sl:Content),
sowie Metainformationen (sl:MetaInfo)
für die Anfertigung der Signatur sowie für die gegebenenfalls notwendige
Anzeige im Trusted Viewer enthält.
Jedenfalls an Metainformation spezifiziert werden muss der Mime-Type (siehe
[MIME]) des zu signierenden Datenobjekts. Weiters darf
ein Hinweis (sl:Description) in Form
einer URI gegeben werden. Schließlich dürfen
noch weitere beliebige Elemente zu diesen Metainformationen hinzugefügt
werden.
Die Angabe des zu signierenden Datenobjekts kann auf zwei Arten erfolgen: Entweder
enthält das Element sl:Content
die base64-kodierten Daten, oder das Element sl:Content
ist leer, hat aber sein Attribut Reference gesetzt. Die Bürgerkarten-Umgebung muss
im letzten
Fall versuchen, die in diesem Attribut angegebene
URI aufzulösen, um so die zu signierenden Daten zu erhalten.
<sl:CreateCMSSignatureRequest Structure="enveloping"> |
| Beispiel: Anfrage zur Erzeugung einer Signatur nach [CMS] |
Die Antwort besteht aus dem Element sl:CMSSignature,
welches die erzeugte Signatur nach [CMS] in base64-kodierter
Form enthält.
In die [CMS]-Signatur muss
ein signiertes Signaturattribut ContentHints nach
[ESS-S/MIME], Abschnitt 2.9
aufgenommen werden. Zur Anfertigung dieses Signaturattributs sind jene Metainformationen
(sl:MetaInfo) zu verwenden, die in der
Anfrage im Behälter für das Datenobjekt (sl:DataObject)
angegeben wurden.
Für das Element sl:MimeType aus
sl:MetaInfo muss
ein erstes Feld
contentDescription
in ContentHints verwendet werden;
ist das Element
sl:Description aus sl:MetaInfo
vorhanden, muss
es
in einem weiteren Feld contentDescription
in ContentHints codiert
werden. Das Feld contentType
muss
jedenfalls mit dem Wert des Object Identifiers für id-data
(siehe [CMS], Abschnitt 4)belegt
werden.
Weiters muss
ein signiertes Signaturattribut OtherSigningCertificate nach [ETSICMS]
in die [CMS]-Signatur aufgenommen
werden, mit dem das für die Verifikation der Signatur zu verwendende
Signatorzertifikat eindeutig identifiziert wird.
Darüber hinaus wird empfohlen, die
gesamte Kette an Zertifikaten, die zur Prüfung der Signatur benötigt
wird (Signatorzertifikat bis zu einer vertrauenswürdigen Wurzelinstanz),
in die [CMS]-Signatur aufzunehmen. Dazu eignen sich das
Feld CertificateSet nach [CMS, Abschitt
5.1] sowie das unsignierte Signaturattribut CompleteCertificateRefs
nach [ETSICMS].
<sl:CreateCMSSignatureResponse> |
| Beispiel: Antwort auf die Anfrage zur Erzeugung einer Signatur nach [CMS] |
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 im Trusted Viewer
enthält. sl:DataObjectInfo ist
mit einem Attribut Structure ausgestattet, das angibt, ob das im
Behälter spezifizierte Datenobjekt in die Signaturstruktur eingebunden
werden soll (Wert "enveloping"), oder ob die Signatur
dieses Datenobjekt nur referenzieren soll (Wert "detached").
Ein solcher Behälter besteht zunächst aus Informationen zu jenem
Datenobjekt, das gegebenenfalls transformiert und nachfolgend signiert wird
(sl:DataObject). In Abhängigkeit
des oben besprochenen Attributs Structure) sind der Inhalt von
sl:DataObject sowie sein Attribut Reference
wie folgt zu verwenden:
| Struktur | Möglichkeit | Beschreibung |
"enveloping" |
A |
Das Attribut |
| B | Das Attribut Reference enthält eine URI, die von der
Bürgerkarten-Umgebung
aufgelöst werden muss, um das Datenobjekt
zu erhalten. Der Inhalt von sl:DataObject
bleibt leer. Handelt es sich bei dem so referenzierten
Datenobjekt um XML-Daten, ist es sinnvoll, das Datenobjekt als geparstes
XML in die Signaturstruktur einzubinden. Die Bürgerkarten-Umgebung
soll
daher bei der Auflösung Informationen des Transportprotokolls auswerten,
um das eventuelle Vorliegen von XML-Daten herauszufinden. Für eine
URI, die als Protokoll http oder https aufweist,
muss
dazu die Information im HTTP-Header (Content-type) ausgewertet
werden. |
|
"detached" |
C | Das Attribut Reference enthält eine URI, die von der
Bürgerkarten-Umgebung
aufgelöst werden muss, um das Datenobjekt zu erhalten. Darüber
hinaus wird diese URI auch für die Kodierung der Referenz auf das Datenobjekt
als Bestandteil der XML-Signatur verwendet (Attribut URI im
Element dsig:Reference). Der Inhalt von sl:DataObject
bleibt leer. |
| D | Das Attribut Reference enthält eine URI, die von der
Bürgerkarten-Umgebung
für die Kodierung der Referenz auf das Datenobjekt als Bestandteil
der XML-Signatur verwendet wird (Attribut URI im Element dsig:Reference).
Der Inhalt von sl:DataObject repräsentiert
das Datenobjekt. |
Hinweis: Soll der Inhalt von sl:Dataobject
zur expliziten Angabe des Datenobjekts verwendet werden, stehen zwei unterschiedliche
Arten der Kodierung zur Verfügung: Das Datenobjekt
kann entweder in base64-kodierter Form (sl:Base64Content)
oder als XML kodiert (sl:XMLContent)
angegeben werden. Bei der Kodierung als XML kann für sl:XMLContent
das Attribut xml:space mit dem Wert preserve versehen
werden, wenn es aus Sicht der Applikation wichtig ist, dass die Bürgerkarten-Umgebung
Whitespace innerhalb des übergebenen XML nicht verändert.
Weiters enthält der Behälter sl:DataObjectInfo
einen oder mehrere Transformationswege für das Datenobjekt (sl:TransformsInfo).
Ein Transformationsweg beschreibt dabei eine Kette von auszuführenden
Transformationen (dsig:Transforms), um vom Datenobjekt zu jenen
Daten zu gelangen, die in die Hashberechnung und in weiterer Folge in die Signaturberechnung
einfließen (nachfolgend als Hash-Eingangsdaten bezeichnet).
Die Hash-Eingangsdaten sind gleichzeitig jene Daten, die gegebenenfalls im
Trusted Viewer der Bürgerkarten-Umgebung
dem Benutzer angezeigt werden müssen. Damit die Bürgerkarten-Umgebung
weiß, welcher Natur die Hash-Eingangsdaten sind, enthält der Transformationsweg
andererseits Metainformationen darüber (sl:FinalDataMetaInfo).
Jedenfalls ist der Mime-Type (siehe [MIME]) anzugeben
(sl:MimeType), zusätzlich darf
eine Referenz auf eine Beschreibung dieser Daten angegeben werden (sl:Description).
Soll das Datenobjekt direkt unterzeichnet werden, wird ebenfalls ein Transformationsweg spezifiziert, jedoch unterbleibt die Angabe der Kette von Transformationen. Bei Angabe mehrerer Transformationswege wählt die Bürgerkarten-Umgebung einen Weg frei aus.
Bei der Angabe eines Transformationsweges muss die
Applikation sicherstellen, dass alle Namenräume, die innerhalb der Struktur
der spezifizierten Transformationen (dsig:Transforms) verwendet
werden, innerhalb dieser Struktur explizit deklariert werden. Die Bürgerkarten-Umgebung
darf nicht Namenraum-Deklarationen innerhalb
von dsig:Transforms hinzufügen, wenn Sie die Struktur in die
zu erzeugende Signatur übernimmt.
Optional können schließlich im Behälter sl:DataObjectInfo
Ergänzungsobjekte (sl:Supplements)
angegeben werden. Solche können übergeben werden, damit Daten, die
im Rahmen des Transformationsprozesses für das Datenobjekt oder im Trusted
Viewer benötigt werden, nicht von der Bürgerkarten-Umgebung
aufgelöst werden müssen.
Als Beispiel sei hier eine Stylesheet-Transformation angeführt, die sich
verschachtelter Stylesheets bedient: Nur der Basis-Stylesheet ist tatsächlich
im Transformationsobjekt (dsig:Transform) als Parameter angeführt;
im Basis-Stylesheet referenzierte weitere Stylesheets müssten von der Bürgerkarten-Umgebung
selbst aufgelöst werden. Dies kann vermieden werden, indem solche referenzierte
Stylesheets als Ergänzungsobjekte übergeben werden.
Ein Ergänzungsobjekt besteht dabei einerseits aus optionalen
Metainformationen (vergleiche sl:FinalDataMetaInfo),
andererseits aus dem eigentlichen Daten (sl:Content):
Das verpflichtend zu verwendende Attribut Reference enthält
dabei als URI die Referenz auf die Ergänzungsdaten, und zwar so, wie sie
von der Bürgerkarten-Umgebung
zur Auflösung verwendet werden würde. Der Inhalt von sl:Content
repräsentiert die Ergänzungsdaten (siehe auch Hinweis
in Abschnitt 2.2.1, Datenobjekt).
Stößt die Bürgerkarten-Umgebung während der Berechnung des Transformationsprozesses auf aufzulösende Daten, muss Sie folgenden Ablauf für die Auflösung einhalten:
sl:Supplement innerhalb jenes sl:DataObjectInfo
vorkommt, das den gerade berechneten Transformationsprozess spezifiziert.
Ist diese Prüfung erfolgreich, sind die in diesem sl:Supplement
angegebenen Daten als Ergebnis der Auflösung zu verwenden. Ansonsten
ist mit Schritt 2 fortzufahren.sl:Supplement eines anderen sl:DataObjectInfo
vorkommt, das im Befehl zur Erzeugung der XML-Signatur spezifiziert wurde.
Die einzelnen sl:DataObjectInfo-Elemente sind dabei in jener
Reihenfolge zu untersuchen, in der Sie im Befehl angegeben wurden. Die im
ersten so gefundenen sl:Supplement angegebenen Daten sind als
Ergebnis der Auflösung zu verwenden. Wird kein sl:Supplement
gefunden, ist mit Schritt 3 fortzufahren.
<sl:CreateXMLSignatureRequest> |
| Beispiel: Anfrage zur Erzeugung einer Signatur nach [XMLDSIG] |
Die Antwort enthält die nach [XMLDSIG] kodierte elektronische 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 für jedes in die Signatur aufzunehmende Datenobjekt alle impliziten Transformationsparameter in ein einziges Signaturmanifest aufgenommen werden.
Ein impliziter Transformationsparameter ist in diesem Zusammenhang ein Datenobjekt,
das von der Bürgerkarten-Umgebung
zur Berechnung der Transformationen verwendet wurde, jedoch nicht explizit als
Parameter im entsprechenden Transformationsobjekt (dsig:Transform)
aufscheint.
Die Referenz-Eingangsdaten sind jedenfalls als impliziter Transformationsparameter zu betrachten. Als weiteres Beispiel soll hier wiederum die bereits in Abschnitt 2.2.1 erwähnte Stylesheet-Transformation erwähnt werden, die sich verschachtelter Stylesheets bedient. Die im Basis-Stylesheet referenzierten weiteren Stylesheets sind implizite Transformationsparameter im obigen Sinne.
Das Signaturmanifest (dsig:Manifest) enthält für jeden
impliziten Transformationsparameter ein eigenes Referenzobjekt (dsig:Reference),
das einen Hash-Wert für den impliziten Transformationsparameter inkludiert.
Transformationen in den Referenzobjekten
des Signaturmanifestsdürfen
nicht verwendet werden. Das Attribut URI eines Referenzobjekts
enthält dabei die Referenz auf den impliziten Transformationsparameter,
und zwar in exakt gleicher Weise, wie sie von der Bürgerkarten-Umgebung
zur Auflösung verwendet werden würde.
Die Einbindung des Signaturmanifests in die Signatur erfolgt durch ein eigenes
Referenzobjekt der Signatur (dsig:Reference in dsig:SignedInfo).
Dabei ist die Verwendung des Attributs Type im Referenzobjekt zur
Kennzeichnung des referenzierten Datums als Signaturmanifest erforderlich.
Das Attribut muss folgenden Wert aufweisen:
http://www.buergerkarte.at/specifications/Security-Layer/20020225#SignatureManifest
Die nachfolgend angegebenen Informationen müssen in die Signatur unter
Verwendung von Signaturattributen nach [ETSIXML]
aufgenommen werden. Die Einbindung der Signaturattribute in die Signatur hat
als als Direct Incorporation entsprechend den Hinweisen in den Abschnitten
6.3 und insbesondere 6.3.1 von [ETSIXML] zu erfolgen.
Das in Abschnitt 6.3.1 erwähnte Attribut Type erforderlich.
Für jedes in der Anfrage spezifizierte zu signierende Datenobjekt (sl:DataObject),
ist ein Signaturattribut aufzunehmen, das die dazu spezifizierten Metainformationen
(sl:FinalDataMetaInfo) enthält.
Dazu ist das signierte Signaturattribut etsi:DataObjectFormat nach
[ETSIXML] zu verwenden. Das Element sl:MimeType
aus sl:FinalDataMetaInfo entspricht
dabei dem Element etsi:MimeType aus
etsi:DataObjectFormat, das optional vorhandene Element sl:Description
aus sl:FinalDataMetaInfo dem Element
etsi:Description aus etsi:DataObjectFormat.
Weiters ist ein Signaturattribut mitaufzunehmen, mit dem das für die Verifikation
der Signatur zu verwendende Signatorzertifikat eindeutig identifiziert wird.
Dazu ist das signierte Signaturattribut etsi:SigningCertificate nach
[ETSIXML] zu verwenden.
Schließlich wird empfohlen, die
gesamte Kette an Zertifikaten, die zur Prüfung der Signatur benötigt
wird (Signatorzertifikat bis zu einer vertrauenswürdigen Wurzelinstanz),
in die XML-Signatur aufzunehmen. Dazu eignen sich die unsignierten Signaturattribute
etsi:CompleteCertificateRefs und etsi:CertificateValues nach
[ETSIXML].
<sl:CreateXMLSignatureResponse>
<dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
<!-- Signatur nach XMLDSIG und ETSIXML -->
</dsig:Signature>
</sl:CreateXMLSignatureResponse>
|
| Beispiel: Antwort auf die Anfrage zur Erzeugung einer Signatur nach [XMLDSIG] |
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.
Die Anfrage zur Signaturüberprüfung
enthält zunächst optional die Angabe
jenes Zeitpunktes, der zur Feststellung der Gültigkeit der zu überprüfenden
Signatur verwendet werden soll (sl:DateTime). Fehlt diese Angabe,
ist als Prüfzeitpunkt der Zeitpunkt des Einlangens der Überprüfungsanfrage
bei der Bürgerkarten-Umgebung anzunehmen.
Nachfolgend enthält die Anfrage die zu überprüfende Signatur
nach [CMS] (sl:CMSSignature)
in base64-kodierter Form.
Falls das signierte Datenobjekt in der zu prüfenden [CMS]-Signatur
nicht mitkodiert ist, muss es in der Anfrage im Element sl:DataObject
mitübergeben werden.
In sl:DataObject können zunächst
Metainformationen (sl:MetaInfo) angegeben
werden (Mime-Type sowie eine Referenz auf eine Beschreibung des signierten Datenobjekts).
Danach folgt die Angabe der Daten auf eine von zwei Arten: Entweder enthält
das Element sl:Content die base64-kodierten
Daten, oder das Element sl:Content ist
leer, hat aber sein Attribut Reference gesetzt. Die Bürgerkarten-Umgebung
versucht im letzten
Fall, die in diesem Attribut angegebene URI aufzulösen, um so das signierte
Datenobjekt zu erhalten.
<sl:VerifyCMSSignatureRequest> |
| Beispiel: Anfrage zur Prüfung einer Signatur nach [CMS] |
Enthält die zu überprüfende Signatur mehrere Signatoren
(Strukturelement SignerInfo), muss
die Signatur des ersten Signators geprüft werden.
Die Antwort auf die Anfrage zur Prüfung einer Signatur nach [CMS]
enthält zunächst in sl:SignerInfo Informationen zum X.509-Zertifikat
des Signators. sl:SignerInfo muss
aus genau einem Element dsig:X509Data bestehen, das mindestens
folgende zwei Elemente enthalten muss :
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.Ob weitere Elemente - wie beispielsweise das Signatorzertifikat selbst - zurückgeliefert werden, bleibt der Bürgerkarten-Umgebung überlassen. Konnte bei der Überprüfung kein Signatorzertifikat nach X.509 identifiziert werden, bleibt es ebenfalls der Bürgerkarten-Umgebung überlassen, welche Informationen über den öffentlichen Schlüssel sie zurückliefert.
Weiters enthalten
sind getrennte Ergebnisse für die kryptographische Überprüfung
der Signatur (sl:SignatureCheck) sowie
für die Prüfung der Signaturprüfdaten (sl:CertificateCheck).
Beide Ergebnisse besitzen die gleiche Struktur: Das Element sl:Code
enthält das Ergebnis der Prüfung in maschinenlesbarer Form, das optionale
Element sl:Info enthält genauere,
nicht näher spezifizierte Zusatzinfomationen. Vorstellbar ist etwa eine
vom Menschen lesbare Klartext-Interpretation des Prüfungsergebnises.
Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation
erstellt, so enthält sie ein Signaturattribut ContentHints nach
[ESS-S/MIME],
Abschnitt 2.9, das Metainformationen zum signierten
Datenobjekt enthält. Dieses Signaturattribut kann von der Bürgerkarten-Umgebung
bei Bedarf ausgewertet werden.
Folgende Werte sind für den Inhalt des Elements sl:Code
in sl:SignatureCheck definiert:
sl:Code |
Bedeutung |
| 0 | Die Überprüfung des Werts der Signatur konnte erfolgreich durchgeführt werden. |
| 1 | Bei der Überprüfung des Werts der Signatur ist ein Fehler aufgetreten. |
Diese umfaßt die Konstruktion der Zertifikatskette vom Signatorzertifikat bis zu einem vertrauenswürdigen Wurzelzertifikat, sowie die Statusprüfung für jedes Zertifikat der konstruierten Zertifikatskette.
Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation
erstellt, so enthält sie ein Signaturattribut OtherSigningCertificate
nach [ETSICMS], das Informationen zum Signatorzertifikat
enthält. Diese Informationen müssen
von der Bürgerkarten-Umgebung
in einem solchen Fall als Ausgangspunkt zur Konstruktion der Zertifikatskette
verwendet werden.
Folgende Werte sind für den Inhalt des Elements sl:Code
in sl:CertificateCheck definiert:
sl:Code |
Bedeutung |
| 0 | Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Jedes Zertifikat dieser Kette ist zum in der Anfrage angegebenen Prüfzeitpunkt gültig. |
| 1 | Es konnte keine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konstruiert werden. |
| 2 | Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Für zumindest ein Zertifikat dieser Kette fällt der Prüfzeitpunkt nicht in das Gültigkeitsintervall. |
| 3 | Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Für alle Zertifikate dieser Kette fällt der Prüfzeitpunkt in das jeweilige Gültigkeitsintervall. Für zumindest ein Zertifikat konnte der Zertifikatstatus nicht festgestellt werden. |
| 4 | Eine formal korrekte Zertifikatskette vom Signatorzertifikat zu einem vertrauenswürdigen Wurzelzertifikat konnte konstruiert werden. Für alle Zertifikate dieser Kette fällt der Prüfzeitpunkt in das jeweilige Gültigkeitsintervall. Zumindest ein Zertifikat ist zum Prüfzeitpunkt widerrufen oder gesperrt. |
<sl:VerifyCMSSignatureResponse> |
| Beispiel: Antwort auf die Anfrage zur Prüfung einer Signatur nach [CMS] |
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, ist als Prüfzeitpunkt der Zeitpunkt des Einlangens
der Überprüfungsanfrage bei der Bürgerkarten-Umgebung
anzunehmen.
Nachfolgend enthält die Anfrage Angaben zur zu überprüfenden
Signatur nach [XMLDSIG] (sl:SignatureInfo).
Zunächst enthält SignatureInfo einen
Container, indem ein einzelnes XML-Element zu übergeben ist, das die zu
überprüfende Signatur enthält (SignatureEnvironment).
Soll ein ganzes XML-Dokument übergeben werden, entspricht der Inhalt von
SignatureEnvironment dem Wurzelelement des Dokuments.
Weiters enthält SignatureInfo mit SignatureLocation
einen Ausdruck nach [XPath], mit dem anzugeben ist,
wo sich innerhalb von SignatureEnvironment die zu überprüfende
Signatur befindet. Als Kontext-Knoten für die Auswertung des XPath-Ausdrucks
ist das in SignatureEnvironment angegebene
Element zu verwenden. Der XPath-Ausdruck darf nicht absolut sein, also nicht
mit "/" beginnen. Werden im XPath-Ausdruck Namespace-Prefixes
verwendet, müssen die entsprechenden Namespace-Deklarationen im Kontext
des Elements SignatureLocation bekannt sein.
Optional können in der Anfrage schließlich Ergänzungsobjekte
übergeben werden. Ein Ergänzungsobjekt ist ein Datenobjekt, das entweder
in einem dsig:Reference Element der Signatur selbst (in dsig:SignedInfo)
oder in einem dsig:Reference Element eines Signaturmanifests (dsig:Manifest)
referenziert wird.
Für ein Ergänzungsobjekt (sl:Supplement) dürfen
zunächst Metainformationen (sl:MetaInfo) angegeben werden
(Mime-Type sowie eine Referenz auf eine Beschreibung des Ergänzungsobjekts).
Danach folgen die verpflichtenden Angaben zum Inhalt des Objekts (sl:Content):
Das Attribut Reference enthält dabei als URI die Referenz
auf das Ergänzungsobjekt, und zwar in exakt gleicher Weise, wie sie von
der Bürgerkarten-Umgebung zur Auflösung verwendet werden würde. Der
Inhalt von sl:Content repräsentiert das Ergänzungsobjekt
(siehe auch Hinweis in Abschnitt 2.2.1, Datenobjekt).
Werden in der Anfrage Ergänzungsobjekte übergeben, muss die Bürgerkarten-Umgebung diese verwenden, anstatt die entsprechenden Referenzen selbst aufzulösen.
Anmerkung: Notwendig ist die Angabe von Ergänzungsobjekten, wenn in der Signaturstruktur Verweise relativ zum Signaturdokument vorhanden sind.
<sl:VerifyXMLSignatureRequest> |
|
Beispiel: Anfrage zur Prüfung einer Signatur nach [XMLDSIG] |
Die Antwort auf die Anfrage zur Prüfung einer Signatur nach XML enthält
zunächst Informationen zum öffentlichen Schlüssel des Signators
(sl:SignerInfo). Konnte bei der Überprüfung
ein dem öffentlichen Schlüssel entsprechendes Signatorzertifikat nach
X.509 identifiziert werden, muss sl:SignerInfo
zumindest folgende Informationen enthalten:
dsig:X509Data Element, das wiederum mindestens drei
Elemente enthalten
muss:
dsig:SubjectName enthält den Namen des Signators aus
dem Signatorzertifikat. Das Element ist wie in [XMLDSIG],
Kapitel 4.4.4 angegeben zu kodieren. In dsig:X509Data muss
genau ein solches Element vorkommen.dsig:IssuerSerial enthält den
Namen des Austellers und die Seriennummer
des Signatorzertifikats. Das Element ist wie in [XMLDSIG],
Kapitel 4.4.4 angegeben zu kodieren. In dsig:X509Data muss
genau ein solches Element vorkommen.Ob weitere Elemente - wie beispielsweise das Signatorzertifikat selbst - zurückgeliefert werden, bleibt der Bürgerkarten-Umgebung überlassen. Konnte bei der Überprüfung kein Signatorzertifikat nach X.509 identifiziert werden, bleibt es ebenfalls der Bürgerkarten-Umgebung überlassen, welche Informationen über den öffentlichen Schlüssel sie zurückliefert.
Weiters enthält die Antwort getrennte Ergebnisse für die kryptographische
Überprüfung der Signatur (sl:SignatureCheck), für
die Prüfung des Signaturmanifests
(sl:SignatureManifestCheck) sowie für
die Prüfung der Signaturprüfdaten (sl:CertificateCheck).
Alle drei Ergebnisse besitzen die gleiche Struktur: Das Element sl:Code
enthält das Ergebnis der Prüfung in maschinenlesbarer Form, das Element
sl:Info kann genauere, nicht näher spezifizierte Zusatzinfomationen
enthalten. Vorstellbar ist etwa eine vom Menschen lesbare Klartext-Interpretation
des Prüfungsergebnises.
Diese hat wie in [XMLDSIG] spezifiziert zu erfolgen.
Das bedeutet, das sowohl der Hash-Wert jedes dsig:Reference Elements
als auch der Wert der Signatur (dsig:SignatureValue) zu überprüfen
sind. Nicht zu überprüfen sind die Hash-Werte der Referenzelemente
(dsig:Reference) in gegebenenfalls vorhandenen Manifesten (dsig:Manifest).
Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation
erstellt, so enthält sie für jedes signierte Datenobjekt ein Signaturattribut
etsi:DataObjectFormat nach [ETSIXML],
das Metainformationen zum jeweiligen Datenobjekt enthält. Diese Signaturattribute
können von der Bürgerkarten-Umgebung
bei Bedarf ausgewertet werden.
Folgende Werte sind für den Inhalt des Elements sl:Code
in sl:SignatureCheck definiert:
sl:Code |
Bedeutung |
| 0 | Die Überprüfung der Hash-Werte und des Werts der Signatur konnte erfolgreich durchgeführt werden. |
| 1 | Bei der Überprüfung des Hash-Werts zumindest einer dsig:Reference
der Signatur ist ein Fehler aufgetreten. Der Wert der Signatur (dsig:SignatureValue)
wurde nicht überprüft. |
| 2 | Die Überprüfung der Hash-Werte konnte erfolgreich durchgeführt
werden. Beim Überprüfen des Werts der Signatur (dsig:SignatureValue)
ist jedoch ein Fehler aufgetreten. |
Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation
erstellt, muß eine dsig:Reference in dsig:SignedInfo
auf das Signaturmanifest
verweisen. In einem solchen Fall ist der Hash-Wert jeder dsig:Reference
des Signaturmanifests zu überprüfen.
Folgende Werte sind für den Inhalt des Elements sl:Code
in sl:SignatureManifestCheck definiert:
sl:Code |
Bedeutung |
| 0 | Die Signatur enthält eine Referenz auf das Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Für jede dsig:Reference des Signaturmanifests konnte der Hash-Wert erfolgreich überprüft werden. |
| 1 | Die Signatur enthält keine Referenz auf ein Signaturmanifest. |
| 2 | Die Signatur enthält zwar eine Referenz auf das Signaturmanifest,
dieses entspricht vom Umfang her jedoch nicht den Anforderungen dieser Spezifikation.
Die Hash-Werte der im Signaturmanifest vorhandenen
dsig:Reference-Elemente wurden nicht überprüft. |
| 3 | Die Signatur enthält eine Referenz auf das Signaturmanifest. Das Signaturmanifest entspricht vom Umfang her den Anforderungen dieser Spezifikation. Bei der Überprüfung des Hash-Werts zumindest einer dsig:Reference des Signaturmanifests ist jedoch ein Fehler aufgetreten. |
Diese umfaßt die Konstruktion der Zertifikatskette vom Signatorzertifikat bis zu einem vertrauenswürdigen Wurzelzertifikat, sowie die Statusprüfung für jedes Zertifikat der konstruierten Zertifikatskette.
Wurde die in der Anfrage spezifizierte Signatur konform zu dieser Spezifikation
erstellt, so enthält sie ein Signaturattribut etsi:SigningCertificate
nach [ETSIXML], das Informationen zum Signatorzertifikat
enthält. Diese Informationen müssen von der Bürgerkarten-Umgebung
in einem solchen Fall als Ausgangspunkt zur Konstruktion der Zertifikatskette
verwendet werden.
Für die definierten Werte für den Inhalt des Elements sl:Code
in sl:CertificateCheck siehe Kapitel
Prüfung der Signaturprüfdaten
im Abschnitt über die Prüfung einer [CMS]-Signatur.
<sl:VerifyXMLSignatureResponse> |
| Beispiel: Antwort auf die Anfrage zur Prüfung einer Signatur nach [XMLDSIG] |
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:
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
4.3.1) übergeben, das Parameterelement sl:BinaryFileParameters
bleibt leer. Die Applikation kann jedoch mit Hilfe des boolschen Attributs sl:ContentIsXMLEntity
in sl:BinaryFileParameters der Bürgerkarten-Umgebung
einen Hinweis geben, ob die in der Binärdatei gespeicherten Daten als XML
interpretierbar sind.
<sl:BinaryFileParameters ContentIsXMLEntity="true"/> |
| Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Binärdatei |
In welcher Form die Daten in der Antwort auf die Leseanfrage (siehe Abschnitt
4.3.2) geliefert werden, hängt vom Attribut sl:ContentIsXMLEntity
in der Leseanfrage ab. Wurde dieses Attribut auf true gesetzt,
enthält sl:BinaryFileData den Inhalt
der Binärdatei als geparstes XML (als Kinder von sl:XMLContent),
ansonsten in base64-kodierter Form (sl:Base64Content).
<sl:BinaryFileData> |
| Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Binärdatei |
Da eine Binärdatei nur in ihrer Gesamtheit verändert werden kann,
ist in der Update-Anfrage als einziger Parameter der gesamte neue Inhalt der
Infobox anzugeben, und zwar entweder in base64-kodierter Form (sl:BinaryFileParameters/sl:Base64Content),
oder als geparstes XML (sl:BinaryFileParameters/sl:XMLContent).
Bei der Kodierung als XML kann für sl:XMLContent
das Attribut xml:space mit dem Wert preserve versehen
werden, wenn es aus Sicht der Applikation wichtig ist, dass die Bürgerkarten-Umgebung
Whitespace innerhalb des übergebenen XML nicht verändert.
<sl:BinaryFileParameters> |
| Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Binärdatei |
In der entsprechenden Antwort auf die Update-Anfrage (siehe Abschnitt 4.4.2) werden keinerlei Daten zurückgeliefert.
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.
Hinweis: Dieses Model für den Einsatz der Wildcard wurde gewählt,
um die Nachbildung mehrdimensionaler Arrays durch das assoziative Array zu ermöglichen.
So könnte etwa ein zweidimensionales Array durch Schlüssel der Form
"<Zahl> '/' <Zahl>" nachgebildet werden.
Mit Hilfe des Suchstrings "1/*" könnte dann etwa
alle Werte der ersten Reihe ausgelesen werden.
<sl:AssocArrayParameters> |
| Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Assoziatives Array - Schlüsselabfrage |
Die Antwortdaten enthalten die gefundenen Schlüssel (Elemente
sl:Key in sl:AssocArrayData).
<sl:AssocArrayData> |
| Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Assoziative Array - Schlüsselabfrage |
Der zweite Lesezugriff (Element sl:ReadPairs
in sl:AssocArrayParameters) ist ähnlich dem ersten,
jedoch werden nicht nur die dem Suchausdruck (Attribut SearchString
in sl:ReadPairs) entsprechenden Schlüssel als Resultat
geliefert, sondern zu jedem Schlüssel wird gleichzeitig auch der zugeordnete
Wert retourniert.
Ähnlich wie bei den Leseparametern für eine Binärdatei (siehe
Abschnitt 4.1.1, Leseparameter und
Antworten) kann die Applikation Hilfe des boolschen Attributs ValuesAreXMLEntities
im Element sl:ReadPairs der Bürgerkarten-Umgebung
einen Hinweis geben, ob die zu den gesuchten Schlüsseln zugeordneten Werte
als XML interpretierbar sind. Sind nicht alle Werte als XML interpretierbar,
darf das Attribut nicht
auf true gesetzt werden.
<sl:AssocArrayParameters> |
| Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Assoziatives Array - Abfrage von Schlüssel/Wert-Paaren |
Die Antwortdaten (sl:AssocArrayData) enthalten
die gefundenen
Schlüssel/Wert-Paare (Elemente sl:Pair).
In sl:Pair befindet sich der Schlüssel
als Attribut Key, sowie der zugehörige Wert als geparstes
XML (sl:XMLContent) oder base64-kodiert (sl:Base64Content).
Die Kodierung der Werte hängt vom oben besprochenen Attribut ValuesAreXMLEntities
ab. Sie erfolgt entweder für alle Werte als geparstes XML oder für
alle Werte base64.
<sl:AssocArrayData> |
| Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Assoziative Array - Abfrage von Schlüssel/Wert-Paaren |
Der dritte Lesezugriff (Element sl:ReadValue
in sl:AssocArrayParameters) erlaubt das Lesen jenes Wertes,
der einem spezifizierten Schlüssel (Attribut Key
in sl:ReadValue) zugeordnet ist. Wie beim Lesen von Schlüsseln
und Werten kann die Applikation auch hier mit Hilfe des boolschen Attributs
ValueIsXMLEntity im Element sl:ReadValue
der Bürgerkarten-Umgebung
einen Hinweis geben, ob der auszulesende Wert als XML interpretierbar ist.
<sl:AssocArrayParameters> |
| Beispiel: Parameter in einer Leseanfrage für Infobox vom Typ Assoziatives Array - Wertabfrage |
sl:AssocArrayData) enthalten
den angegebenen Schlüssel (Attribut Key in sl:Pair)
sowie den dazugehörigen Wert (Inhalt von sl:Pair).
Die Kodierung des Werts hängt vom oben besprochenen Attribut ValueIsXMLEntity
ab. Sie erfolgt entweder als geparstes XML (sl:XMLContent)
oder als base64 (sl:Base64Content).
<sl:AssocArrayData> |
| Beispiel: Daten in der Antwort auf eine Leseanfrage für Infobox vom Typ Assoziative Array - Wertabfrage |
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.
<sl:AssocArrayParameters> |
| Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Assoziatives Array - Schlüssel verändern |
Mittels der zweiten Anfrage (Element sl:UpdateValue
in sl:AssocArrayParameters) kann der Wert eines im Assoziativen
Array gespeicherten Schlüssel/Wert-Paares geändert werden. In
sl:UpdateValue sind dabei der
Schlüssel der zu ändernden Assoziation (Attribut Key)
sowie der neue Wert (Inhalt von sl:UpdateValue) zu spezifizieren.
Hinsichtlich der Kodierung des Wertes gelten die in Abschnitt 4.1.1, Updateparameter und Antwortdaten gemachten Aussagen.
<sl:AssocArrayParameters> |
| Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Assoziatives Array - Wert verändern |
Die dritte mögliche Anfrage (Element sl:DeletePair
in sl:AssocArrayParameters) gestattet schließlich
das Löschen eines Schlüssel/Wert-Paares aus dem Assoziativen Array.
Dazu muß der Schlüssel des Paares als Attribut Key in sl:DeletePair
angegeben werden.
<sl:AssocArrayParameters> |
| Beispiel: Parameter in einer Update-Anfrage für Infobox vom Typ Assoziatives Array - Wertepaar löschen |
In der entsprechenden Antwort auf alle drei möglichen Update-Anfragen (siehe Abschnitt 4.4.2) werden keinerlei Daten zurückgeliefert.
Mit diesem Kommando erhält die Applikation von der Bürgerkarten-Umgebung die Auskunft, welche Infoboxen für Zugriffe zur Verfügung stehen.
Die Anfrage ist ein leeres Kommando ohne Parameter.
<sl:InfoboxAvailableRequest/> |
| Beispiel: Anfrage zur Abfrage der verfügbaren Infoboxen |
Die Antwort
enthält eine Liste von Bezeichnern (Elemente sl:InfoboxIdentifier).
Jeder Bezeichner entspricht einer Infoxbox, die der Applikation für Zugriffe
zur Verfügung steht. Die Bezeichner werden in den nachfolgend beschriebenen
Kommandos zum Lesen bzw. zum Verändern von Daten einer Infobox zur Identifikation
der Infobox verwendet.
<sl:InfoboxAvailableResponse> |
| Beispiel: Antwort auf die Abfrage der verfügbaren Infoboxen |
Dieses Kommando erlaubt der Applikation das Lesen von Daten einer Infobox.
Die Anfrage enthält zunächst den Bezeichner jener Infobox, deren
Inhalt gelesen werden soll (Elementsl:InfoboxIdentifier).
Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem
Kommando sl:InfoboxAvailableRequest
abfragen.
Weiters sind - abhängig vom Typ der Infobox - Parameter für die Lese-Anfrage zu spezifizieren. Für weitere Informationen zu diesen Parametern siehe Abschnitt 4.1.
<sl:InfoboxReadRequest> |
| Beispiel: Anfrage zum Lesen von Daten einer Infobox vom Typ Binärdatei |
Die Antwort besteht aus den abgefragten Daten der bezeichneten Infobox. Für weitere Informationen zu diesen vom Typ der Infobox sowie von der Art der Lese-Anfrage abhängigen Daten siehe Abschitt Abschnitt 4.1.
<sl:InfoboxReadResponse> |
| Beispiel: Antwort auf die Anfrage zum Lesen von Daten einer Infobox vom Typ Binärdatei |
Dieses Kommando erlaubt der Applikation das Verändern von Daten einer Infobox.
Die Anfrage enthält zunächst den Bezeichner jener Infobox, deren
Inhalt verändert werden soll (Elementsl:InfoboxIdentifier).
Die Applikation kann die Bezeichner aller verfügbaren Infoboxen mit dem
Kommando sl:InfoboxAvailableRequest
abfragen.
Die Parameter für die Update-Anfrage sind abhängig vom Typ der zu verändernden Infobox sowie von der Art der Anfrage. Für genauere Informationen siehe Abschnitt 4.1.
<sl:InfoboxUpdateRequest> |
| Beispiel: Anfrage zur Veränderung von Daten einer Infobox vom Typ Assoziatives Array - Wert verändern |
Die Antwort ist ein leeres Kommando ohne Parameter.
<sl:InfoboxUpdateResponse/> |
| Beispiel: Antwort auf die Anfrage zur Änderung von Daten in einer Infobox |
Zur Unterstützung des Aufbaus einer vertraulichen und authentifizierten Kommunikation bietet die Bürgerkarten-Umgebung die Möglichkeit, ein Schlüsselpaar zusammen mit einem zugehörigen Zertifikat zu generieren. Der öffentliche Schlüssel dieses Schlüsselpaares wird mit Signaturerstellungsdaten der Bürgerkarte zertifiziert, um Authentifikation zu ermöglichen.
Die Anfrage enthält zunächst den Bezeichner jener Keybox, in der die zur Zertifizierung zu verwendenden Signaturerstellungsdaten abgelegt sind. Weiters ist ein Passwort anzugeben, mit dem die in der Antwort zurückgelieferte, nach [PKCS#12] kodierte Datenstruktur verschlüsselt werden soll. Schließlich wird in der Anfrage noch die Gültigkeitsdauer des zu erzeugenden Zertifikats spezifiziert.
<sl:CreateSessionKeyRequest> <sl:KeyboxIdentifier>Bezeichner der Keybox</sl:KeyboxIdentifier> |
| Beispiel: Anfrage zur Erzeugung von Session-Keys und Session-Zertifikat |
Die Antwort enthält eine Datenstruktur nach [PKCS#12], welche das generierte Schlüsselpaar zusammen mit dem erzeugten Zertifikat passwortgeschützt kapselt. Zusätzlich ist das Zertifikat auch ohne Passwortschutz als DER-kodiertes X509 Zertifikat ein zweites Mal enthalten.
<sl:CreateSessionKeyResponse> <sl:PKCS12Object>PKCS#12 Datenstruktur (Base64 kodiert)</sl:PKCS12Object> |
| Beispiel: Antwort auf die Anfrage zur Erzeugung von Session-Keys und Session-Zertifikat |
Der Security-Layer bietet Anwendungen, die symmetrische Kryptographie benötigen, die Möglichkeit ein symmetrisches Geheimnis basierend auf einem asymmetrischen Schlüsselpaar zu berechnen. Das gemeinsame Geheimnis (Master-Secret) wird mit Hilfe des Diffie-Hellman-Algorithmus (siehe Abschnitt 5.3) berechnet und basiert auf den asymmetrischen Schlüsselpaaren der beiden Kommunikationspartner.
Die Anfrage enthält zunächst den Bezeichner jener Keybox, in der
die zur Berechnung
zu verwendenden Signaturerstellungsdaten abgelegt sind (Element
sl:KeyboxIdentifier).
Weiters ist der öffentliche Schlüssel
des Kommunikationspartners mittels des Elements dsig:KeyInfo anzugeben.
<sl:GetSymmetricSecretRequest> <sl:KeyboxIdentifier>Bezeichner der Keybox</sl:KeyboxIdentifier> |
| Beispiel: Anfrage zur Berechnung eines symmetrischen Geheimnisses basierend auf Diffie-Hellman |
Die Antwort enthält das symmetrische Geheimnis als Base64-kodierte Binärzahl.
<GetSymmetricSecretResponse> <SymmetricSecretValue>Mastersecret (Base64 kodiert)</SymmetricSecretValue> |
| Beispiel: Antwort auf die Anfrage zur Berechnung eines symmetrischen Geheimnisses |
Bei Verwendung von (EC)DSA-basierten Schlüsseln erfolgt
die Berechnung grundsätzlich nach dem Schema in [IEEE1363],
Abschnitt 9.2. Für DSA-basierte Schlüssel ist dabei zur Berechnung
des symmetrischen Geheimnisses die Methode aus [IEEE1363],
Abschnitt 6.2.1 zu verwenden, für ECDSA-basierte Schlüssel jene aus
[IEEE1363], Abschnitt 7.2.1. Im Element sl:SymmetricSecretValue
der Antwort zurückgeliefert wird der base64 kodierte Oktettstring, wie
er in Punkt 6 der Aufzählung in [IEE1363],
Abschnitt 9.2.2 beschrieben ist.
Bei Verwendung von RSA-basierten Schlüsseln erfolgt die
Berechnung nach [DH-RSA], Abschnitt 2.1.1. Im Element
sl:SymmetricSecretValue der Antwort
zurückgeliefert wird die base64 kodierte Zahl ZZ, deren Brechung im genannten
Abschnitt ausgeführt ist.
Üblicherweise wird dieses Geheimnis nicht direkt zur Verschlüsselung benutzt, sondern dient als Mastersecret zur Verschlüsselung eines temporären Schlüssels (z. B. eine Zufallszahl) mit dem die eigentliche Verschlüsselung der Kommunikation stattfindet.
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.
Die Applikation benötigt für bestimmte Aufgaben gegebenenfalls zusätzliche Informationen über die Bürgerkarten-Umgebung. Dieses Kommando dient zur Abfrage solcher Eigenschafen.
Die Anfrage ist ein leeres Kommando ohne Parameter.
<sl:GetPropertiesRequest/> |
| Beispiel: Anfrage zu Umgebungseigenschaften |
Die Antwort enthält folgende Eigenschaften der Bürgerkarten-Umgebung:
<sl:GetPropertiesResponse> |
| Beispiel: Antwort auf die Anfrage zu Umgebungseigenschaften |
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 keine Parameter, liefert die Bürgerkarten-Umgebung in der Antwort sofort den aktuellen Status des verwendeten Bürgerkarten-Tokens zurück.
Optional kann die Anfrage jedoch die beiden Elemente sl:TokenStatus
und sl:MaxDelay enthalten. In einem
solchen Fall gibt sl:TokenStatus den
von der Applikation gewünschten Status des
Bürgerkarten-Tokens an, und sl:MaxDelay
die längste Zeitspanne in Sekunden, um die die Bürgerkarten-Umgebung
die Antwort auf diese Anfrage bis zum Eintritt des gewünschten Zustandes
verzögern soll.
<sl:GetStatusRequest> |
| Beispiel: Anfrage zum Tokenstatus |
Die Antwort enthält den aktuellen Status des
Tokens (entweder
ready oder removed).
<sl:GetStatusResponse> |
| Beispiel: Antwort auf die Anfrage zum Tokenstatus |
Sollte innerhalb der Bürgerkarten-Umgebung ein Fehler auftreten, der die korrekte Beantwortung einer Anfrage verhindert, wird anstatt der zur Anfrage gehörenden Antwort eine Fehler-Antwort an die Applikation zurückgeschickt.
Die Datenstruktur der Fehler-Antwort besteht aus einem maschinenlesbaren Fehlercode
(sl:Code), sowie optional aus weiterführender
Information (sl:Info), die an dieser
Stelle nicht näher spezifiziert wird. Vorstellbar wäre etwa eine klartextliche
Erläuterung des Fehlers, oder eine XML-Struktur mit nähren Informationen
zum aufgetretenen Fehler.
<sl:ErrorResponse> <sl:Code>1152</sl:Code> <sl:Info>Read Access denied.</sl:Info> </sl:ErrorResponse> |
| Beispiel: Fehler-Antwort auf die Anfrage zum Lesen des Inhalts einer Infobox |
Siehe eigenes Dokument " Security-Layer zur Bürgerkarte - Fehlercodes".
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.
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.sl versehen.sl:CreateCMSSignatureRequest:
ContentHints von
[ETSICMS] auf [ESS-S/MIME]
geändert, da dieses Attribut in einer Revision von [ETSICMS]
entfernt wurde.sl:VerifyCMSSignatureResponse:
ContentHints von
[ETSICMS] auf [ESS-S/MIME]
geändert, da dieses Attribut in einer Revision von [ETSICMS]
entfernt wurde.sl:CreateXMLSignatureRequest:
enveloped" Struktur präzisiert.dsig:Transforms)
durch die Applikation vorgeschrieben.sl:VerifyXMLSignatureResponse:
2 bei der Überprüfung
des Signaturmanifests präzisiert.sl:InfoboxUpdateRequest:
sl:InfoboxIdentifier
statt sl:InfoboxIdentifer).sl:CreateSymmetricSecretRequest, sl:CreateSymmetricSecretResponse: