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

Security-Layer für das Konzept Bürgerkarte

Bindung an Transportprotokolle


Dokumenteninformation

Bezeichnung Bindung des Schnittstellenprotokolls des Security-Layers für das Konzept Bürgerkarte an Transportprotokolle
Kurzbezeichnung Transportprotokolle Security-Layer
Version 1.1.0
Datum 31.08.2002
Dokumentklasse Konvention
Dokumentstadium Öffentlicher Entwurf
Kurzbeschreibung Die Schnittstellenspezifikation Security-Layer definiert die Struktur der XML-Kommandos und die notwendige Funktionalität der Kommandos. Dieses Dokument beschreibt, wie diese XML-Kommandos in eine Reihe von Transportprotokollen eingebunden werden können.
Autoren Arno Hollosi (arno.hollosi@cio.gv.at)
Gregor Karlinger (gregor.karlinger@cio.gv.at)
Arbeitsgruppe BMÖLS, CIO des Bundes, Operative Unit
© Diese Spezifikation wird von A-SIT und dem BMÖLS zur Verfügung gestellt. Die Verwendung ohne Modifikation ist unter Bezugnahme auf diese Copyright-Notiz zulässig. Eine Erweiterung der Spezifikation ist erlaubt, jedoch muss dies eindeutig gekennzeichnet sein, und es muss die erweiterte Spezifikation frei zur Verfügung gestellt werden.

Inhalt

  1. Einleitung
  2. TCP/IP - Bindung
    1. Bezeichner und Parameter
    2. Umgebungs-Variablen
    3. Ablauf
    4. Kodierung
    5. Anmerkungen
  3. HTTP - Bindung
    1. Bezeichner und Parameter
    2. Umgebungs-Variablen
    3. Ablauf
    4. Kodierung
    5. Referenzieren von Formular-Feldern
    6. Anmerkungen
    7. Beispiele
    8. Anwendungsfälle
  4. SSL/TLS - Bindung
    1. Bezeichner und Parameter
    2. Umgebungs-Variablen
    3. Ablauf
    4. Kodierung
    5. Anmerkungen
  5. HTTPS - Bindung
    1. Bezeichner und Parameter
    2. Umgebungs-Variablen
    3. Ablauf
    4. Kodierung
    5. Anmerkungen
  6. Refrenzen
  7. Historie

1. Einleitung

Die Schnittstellenspezifikation des Security-Layer definiert die Struktur der XML-Kommandos und die notwendige Funktionalität der Kommandos. Dieses Dokument beschreibt, wie diese XML-Kommandos in bestimmte Transportprotokolle eingebunden werden. Das folgende Blockbild zeigt die prinzipielle Struktur der Bürgerkarten-Umgebung. Die XML-Kommandos werden über verschiedene Module an Transportprotokolle gebunden, im Bild z.B. an TCP/IP und HTTP. Die Module sorgen für die notwendige Umsetzung und Kodierung - die funktionalen Module der Bürgerkarten-Umgebung arbeiten nur mit den definierten XML-Kommandos und sind gegenüber dem Transport und den Eigenschaften des verwendeten Protokolls ignorant.

Die Adresse der Bindungen ist im Allgemeinen durch den verwendeten Internet-Socket bestimmt. Die Socket-Adresse besteht aus zwei Teilen: IP-Adresse und Portnummer. Für jede Bindung wird eine Default-IP-Adresse (bzw. DNS-Name) sowie eine Default-Portnummer spezifiziert. Um möglichst flexibel zu sein, kann von den Standard-Default-Adressen durch entsprechende Angabe von lokalen Environment-Variablen am Rechner abgewichen werden. Implementation der Bürgerkarten-Umgebung MÜSSEN die Umgebungs-Variablen auf die Werte für ihre Bindungen setzen, selbst wenn diese deckungsgleich mit den Standardvorgaben sind.

