Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

KOM-LE-Clientmodul

    

     

      
Version
      
1.13.0
     
     

      
Revision
      
548770
     
     

      
Stand
      
31.01.2022
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_CM_KOMLE
     
    

Dokumentinformationen

Änderungen zur Vorversion

Anpassungen des vorliegenden Dokumentes im Vergleich zur Vorversion können Sie der nachfolgenden Tabelle entnehmen.

Dokumentenhistorie

Inhaltsverzeichnis

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 Afo-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. Optional kann das Clientmodul in das Clientsystem integriert werden. 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 von kleiner oder gleich 25 MB 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. Bei E-Mail-Nachrichten größer als 25 MB wird der Anhang aus der E-Mail extrahiert und auf einem separaten Speicherort (Fachdienst) verschlüsselt abgelegt. 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 personenbezogenen 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

Die durch das Clientmodul versendeten Nachrichten können vom Client optional gekennzeichnet werden. Es wird empfohlen eine Dienstkennung zu setzen. Andernfalls werden Nachrichten mit einer standardisierten Dienstkennung versehen. Das hierfür notwendiges Attribut im Header der Mail (X-KIM-Dienstkennung) wird im Kapitel 3.6 beschrieben. Erfolgte durch den Client keine Belegung dieses Attributes, wird durch das Clientmodul eine Default-Kennung gesetzt. Um die Abholung der auf dem Mail-Server ankommenden Nachrichten inhaltsabhängig durchführen zu können, wird das Header-Feld "X-KIM-Dienstkennung" aus der inneren Nachricht, die signiert und verschlüsselt ist, in den äußeren Header der Nachricht übernommen.

