Elektronische Gesundheitskarte und Telematikinfrastruktur
Spezifikation
KOM-LE-Clientmodul
Version |
1. |
Revision |
548770 |
Stand |
|
Status |
|
Klassifizierung |
öffentlich |
Referenzierung |
gemSpec_CM_KOMLE |
Dokumentinformationen
Änderungen zur Vorversion
Einarbeitung gemäß Änderungsliste P15.4P18.1
Dokumentenhistorie
Version |
Stand |
Kap./ Seite |
Grund der Änderung, besondere Hinweise |
Bearbeitung |
0.5.0 |
19.11.13 |
|
zur Abstimmung freigegeben |
gematik |
1.0.0 |
27.01.14 |
|
Einarbeitung Kommentare |
|
1.1.0 |
28.02.14 |
4.1.2 |
XP-Verweis entfernt |
P74 |
1.2.0 |
25.07.14 |
3.1 |
Zeitsynchronisation Konnektor ergänzt |
P74 |
1.3.0 |
24.07.15 |
|
Begriff Betreiber durch Anbieter ersetzt |
|
1.4.0 |
16.10.16 |
|
Anpassungen gemäß Änderungsliste |
gematik |
1.5.0 |
14.05.18 |
|
Einarbeitung P15.4 |
gematik |
|
|
|
Einarbeitung P18.1 |
|
1. |
|
|
freigegeben |
gematik |
Inhaltsverzeichnis
DokumentinformationenDokumentinformationen
InhaltsverzeichnisInhaltsverzeichnis
3.2.2.2 Verbindungsaufbau mit MTA
3.2.4.1 Empfang und Weiterleitung einer Nachricht
3.2.4.1.1 Bearbeitung einer ungeschützten Nachricht
3.2.4.1.2 Bearbeitung einer geschützten KOM-LE-Nachricht
3.3.2.2 Verbindungsaufbau mit dem POP3-Server
3.3.4.1 Empfang und Weiterleitung einer Nachricht
3.3.4.2 Aufbereitung einer Nachricht
3.4 Übermittlung von Kontaktdaten
3.5 Kryptographischen Schnittstellen des Konnektors
3.5.1 Erstellung der digitalen Signatur einer Nachricht mit einer SM-B
3.5.2 Prüfung der digitalen Signatur einer Nachricht
3.5.3 Verschlüsselung einer Nachricht
3.5.4 Entschlüsselung einer Nachricht mit einer SM-B bzw. einem HBA
4 Nichtfunktionale Anforderungen
4.1.2 Transportsicherung zwischen Clientsystem und Clientmodul
4.1.3 Transportsicherung zwischen Clientmodul und Konnektor
4.1.4 Transportsicherung zwischen Clientmodul und Fachdienst
4.2 Nutzung von Webservice-Schnittstellen des Konnektors
1 Einordnung des Dokumentes
1.1 Zielsetzung
Das vorliegende Dokument spezifiziert die Anforderungen an den Produkttyp KOM-LE-Clientmodul. Das Clientmodul ist verantwortlich für das Signieren und Verschlüsseln von KOM-LE-Nachrichten beim Versenden sowie für die Entschlüsselung und Signaturprüfung beim Abholen von KOM-LE-Nachrichten.
Aus den Kommunikationsbeziehungen mit Clientsystem, Konnektor, Verzeichnisdienst und KOM-LE-Fachdienst resultieren vom Clientmodul anzubietende Schnittstellen, die in diesem Dokument normativ beschrieben werden. Vom Clientmodul genutzte Schnittstellen liegen zumeist in anderen Verantwortungsbereichen (Konnektor, Verzeichnisdienst). Diese werden in den entsprechenden Produkttypspezifikationen definiert.
1.2 Zielgruppe
Dieses Dokument richtet sich an
- Entwickler des KOM-LE-Clientmoduls,
- Primärsystemhersteller und
- Verantwortliche für Zulassung und Test.
1.3 Geltungsbereich
Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren werden durch die gematik GmbH in gesonderten Dokumenten (z.B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.
1.4 Arbeitsgrundlagen
Grundlagen für die Ausführungen dieses Dokumentes sind
- Lastenheft Adressierte Kommunikation Leistungserbringer
- Systemspezifisches Konzept KOM-LE [gemSysL_KOMLE]
- KOM-LE S/MIME-Profil [gemSMIME_KOMLE]
- Gesamtarchitektur der TI [gemÜK_Arch_TI]
- Konzept Architektur der TI-Plattform [gemKPT_Arch_TIP]
- Spezifikation PKI [gemSpec_PKI]
- Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemSpec_Krypt]
- Spezifikation Konnektor [gemSpec_Kon]
1.5 Abgrenzung des Dokuments
Spezifiziert werden in dem Dokument die vom Produkttyp bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf die entsprechenden Dokumente wird referenziert.
Die Systemlösung der Fachanwendung KOM-LE ist im systemspezifischen Konzept [gemSysL_KOMLE] beschrieben. Dieses Konzept setzt die fachlichen Anforderungen des Lastenheftes auf Systemebene um, zerlegt die Fachanwendung KOM-LE in die zugehörigen Produkttypen, darunter das KOM-LE-Clientmodul und der KOM-LE-Fachdienst. Ferner definiert es die Schnittstellen zwischen den einzelnen Produkttypen. Für das Verständnis dieser Spezifikation wird die Kenntnis von [gemSysL_KOMLE] vorausgesetzt.
Die Anforderungen am Fachdienst werden separat in der Spezifikationen Fachdienst KOM-LE [gemSpec_FD_KOMLE] beschrieben.
Die Anforderungen an das Format der KOM-LE-Nachrichten, die zwischen dem Clientmodul und dem Fachdienst übermittelt werden, werden separat im KOM-LE-S/MIME-Profil [gemSMIME_KOMLE] beschrieben.
Abbildung 1 zeigt schematisch die Einbettung des vorliegenden Dokuments in die Dokumentenlandschaft der Lastenheft- und Pflichtenheftphase in Form einer Dokumentenhierarchie.
Abbildung 1: Abb_Dok_Hierarchie Dokumentenhierarchie KOM-LE
1.6 Methodik
1.6.1 Anforderungen
Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID 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 innerhalb der TextmarkenAfo-ID und der Textmarke angeführten Inhalte.
1.6.2 Diagramme
Die Darstellung der Spezifikationen von Komponenten erfolgt auf der Grundlage einer durchgängigen Use-Case-Modellierung als
- technische Use Cases (eingebundene Graphik sowie tabellarische Darstellung mit Vor- und Nachbedingungen gemäß Modellierungsleitfaden),
- Sequenz- und Aktivitätendiagramme sowie
- Klassendiagramme
- XML-Strukturen und Schnittstellenbeschreibungen.
1.6.3 Nomenklatur
Sofern im Text dieser Spezifikation auf die Ausgangsanforderungen verwiesen wird, erfolgt dies in eckigen Klammern, z.B. [KOMLE-A_2015]. Wird auf Eingangsanforderungen verwiesen, erfolgt dies in runden Klammern, z.B. (KOMLE-A_202).
2 Systemüberblick
Das Clientmodul bietet die Funktionalität, die für Anwendungsfälle KOM-LE_AF_1 „Nachricht senden“ und KOM-LE_AF_2 „Nachricht empfangen“ (siehe [gemSysL_KOMLE]) relevant ist. Die Aufgabe des Clientmoduls ist das Aufbringen und Aufheben des Schutzes der Integrität und Vertraulichkeit der zwischen den KOM-LE-Teilnehmern ausgetauschten E-Mail-Nachrichten. Dabei kommuniziert das Clientmodul mit dem Clientsystem, dem KOM-LE-Fachdienst und nutzt mehrere Dienste der TI-Plattform. Abbildung 2 stellt die grundlegenden Elemente der KOM-LE-Architektur dar.
Abbildung 2: Abb_KOMLE_Komp KOM-LE-Komponenten
Die im Clientmodul bearbeitende E-Mail-Nachrichten werden beim Senden entsprechend dem KOM-LE-S/MIME-Profil [gemSMIME_KOMLE] digital signiert und verschlüsselt und beim Empfangen entschlüsselt und deren Signatur geprüft. Das KOM-LE-S/MIME-Profil konkretisiert die S/MIME-Spezifikation und stellt sicher, dass die Interoperabilität zwischen den verschiedenen KOM-LE-Komponenten sowie der Schutz von Integrität und Vertraulichkeit für alle personbezogenen medizinischen Daten gewährleistet werden.
Jede dem KOM-LE-S/MIME-Profil entsprechende Nachricht hat die in Abbildung 3 dargestellte Struktur. Die äußere Nachricht ist eine entsprechend dem S/MIME-Standard signierte und verschlüsselte E-Mail-Nachricht. Die innere Nachricht ist eine im Clientsystem erzeugte E-Mail-Nachricht, die Nutzdaten enthält und als message/rfc822 Anhang in die äußere Nachricht verpackt ist.
Abbildung 3: Abb_Struk_KOMLE_Msg Struktur einer KOM-LE-Nachricht
3 Produktfunktionen
3.1 Allgemeine Anforderungen
KOM-LE-A_2003 - Unterstützung von E-Mail-Clients
Das KOM-LE-Clientmodul MUSS das Senden und Empfangen von Nachrichten mit marktüblichen SMTP/POP3 Desktop-E-Mail-Clients unterstützen.
[<=]
KOM-LE-A_2004 - Größe einer KOM-LE-Nachricht
Das KOM-LE-Clientmodul MUSS Nachrichten mit einer Nettogröße von bis zu 25 MB bearbeiten können. Dabei ist zu beachten, dass sich durch die base64-Kodierung der Nachricht die zu verarbeitende Bruttogröße um den Faktor 1,37 erhöht.
[<=]
KOM-LE-A_2005 - Keine persistente Speicherung von Nachrichten
Das KOM-LE-Clientmodul DARF NICHT die Inhalte von Nachrichten länger als es für die Aufbereitung und Übermittlung nötig ist, speichern.
[<=]
KOM-LE-A_2230 - Synchronisation mit der Systemzeit des Konnektors
Das KOM-LE-Clientmodul MUSS sich unter Verwendung der Operation sync_Time mit der Systemzeit des Konnektors synchronisieren.
[<=]
Diese Spezifikation erläutert nicht alle Schritte und Einzelheiten der SMTP- und POP3-Kommunikation zwischen dem Clientsystem, dem KOM-LE-Clientmodul und dem KOM-LE-Fachdienst. Es setzt voraus, dass das Format einer E-Mail, MIME, SMTP und POP3 dem Leser bekannt sind.
KOM-LE-A_2006 - Einzuhaltende Standards beim Senden und Empfangen
Das KOM-LE-Clientmodul MUSS sich beim Senden und Empfangen von Nachrichten konform zu folgenden Standards verhalten:
- IETF Draft: The LOGIN SASL Mechanism, K. Murchison, M. Crispin, August 2003,
- RFC 1939: Post Office Protocol – Version 3 [RFC1939],
- RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies [RFC2045],
- RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types [RFC2046],
- RFC 2449: POP3 Extension Mechanism [RFC2449],
- RFC 3463: Enhanced Mail System Status Codes [RFC3463],
- RFC 4616: The PLAIN Simple Authentication and Security Layer (SASL) Mechanism, K. Zeilenga, August 2006 [RFC4616],
- RFC 4954: SMTP Service Extension for Authentication [RFC5321],
- RFC 5321: Simple Mail Transfer Protocol [RFC5248],
- RFC 5322: Internet Message Format [RFC5322],
- RFC 5750: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate Handling, B. Ramsdell, S. Turner, Januar 2010 [RFC5750] und
- RFC 5751: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification, B. Ramsdell, S. Turner, Januar 2010 [RFC5751].
[<=]
3.2 Senden von Nachrichten
In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die für den Anwendungsfall „KOM-LE_AF_1 Nachricht senden“ [gemSysL_KOMLE] spezifisch sind.
3.2.1 Übersicht
Beim Senden von KOM-LE-Nachrichten sorgt das Clientmodul dafür, dass die gesendeten E-Mail-Nachrichten digital signiert und verschlüsselt dem Message Transfer MailTransfer Agent des KOM-LE-Fachdienstes (weiter im Text als MTA bezeichnet), bei dem der Sender registriert ist, übermittelt werden. Abbildung 4 stellt die Interaktionen zwischen den am Senden von KOM-LE-Nachrichten beteiligten Komponenten dar. Aus der Sicht des Clientsystems agiert das Clientmodul als ein MTA und aus der Sicht des MTAs des Fachdienstes agiert das Clientmodul als MUA. Für Funktionen wie Datentransport, kryptographische Operationen und Kommunikation mit dem Verzeichnisdienst verwendet das Clientmodul entsprechende Dienste der TI-Plattform.
Abbildung 4: Abb_Send_Msg Senden von Nachrichten
Beim Senden von Nachrichten findet die Kommunikation zwischen dem Clientsystem, dem Clientmodul und dem MTA über SMTP statt. Das Clientmodul fungiert als SMTP Proxy, der das Clientsystem mit dem MTA verbindet, die Integrität und Vertraulichkeit der vom Clientsystem gesendeten Nachricht schützt und die Nachricht an den MTA übermittelt.
Sobald die Nachricht komplett dem MTA übertragen wurde und der MTA das Ankommen der Nachricht bestätigt, übergibt das Clientmodul die Verantwortung für die Nachricht an den MTA. Die Übermittlung von Nachrichten zwischen MTAs ist nicht Bestandteil dieser Spezifikation.
Es liegt in der Verantwortung des Clientmoduls sicher zu stellen, dass die Nachricht erfolgreich dem MTA übertragen wird. Falls die Übermittlung einer Nachricht an den MTA fehlschlägt (z.B. bei Verbindungsaufbau mit dem MTA, Authentifizierung gegenüber dem MTA, Verschlüsselung oder Signieren der Nachricht), benachrichtigt das Clientmodul das Clientsystem unter Verwendung entsprechenden SMTP-Antwortcodes über den Fehler.
Beispiel: Verwendet das Clientsystem beim Senden von Nachrichten falsche Anmeldungsdaten, erhält es vom Clientmodul „535 5.7.8 Der Nutzer konnte nicht authentifiziert werden“ als Antwort auf sein AUTH-Kommando.
Das Verhalten des Clientmoduls beim Senden von Nachrichten wird mit Hilfe der in Abbildung 5 dargestellten Zustandsmuster beschrieben werden. Die im Dokument dargestellten Zustände haben nur illustrativen und keinen normativen Charakter. Die Umsetzung kann sich unterscheiden, solange das Ergebnis das Gleiche ist. Die den Zuständen zugeordnete Anforderungen sind normativ, können aber außerhalb des Kontexts dieser Zustände umgesetzt werden.
Abbildung 5: Abb_State_CM_Send Zustände Clientmodul beim Senden von Nachrichten
Das Clientmodul lauscht auf einem TCP Port und wartet bis ein Clientsystem mit ihm eine Verbindung aufbaut. Sobald dies passiert, geht das Clientmodul in den CONNECT-Zustand über und betrachtet die SMTP-Verbindung als geöffnet. Die Verbindung zwischen dem Clientsystem und dem Clientmodul muss mit TLS geschützt werden. Um mit marktüblichen E-Mail-Clients kompatibel zu sein ist die Unterstützung von TLS 1.0 obligatorisch.
Im CONNECT-Zustand führt das Clientmodul einen SMTP-Dialog mit dem Clientsystem, in dem ihm die Anmeldedaten des Nutzers sowie die Adresse und die Portnummer des MTAs mitgeteilt werden. Sobald die Anmeldedaten und die Adresse des MTAs übermittelt sind, baut das Clientmodul eine über TLS geschützte SMTP-Verbindung mit dem MTA auf, authentifiziert sich und geht in den PROXY-Zustand über.
Im PROXY-Zustand leitet das Clientmodul SMTP-Kommandos und SMTP-Antwortcodes zwischen dem Clientsystem und dem MTA weiter, bis das Clientsystem mit dem DATA-Kommando die Übertragung einer Nachricht initiiert. Sobald das Clientsystem anfängt, Inhalte einer Nachricht zu übertragen, geht das Clientmodul in den PROCESS-Zustand über.
In PROCESS-Zustand wird die Nachricht entsprechend dem KOM-LE-S/MIME-Profile [gemSMIME_KOMLE] geschützt und anschließend an den MTA übermittelt. Sobald die Nachricht erfolgreich an den MTA übertragen wurde oder im Fehlerfall, geht das Clientmodul in den PROXY-Zustand zurück.
Nachdem die Verbindungen zwischen dem Clientsystem, dem Clientmodul und dem MTA aufgebaut wurden, übermittelt das Clientmodul die SMTP-Meldungen zwischen dem Clientsystem und dem MTA so lange die beiden Verbindungen bestehen.
3.2.2 CONNECT-Zustand
Sobald die TCP-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut ist, geht das Clientmodul in den CONNECT-Zustand über.
3.2.2.1 Initialisierung
KOM-LE-A_2007 - SMTP Begrüßung
Nachdem die SMTP-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut ist, MUSS das Clientmodul dem Clientsystem die SMTP-Begrüßung senden. Um zu signalisieren, dass Extended SMTP unterstützt wird, muss die Begrüßung „ESMTP“ enthalten.
[<=]
Beispiel einer solchen Begrüßung: 220 KOM-LE-Clientmodul ESMTP
Das Clientmodul führt einen SMTP-Dialog mit dem Clientsystem bis zum Punkt, an dem das Clientsystem ihm die Adresse und die Portnummer des MTAs als einen Teil des während des Authentifizierungsverfahrens übertragenen Benutzernamens mitteilt (siehe Kapitel 3.2.2.2).
Tabelle 1 beschreibt Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.
Tabelle 1: Tab_SMTP_Ant_Init Antworten Clientmodul im CONNECT-Zustand
SMTP-Kommando |
SMTP-Antwortcode |
HELO |
“250 OK” Antwortcode |
EHLO |
“250 OK” Antwortcode mit folgenden EHLO Kennworten: |
AUTH |
Anmeldungsdaten erhalten und Verbindungsaufbau mit dem MTA beginnen (siehe Kapitel 3.2.2.2) |
RSET, NOOP |
„250 OK“ Antwortcode |
MAIL, RCPT, DATA |
„530 5.7.0“ Antwortcode (Authentication required) |
QUIT |
„221 OK“ Antwortcode senden und die Verbindung mit dem Clientsystem schließen |
Andere Meldungen |
„502 5.5.1“ Antwortcode (Invalid command) |
KOM-LE-A_2008 - Initialer SMTP-Dialog
Das Clientmodul MUSS, nachdem die SMTP-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut wird und bis zum Punkt an dem das Clientsystem die Bestätigung des Erfolgs oder Misserfolgs seiner Authentifizierung erwartet, einen SMTP-Dialog entsprechend der Tabelle Tab_SMTP_Ant_Init mit dem Clientsystem führen.
[<=]
3.2.2.2 Verbindungsaufbau mit MTA
Das Clientmodul kann die Verbindung mit dem MTA nur dann aufbauen, wenn ihm das Clientsystem die Adresse des MTAs und die Portnummer des SMTP-Dienstes übermittelt. Das Clientmodul erwartet, dass ihm der Domain Name oder die IP-Adresse und die Portnummer während des Authentifizierungsverfahrens als Teil des Benutzernamens mitgeteilt werden.
Das Clientmodul führt das Authentifizierungsverfahren mit dem Clientsystem bis zu dem Punkt, an dem es mit dem entsprechenden Antwortcode die Authentifizierung akzeptieren oder ablehnen muss. Das Clientmodul allein kann das Clientsystem nicht authentifizieren. Die Authentizität der Zugangsdaten kann nur vom MTA überprüft werden. Dazu authentifiziert sich das Clientmodul im Auftrag vom Clientsystem gegenüber dem MTA.
Die MTA-Adresse und die Portnummer des SMTP-Dienstes sind als Teil des SMTP-Benutzernamens vom Clientsystem zu übergeben. Sie sind vom eigentlichen Benutzernamen durch das Zeichen ’#’ getrennt und als adresse:port String formatiert.
Um mit der SM-B über den Konnektor kommunizieren zu können, werden dem KOM-LE-Clientmodul ebenfalls als Teil des SMTP-Benutzernamens, die Prameter
- MandantId,
- ClientSystemId und
- WorkplaceId
übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId und WorkplaceId). Die Parameter entsprechen denen des aufrufenden Clients und werden voneinander durch das Zeichen ’#’ getrennt.
Der Aufbau des SMTP-Benutzernamens entspricht somit dem folgenden Muster:
Abbildung 6: Abb_MTA_Nutzername Format des SMTP- Benutzernamens
Beispiel:
Bei folgenden Informationen
- Benutzername des Clients = „ erik.mustermann@komle.de“,
- Domain Adresse des MTAs = „mail.komle.de“ und Portnummer = 465,
- MandantId = 1,
- ClientsystemId = KOM_LE,
- WorkplaceId = 7
erwartet das Clientmodul, dass das Clientsystem ihm folgenden SMTP-Benutzernamen als String überträgt:
erik.mustermann@komle.de#mail.komle.de:465#1#KOM_LE#7
Das KOM-LE-Clientmodul bricht die Kommunikation mit dem entsprechende SMTP-Antwortcode ab (siehe Tabelle 2), wenn der erhaltene SMTP-Benutzername nicht alle erforderlichen Parameter enthält. Beinhaltet der SMTP-Benutzername zusätzliche durch ‚#’ abgegrenzte Parameter (z.B. #UserId), werden diese Parameter vom Clientmodul nicht ausgewertet und der Sendevorgang wird fortgesetzt.
Für SMTP-Authentifizierung existieren sowohl Mechanismen für die Übertragung von Nutzername und Passwort im Klartext (PLAIN und LOGIN) als auch Challenge-Response-Mechanismen. Die auf Challenge-Response (DIGEST-MD5, CRAM-MD5, NTLM) basierenden Mechanismen machen das Extrahieren des Passworts aus der Challenge-basierten Response für das Clientmodul unmöglich. Deshalb werden für die SMTP-Authentifizierung nur die PLAIN oder LOGIN-Mechanismen verwendet.
Sobald das Clientmodul die Anmeldedaten des Nutzers erhält, extrahiert es die Adresse des MTAs und die Portnummer des SMTP-Dienstes aus dem Nutzernamen und baut damit die Verbindung zum MTA auf. Die Verbindung wird über TLS geschützt. Details zum Aufbau der TLS-Verbindung werden in Kapitel 4.1.3 beschrieben.
Tabelle 2 enthält SMTP-Antwortcodes, die das Clientmodul dem Clientsystem bei einem Verbindungsaufbau mit dem MTA übermittelt.
Tabelle 2: Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau
Bedingung |
SMTP-Antwortcode |
Das Clientmodul hat sich erfolgreich gegenüber dem MTA mit den vom Clientsystem erhaltenen Anmeldungsdaten authentifiziert. |
235 2.7.0 (Authentication successful) |
Das Clientsystem verwendet für die SMTP-Authentifizierung einen anderen Mechanismus als PLAIN oder LOGIN. |
504 5.7.4 (Security features not supported) |
Die vom Clientsystem erhaltene SMTP-Authentifizierungsidentität ist nicht vollständig (MTA-Adresse, MandantId, ClientSystemId oder WorkplaceID fehlt – siehe Abbildung 6) |
501 5.5.4 (Invalid command arguments) |
Die Verbindung zwischen dem Clientmodul und dem MTA kann nicht aufgebaut werden. |
454 4.7.0 (Temporary authentication failure) |
Die Authentifizierung gegenüber dem MTA schlägt fehl. |
535 5.7.8 (Authentication credentials invalid) |
Die Verbindungen zwischen dem Clientsystem und dem Clientmodul sowie zwischen dem Clientmodul und dem MTA bleiben solange offen, bis eine von beiden geschlossen oder abgebrochen wird. Sobald eine der beiden Verbindungen geschlossen oder abgebrochen wird, übermittelt das Clientmodul die ausstehenden SMTP-Meldungen und schließt die andere Verbindung. Die SMTP-Sitzung wird damit für den MTA, das Clientsystem und das Clientmodul beendet.
Beispiel: Nachdem das Clientmodul das QUIT-Kommando vom Clientsystem erhalten und dem MTA übermittelt hat, bestätigt der MTA das Ankommen des Kommandos mit dem „221“ Antwortcode und schließt die Verbindung mit dem Clientmodul. Das Clientmodul übermittelt den „221“ Antwortcode dem Clientsystem und schließt die Verbindung mit dem Clientsystem.
KOM-LE-A_2009 - Unterstützung der Serverteile der Mechanismen PLAIN und LOGIN
Das Clientmodul MUSS für die SMTP-Authentifizierung des Clientsystems ausschließlich die Serverteile der SASL-Mechanismen PLAIN und LOGIN unterstützen.
[<=]
KOM-LE-A_2010 - Extrahieren von MTA-Adresse, Portnummer und Kartenaufrufkontext
Das Clientmodul MUSS den Benutzernamen, die MTA-Adresse, die zugehörige Portnummer und den Kartenaufrufkontext aus dem vom Clientsystem erhaltenen SMTP-Benutzernamen entsprechend Abbildung Abb_MTA_Nutzer_Name extrahieren.
[<=]
KOM-LE-A_2011 - Verbindungsaufbau mit dem MTA über MTA-Adresse und Portnummer
Das Clientmodul MUSS die MTA-Adresse und die Portnummer, die aus dem vom Clientsystem erhaltenen SMTP-Benutzernamen extrahiert wurden (siehe Abbildung Abb_MTA_Nutzer_Name), für den Verbindungsaufbau mit dem MTA verwenden.
[<=]
KOM-LE-A_2012 - Authentisierung gegenüber dem MTA mit Benutzernamen und Passwort
Das Clientmodul MUSS den Benutzernamen, der aus dem vom Clientsystem erhaltenen SMTP-Benutzernamen extrahiert wurde (siehe Abbildung Abb_MTA_Nutzer_Name) sowie das vom Clientsystem erhaltene Passwort für die Authentisierung gegenüber den MTA verwenden.
[<=]
KOM-LE-A_2013 - Unterstützung der Clientteile der Mechanismen PLAIN und LOGIN
Das Clientmodul MUSS für die SMTP-Authentifizierung mit dem MTA die Clientteile der der SASL-Mechanismen PLAIN und LOGIN unterstützen.
[<=]
KOM-LE-A_2014 - Authentifizierung gegenüber MTA mit anderen Mechanismen als PLAIN und LOGIN
Das Clientmodul KANN für die Authentifizierung gegenüber dem MTA andere Authentifizierungsmechanismen als PLAIN oder LOGIN benutzen.
[<=]
KOM-LE-A_2015 - Ergebnis des Verbindungsaufbaus mit dem MTA
Das Clientmodul MUSS das Clientsystem über das Ergebnis des Verbindungsaufbaus mit dem MTA mit den in Tabelle Tab_SMTP_Verbindung beschriebenen SMTP-Antwortcodes informieren.
[<=]
KOM-LE-A_2016 - Schließen der SMTP-Verbindung mit dem Clientsystem
Das Clientmodul MUSS die SMTP-Verbindung mit dem Clientsystem aufrechterhalten. Das Schließen der Verbindung ist nur bei folgenden Ausnahmen zulässig:
- Nachdem die Verbindung zwischen dem Clientmodul und dem MTA geschlossen oder abgebrochen wurde. In diesem Fall MUSS das Clientmodul die Verbindung mit dem Clientsystem schließen. Falls es vom MTA erhaltene und vom Clientsystem noch nicht übertragene SMTP-Antwortcodes gibt, MUSS das Clientmodul diese Antwortcodes an das Clientsystem weiterleiten und danach die Verbindung mit dem Clientsystem schließen.
- Wenn der MTA innerhalb eines konfigurierbaren Timeouts nicht auf ein SMTP-Kommando reagiert. In diesem Fall MUSS das Clientmodul den Antwortcode „421“ an das Clientsystem senden und anschließend die Verbindung schließen.
- Wenn die Verbindung zwischen dem Clientmodul und dem MTA noch nicht aufgebaut wurde und das Clientsystem das QUIT-Kommando übermittelt. In diesem Fall MUSS das Clientmodul mit „221 OK“ Antwortcode antworten und die Verbindung mit dem Clientsystem schließen.
[<=]
KOM-LE-A_2017 - Schließen der SMTP-Verbindung mit dem MTA
Das Clientmodul MUSS die SMTP-Verbindung mit dem MTA aufrechterhalten. Das Schließen der Verbindung ist nur zulässig:
- Nachdem die Verbindung zwischen dem Clientmodul und dem Clientsystem geschlossen oder abgebrochen wird. In diesem Fall MUSS das Clientmodul die Verbindung mit dem MTA schließen. Falls es vom Clientsystem erhaltene und dem MTA noch nicht übertragene SMTP-Meldungen gibt, MUSS das Clientmodul diese Meldungen dem MTA übertragen, und nur danach die Verbindung mit dem MTA schließen.
- Wenn das Clientmodul innerhalb eines konfigurierbaren Timeouts keine neuen SMTP-Kommandos sendet. In diesem Fall MUSS das Clientmodul die Verbindung mit dem MTA schließen.
[<=]
Nachdem sich das Clientsystem gegenüber dem MTA erfolgreich authentifiziert hat, geht das Clientmodul in den PROXY-Zustand über. Anderenfalls bleibt das Clientmodul im CONNECT-Zustand.
3.2.3 PROXY-Zustand
Im PROXY-Zustand vermittelt das Clientmodul SMTP-Meldungen und Antwortcodes zwischen dem Clientsystem und dem MTA. Das Clientmodul bleibt in diesem Zustand bis das Clientmodul das DATA-Kommando bekommt und der MTA das Erhalten von diesem Kommando mit dem Antwortcode „354“ bestätigt. Das Clientmodul leitet den Antwortcode „354“ an das Clientsystem weiter und geht in den PROCESS-Zustand über.
KOM-LE-A_2018 - Weiterleitung von SMTP-Meldungen und Antwortcodes
Nach erfolgreicher Beendigung des Authentifizierungsverfahrens mit dem MTA MUSS das Clientmodul alle vom Clientsystem erhaltenen SMTP-Meldungen, mit Ausnahme des RCPT-Kommandos und der Inhalte von E-Mail-Nachrichten (inklusive dem DATA-Kommando) sowie alle vom MTA erhaltenen Antwortcodes ohne Veränderung dem MTA bzw. dem Clientsystem unverzüglich übermitteln.
[<=]
KOM-LE-A_2176 - Prüfen auf gültiges ENC-Zertifikat für den Empfänger im RCPT-Kommando
Das Clientmodul MUSS, wenn es vom Clientsystem ein RCPT TO:<recipient-address> Kommando erhält, prüfen, ob für den im Kommando aufgeführten Empfänger mindestens ein gültiges ENC-Zertifikat existiert. Da die Nachricht nur an Empfänger, die ein gültiges ENC-Zertifikat besitzen weitergeleitet werden darf, MUSS dassdas Clientmodul im Negativfall das Kommando verwerfen und dem Clientsystem den Antwortcode „550“ senden . Im Positivfall MUSS das Clientmodul das Kommando an den MTA weiterleiten.
[<=]
[<=]
3.2.4 PROCESS-Zustand
Im PROZESS-Zustand nimmt das Clientmodul die Inhalte der vom Clientsystem gesendeten Nachricht entgegen. Mit Hilfe von Diensten der TI-Plattform schützt es die Vertraulichkeit und Integrität der Nachricht entsprechend dem KOM-LE-S/MIME-Profil [gemSMIME_KOMLE]. Anschließend leitet das Clientmodul die geschützte Nachricht an den MTA, bei dem der Nutzer registriert ist, weiter. Im Erfolgsfall wird das Clientsystem über das Versenden der Nachricht informiert. Im Fehlerfall wird das Clientsystem mit dem entsprechenden Antwortcode über den Fehler benachrichtigt. Im folgenden Text wird eine entsprechend dem KOM-LE-S/MIME-Profil geschützte Nachricht auch als KOM-LE-S/MIME-Nachricht bezeichnet.
3.2.4.1 Empfang und Weiterleitung einer Nachricht
Nachdem die Bereitschaft zum Empfangen der Nachricht dem Clientsystem mit dem Antwortcode „354“ bestätigt wurde, erwartet das Clientmodul, dass das Clientsystem mit der Übertragung der Nachricht fortfährt. Die Inhalte der Nachricht werden im Clientmodul zwischengespeichert und sobald das Clientsystem durch die „<CRLF>.<CRLF>“ Zeichensequenz das Ende der Nachricht markiert, werden die Inhalte der Nachricht im Clientmodul durch digitale Signatur und die Verschlüsselung geschützt. Die Details werden im Kapitel 3.2.4.1.1 beschrieben.
KOM-LE bietet die Möglichkeit Nachrichten, die beim Abholen nicht entschlüsselt wurden (z.B. auf Grund eines fehlenden HBA mit dem entsprechenden privaten Schlüssel), nachträglich zu entschlüsseln. Um die nachträgliche Entschlüsselung einer verschlüsselten KOM-LE-Nachricht durchführen zu können, schickt der Empfänger die verschlüsselte Nachricht als ein message/rfc822 Anhang in einer neuen Nachricht an seine eigene E-Mail-Adresse. Beim nächsten Abholvorgang kann diese Nachricht, sofern die erforderliche Karte vorhanden ist, durch das Clientmodul entschlüsselt werden. Werden solche Nachrichten im Clientmodul erkannt, werden sie weder signiert noch verschlüsselt. Stattdessen wird die verschlüsselte KOM-LE-Nachricht aus dem message/rfc822 Anhang extrahiert und die from Header-Elemente werden durch das from Header-Element (E-Mail-Adresse des Absenders) der angekommenen multipart MIME-Nachricht ersetzt. Anschließend wird die Nachricht dem MTA übermittelt. Die Details werden im Kapitel 3.2.4.1.2 beschrieben.
Die Benachrichtigung des Clientsystems über den Erfolg des Sendens einer Nachricht findet nur dann statt, wenn der MTA die Übernahme der Verantwortung für die Nachricht mit positiven Erledigungsstatus über den „250“ Antwortcode bestätigt. Ab diesem Moment gilt die Nachricht für das Clientsystem als versendet und der MTA hat sich zu ihrer Lieferung oder Benachrichtigung des Senders über einen Fehlerfall verpflichtet.
Nachdem das Clientsystem über das erfolgreiche Senden der Nachricht oder über einen Fehlerfall mit entsprechendem Antwortcode benachrichtigt wurde, löscht das Clientmodul die zwischengespeicherten Inhalte der Nachricht und geht zurück in den PROXY-Zustand.
KOM-LE-A_2019 - Signatur und Verschlüsselung entsprechend KOM-LE-S/MiME-Profil
Das Clientmodul MUSS die vom Clientsystem erhaltene KOM-LE-Nachricht entsprechend dem KOM-LE-S/MIME-Profil [gemSMIME_KOMLE] signieren und verschlüsseln und anschließend dem MTA übermitteln.
[<=]
3.2.4.1.1 Bearbeitung einer ungeschützten Nachricht
Um die Vertraulichkeit und die Integrität einer Nachricht zu schützen wird die Nachricht entsprechend dem KOM-LE-S/MIME-Profil signiert und verschlüsselt. Für das Signieren und die Verschlüsselung nutzt das Clientmodul die Dienste der TI-Plattform. Die folgende Abbildung stellt den prinzipiellen Ablauf und die Aktivitäten des Clientmoduls beim Erzeugen einer dem KOM-LE-S/MIME-Profil entsprechenden Nachricht dar.
Abbildung 7: Abb_Sig_Verschl Signieren und Verschlüsseln entsprechend S/MIME Profil
Für das digitale Signieren einer Nachricht verwendet das Clientmodul den privaten PrK.HCI.OSIG-Schlüssel der SM-B. Der Zugriff auf die entsprechende Karte und die Erstellung der Signatur erfolgt über die Aufrufe der entsprechenden Operationen der Außenschnittstelle des Konnektors. Eine detaillierte Beschreibung erfolgt im Kapitel 3.5.1.
Wenn das Signieren fehlschlägt, wird das Senden der Nachricht abgebrochen indem dem MTA das RSET-Kommando übermittelt wird und das Clientsystem mit dem Antwortcode „451“ inklusive der entsprechenden Fehlermeldung über den Fehlerfall informiert wird.
KOM-LE-A_2177 - Verwenden von SignDocument und EncryptDocument
Das Clientmodul MUSS für das Signieren und Verschlüsseln der Nachrichten die Operationen SignDocument und EncryptDocument der Außenschnittstelle des Konnektors verwenden.
[<=]
KOM-LE-A_2299 - Vorgehen bei Signatur und Verschlüsselung einer KOM-LE Nachricht
Zur Signatur und Verschlüsselung von KOM-LE Nachrichten MUSS das folgende Vorgehen umgesetzt werden:
- Zur CMS(CAdES)-Signatur durch den Konnektor übergibt das KOM-LE-CM beim Aufruf der SignDocument-Operation am Konnektor das zu signierende Dokument als binär-Dokument. Als Antwort gibt der Konnektors einen binären CMS-Container zurück. Zum Transport sind die binären Objekte in den SOAP-Nachrichten jeweils base64-kodiert.
- Der binäre CMS-Container mit der signierten Nachricht wird als „application/pkcs7-mime“ MIME-Einheit vom smime-type „signed-data“ mit dem Content-Transfer-Encoding „binary“ (nicht "base64") verpackt.
- Zur CMS-Verschlüsselung durch den Konnektor übergibt das KOM-LE-CM beim Aufruf der EncryptDocument-Operation am Konnektor die in Schritt zwei erzeugte Nachricht als binär-Dokument. Als Antwort gibt der Konnektors einen binären CMS-Kontainer zurück. Zum Transport sind die binären Objekte in den SOAP-Nachrichten jeweils base64-kodiert.
- Der aus der Verschlüsselung resultierende CMS-Container wird in eine „application/pkcs7-mime“ MIME-Einheit vom smime-type „authenticated-enveloped-data“ mit dem Content-Transfer-Encoding „base64“ verpackt.
[<=]
KOM-LE-A_2190 - Übergabe des recipient-emails Attributs beim Signieren
Das Clientmodul MUSS beim Aufruf der Operation SignDocument des Konnektors das recipient-emails Attribut als Aufrufparameter in der ASN.1-Form
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
übergeben. Das ASN.1-Atribut MUSS DER-kodiert und base64 verpackt im Request-Element
<SIG:SignDocument>/<SIG:SignRequest>/<SIG:OptionalInputs>/<dss:Properties>/<dss:SignedProperties>/<dss:Property>/<dss:Value>/<CMSAttribute>
übergeben werden.
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
übergeben. Das ASN.1-Atribut MUSS DER-kodiert und base64 verpackt im Request-Element
<SIG:SignDocument>/<SIG:SignRequest>/<SIG:OptionalInputs>/<dss:Properties>/<dss:SignedProperties>/<dss:Property>/<dss:Value>/<CMSAttribute>
übergeben werden.
[<=]
Folgend ein Beispiel für den SOAP-Request beim Signieren:
<?xml version="1.0" encoding="UTF-8" ?>
<SIG:SignDocument xmlns:CERTCMN="http://ws.gematik.de/conn/CertificateServiceCommon/v2.0" xmlns:CONN="http://ws.gematik.de/conn/ConnectorCommon/v5.0" xmlns:CCTX="http://ws.gematik.de/conn/ConnectorContext/v2.0" xmlns:SIG="http://ws.gematik.de/conn/SignatureService/v7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema">
<CONN:CardHandle>zDgq6V5EsA</CONN:CardHandle>
<SIG:Crypt>RSA</SIG:Crypt>
<CCTX:Context>
<CONN:MandantId>Praxis Dr. Mustermann</CONN:MandantId>
<CONN:ClientSystemId>Mediakom-PVS-3000</CONN:ClientSystemId>
<CONN:WorkplaceId>Arztzimmer2</CONN:WorkplaceId>
</CCTX:Context>
<SIG:TvMode>NONE</SIG:TvMode>
<SIG:SignRequest RequestID="SignRequestNo_001">
<SIG:OptionalInputs>
<SIG:KeyReference>C.OSIG</SIG:KeyReference>
<dss:SignatureType>urn:ietf:rfc:5652</dss:SignatureType>
<dss:Properties>
<dss:SignedProperties>
<dss:Property>
<dss:Identifier>RecipientEmailsAttribute</dss:Identifier>
<dss:Value>
<CMSAttribute>QnNVakJzUjA5RWJHaGpaMGRUUVV4TlVqQnNSMDlFYkdoalowZFRRVXhOUVVGQlVRVU
ZCVVVOQlJVMXRRMXAwZFUxR1VYaEVVemhp</CMSAttribute>
</dss:Value>
</dss:Property>
</dss:SignedProperties>
</dss:Properties>
<SIG:IncludeEContent>true</SIG:IncludeEContent>
</SIG:OptionalInputs>
<SIG:Document ShortText="none">
<dss:Base64Data>TUlNRS1WZXJzaW9uOiAxLjANCkNvbnRlbnQtdHlwZTogdGV4dC9wbGFpbjsgY2hh
cnNldD1pc28tODg1OS0xNQ0KQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzogOGJpdA0KRnJvbTogPGhh
bnMubXVzdGVyYXJ6dEBwcmF4aXNBLmRlPg0KVG86IDxldmEubXVzdGVyYXJ6dEBwcmF4aXNCLmRlPg0K
U3ViamVjdDog3GJlcndlaXN1bmcgSHIuIE0uIFBhdGllbnRCDQpEYXRlOiBNb24sIDExIE5vdiAyMDEz
IDE0OjM0OjI3ICswMTAwDQoNClNlaHIgZ2VlaHJ0ZSBGcmF1IEtvbGxlZ2luIERyLiBNdXN0ZXJhcnp0
LA0KDQpoaWVybWl0IPxiZXJ3ZWlzZSBpY2ggSWhuZW4gSHIuIE0uIFBhdGllbnRCIGF1ZiBHcnVuZCAu
Li4uDQoNCk1pdCBmcmV1bmRsaWNoZW4gR3L832VuLA0KDQpEci4gSGFucyBNdXN0ZXJhcnp0</dss:Ba
se64Data>
</SIG:Document>
<SIG:IncludeRevocationInfo>false</SIG:IncludeRevocationInfo>
</SIG:SignRequest>
</SIG:SignDocument>
Da der Versand einer Nachricht an mehrere Empfänger erfolgen kann und das Clientmodul nicht erkennt, ob alle Empfänger ECC beherrschen, muss das Signieren einer Nachricht immer mit dem RSA-Schlüssel der SM-B erfolgen.
KOM-LE-A_2020 - Signieren der Nachricht mit dem Schlüssel Prk.HCI.OSIG
Das Clientmodul MUSS für das Signieren einer KOM-LE-Nachricht den privaten Schlüssel PrK.HCI.OSIG.R2048 der SM-B der medizinischen Institution verwenden.
[<=]
[<=]
KOM-LE-A_2021 - Verhalten, wenn Nachricht nicht signiert werden kann
Das Clientmodul MUSS dem MTA das Kommando RSET senden und das Clientsystem mit dem Antwortcode „451“ benachrichtigen, wenn das Clientmodul die vom Clientsystem erhaltene Nachricht nicht digital signieren kann.
[<=]
Die Verschlüsselung erfolgt sowohl für den Sender als auch für alle Empfänger. Die erforderlichen Verschlüsselungszertifikate C.HCI.ENC für Institutionen und C.HP.ENC für Leistungserbringer werden im Verzeichnisdienst zur Verfügung gestellt. Für die Suche nach den passenden Einträgen im Verzeichnisdienst wird die KOM-LE-E-Mail-Adresse als Suchschlüssel verwendet. Wenn der Sender bzw. ein Empfänger mehrere Verschlüsslungszertifikate hat (z.B. wenn dem Empfänger ein neuer HBA ausgegeben wurde und der alte noch gültig ist), wird die Nachricht mit allen vorhandenen Verschlüsselungszertifikaten verschlüsselt.
KOM-LE-A_2191 - Übergabe des recipient-emails Attributs beim VerschlülsselnVerschlüsseln
Das Clientmodul MUSS beim Aufruf der Operation EncryptDocument des Konnektors das recipient-emails Attribut als Aufrufparameter in der ASN.1-Form
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
übergeben. Das ASN.1-Atribut MUSS DER-kodiert und base64 verpackt im Request-Element
<CRYPT:EncryptDocument>/<CRYPT:OptionalInputs>/<CRYPT:UnprotectedProperties>/<dss:Property>/<dss:Value>/<CMSAttribulte>
übergeben werden.
[<=]
Attribute ::= SEQUENCE {
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue }
übergeben. Das ASN.1-Atribut MUSS DER-kodiert und base64 verpackt im Request-Element
<CRYPT:EncryptDocument>/<CRYPT:OptionalInputs>/<CRYPT:UnprotectedProperties>/<dss:Property>/<dss:Value>/<CMSAttribulte>
übergeben werden.
[<=]
Folgend ein Beispiel für den SOAP-Request beim Verschlüsseln:
<?xml version="1.0" encoding="UTF-8" ?>
<CRYPT:EncryptDocument xmlns:CONN="http://ws.gematik.de/conn/ConnectorCommon/v5.0" xmlns:CCTX="http://ws.gematik.de/conn/ConnectorContext/v2.0" xmlns:CRYPT="http://ws.gematik.de/conn/EncryptionService/v6.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema">
<CCTX:Context>
<CONN:MandantId>Praxis Dr. Mustermann</CONN:MandantId>
<CONN:ClientSystemId>Mediakom-PVS-3000</CONN:ClientSystemId>
<CONN:WorkplaceId>Arztzimmer2</CONN:WorkplaceId>
</CCTX:Context>
<CRYPT:RecipientKeys>
<CRYPT:CertificateOnCard>
<CONN:CardHandle>zDgq6V5EsA</CONN:CardHandle>
<CRYPT:KeyReference>C.ENC1.R2048Crypt> ECC </CRYPT:KeyReference>
</CRYPT:CertificateOnCard> <CRYPT:Certificate>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</CRYPT:Certificate>
</CRYPT:RecipientKeys>
<CONN:Document>
<dss:Base64Data>QnNVakJzUjA5RWJHaGpaMGRUUVV4TlVqQnNSMDlFYkdoalowZFRRVXhOUV
VGQlVRVUZCVVVOQlJVMXRRMXAwZFUxR1VYaEVVemhp</dss:Base64Data>
</CONN:Document>
<CRYPT:OptionalInputs>
<CRYPT:EncryptionType>urn:ietf:rfc:5652</CRYPT:EncryptionType>
<CRYPT:UnprotectedProperties>
<dss:Property>
<dss:Identifier>RecipientEmailsAttribute</dss:Identifier>
<dss:Value>
<CMSAttribute>QnNVakJzUjA5RWJHaGpaMGRUUVV4TlVqQnNSMDlFYkdoalowZFRRVXhOUVVG
QlVRVUZCVVVOQlJVMXRRMXAwZFUxR1VYaEVVemhp</CMSAttribute>
</dss:Value>
</dss:Property>
</CRYPT:UnprotectedProperties>
</CRYPT:OptionalInputs>
</CRYPT:EncryptDocument>
Zum Verschlüsseln der Nachricht bezieht das Clientmodul die erforderlichen Zertifikate aus dem Verzeichnisdienst der TI. Vor der Verwendung der Zertifikate für die Verschlüsselung muss das Clientmodul prüfen, ob der verwendete Konnektor die ECC-Kryptographie unterstützt. Ist dies nicht der Fall, dürfen im Verzeichnisdienst gefundene ECC-Zertifikate nicht für die Verschlüsselung benutzt werden. Unterstützt der Konnektor ECC, sind sowohl die RSA- als auch die ECC-Zertifikate für die Verschlüsselung zu verwenden. Durch diese Herangehensweise wird sichergestellt, dass auch Empfänger, die noch kein ECC beherrschen, die Nachricht entschlüsseln können. Dieses Prinzip gilt solange, bis alle TI-Beteiligten ECC beherrschen und somit die RSA-Zertifikate gesperrt sind.
A_17464 - ECC-Migration, Prüfung der ECC-Fähigkeit des Konnektors
Das Clientmodul MUSS über eine Abfrage des Dienstverzeichnisdienstes des Konnektors prüfen, ob der verwendete Konnektor ECC-Kryptographie unterstützt. Ein Konnektor unterstützt ECC, wenn die Konnektordienstversionen des Signaturdienstes mindestens 7.4.1 und des Verschlüsselungsdienstes mindestens 6.1.1 sind. [<=]
KOM-LE-A_2022 - Verschlüsseln der Nachricht mit den Verschlüsselungszertifikaten C.HCI.ENC bzw. C.HP.ENC
Das Clientmodul MUSS vom Clientsystem erhaltene E-Mail-Nachrichten sowohl für jeden in den RCPT-Kommandos angegeben Empfänger als auch für den Sender aus dem from bzw. sender Header-Element der Nachricht mit allen dem Sender bzw. Empfängern zugeordneten Verschlüsselungszertifikaten (C.HCI.ENC für eine Institution oder C.HP.ENC für einen Leistungserbringer) verschlüsseln.
[<=]
A_17472 - ECC-Migration, Keine Verwendung von ECC-Verschlüsselungszertifikaten bei Konnektoren ohne ECC-Unterstützung
[<=] Verwendet das Clientmodul einen Konnektor, der die ECC-Kryptographie nicht unterstützt, DARF das Clientmodul ECC-Verschlüsselungszertifikate NICHT für die Verschlüsselung der Nachricht verwenden.
[<=]
KOM-LE-A_2178 - Kein Versenden an Empfänger mit unterschiedlichen Telematik-IDs in den Verschlüsselungszertifikaten
Existieren für einen Empfänger mehrere Verschlüsselungszertifikate mit unterschiedlichen Telematik-IDs DARF das Clientmodul die Nachricht NICHT an diesen Empfänger versenden.
[<=]
KOM-LE-A_2192 - Fehlernachricht bei Empfänger mit unterschiedlichen Telematik-IDs in den Verschlüsselungszertifikaten
Existieren für einen Empfänger mehrere Verschlüsselungszertifikate mit unterschiedlichen Telematik-IDs MUSS das Clientmodul den Absender der Nachricht mit einer Fehlernachricht, die weder zu signieren noch zu verschlüsseln ist, informieren.
[<=]
KOM-LE-A_2023 - Verschlüsselungszertifikate aus dem Verzeichnisdienst
Das Clientmodul MUSS in der Lage sein, die Verschlüsselungszertifikate aus dem Verzeichnisdienst der TI mit Hilfe der E-Mail-Adresse zu ermitteln.
[<=]
Nachdem die Nachricht erfolgreich signiert wurde und die entsprechenden Verschlüsselungszertifikate zur Verfügung stehen, führt das Clientmodul die Verschlüsselung der Nachricht für alle Empfänger bzw. Sender durch. Die Empfänger werden über die E-Mail-Adressen aus den RCPT-Kommandos identifiziert. Die Sender werden über die E-Mail-Adressen im sender Header-Element identifiziert. Wenn der Header der Nachricht kein sender Element enthält, werden die E-Mail-Adressen des Senders aus dem from Header-Element übernommen.
Beim Verschlüsselungsvorgang sind die folgenden Szenarien möglich:
- Die Nachricht kann für alle E-Mail-Adressen (sowohl Sender als auch Empfänger) verschlüsselt werden.
- Es gibt E-Mail-Adressen, für die aufgrund der fehlenden oder nicht gültigen Zertifikate die Nachricht nicht verschlüsselt werden kann. In diesem Fall wird die Nachricht mit den verfügbaren Zertifikaten verschlüsselt und an den MTA übermittelt. Die E-Mail-Adressen für die die Verschlüsselung nicht durchgeführt werden konnte werden aus dem Header entfernt. Der Absender der Nachricht wird über eine im Clientmodul generierte und an den MTA übermittelte E-Mail über den Fehlerfall informiert. Die Nachricht mit der Fehlermeldung wird weder signiert noch verschlüsselt.
- Wenn die Verschlüsselung für keinen der Empfänger durchgeführt werden kann, wird das Senden der Nachricht abgebrochen. Dabei wird dem MTA das RSET-Kommando gesendet und das Clientsystem wird mit dem Antwortcode „451“ und der entsprechenden Fehlermeldung über den Fehlerfall informiert.
Die Verschlüsselung erfolgt über die Aufrufe der entsprechenden Operationen der Außenschnittstelle des Konnektors. Eine detaillierte Beschreibung erfolgt in Kapitel 3.5.3.
KOM-LE-A_2024 - Information des Absenders über Empfänger, für die nicht verschlüsselt werden kann
Kann eine Nachricht auf Grund von fehlenden oder ungültigen Zertifikaten nicht für alle Empfänger verschlüsselt werden, MUSS das Clientmodul den Absender mit einer E-Mail über den Fehlerfall informieren. Aus dem Inhalt der Fehlernachricht müssen alle Empfänger, für die nicht verschlüsselt werden konnte, hervorgehen. Die Fehlernachricht ist weder zu signieren noch zu verschlüsseln. Die Originalnachricht darf an die Empfänger, für die nicht verschlüsselt werden konnte, nicht versendet werden.
[<=]
KOM-LE-A_2025 - Abbruch des Sendens, wenn keine Verschlüsselung möglich
Das Clientmodul MUSS das Clientsystem mit dem Antwortcode „451“ benachrichtigen und den Senden-Vorgang zum MTA mit dem RSET-Kommando abbrechen, wenn das Clientmodul die vom Clientsystem erhaltene Nachricht für keinen Empfänger verschlüsseln kann.
[<=]
Das KOM-LE-S/MIME-Profil fordert, dass jede entsprechend dem Profil verschlüsselte Nachricht das recipient-emails Attribut enthält. In diesem Attribut werden Zusammenhänge zwischen den für die Verschlüsselung verwendeten Zertifikaten und den E-Mail-Adressen der Empfänger bzw. des Senders angegeben. Das Clientmodul befüllt dieses Attribut nur mit den E-Mail-Adressen für die die Nachricht erfolgreich verschlüsselt werden konnte.
Um die Anzahl von Anfragen an den Verzeichnisdienst und die Bearbeitungszeiten zu reduzieren werden die für die Verschlüsselung verwendeten Zertifikate für eine konfigurierbare Zeitdauer im Clientmodul gecached.
KOM-LE-A_2026 - Cachen von Verschlüsselungszertifikaten
Das Clientmodul MUSS das manipulationssichere Cachen von Verschlüsselungszertifikaten für eine konfigurierbare Zeitdauer unterstützen.
[<=]
Die folgenden Schritte stellen den Schutzvorgang für eine Nachricht im Clientmodul dar. Die Schritte haben einen beschreibenden und nicht normativen Charakter. Die Umsetzung kann sich unterscheiden, solange die Anforderungen des Dokuments erfüllt sind.
- Der Cache und anschließend falls erforderlich der Verzeichnisdienst werden für Verschlüsselungszertifikate der Empfänger und Sender durchgesucht. Die entsprechenden E-Mail-Adressen dienen als die Suchschlüssel.
- Der Signaturdienst der TI-Plattform wird mit der zu sendenden Nachricht und der Referenz auf den Signaturschlüssel als Aufrufparameter aufgerufen.
- Der Verschlüsselungsdienst der TI-Plattform wird mit der signierten Nachricht und den gefundenen Verschlüsselungszertifikaten als Aufrufparameter aufgerufen.
- Die TI-Plattform prüft den Sperrstatus der übergebenen Verschlüsselungszertifikate und führt die Verschlüsselung durch, wenn alle Zertifikate gültig sind. Sollte die Prüfung eines oder mehreren Zertifikate als nicht gültig ausweisen, bricht die TI-Plattform den Verschlüsselungsvorgang ab. Falls sich unter den ungültigen Zertifikaten die aus dem Cache geholten Zertifikate befinden, wird der Verzeichnisdienst nach Ersatzzertifikaten durchsucht.
- Falls Ersatzzertifikate gefunden werden, wird der Verschlüsselungsvorgang wiederholt.
- Werden keine Ersatzzertifikate gefunden, werden diesen Zertifikaten entsprechende Empfänger aus dem Header der Nachricht entfernt und über den Fehlerfall mit Hilfe einer im Clientmodul generierten E-Mail informiert. Die ursprüngliche Nachricht wird an diese Empfänger nicht gesendet, weil sie nicht in der Lage sind, diese Nachricht zu entschlüsseln.
- Falls Ersatzzertifikate gefunden werden, wird der Verschlüsselungsvorgang wiederholt.