Sofern Bindungen über die Art der übertragenen Daten unterschieden werden können, ist es möglich, dass Bindungen denselben Port benützen. Im besonderen wird darauf hingewiesen, dass sich die TCP/IP-Bindung und die HTTP-Bindung eine Adresse teilen können MÜSSEN, ebenso wie die TLS und HTTPS Bindung (die Anforderung ergibt sich aus den Default-Werten für die Ports). Die Internet Assigned Numbers Authority (IANA) hat für den Security-Layer zwei Ports reserviert [port-numbers] (siehe Default-Werte in den Abschnitten 2.2, 3.2, 4.2 und 5.2).

Für Informationen, welche der in diesem Dokument beschriebenen Bindungen von einer Implementation verpflichtend zur Verfügung gestellt werden müssen, um dem Konzept Bürgerkarte zu genügen, siehe das Dokument Minimalanforderungen Security-Layer.

2. TCP/IP - Bindung

Die TCP/IP-Bindung ist eine 1:1 Umsetzung der Security-Layer-Kommandos. Es wird eine übliche TCP/IP-Verbindung über Sockets benutzt. Die definierten Kommandos werden ohne weitere Kodierung oder Umsetzung/Einbettung in der Verbindung übertragen.

2.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im Befehl GetPropertiesResponse des Security-Layer verwendet.

Der Bezeichner dieser Bindung ist "TCP/IP".

Parameter der Bindung: keine

2.2. Umgebungs-Variablen

2.3. Ablauf

  1. Die Bürgerkarten-Umgebung öffnet das Service am angegebenen Port und wartet auf eingehende Verbindungen
  2. Eine Applikation liest die Umgebungsvariablen aus (bzw. benützt die Default-Werte) und öffnet eine Verbindung zur angegebenen Adresse
  3. Die Applikation überträgt den XML-Request
  4. Die Bürgerkarten-Umgebung arbeitet den Request ab und schickt eine Response.
  5. Die Bürgerkarten-Umgebung schließt die Verbindung.

2.4. Kodierung

Keine weitere Kodierung. Die XML-Kommandos werden 1:1 in der Verbindung übertragen.

2.5. Anmerkungen

Die TCP/IP-Bindung bietet weder Authentifizierung der anfragenden Applikation, noch bietet sie Vertraulichkeit (Verschlüsselung) der Kommunikation. Applikationen können ausschließlich über die IP-Adresse unterschieden werden, was jedoch keinen ausreichenden Schutz bietet. Aus diesem Grund wird EMPFOHLEN, dass diese Bindung nur Verbindungen zulässt, die vom lokalen Rechner (127.0.0.1) kommen.

Es wird EMPFOHLEN, dass die Bürgerkarten-Umgebung den Endanwender über mögliche Risiken der TCP/IP-Bindung informiert (z.B. Help-Text während Abfrage eines PINs für einen Infobox- oder Signatur-Request).

3. HTTP - Bindung

Die HTTP-Bindung bietet Webbrowsern und anderen Web-fähigen Applikationen die Möglichkeit direkt - ohne weitere aktive Komponenten - auf die Funktionen der Bürgerkarten-Umgebung zuzugreifen. Dazu ist eine entsprechende Kodierung als HTTP-Request erforderlich.

3.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im Befehl GetPropertiesResponse des Security-Layer verwendet.

Der Bezeichner dieser Bindung ist "HTTP".

Parameter der Bindung: keine

3.2. Umgebungs-Variablen

3.3. Ablauf

Anmerkung zur Terminologie: die HTTP-Bindung arbeitet mit HTML Formularfeldern. Speziell ausgezeichnete Formularfelder, die Parameter zur Steuerung des Ablaufes enthalten, werden im folgenden als Formular-Parameter bezeichnet. Felder die zur Weiterreichung von Daten (ausgehend von der Applikation über die Bürgerkarten-Umgebung) zum Server dienen werden als Weitergabe-Felder bezeichnet. Alle anderen Formularfelder werden als weitere Felder bzw. weitere Formularfelder bezeichnet.