Zusätzlich wird das Clientmodul um das Administrationsmodul erweitert (siehe auch Kap. 3.7). Mit Hilfe des Administrationsmoduls kann sich der KOM-LE-Teilnehmer beim Fachdienst registrieren oder eine Deregistrierung vornehmen. Zugleich kann über das Administrationsmodul das benötigte Clientzertifikat (PKCS#12 - Datei) heruntergeladen werden.

Abbildung 4: Administrationsmodul für die Kommunikation mit dem Account Manager

Der Funktionsumfang des Clientmodules kann optional in das Clientsystem integriert werden. Somit ist kein separates Clientmodul mehr notwendig.

Wenn das Clientmodul in das Clientsystem (PVS) integriert wird, richten sich die Anforderungen des Clientmodul an das Clientsystem (PVS). Durch die optionale Integration entfallen alle Anforderungen an die Schnittstelle zwischen Clientsystem und Clientmodul, da diese nicht mehr existiert.

In diesem Szenario gilt für Anforderungen, die nur Anteile auf die Schnittstelle zwischen Clientsystem und dem Clientmodul enthalten (z.B. "vom Clientsystem erhaltene E-Mail-Nachrichten"), dass diese Anteile entfallen und die restliche Anforderung umgesetzt werden muss. Abzüglich der Tests der weggefallenen Schnittstelle ändert sich also das Zulassungsverfahren nicht.

3 Produktfunktionen

3.1 Allgemeine Anforderungen

Durch die Limitierung des Konnektors sind E-Mail-Nachrichten bis zu einer Größe von 25 MB möglich. Wenn der Empfänger einen KOM-LE-Client ab Version 1.5 nutzt, können mit der in Kap. 3.2 beschriebenen Vorgehensweise auch große Mails mit  Anhängen von über 25 MB versendet werden. Die Nachricht darf, nach Extraktion der Anhänge, weiterhin die Größe von 25 MB nicht übersteigen und muss durch das KOM-LE-Clientmodul und den KOM-LE-Fachdienst verarbeitet werden.

Die PKCS#12-Datei wird für die Registrierung eines KOM-LE-Teilnehmers sowie bei Ablauf des Clientzertifikates benötigt.

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.

Die KOM-LE-Version des Clientmodules muss mitgeteilt werden, damit der Nutzer weiß, welche Clientmodul-Version zu verwenden ist. Bei Nutzung eines Clientmodules in der KOM-LE-Version 1.0 ist eine Registrierung durch den Teilnehmer über die KOM-LE-1.5-Schnittstelle am KOM-LE-Fachdienst nicht möglich.

Die Übermittlung der KOM-LE-Version vom Anbieter kann hierbei in geeigneter Form erfolgen. Die jeweilige Client-Version kann aus dem LDAP-Directory Attribut: komLeData vom VZD entnommen werden. Geltende KOM-LE-Versionen sind 1.0 und 1.5 und werden in der Form in das Header-Element X-KOM-LE-Version eingetragen.

Tabelle #: Tab_Fehlercodes_KOMLE-Clientmodule

Die Fehlermeldungen beim Senden einer KIM-Mail werden über den Fachdienst zurück an den Sender übermittelt, da eine direkte Rückgabe der Fehlernachricht zum Client nicht vorgesehen ist. Das Clientmodul befüllt im Fehlerfall das X-KIM-Fehlermeldung-Attribut und sendet dies anschließend über den Fachdienst an den Sender zurück. Die Fehlermeldungen beim Empfang einer KIM-Mail werden auf direkten Weg dem Empfänger zugestellt. Der Client (z. B. PVS) muss die Fehlercodes aus der Tabelle Tab_Fehlercodes_KOMLE-Clientmodule auswerten.

Die folgende Anforderung bezweckt, dass bei Einsatz mehrerer Clientmodule in unterschiedlichen Versionen, der KIM-Teilnehmer bei Verwendung eines Clientmoduls in einer kleineren Version darüber informiert wird, dieses zu updaten.

Beispiel:
X-KIM-CMVersion: [VendorID]_2.1.2-8
X-KIM-PTVersion: 1.5.0-2
X-KIM-KONVersion: <secunet konnektor 2.0.0><Konnektor PTV4Plus><4.80.3><2.0.0><4.10.1>

Die Produkttypversion entspricht dabei der Produkttypversion aus dem Produkttypsteckbrief. Die Clientmodulversion entspricht dabei der zugelassenen Produktversion, die im TI-ITSM-System hinterlegt und gepflegt wird.

3.2 Umgang mit großen Anhängen

Dieses Kapitel beschreibt die Verarbeitung von Mails, welche die Nettogröße von 25 MB überschreiten. Die Größenbeschränkung auf 25 MB basiert auf den Konnektoroperationen zum Signieren und Verschlüsseln. Für diese Operationen existiert eine Größenbeschränkung auf 25 MB.

E-Mails mit einer Gesamtgröße bis zu 25 MB werden entsprechend den Festlegungen im KOM-LE 1.0 behandelt. Übersteigt die Größe einer Mail die 25-MB-Grenze, werden alle Anhänge durch das KOM-LE-Clientmodul aus der Mail entnommen und auf einem Speicher des KOM-LE-Fachdiensts (KAS) abgelegt. Das KOM-LE-Clientmodul ergänzt die Mail um die Links auf die Anhänge und versendet sie als KOM-LE-Mail. Das KOM-LE-Clientmodul des Empfängers erkennt die Links der entfernten Anhänge in der Mail, lädt die Anhänge vom KOM-LE-Fachdienst (KAS) und setzt sie wieder in die Mail ein. 

In [gemSpec_FD_KOMLE]  Kapitel "Schnittstelle I_Attachment_Services" wird der Umgang mit großen Anhängen in einem Sequenzdiagramm erläutert.

3.2.1 Senden von Nachrichten mit großen Anhängen

In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die es erlauben, Nachrichten von über 25MB inklusiver Anhänge zu versenden.

Mit der folgenden Anforderung wird sichergestellt, dass ein Client nicht bereits unerwünschten Kontent (über die Attachment Datenstruktur) in die an das Clientmodul übergebene KIM-Mail eingefügt hat.

Beispiel für eine Mail mit zwei Anhängen vor der Entnahme der Anhänge:

From: "Sender" <sender@maildomain.de>
To: <empfaenger@maildomain.de>
Subject: Mail mit zwei Anhängen
Mime-Version: 1.0

X-KIM-Dienstkennung: KIM-Mail;Default;V1.0

Content-Type: multipart/mixed; boundary="body_part_boundary"

--body_part_boundary
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ein Dokument und eine Aufnahme im Anhang.

--body_part_boundary
Content-Type: application/msword; name="MR-2020-04-01-xyz.doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="MR-2020-04-01-xyz.doc"

ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD
[Anhang gekürzt]
ABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCDABCD
ABCDABCDABCDABCDABCDABCDABCD==

--body_part_boundary
Content-Type: image/jpeg; name="Roentgenbild-375632378.jpg"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="Roentgenbild-375632378.jpg"

/9j/4AAQSkZJRgABAQEASSBIAAD/2wBDAAEBAQEBAQEBAQEBAQEBAQEDAQEBAQEBAQEBAEEBAQEB
[Anhang gekürzt]
RAQFRBcwRD8H6y8B+voDMoSa1I4Md6+UMzwKVdT3W/fz4cotgwwoZDa1sbvrwU1QcEyNlI3KwKwZ
uiFj1Ka6BVAM2WU4rCh+xfXS1/p573//2Q==

--body_part_boundary--

Die gleiche Mail nach Entnahme der Anhänge:

From: "Sender" <sender@maildomain.de>
To: <empfaenger@maildomain.de>
Subject: Mail mit zwei Anhängen
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="body_part_boundary"

--body_part_boundary
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Ein Dokument und eine Aufnahme im Anhang.

--body_part_boundary
Content-Type: text/plain; charset=utf-8
Content-Disposition: x-kas

  {
    "name":     "MR-2020-04-01-xyz.doc",
    "link":     "HTTPS://KIM-FD1.telematik.de/CXFDTE82346dfzwr7634dfs76sd76sdtzq376e3tzsd",
    "k":        "RzVEY3M0MzkmNGZkc2RneCVoX2tkdFQlNXczZnZDdDM2ZGZ2eGZzJDYxITJndmR1VWpzKGk=",
    "hash":     "Z6A65Z2dasI2I00mM7uxtQjLsEwwl+WLMnDw8eLntaA=",
    "size":     143271,
    "type":     "application/msword"
   }
--body_part_boundary
Content-Type: text/plain; charset=utf-8
Content-Disposition: x-kas

  {
    "name":     "Roentgenbild-375632378.jpg",
    "link":     "HTTPS://KIM-FD1.telematik.de/Cduiz763478dfjkdfjhgow4784JHKZsdtq376e3t478d",
    "k":        "Ry80ZmRpdWhjczQzOSY0ZmRzZGd4JWhfa2R0VCU1dzNmdkzZkYXNlcmZnODkzNDV1aXNyZg==",
    "hash":     "Hp30Rx6T9aX8PUmyuASDDIAJ2lPAwbPdc5OSAMK49I=",
    "size":     32573,
    "type":     "image/jpeg"
   }
--body_part_boundary--

Die für die Lokalisierung  benötigten DNS Service-Records werden in der [gemSpec_FD_KOMLE] im Kapitel 3.4 Service Lokalisierung beschrieben.

Der KAS ist ein Bestandteil des Fachdiensts. Deshalb gelten für die TLS-Verbindungen (inklusive genutzter Zertifikate) zum KAS ebenfalls die Festlegungen von Kap. 4.1.4.

3.2.2 Empfangen von Nachrichten mit großen Anhängen

In diesem Kapitel werden Anforderungen an das Clientmodul formuliert, die es erlauben, große Anhänge zu empfangen.

Eine KOM-LE 1.0 E-Mail ist maximal 25 MB groß (netto). Hierbei ist zu beachten, dass durch die Base64-Kodierung der Nachricht die zu verarbeitende Bruttogröße um den Faktor 1,37 erhöht wird (brutto).

Die Anforderungen an die TLS Authentifizierung und die Zertifikate entsprechen den Anforderungen von dem Fachdienst.

Bei einer Nachricht mit dem Subject „Mindestens ein Anhang der Nachricht konnte nicht heruntergeladen werden“ gibt es folgende Optionen:

• Wenn die empfangene Nachricht vom Server gelöscht wurde, hat der Nutzer die Möglichkeit, durch das Senden an die eigene E-Mail-Adresse und das anschließende Abholen die Aufbereitung zu wiederholen.
• Wenn die empfangene Nachricht nicht vom Server gelöscht wurde, wird beim nächsten Abholen die Aufbereitung wiederholt.

Tabelle "Tab_Fehlertext_Download Fehlertext beim Download von Anlagen" enthält den Fehlertext, der in die Nachricht eingeführt wird, wenn der Download von Anhängen nicht durchgeführt werden konnte.

Tabelle 2 Tab_Fehlertext_Download Fehlertext beim Download von Anlagen

3.3 Senden von Nachrichten

3.3.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 MailTransfer Agent des KOM-LE-Fachdienstes (weiter im Text als MTA bezeichnet), bei dem der Sender registriert ist, übermittelt werden. Bei E-Mail-Nachrichten größer 25 MB werden alle zur E-Mail-Nachricht gehörenden Anhänge vor der Durchführung der kryptographischen Operationen extrahiert und symmetrisch verschlüsselt auf dem Fachdienst abgespeichert.

Abbildung 5 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 5: 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 6 dargestellten Zustandsmuster beschrieben. 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 6: 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.

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.3.2 CONNECT-Zustand

Sobald die TCP-Verbindung zwischen dem Clientsystem und dem Clientmodul aufgebaut ist, geht das Clientmodul in den CONNECT-Zustand über.

3.3.2.1 Initialisierung

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 Tab_SMTP_Ant_Init beschreibt Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.

Tabelle 3: Tab_SMTP_Ant_Init Antworten Clientmodul im CONNECT-Zustand

3.3.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 Parameter

• MandantId,
• ClientSystemId und
• WorkplaceId
• KonnektorId (optional)

übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId und WorkplaceId). Der optionale Parameter KonnektorID, als Bestandteil des Aufrufkontext für SM-B, ermöglicht die Unterstützung von Multikonnektor-Umgebungen. Die Parameter entsprechen denen des aufrufenden Clients und werden voneinander durch das Zeichen ’#’ getrennt.

