gemSpec_Kon_SigProxy_V1.5.0

Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

Konnektor Signaturproxy

    

     

      
Version
      
1.5.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
15.05.2019
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_Kon_SigProxy
     
    

Dokumentinformationen

Änderungen zur Vorversion

Einarbeitung Änderungsliste P18.1

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen zu Herstellung, Test und Betrieb des Konnektor Signaturproxy.

Der Signaturproxy ist eine Komponente, die zwischengeschaltet auf der Kommunikationsstrecke zwischen Client-System und Konnektor dafür sorgt, dass die zu signierenden oder zu prüfenden Dokumente dem Nutzer angezeigt werden.

Herstellern von Primärsystemen ist es freigestellt, die Ansichtsfunktion umzusetzen, und auf die Verwendung des Signaturproxy zu verzichten. Bei der Umsetzung der Ansichtsfunktion im Primärsystem sollte sich der Primärsystemhersteller an der Spezifikation des Signaturproxy richten.

1.2 Zielgruppe

Das Dokument ist maßgeblich für die Hersteller von Konnektoren und für die Primärsystemhersteller.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungs- oder Abnahmeverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzungen

Spezifiziert werden in dem Dokument die von dem Konnektor Signaturproxy bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert (siehe auch Anhang A5).

Die vollständige Anforderungslage für den Konnektor Signaturproxy ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps Konnektor verzeichnet.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Sie werden im Dokument wie folgt dargestellt:

<AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=]  angeführten Inhalte.

1.5.1 Hinweis auf offene Punkte

• Vollständig anzeigbare XML-Formate (Signaturrichtlinien) sind aktuell nicht vorgesehen, könnten aber z.B. mit NFDM ergänzt werden.

2 Systemüberblick

2.1 Funktion des Signaturproxy

Der Signaturproxy hat zwei Hauptaufgaben: die erste Aufgabe besteht darin, eine lokale und optionale Anzeige für die Signaturerstellung und Signaturprüfung zur Verfügung zu stellen, die zweite Aufgabe ist die Weiterleitung des Signaturauftrages an den Konnektor und der Signaturantwort an das Primärsystem.

Um die lokale Anzeige für die Signaturerstellung und Signaturprüfung zu realisieren, ermittelt der Signaturproxy alle Informationen, die für die Anzeige notwendig sind und bereitet die Informationen sowie das Dokument zur Anzeige auf. Im Rahmen der Anzeige bietet der Signaturproxy dem Anwender Möglichkeiten, mit dem Signaturvorgang zu interagieren.

Der Signaturproxy stellt dabei keine „sichere“ Anzeige im Sinne des Signaturgesetzes (SigG/SigV) bereit, wie es der sicherheitsbestätigte xTV in älteren Versionen der Konnektorspezifikation getan hat. Erhalten geblieben sind die beiden Qualitätsniveaus der Anzeige, die jetzt als einfache und vollständige Anzeige bezeichnet werden.

Da durch die aktuelle Gesetzeslage (eIDAS-Verordnung) für die Erstellung einer QES keine sichere Anzeigekomponente notwendig ist, kann sich der Anwender auch mit anderen Mitteln als dem hier spezifizierten Signaturproxy eine hinreichende Sicherheit über den Gegenstand seiner Signatur verschaffen. Der Einsatz des Signaturproxy ist für den Leistungserbringer/Primärsystemhersteller optional und die Anzeigefunktion kann im aufrufenden Primärsystem realisiert werden. Die Bereitstellung des Signaturproxy ist für den Konnektorhersteller obligatorisch.

Um die Weiterleitung des Signaturauftrages an den Konnektor zu implementieren, befindet sich der Signaturproxy im Informationsfluss zwischen dem aufrufenden Primärsystem und dem Konnektor. Der Signaturauftrag wird so vom Primärsystem an den Signaturproxy übergeben und von dem Signaturproxy an den Konnektor. Die Antwort des Konnektors wird genauso über den Signaturproxy an das Primärsystem zurückgemeldet.

2.2 Deployment des Signaturproxy