3.3.1 Formular-Parameter

Die Applikation übermittelt der Bürgerkarten-Umgebung bei der HTTP-Bindung ein HTML-Formular, das folgende Formularfelder enthält:

Diese Felder werden als Formularparameter bezeichnet, da sie der Ablaufsteuerung dienen. Das HTML-Formular kann zusätzlich Weitergabe-Felder bzw. weitere Formularfelder enthalten.

Alle HTML-Formularfelder können von einem Security-Layer Befehl aus referenziert werden. Siehe dazu Abschnitt 3.5.

3.3.2 Schrittweiser Ablauf

  1. Die Bürgerkarten-Umgebung öffnet das Service am angegebenen Port und wartet auf eingehende Verbindungen
  2. Eine Applikation liest die Umgebungsvariablen aus (bzw. benützt die Default-Werte) und setzt einen HTTP-Request zur angegebenen Adresse ab. Die so erzeugte Verbindung wird im folgenden als Browser-Verbindung bezeichnet.
  3. Ist eine RedirectURL angegeben schickt die Bürgerkarten-Umgebung als Antwort einen HTTP-Redirect (HTTP Code: 302 oder 303) und schließt die Browser-Verbindung.
  4. Die Bürgerkarten-Umgebung entnimmt den zu bearbeitenden XML-Request aus dem XMLRequest Formular-Parameter und bearbeitet den Request.
  5. Ist eine DataURL angegeben schickt die Bürgerkarten-Umgebung die XML-Response entsprechend Kapitel 3.4.2 kodiert mittels HTTP-POST an diese URL. Die Antwort des Servers beeinflusst den Ablauf wie folgt:
  6. Ist eine StylesheetURL angegeben liest die Bürgerkarten-Umgebung einen XSL-Stylesheet von der angegebenen Adresse und transformiert damit die XML-Response. Das Transformationsergebnis hat vom Typ text/html zu sein.
  7. Ist keine RedirectURL angegeben schickt die Bürgerkarten-Umgebung eine (eventuell transformierte) XML-Response in der Browser-Verbindung und schließt die Browser-Verbindung

Anmerkung: Ist eine RedirectURL angegeben, wird im Schritt 3 die Browser-Verbindung beendet. Sollte also im Schritt 5 die Notwendigkeit entstehen (z.B. Fall e), Daten an die Browser-Verbindung weiterzuleiten, kann dieses nicht stattfinden. In diesem Fall, sollte die Bürgerkarten-Umgebung eine entsprechenden Fehlermeldung ausgeben.

3.3.3 Kombination der Formular-Parameter

Aus dem beschriebenen Ablauf ergeben sich sinnvolle und nicht sinnvolle Kombinationen der Formularparamter. Die folgende Tabelle gibt eine Übersicht und erläutert kurz die Auswirkung:

RedirectURL DataURL StylesheetURL Sinnhaftigkeit Auswirkung
- - - Beschränkt sinnvoll XML-Response wird direkt an aufrufende Applikation geschickt. Nur für Auswertung durch Programme oder Scripts geeignet. Für Endanwender nicht geeignet, da sie mit XML als Klartext konfrontiert werden.
- - X Sinnvoll XML-Response wird nach HTML transformiert und an aufrufende Applikation geschickt.
- X - Sinnvoll

Sinnvoll. XML-Response wird an DataURL geschickt. DataURL sollte entsprechende Antwort für Applikation (z.B. Browser) zurückliefern (Fall 5e). Ansonsten (Fall 5a, der im wesentlichen der Spezifikation 1.0 entspricht), nur beschränkt sinnvoll. XML-Response wird an DataURL und an aufrufende Applikation geschickt. Nur für Programme und Scripts geeignet, da Antwort an Applikation XML als Klartext enthält.