Der Aufbau des SMTP-Benutzernamens entspricht somit dem folgenden Muster und hat der den Parametern vorangestellten Nummer in der Reihenfolge zu entsprechen:

[0] Benutzername
[1] <Domain Adresse des SMTP-Servers>:<Port>
[2] MandantId
[3] ClientsystemId
[4] WorkplaceId
— <optional> —
[5] KonnektorId
[...]

Abbildung 7: Abb_MTA_Nutzername Format des SMTP- Benutzernamens

Beispiel:

Bei folgenden Informationen

• Benutzername des Clients = „erik.mustermann@hrst_domain.kim.telematik“,
• Domain Adresse des MTAs = „hrst_domain.kim.telematik“ und Portnummer = 465,
• MandantId = 1,
• ClientsystemId = KOM_LE,
• WorkplaceId = 7
• KonnektorId = Konn_1

erwartet das Clientmodul, dass das Clientsystem ihm folgenden SMTP-Benutzernamen als String überträgt:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KOM_LE#7#Konn_1

Das KOM-LE-Clientmodul bricht die Kommunikation mit dem entsprechende SMTP-Antwortcode ab (siehe Tabelle Tab_SMTP_Verbindung), wenn der erhaltene SMTP-Benutzername nicht alle erforderlichen Parameter enthält. Beinhaltet der SMTP-Benutzername zusätzliche optionale durch ‚#’ abgegrenzte Parameter (z. B. #KonnektorId), dann müssen diese Parameter vom Clientmodul ausgewertet werden 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 Tab_SMTP_Verbindung enthält SMTP-Antwortcodes, die das Clientmodul dem Clientsystem bei einem Verbindungsaufbau mit dem MTA übermittelt.