Der Signaturproxy ist als lokale Anzeigesoftware zum Einsatz auf dem Clientrechner vorgesehen. Daher sollen seine Schnittstellen zum Clientsystem nur auf dem lokalen Interface (localhost) zur Verfügung stehen. Für den Konnektor stellt sich der Signaturproxy wie ein Clientsystem dar. Da der Signaturproxy den Kontext (Clientsystem-ID, Arbeitsplatz-ID, Mandant) aus dem Aufruf weiterreicht, hat der Signaturproxy keine eigene Entität im Informationsmodell des Konnektors.

2.3 Zielstellung für den Signaturproxy

Durch die in diesem Dokument beschriebene Definition des Signaturproxy soll vor allem erreicht werden, dass die Anzeigefunktionalität für die zu signierenden Dokumente sowie bestimmte Validierungsaspekte dieser Dokumente aus dem Konnektor entfernt und in den externen Signaturproxy verlagert werden. In diesem Zusammenhang wird die Komplexität des Konnektors reduziert, die Performance des Signaturvorgangs verbessert und der Evaluierungsaufwand für den Konnektor verringert.

2.4 Schnittstellen des Signaturproxy

In der Abbildung 1 sind sowohl die am Signaturproxy angebotenen als auch die vom Signaturproxy benutzten Schnittstellen dargestellt. Die Zuordnung der einzelnen Operationen zu den entsprechenden Schnittstellen erfolgt in den Kapiteln 2.4.1 und 2.4.2.

Abbildung 1: Schnittstellen des Signaturproxy

2.4.1 Genutzte Logische Operationen

Folgende Operationen des Konnektors werden vom Signaturproxy verwendet:

• Schnittstelle I_Sign_Operations
• I_Sign_Operations::sign_Document
• I_Sign_Operations::verify_Document
• I_Sign_Operations::get_Certificate
• I_Sign_Operations::get_Jobnummer
• I_Sign_Operations::stop_signatur
• Schnittstelle I_SAK_Operations
• I_SAK_Operations::sign_Document_QES
• I_SAK_Operations::verify_Document_QES
• Schnittstelle I_Reg_Notification
• I_Reg_Notification::register_for_Notifications
• Schnittstelle I_Cert_Verification
• I_Cert_Verification::verify_CertificateSchnittstelle I_Poll_System_Information
• I_Poll_System_Information::Get_Ressource_Information

Der Notification-Mechanismus ist für alle Clientsysteme (einschließlich Signaturproxy) gleich: Beim Erstellen einer Subscription wird die Senke für die Events dieser Subscription angegeben. Dadurch kann der Konnektor die Events an die entsprechenden Systeme zustellen, z. B. an das Primärsystem oder an den Signaturproxy.

2.4.2 Angebotene Logische Operationen

Folgende Operationen vom Signaturproxy angeboten:

• Schnittstelle I_Notification
• I_Notification::notify
• Schnittstelle I_TV_User_Interaction
• I_TV_User_Interaction::display_Document
• I_TV_User_Interaction::display_Metadata
• I_TV_User_Interaction::request_Confirmation
• Schnittstelle I_Sign_Operations
• I_Sign_Operations::sign_Document
• I_Sign_Operations::verify_Document
• Schnittstelle I_SAK_Operations
• I_SAK_Operations::sign_Document
• I_SAK_Operations::verify_Document

2.5 Anwendungsfälle

Abbildung 2: Anwendungsfälle für den Signaturproxy

Die in der Abbildung 2 dargestellten interaktiven Anwendungsfälle werden durch folgende logische Operationen umgesetzt:

1. Sign_Document(_QES):     
1. Signaturauftrag freigeben:
   Der Signaturauftrag wird nach Prüfung in der Anzeige zur Erstellung der Signatur freigegeben.
2. Signaturauftrag ablehnen
   Der Signaturauftrag wird nach Prüfung in der Anzeige abgebrochen. Es wird ein Fehler an das aufrufende System gemeldet
3. Dokument aus Signaturstapel entfernen
   Aus einem Stapelsignaturauftrag wird ein Dokument entfernt. Der geänderte Signaturauftrag kann dann freigegeben werden.
4. Signaturfortschritt einsehen
   Der Fortschritt eines Stapelsignaturauftrags wird dem Anwender angezeigt. Die erfolgreiche Erstellung der Signatur wird dem Benutzer angezeigt. Die Anzeige wird vom Benutzer oder nach Zeitablauf gelöscht.