- X X Sinnvoll

Resultat wird an DataURL geschickt, aufrufende Applikation erhält HTML-transformiertes Resultat: entspricht einer synchronen Benutzerführung.

Nur sinnvoll, in den Fällen 5a, 5b, 5c. In den Fällen 5d, 5e, 5f ist die Angabe der StylesheetURL nutzlos.

X - - / X Nicht sinnvoll Applikation wird umgeleitet, aber Resultat (XML-Response) kann von niemandem in Empfang genommen werden.
X X - Sinnvoll Applikation erhält sofort einen Redirect, Resultat wird an DataURL geschickt: entspricht einer asynchronen Benutzerführung.
X X X Nicht sinnvoll StylesheetURL ist nutzlos. Stattdessen vorhergehenden Fall verwenden.

3.4. Kodierung

3.4.1 Request und Formular-Parameter

Die HTTP-Requests der Applikation an die Bürgerkarten-Umgebung werden entsprechend [RFC2616] HTTP kodiert. Der Request kann wahlweise als HTTP-GET oder HTTP-POST erfolgen; es MÜSSEN beide Varianten von der Bürgerkarten-Umgebung unterstützt werden. (Anmerkung: manche Webclients unterstützen nur eine limitierte Größe der HTTP-GET Requests). Die Anfrage kann als application/x-www-form-urlencoded oder als multipart/form-data kodiert werden. Beide Formate MÜSSEN unterstützt werden.

Die HTTP-Anfrage MUSS an die URL "/http-security-layer-request" erfolgen. (Über die URL können zukünftig verschiedene Requesttypen unterschieden werden). Bei einem Request an eine unbekannte URL ist eine HTTP-404 Fehlermeldung zurückzuliefern .

Folgende Formularfelder können angegeben werden:

Andere Formularfelder im HTTP-Request werden nicht ausgewertet.

Alle Formularfelder des eingehenden HTTP-Requests können vom Security-Layer Befehl aus referenziert werden (siehe Abschnitt 3.5).

3.4.2 Response an DataURL (Schritt 5 des Ablaufs)

Die Response der Bürgerkarten-Umgebung an die DataURL in Schritt 5 ist HTTP-POST kodiert. Sie enthält folgende Formularfelder:

3.4.3 Protokolle für DataURL und StylesheetURL

Für Zugriffe auf die DataURL und die StylesheetURL MÜSSEN HTTP und HTTPS als Protokolle unterstützt werden.

3.5 Referenzieren von Formularfeldern

Im Kontext der HTTP-Bindung ist es möglich Formular-Felder, die im HTTP-Request übergeben werden vom Security-Layer Befehl aus zu referenzieren. Dabei können nicht nur die oben definierten Formular-Parameter referenziert werden, sondern beliebige Formularfelder. Mögliche Anwendungsfälle sind das Referenzieren bei den Signaturbefehlen Create(XML|CMS)SignatureRequest und Verify(XML|CMS)SignatureRequest.

URI-Protokoll: formdata

Analog zu Abschnitt "Signatur nach XMLDSig / Anfrage / Ergänzungsobjekte" der Schnittstellenspezifikation, werden Referenzen, die als Protokoll "formdata" haben, mit dem übergebenen Inhalt (hier der Inhalt des entsprechenden Formularfelds) aufgelöst.

Beispiel:

HTML-Formular: <input name="summary" value="Eine kurze Zusammenfassung."

Referenz-URI: formdata:summary

Auflösen der Referenz ergibt "Eine kurze Zusammenfassung."

3.6. Anmerkungen