Tabelle 4: Tab_SMTP_Verbindung SMTP-Antwortcodes für MTA-Verbindungsaufbau

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.

Der Parameter KonnektorId ist eine Referenz auf eine URI oder eine IP-Adresse eines Konnektors, um in einer Umgebung mit mehreren Konnektoren einen bestimmten Konnektor ansprechen zu können. Diese kann beispielweise in einer Konfigurations-Datei im Clientmodul hinterlegt sein.

Beispiel einer vollständigen SMTP-Benutzername-Zeichenkette:

• ohne optionale Bestandteile:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KOM_LE#7

• KonnektorId als optionaler Bestandteil:

erik.mustermann@hrst_domain.kim.telematik#hrst_domain.kim.telematik:465#1#KOM_LE#7#Konn_1

Erfolgt die Einbindung von KIM in ein bestehendes Mail-System, kann ein übergebener Delimiter ":" zwischen dem Serveranteil und dem Port (z. B. hrst_domain.kim.telematik:465) des SMTP-Benutzernamens zu Fehlern bei der Interpretation im Bestandsystem führen. Es werden daher weitere Delimiter im Benutzernamen unterstützt, sofern die Funktionalität gemäß der Bestandsanforderungen zu den Benutzernamen, in semantischer Abgrenzung, uneingeschränkt erhalten bleiben. Es gilt, dass die Bestandteile des SMTP-Benutzernames in ihrem semantischen Bezug gemäß [RFC1123, RFC2822] einhalten müssen.

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.3.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.

3.3.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.3.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.3.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.3.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.

3.3.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. Hierbei wird von einer E-Mail-Nachricht Größe von kleiner oder gleich 25 MB ausgegangen.

Abbildung 8: 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.8.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.

Ein Beispiel einer diesem Profil konformen Nachricht für den Aufbau des binären CMS-Container ist in [gemSMIME_KOMLE] enthalten. Insbesondere wird auf die Aufnahme des „Content Headers“ hingewiesen.

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>

  <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.

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.

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:Crypt> 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.

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.

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.

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.

1. 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.
2. Der Signaturdienst der TI-Plattform wird mit der zu sendenden Nachricht und der Referenz auf den Signaturschlüssel als Aufrufparameter aufgerufen.
3. Der Verschlüsselungsdienst der TI-Plattform wird mit der signierten Nachricht und den gefundenen Verschlüsselungszertifikaten als Aufrufparameter aufgerufen.
4. 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 mehrere 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.

1. Falls Ersatzzertifikate gefunden werden, wird der Verschlüsselungsvorgang wiederholt.
2. 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.