5. Stapelsignatur abbrechen
   Ein Stapelsignaturauftrag wird abgebrochen. Bereits signierte Dokumente werden zurückgeliefert.
2. Verify_Document(_QES):
1. Signaturprüfung freigeben
   Eine Signaturprüfung mit Warnungen wird von dem Benutzer als gültig akzeptiert und mit Status „OK“ an das führende System zurückgemeldet.
2. Signaturprüfung ablehnen
   Eine Signaturprüfung mit Warnungen wird von dem Benutzer als ungültig eingestuft und mit Status „Fehler“ an das führende System zurückgemeldet.

2.6 Abläufe (exemplarisch)

Die in diesem Kapitel enthaltenen Ablaufdiagramme haben einen informativen Charakter. Die abgebildeten Parameter können eine Untermenge aller erlaubten Parameter darstellen. Die Aufrufe der spezifizierten Methoden sind mit dem definierten Namen identifiziert, alle übrigen Abläufe sind rein informativ umschrieben.

Abbildung 3: Ablauf der Operation sign_Document

Abbildung 4: Ablauf der Operation verify_Document

3 Übergreifende Festlegungen

Dokumentformate

Mit dem Aufruf einer Operation, die Dokumente verarbeitet, muss durch den Aufrufer festgelegt werden können, um welches Dokumentenformat es sich handelt, damit die unterschiedlichen Formate zur Verarbeitung und etwaigen Anzeige unterschieden werden können. Die nicht-XML-Formate werden dabei nach MIME-Typ-Klassen unterschieden:

• “PDF/A” für MIME-Typ „application/pdf-a” gemäß [ISO 19005],
• “Text” für MIME-Typ “text/plain”,
• “TIFF“ für MIME-Typ “image/tiff” gemäß [TIFF6]
• „Binär“ für alle übrigen MIME-Typen.

Folgende Bezeichner werden verwendet:

Alle_DocFormate:        XML, PDF/A, Text, TIFF, Binär

nonQES_DocFormate:    XML, PDF/A, Text, TIFF, Binär

QES_DocFormate:        XML, PDF/A, Text, TIFF

Für nonQES_DocFormate wird, trotz Gleichheit zu Alle_DocFormate, ein eigener Referenzbezeichner verwendet, da sich diese Liste noch ändern könnte. TIFF wird durch [gemKPT_Arch_TIP] nicht für die nonQES verlangt. Die Unterstützung dieses Formats für nonQES bedeutet jedoch keinen Mehraufwand, da die Routinen durch QES bereits implementiert sind und nachgenutzt werden können.

Die QES_DocFormate müssen hinsichtlich ihrer Anzeigequalität im Signaturproxy weiter verfeinert werden:

 QES_DF_BestView:    Dokumentformate, die im Signaturproxy vollständig angezeigt werden können

 DF_BV_PDFA:    PDF/A-2b [PDF/A-2] unter Beachtung der in Anhang C festgelegten Einschränkungen

 DF_BV_Text:     Text-Dokument (Zeichensatz ISO-8859-15 oder UTF-8)

 DF_BV_TIFF:     TIFF 6.0: Part 1 Baseline TIFF [TIFF6] unter Beachtung der in Anhang C festgelegten Einschränkungen

 DF_BV_XML:    Liste aller vollständig anzeigbaren XML-Dokumentformate. Aktuell wird für keine XML-Formate die vollständige Anzeigbarkeit garantiert.

 QES_DF_View:    Dokumentformate, die im Signaturproxy ohne den Anspruch auf Korrektheit und Vollständigkeit angezeigt werden können (bestmögliche Darstellung mit entsprechendem Warnhinweis, siehe TIP1-A_4650 TUC_SIG_153). Dies umfasst alle Dokumente, die zwar zur Gruppe der QES_DocFormate gehören, aber im Einzelfall in konkreten Teilen von den unter QES_DF_BestView benannten Formaten abweichen (beispielsweise unerlaubte Subelemente beinhalten).

Der Default-Fall ist das Erstellen von PDF-Dateien.