Die HTTP-Bindung bietet weder Authentifizierung der anfragenden Applikation, noch bietet sie Vertraulichkeit (Verschlüsselung) der Kommunikation. Applikationen können über die IP-Adresse und die DataURL unterschieden werden, was je nach Anwendungsfall ausreichen kann, im Allgemeinen jedoch nicht ausreichend Schutz bietet. Aus diesem Grund wird EMPFOHLEN, dass diese Bindung nur Verbindungen zulässt, die vom lokalen Rechner (127.0.0.1) kommen, und dem Benutzer die Möglichkeit zu bieten, selbst zu entscheiden, ob Daten an eine bestimmte DataURL gesendet werden sollen.

Ist die DataURL gesetzt und verwendet das HTTPS-Protokoll(1), kann das Server-Zertifikat der Gegenstelle ausgewertet werden. Dies ist eine verläßliche Methode zur Authentifikation der Gegenstelle. Da das Resultat eines XML-Requests an diese URL gepostet wird, findet eine Authentifikation des Empfängers, nicht aber des Absenders des Requests statt. In der Praxis bietet daher diese Methode ähnlich hohen Schutz vor ungewollter Dateneinsicht und/oder anderen Attacken wie die HTTPS-Bindung (siehe Abschnitt 5). Ein Rechte-Management basierend auf DataURLs erscheint als eine sinnvolle und benutzerfreundliche Sicherheitsmaßnahme.

(1) Auch eine gegebenenfalls gesetzte StylesheetURL sollte in diesem Fall vom gleichen Server originieren. Anderenfalls könnte über den von der StylesheetURL referenzierten Stylesheet (stammt potentiell von einem bösartigen Server) Daten ausgespäht werden.

3.7 Beispiele

Die hier angeführten Beispiele sollen lediglich einen Eindruck der Befehle und der Kodierung vermitteln. Sie erheben keinen Anspruch auf Vollständigkeit (zum Beispiel wird die Verwendung eines HTTP-GET Requests nicht demonstriert).

POST /http-security-layer-request HTTP/1.1
Host: localhost:3495
Content-type: application/x-www-form-urlencoded

XMLRequest=%3C%3Fxml+version%3D%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A
%
%3CInfoboxReadRequest+xmlns%3D%22http%3A%2F%2Fwww.buergerkarte.at%2Fnamesp
aces%2Fsecuritylayer%2F20020225%23%22%3E%0D%0A%3CInfoboxIdentifier%3EIdenti
tyLink%3C%2FInfoboxIdentifier%3E%0D%0A%3CBinaryFileParameters%2F%3E%0D%0A%3
C%2FInfoboxReadRequest%3E%0D%0A&RedirectURL=http%3A%2F%2Fredirect.me.to%2Fp
ausenfueller.html&DataURL=http%3A%2F%2Fpost.data.here%2Freaddata.script

Request der Applikation als application/x-www-form-urlencoded (Punkt 2 des Ablaufs)

 

POST /http-security-layer-request HTTP/1.1
Host: localhost:3495
Content-type: multipart/form-data; boundary=----boundary-12345

------boundary-12345
Content-Disposition: form-data; name="XMLRequest"

<?xml version="1.0" encoding="UTF-8"?>
<InfoboxReadRequest xmlns="http://www.buergerkarte.at/namespaces/securitylayer/20020225#">
<InfoboxIdentifier>IdentityLink</InfoboxIdentifier>
<BinaryFileParameters/>
</InfoboxReadRequest>
------boundary-12345
Content-Disposition: form-data; name="RedirectURL"

http://redirect.me.to/pausenfueller.html
------boundary-12345
Content-Disposition: form-data; name="DataURL"

http://post.data.here/readdata.script
------boundary-12345
Content-Disposition: form-data; name="ProgramCode_"

123:667/kx9
------boundary-12345--

Request der Applikation mit Weitergabe-Feldern als multipart/form-data kodiert (Punkt 2 des Ablaufs)

 

HTTP/1.1 302 See other
Server: Security-Kapsel/FastProtoType/1.0
Date: Fri, 13 Nov 2001 07:28:23 GMT
Connection: close
Location: http://redirect.me.to/pausenfueller.html
Content-Length: 127
Content-Type: text/html