Der Erstellungsprozess der PDF-Dateien ist zweistufig. Aus dem XML-Dokument wird mit Hilfe des Stylesheets ein neues XML-Dokument erzeugt, welches einen FormatingObjekt-Baum im Namensraum http://www.w3.org/1999/XSL/Format erzeugt. Aus diesem Baum wird im zweiten Schritt über einen Formating Objects Processsor (z.B. Apache FOP) eine PDF-Datei erzeugt.

Im Fall der HTML-Generierung liegt es in der Verantwortung des Herstellers, für eine geeignete Dokumentierung des optionalen Features zu sorgen, die eine Nutzung ermöglicht.

Der Proxy muss zusammen mit dem aufrufenden Clientsystem auf einer Hardware installiert werden. Dadurch soll sowohl die lokale Anzeige sichergestellt werden, als auch eine sichere und effiziente Übergabe des Signaturauftrags vom Clientsystem an den Signaturproxy. Das Interface des Signaturproxy darf nicht über NAT/PAT anderen Systemen zugänglich gemacht werden.

Durch die localhost-Bindung laufen Clientsystem und Signaturproxy auf dem gleichen System und innerhalb eines Rechners ist eine TLS-Absicherung unnötig. Explizit ausgeschlossen wird sie nicht. Die LE-Umgebung wird als nicht kompromittiert angenommen. Daher ist auch eine Authentifizierung unnötig.

Falls der Administrator keine Transportsicherung im LAN einschaltet, so gilt dieses auch für Verbindung zwischen Signaturproxy und Konnektor.

Da in dieser Verbindung der Konnektor der Server ist, wird die TLS-Verbindung über die Anforderungen an den Konnektor geregelt.

Für den Signaturproxy gelten die gleichen Authentisierungsverfahren wie für alle Clientsysteme. Wenn der Administrator TLS mit Clientauthentifizierung auswählt, muss er entsprechende Zertifikate im Signaturproxy konfigurieren.

Hinweis zu Punkt (h): Die Eigenschaft ergibt sich direkt aus dem Aufrufparameter dss:ReturnUpdatedSignature:

• Parallelsignatur, falls dss:ReturnUpdatedSignature = http://ws.gematik.de/conn/sig/sigupdate/parallel
• Dokumentinkludierende Gegensignatur, falls dss:ReturnUpdatedSignature = http://ws.gematik.de/conn/sig/sigupdate/counter/documentincluding
• Dokumentexkludierende Gegensignatur, falls dss:ReturnUpdatedSignature = http://ws.gematik.de/conn/sig/sigupdate/counter/documentexcluding

Für den Fall, dass die Lösung zur Unterstützung der geforderten Clientsysteme auf einer betriebssystemabstrahierenden Schicht aufsetzt (z. B. Java SE), liegt die Bereitstellung der abstrahierenden Schicht als Teil der Lösung in der Verantwortung des Herstellers. Es kann beispielsweise nicht davon ausgegangen werden, dass in den Arztpraxen eine bestimmte Java-Laufzeitumgebung (JRE) installiert ist.

Da der Signaturproxy eine optionale Komponente ist, kann die Ansichtsfunktion auch im Primärsystem umgesetzt werden.

Bei der hier vorgeschlagenen Lösung wird der Signaturproxy vom Primärsystem unter Angabe des vom Primärsystem vorgegebenen und verwalteten Listener-Port gestartet. Somit verwaltet das Primärsystem die Ports.

4 Funktionsmerkmale

4.1 Signaturdienst

4.1.1 Operation SignDocument

TIP1-A_5674 - SigProxy: Operation SignDocument (nonQES und QES)

Der Signaturdienst des Signaturproxy MUSS an der Clientschnittstelle eine an [OASIS-DSS] angelehnte Operation SignDocument anbieten.

Tabelle 9: TAB_SIG_848 Operation SignDocument (nonQES und QES)