<HTML><BODY>Please go to
<A HREF="http://redirect.me.to/pausenfueller.html">Pausenfueller</A>.
</BODY></HTML>
Redirect an Applikation (Punkt 3 des Ablaufs)

 

POST /readdata.script HTTP/1.1
Host: post.data.here
Content-type: application/x-www-form-urlencoded
Content-Length: 503

ResponseType=HTTP-Security-Layer-RESPONSE&XMLResponse=%3C%3Fxml+version%3D
%221.0%22+encoding%3D%22UTF-8%22%3F%3E%0D%0A
%3Csl%3AInfoboxReadResponse+xm
lns%3Asl%3D%22http%3A%2F%2Fwww.buergerkarte.at%2Fnamespaces%2Fsecuritylaye
r%2F20020225%23%22%3E%0D%0A%3Csl%3ABinaryFileData%3E%3Csl%3AXMLContent%3E%
0D%0A%3CDocumentText%3EInhalt+einer+einer+Infobox%3C%2FDocumentText%3E%0D%
0A%3C%2Fsl%3AXMLContent%3E%3C%2Fsl%3ABinaryFileData%3E%0D%0A%3C%2Fsl%3AInf
oboxReadResponse%3E%0D%0A&ProgramCode_=123%3A667%2Fkx9
Response an DataURL inklusive Weitergabefeld (Punkt 5 des Ablaufs)

 

HTTP/1.1 200 OK
Date: Fri, 13 Nov 2001 07:28:24 GMT
Connection: close
Content-Length: 5
Content-Type: text/xml

<ok/>

Antwort des Servers auf HTTP-POST auf DataURL (Punkt 5 des Ablaufs)

 

HTTP/1.1 200 OK
Server: Security-Kapsel/FastProtoType/1.0
Date: Fri, 13 Nov 2001 07:28:24 GMT
Connection: close
Content-Length: 291
Content-Type: text/xml

<?xml version="1.0" encoding="UTF-8"?>
<sl:InfoboxReadResponse xmlns:sl="http://www.buergerkarte.at/namespaces/securitylayer/20020225#">
<sl:BinaryFileData><sl:XMLContent>
<DocumentText>Inhalt einer einer Infobox</DocumentText>
</sl:XMLContent></sl:BinaryFileData>
</sl:InfoboxReadResponse>

Response an Applikation (Punkt 6 des Ablaufs)

3.8 Anwendungsfälle

Aus dem beschriebenen Ablauf, der Kodierung und der möglichen Referenzierung von Feldern ergeben sich beispielhaft untenstehende Anwendungsfälle. Mit "v1.0" werden die Möglichkeiten der Spezifikation Version 1.0 des Security-Layer markiert. Mit "v1.1" werden die Möglichkeiten der Spezifikation Version 1.1 des Security-Layer markiert. Generell ist die Version 1.1 vollständig rückwärtskompatibel mit Version 1.0, wenn im Schritt 5 des Ablaufs eine "<ok/>"-Antwort von Serverseite erfolgt (Fall 5a). Alle "v1.0" Fälle gelten also auch für Version 1.1 der Spezifikation.

Die hier beschriebenen Lösungen sind als mögliche Anwendungsszenarien zu verstehen. Für einige der Fälle gibt es auch hier nicht angeführte Alternativen.

3.8.1 Signieren eines Formulars

Die Eingabefelder des HTML-Formulars werden serverseitig oder clientseitig (JavaScript) in einen XML-Request kodiert. Das so erzeugte Formular wird durch den Anwender an die Bürgerkarten-Umgebung gepostet.

Ab v1.0 (= Fall 5a): DataURL und entweder RedirectURL oder StylesheetURL sind gesetzt. Die Signaturdaten werden automatisch an den Server gesandt. Eventuelle Programmparameter (zum Beispiel Session-ID) können in die DataURL kodiert werden (...?para1=value1&para2=value2...). Der Anwender erhält eine HTML Antwort.