Name	SignDocument
Beschreibung	Die Funktionalität der Methode ist identisch zu der Funktionalität von [gemSpec_Kon#AB_KON_065].
Aufrufparameter	Die Parameter der Methode sind identisch mit den Parametern von [gemSpec_Kon#TAB_KON_065]. Die unterschiedliche Interpretation bestimmter Parameter wird nachfolgend erläutert.
	Name	Beschreibung
	TvMode	Legt das Verhalten des Signaturproxy für den SignRequest-Stapel fest. Erlaubte Werte: CONFIRMED (Bestätigungsmodus): Unter Nutzung des ShortText-Attributes aus den SIG:Document-Elementen werden die zu signierenden Dokumente im Signaturproxy angezeigt. Der Benutzer kann Dokumente durch Deselektion von der Signatur ausschließen und sich den Inhalt einzelner zu signierender Dokumente anzeigen lassen. Der Signaturvorgang wird erst nach einer Bestätigung durch den Benutzer im Signaturproxy gestartet. UNCONFIRMED (Ansichtsmodus): Im Vergleich zum Bestätigungsmodus wird nicht auf eine Bestätigung des Signaturvorgangs durch den Benutzer im Signaturproxy gewartet. Eine Deselektion einzelner zu signierender Dokumente durch den Benutzer ist nicht möglich. NONE Keine Anzeige im Signaturproxy. Dieser Wert ist nur für nonQES erlaubt. Wenn der Parameter bei QES auf NONE gesetzt wird, gibt der Signaturproxy einen Fehler 4248 zurück. (siehe weitere Anzeige gemäß TIP1-A_4656: Anzeige verpflichtender Parameter bei Signaturerstellung).
	SIG: JobNumber	Optional: Die Nummer des Jobs, unter der der nächste Signaturvorgang gestartet wird.
	sp:GenerateUnder SignaturePolicy	Der Parameter wird im Signaturproxy nicht ausgewertet.
	SIG:ViewerInfo	Enthält Informationen zur Anzeigeaufbereitung in Form von Stylesheets. Die Struktur dieses Elementes ist identisch zur Struktur beschrieben in [gemSpec_Kon#TAB_KON_065] und die eventuellen Unterschiede sind nachfolgend erläutert. Für definierte XML-Formate gemäß DF_BV_XML DARF dieses optionale Element NICHT vorhanden sein. Das zur Anzeige zu verwendende Stylesheet wird hierbei vom Signaturproxy durch das erkannte Format des XML-Dokuments bestimmt.
	SIG:XslStylesheets	Optionale Liste von XSL-Stylesheets zur Aufbereitung des XML-Dokuments für die Anzeige. Hierbei MUSS das Haupt-Stylesheet als erstes Element übergeben werden.
	CONN:XslStylesheet	Dieses Element enthält ein base64-codiertes Stylesheet im CONN:Data-Element und eine das Stylesheet identifizierende URI im CONN:RefURI-Element.
Rückgabe	Die Rückgabewerte der Methode sind identisch mit den Rückgabewerten von [gemSpec_Kon#TAB_KON_065]. Die Unterschiedliche Interpretation bestimmter Rückgabewerte wird nachfolgend erläutert.
	SIG:SignResponse	Für Dokumente, die vom Benutzer durch Deselektion von der Signaturerzeugung ausgeschlossen wurden, wird ebenfalls ein Element SignResponse zurückgegeben, wobei enthalten ist: kein SIG:OptionalOutputs, kein dss:SignatureObject, CONN:Status/CONN:Result = “Warning“, CONN:Status/CONN:Error mit einem Fehlereintrag Fehlercode 4249.
Vorbedingungen	Keine
Nachbedingungen	Keine

Der Ablauf der Operation SignDocument ist in Tabelle 10: TAB_SIG_849 Ablauf Operation SignDocument (nonQES und QES) beschrieben:

Tabelle 10: TAB_SIG_849 Ablauf Operation SignDocument (nonQES und QES)

Nr.	Aufruf Technischer Use Case oder Interne Operation		Beschreibung
1.	checkArguments		Alle übergebenen Parameterwerte werden auf Konsistenz und Gültigkeit überprüft. Treten hierbei Fehler auf, so bricht die Operation mit Fehler 4000 ab.
2.	Aufruf der Operation GetResourceInformation am Konnektor		Es wird der Kartentyp beim Konnektor anhand des CardHandle abgefragt. Anhand des Kartentyps wird ermittelt, ob eine QES oder eine nonQES erzeugt werden soll. Der Kartentyp wird weiter benötigt, um das richtige Zertifikat beim Konnektor abzufragen (siehe Tabelle [gemSpec_Kon#TAB_KON_900]. Tritt beim Lesen ein Fehler auf, bricht die Operation mit Fehlercode aus GetResourceInformation ab.
Bei TvMode= Confirmed oder Unconfirmed wird Schritt 3 ausgeführt
3.	Aufruf der Operation ReadCardCertificate am Konnektor		Es wird das im Schritt 2 identifizierte Zertifikat beim Konnektor abgefragt, mit dem anschließend das Signieren erfolgt. Falls crypt=RSA_ECC wird der Parameter crypt zum Aufruf der Operation ReadCardCertificate wie folgt gesetzt: für Karten vom Type G2.0: crypt=RSA für Karten vom Type G2.1: crypt=ECC Tritt beim Lesen ein Fehler auf, bricht die Operation mit Fehlercode aus ReadCardCertificate ab.
Wenn keine Jobnummer mit SignDocument übergeben wurde, wird Schritt 4 ausgeführt
4.	Aufruf der Operation GetJobNumber am Konnektor		Ermittle Jobnummer für das Signieren, um sie beim Anzeigen des Dokumentes einblenden zu können. Tritt beim Holen der Jobnummer ein Fehler auf, bricht die Operation mit Fehlercode aus GetJobNumber ab.
Für jedes Dokument wird Schritt 5. und bei einer angeforderten Gegensignatur Schritt 6. ausgeführt
5.	Prüfung der Typkonformität	TUC_SIG_192 „Dokumentenvalidierung“ Für jedes Dokument findet eine Prüfung der Konformität zum behaupteten Typ statt. Wenn hierbei ein Fehler auftritt, wird die Verarbeitung für das jeweilige Dokument abgebrochen. Für das Dokument wird eine SignResponse in SignDocumentResponse aufgenommen, mit CONN:Status/CONN:Result=Warning und dem Abbruchfehler unter CONN:Status/GERROR:Error/GERROR:Trace
6.	Aufruf der Operation VerifyDocument am  Konnektor	Die Prüfung der gegenzusignierenden Signaturen erfolgt durch den Aufruf von VerifyDocument mit dem gleichen Dokument.  Die vom Konnektor erzeugten Elemente VerificationReport/IndividualReport werden unter SignResponse/OptionalOutputs/VerficationReports/IndividualReport in der Antwortnachricht eingebettet.
Bei TvMode= Confirmed oder Unconfirmed werden Schritte 7 und 8 ausgeführt Schritt 7 muss dabei für jedes Dokument erst dann ausgeführt werden, wenn das jeweilige Dokument dem Benutzer angezeigt wird.
7.	Anzeige Aufbereiten		TUC_SIG_193 „Anzeigbarkeit des Dokuments prüfen und herstellen“ Das Anzeigen des Dokuments wird vorbereitet.
8.	Nutzeranzeige		TUC_SIG_153 „Dokumentenliste im Signaturproxy anzeigen“ Das Dokument wird angezeigt. Die Anzeige beinhaltet: Dokument Jobnummer Zertifikat Prüfergebnis von Vorsignaturen bei Gegensignatur Für XML-Dateien, für die dem Signaturproxy keine XSL-Transformationsdatei zur Verfügung steht (keine wurde übergeben), zeigt der Signaturproxy unveränderte XML-Daten an, die zur Erhöhung der Lesbarkeit formatiert sein können.
9.	Aufruf der Operation SignDocument am Konnektor		Der Signaturauftrag wird entsprechend der Bearbeitung durch den Benutzer an den Konnektor übergeben. Stylesheets werden nicht an den Konnektor übermittelt. Schemata werden wie im Aufruf enthalten vom Signaturproxy an den Konnektor übermittelt. Tritt bei der Prüfung ein Fehler auf, bricht die Operation mit Fehlercode aus SignDocument ab.
Bei TvMode= Confirmed oder Unconfirmed werden Schritte 10 und 11 ausgeführt.
10.	Fortschrittsanzeige		Getriggert durch die Fortschrittsevents des Konnektors wird dem User der Fortschritt des Signierens im Falle einer Stapelsignatur präsentiert.
11.	Ergebnisanzeige		Das Ergebnis der Prüf- und Signaturschritte wird dem Nutzer präsentiert.

Tabelle 11: TAB_SIG_850 Übersicht Fehler Operation SignDocument (nonQES und QES)

Fehlercode	ErrorType	Severity	Fehlertext
Neben den Fehlercodes der aufgerufenen Operationen können folgende weiteren Fehlercodes auftreten:
4000	Technical	Error	Syntaxfehler
4244	Technical	Error	Fehler beim Aufbereiten der Anzeige
4245	Technical	Error	Fehler bei der Anzeige
4248	Technical	Error	TvMode = NONE nicht erlaubt bei QES
4249	Technical	Warning	Dokument wurde deselektiert
4250	Technical	Error	Verbindung zum Konnektor ist gestört
4049	Technical	Error	Abbruch durch den Benutzer
4116	Technical	Error	Timeout (Benutzer)

Die zulässigen Zertifikate und Schlüssel für die nonQES sind in der Tabelle [gemSpec_Kon#TAB_KON_900] und privater Schlüssel je Karte für Sign/VerifyDocument (nonQES) aufgeführt.
Die zulässigen Zertifikate und Schlüssel für die QES sind in der Tabelle [gemSpec_Kon#TAB_KON_900] Zertifikat und privater Schlüssel je Karte für Sign/VerifyDocument (QES) aufgeführt.

[<=]

4.1.2 Operation VerifyDocument

4.2 Dienstverzeichnisdienst

Der Dienstverzeichnisdienst des Signaturproxy ist identisch mit dem Dienstverzeichnisdienst des Konnektors bis auf die Anforderung TIP1-A_4528 (vergl. Konnektorspezifikation), die im Folgenden für den Signaturproxy durch TIP1-A_5676 ersetzt wird.

Die Endpunkte der Basisdienste werden in WSDL spezifiziert. Diese Endpunkte und weitere konnektormodellspezifische Informationen werden dem Clientsystem in Form eines Dienstverzeichnisdienstes gesammelt angeboten.

Der prinzipielle Ablauf sieht dabei folgendermaßen aus:

Der Signaturproxy ruft beim Initialisieren des Systems mit HTTP-GET die vordefinierte URL:     https://<ANLW_LAN_IP_ADDRESS oder     MGM_KONN_HOSTNAME>/connector.sds oderhttp://<ANLW_LAN_IP_ADDRESS oder MGM_KONN_HOSTNAME>/connector.sds des Konnektors auf.

Der Konnektor stellt die Liste der Dienste, der Versionen und die Endpunkte der Dienste in einem XML-Dokument zusammen (vergl. Kapitel 4.1.3.1 in der Konnektorspezifikation). Der Signaturproxy ersetzt in der vom Konnektor empfangenen Datei connector.sds die Einträge der von ihm angebotenen Dienste entsprechend. Die so erstellte Liste der Dienste wird als Antwort an das Clientsystem übergeben, wenn das Clientsystem initialisiert und die Liste vom Signaturproxy abgeholt wird.

Das Clientsystem prüft, ob die gewünschten Dienste und Versionen unterstützt werden und merkt sich die Endpunkte der Dienste für die späteren Aufrufe. Danach kann das Clientsystem diese Dienstendpunkte nach Bedarf aufrufen.

Bei HTTP_PORT und HTTPS_PORT handelt es sich um Konfigurationswerte, die bei der Installation oder gemäß TIP1-A_5679 beim Starten des Signaturproxy gesetzt werden können.

Da auf dem Clientsystem noch andere Anwendungen laufen und der Signaturproxy nicht privilegiert im user-Kontext laufen kann, kann die Verwendung von Standard-Ports nicht verlangt werden.

4.3 Betriebsaspekte

4.3.1 Protokollierung

Die Häufigkeit und der Inhalt der protokollierten Informationen sind herstellerspezifisch.

4.3.2 Terminal-Server-Umgebungen

In Terminal-Server-Umgebungen müssen viele Instanzen des Signaturproxy parallel in unterschiedlichem User-/Arbeitsplatz-Kontext laufen können und durch Clientsystem explizit angesprochen werden können. Diese Ansprache erfolgt durch dedizierte Ports. Um dem Clientsystem die Zuordnung dieser Ports zu ermöglichen gilt folgende Anforderung:

Mit Terminal-Server-Umgebungen sind solche Umgebungen gemeint, in denen an jedem Arbeitsplatz nur ein Thin-Client läuft, welcher die Anzeige von einem Server (Terminal-Server) übernimmt und Eingaben an diesen Terminal-Server weiterleitet (z.B. RDP-Protokoll). Auf dem Server läuft dann für jeden Arbeitsplatz eine Sitzung mit einem spezifischen User-Kontext. Das Primärsystem läuft auch auf dem Terminal-Server.

Das Konzept geht davon aus, dass der Signaturproxy innerhalb dieser Sitzung auf dem Terminal-Server läuft und nicht auf dem Thin-Client. Somit kann das Primärsystem den Signaturproxy auf Localhost ansprechen.

Für den Signaturproxy wird mit der Anforderung gefordert, dass der Signaturproxy durch einen Systemaufruf im Kontext einer Sitzung mit User-Kontext gestartet werden kann und dass in diesem Systemaufruf die Listener-Ports (SOAP und CEPT) festgelegt werden.

Von der SOLL-Anforderung darf abgewichen werden, wenn durch einen anderen Mechanismus für das Primärsystem eine korrekte Zuordnung von Port zum Arbeitsplatz möglich ist.

5 Anhang A – Verzeichnisse

5.1 Abkürzungen

5.2 Glossar

Das Glossar wird als eigenständiges Dokument, vgl. [gemGlossar] zur Verfügung gestellt.

5.3 Abbildungsverzeichnis

5.4 Tabellenverzeichnis

5.5 Referenzierte Dokumente

5.5.1 Dokumente der gematik

Die nachfolgende Tabelle enthält die Bezeichnung der in dem vorliegenden Dokument referenzierten Dokumente der gematik zur Telematikinfrastruktur. Der mit der vorliegenden Version korrelierende Entwicklungsstand dieser Konzepte und Spezifikationen wird pro Release in einer Dokumentenlandkarte definiert, Version und Stand der referenzierten Dokumente sind daher in der nachfolgenden Tabelle nicht aufgeführt. Deren zu diesem Dokument passende jeweils gültige Versionsnummer sind in der aktuellsten, von der gematik veröffentlichten Dokumentenlandkarte enthalten, in der die vorliegende Version aufgeführt wird.

5.5.2 Weitere Dokumente

6 Anhang B – Profilierung der Signatur- und Verschlüsselungsformate (normativ)

6.1 – Profilierung der Signaturformate

Tabelle 15: TAB_SIG_779 „Profilierung der Signaturformate“

6.2 – Profilierung der Transformation von XML-Dokumenten für die Anzeige

Funktional zu unterstützende XSL-FO-Objects und -Properties aus dem [XSL]-Standard.

Tabelle 16: TAB_SIG_801 „Zu unterstützende XSL-FO-Objects und -Properties“

7 Anhang C – QES-Dokumentenformate und -Signaturrichtlinien (normativ)

7.1 – Dokumentenformat DF_BV_PDFA

DF_BV_PDFA, das Dokumentenformat für die vollständige Anzeige von PDF-Dokumenten im Signaturproxy, ist definiert als PDF/A-2b [PDF/A-2] mit den nachfolgenden Einschränkungen:

• das Dokument enthält keine transparenten Elemente
• das Dokument bettet keine weiteren PDF-Dokumente ein
• das Dokument enthält keine JPEG 2000 Elemente
• das Dokument enthält keine Ebenen

7.2 – Dokumentenformat DF_BV_TIFF

DF_BV_TIFF, das Dokumentenformat für die vollständige Anzeige von TIFF-Dokumenten im Signaturproxy, ist definiert als TIFF 6.0: Part 1 Baseline TIFF [TIFF6] mit den nachfolgenden Einschränkungen:

• das Dokument enthält keine eingebetteten Unterdateien
• das Dokument enthält ausschließlich solche Tags, die in [TIFF6], Part 1: Baseline TIFF,  aufgeführt sind.

8 Anhang D – Fehlercodes

Tabelle 17: TAB_SIG_855 Fehlercodes des Signaturproxy