Ab v1.1: Nur Setzen der DataURL, Server sendet Antwort an Anwender (Fall 5e). Eventuelle Programmparameter können in Weitergabe-Feldern enthalten sein.

3.8.2 Signieren eines Formulars mit Upload von Datenfiles

Ab v1.1: Die Daten-Files werden in Weitergabe-Feldern (Name endet mit '_') im Formular aufgenommen. Die DataURL wird gesetzt. Die Bürgerkarten-Umgebung leitet die Felder entsprechend an den Server weiter. Die Felder (und damit die Files) können auch zum Beispiel in eine Signatur miteinbezogen werden (siehe Abschnitt 3.5). Die Antwort kommt entweder vom Server (Fall 5e), oder alternativ durch Setzen der StylesheetURL oder RedirectURL.

3.8.3 Vorausfüllen von Formularen mit Infobox-Inhalten

Es wird ein InfoboxReadRequest an die Bürgerkarten-Umgebung abgesetzt. Die Infobox enthält die notwendigen Daten.

Ab v1.0: DataURL und StylesheetURL sind gesetzt. Der Inhalt der Infobox wird an die DataURL gepostet, der vom Server stammende Stylesheet erzeugt ein passendes Formular.

Ab v1.1: nur DataURL setzen. Server bindet Daten in Formular ein und liefert fertiges Formular an Bürgerkarten-Umgebung (Fall 5e).

3.8.4 Beigeben der Personenbindung und Signieren eines Formulars

Ab v1.0: Aufteilen in zwei Arbeitsschritte. Die einzelnen Arbeitsschritte können wie in obigen Fällen ausgeführt werden. Eine gewisse Automatisierung des Ablaufes ist durch Einsatz von Javascript auf der Client-Seite möglich.

Ab v1.1: Befehlskaskadierung: Die Formularfelder, die die eigentlichen Anwender-Eingabedaten enthalten, werden alle als Weitergabe-Felder markiert. Als erster Befehl wird vom Anwender ein InfoboxReadRequest zum Auslesen der Personenbindung abgesetzt. Resultat wird per DataURL an Server gesendet. Dieser empfängt Personenbindung und wertet die Weitergabe-Felder, die die Anwender-Eingabedaten enthalten, aus. Aus diesen Weitergabe-Feldern wird ein entsprechender CreateSignatureRequest erzeugt. Dieser wird als Antwort in die DataURL-Verbindung an die Bürgerkarten-Umgebung geschickt (Fälle 5b, 5c, 5d - 5c erscheint am sinnvollsten). Die Bürgerkarten-Umgebung arbeitet daraufhin den empfangenen Signatur-Befehl ab und sendet das Resultat an die neue DataURL (Fall 5c). Dort kann der Server die Antwort entsprechend auswerten und eine passende Antwort erzeugen (5e). Alternativ kann die Antwort (und damit die Benutzerführung) durch Setzen der StylesheetURL bzw. RedirectURL erfolgen.

4. SSL/TLS-Bindung

Die TLS-Bindung ist eine 1:1 Umsetzung der Security-Layer-Kommandos. Es wird eine übliche TLS-Verbindung [TLS] über Sockets benutzt. Die definierten Kommandos werden ohne weitere Kodierung oder Umsetzung/Einbettung in der Verbindung übertragen.

Die TLS-Bindung entspricht von Ablauf und Aufbau her der TCP/IP-Bindung, mit dem Unterschied, dass das zugrundeliegende Transportprotokoll TLS ist.

4.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im Befehl GetPropertiesResponse des Security-Layer verwendet.

Der Bezeichner dieser Bindung ist "TLS".

Parameter der Bindung: keine

4.2. Umgebungs-Variablen

4.3. Ablauf

Wie in Abschnitt 2.3 der TCP/IP-Bindung, mit dem Unterschied, dass im Punkt 2 beim Aufbau der Verbindung zusätzlich entsprechend TLS ein Handshake und eine Verschlüsselung des Kanales stattfindet.

4.4. Kodierung

Keine weitere Kodierung. Die XML-Kommandos werden 1:1 in der Verbindung übertragen.

4.5. Anmerkungen

Die TLS-Bindung bietet Authentifizierung der anfragenden Applikation und der Bürgerkarten-Umgebung, sowie Vertraulichkeit (Verschlüsselung) der Kommunikation. Damit entspricht diese Bindung erhöhten Sicherheitsanforderungen und bietet ausreichend Schutz um auch Kommunikation über ungesicherte Netzwerke zu gewährleisten.

Die Bürgerkarten-Umgebung kann auch auf Basis der Zertifikate der Applikationen entsprechende Zugriffsrechte vergeben und damit dem Benützer gegenüber für erhöhten Komfort, sowie Unterstützung bei der Sicherheitskonfiguration sorgen.

5. HTTPS-Bindung

Die HTTPS-Bindung bietet wie die HTTP-Bindung Webbrowsern und anderen Web-fähigen Applikationen die Möglichkeit direkt - ohne weitere aktive Komponenten - auf die Funktionen der Bürgerkarten-Umgebung zuzugreifen. Dazu ist eine entsprechende Kodierung als HTTP-Request erforderlich.

Die HTTPS-Bindung entspricht der HTTP-Bindung mit dem Unterschied, dass das zugrundeliegende Protokoll HTTPS [HTTPS] (HTTP mit SSL/TLS [TLS]) ist.

5.1. Bezeichner und Parameter

Bezeichner und Parameter der Bindung werden im Befehl GetPropertiesResponse des Security-Layer verwendet.

Der Bezeichner dieser Bindung ist "HTTPS".

Parameter der Bindung: keine

5.2. Umgebungs-Variablen

5.3. Ablauf

Wie in Abschnitt 3.3 der HTTP-Bindung, mit dem Unterschied, dass im Punkt 2 beim Aufbau der Verbindung zusätzlich entsprechend TLS ein Handshake und eine Verschlüsselung des Kanales stattfindet.

5.4. Kodierung

Wie in Abschnitt 3.4 der HTTP-Bindung, mit dem Unterschied,

5.5. Anmerkungen

Die HTTPS-Bindung bietet wie die TLS-Bindung Authentifizierung der anfragenden Applikation und der Bürgerkarten-Umgebung, sowie Vertraulichkeit (Verschlüsselung) der Kommunikation. Damit entspricht diese Bindung erhöhten Sicherheitsanforderungen und bietet ausreichend Schutz um auch Kommunikation über ungesicherte Netzwerke zu gewährleisten.

Die Bürgerkarten-Umgebung kann auch auf Basis der Zertifikate der Applikationen entsprechende Zugriffsrechte vergeben und damit dem Benützer gegenüber für erhöhten Komfort, sowie Unterstützung bei der Sicherheitskonfiguration sorgen.

6. Referenzen

HTTP 1.1
Gettys, Mogul, Frystyk, Masinter, Leach, Berners-Lee: Hypertext Transfer Protocol -- HTTP/1.1, Juni 1999
http://www.ietf.org/rfc/rfc2616.txt
HTTPS
E. Rescorla: RFC 2818: HTTP over TLS, Mai 2000
http://www.ietf.org/rfc/rfc2818.txt
TLS
T. Dierks, C. Allen: RFC 2246: The Transport Layer Security (TLS) Protocol, Version 1.0, Januar 1999
http://www.ietf.org/rfc/rfc2246.txt
IANA - Port numbers
Internet Assigned Numbers Authority: Port Numbers
http://www.iana.org/assignments/port-numbers

7. Historie

Version 1.1.0 vom 31.08.2002: Veränderungen zu Version 1.0.3