Inhaltsverzeichnis
Mit dem KIM 1.5.5 Spezifikations-Release sollen folgende Punkte adressiert werden:
Basis dieser Änderungen ist der Release-Stand KIM 1.5.4
Die Änderungen mit dem KIM Security Hotfix 1.5.2-10 erfolgten auf dem Release-Stand KIM 1.5.2-9 und müssen äquivalent, aufbauend auf den aktuellen Release-Stand KIM 1.5.4 aufgenommen werden.
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aus CVDP-Meldung, folgendes Szenario
Ein "reguläres" KIM Clientmodul kommuniziert mit einem "bösartigen" KIM Fachdienst, der missbräuchlich, als Serverzertifikat ein valides KIM Clientmodul Client-Server-Zertifikat verwendet (men in the middle). Voraussetzung ist Zugang zur TI und KIM.
Die Analyse der bestehenden Spezifikationslage zeigte, dass TLS-Zertifikate in KIM nicht ausreichend, gemäß der Möglichkeiten, geprüft werden und sowohl für das KIM Clientmodul als auch den KIM Fachdienst Optimierungen notwendig sind.
Die nachfolgenden Änderungen sollen eine entsprechende, mehrstufige Prüfung von TLS-Zertifikaten abbilden, welche Sicherheitsaspekte wie men in the middle, dns spoofing/cache poisoning ebenfalls adressieren.
geändert:
KOM-LE-A_2075-03 - Prüfung von TLS-Server-Zertifikaten
Das Clientmodul MUSS bei der Prüfung von TLS-Server-Zertifikaten der KOM-LE-Fachdienste prüfen, ob es sich um ein KOM-LE Fachdienst Zertifikat handelt ([gemSpec_OID] - Tab_PKI_406-* OID-Festlegung technische Rolle in X.509-Zertifikaten - C.FD.TLS-S; OID: 1.2.276.0.76.4.172). Zusätzlich MUSS das Clientmodul den FQDN für die Prüfung gemäß [GS-A_5077-*] anhand des Domainanteils, der zur Adressierung des Endpunkts relevanten KIM-Adresse, per DNS-Auflösung ermitteln. Resultiert eine dieser Prüfungen in einem negativen Ergebnis, MUSS der Verbindungsaufbau abgebrochen werden. Bei positivem Ergebnis der vorangegangenen Prüfschritte MUSS das Clientmodul die Operation "VerifyCertificate" nutzen, um die Gültigkeit des Zertifikats zu validieren. Wird durch diese Operation das Prüfergebnis "INVALID" zurückgegeben, MUSS der beabsichtigte Verbindungsaufbau abgebrochen werden.
[<=]
Entfällt:
A_17503-01 - Prüfung von TLS-Server-Zertifikaten in der gemSpec_BasisKTR_Consumer, da redundant
geändert:
A_22348-02 - Caching der Prüfergebnisse der TLS-Server-Zertifikate
Das Clientmodul MUSS das Ergebnis der Zertifikatsprüfung für eine definierte Zeitdauer TTL_FD_CERT (Tabelle 15: Tab_Konf_Param Standardkonfiguration allgemeine Parameter) temporär und manipulationssicher speichern. Für die Zuordnung sind eindeutige Identifikatoren, wie bspw. der Zertifikats-Fingerabdruck, zu verwenden. Bei erneuter Prüfung eines gleichen Zertifikats kann das vorangegangene Verifikations-Ergebnis dieses Zertifikats genutzt werden. Die Speicherdauer ist an die zeitliche Gültigkeit ("notAfter") des Zertifikats anzupassen, d.h. darf nicht über dessen Gültigkeit hinweg reichen. Führt die Zertifikatsprüfung zu einem negativen Ergebnis erfolgt die Speicherung des Ergebnisses analog, jedoch für eine geringere Zeitdauer gemäß dem Wert TTL_FD_CERT_ERR.
[<=]
Tabelle 1: Tab_Konf_Param Standardkonfiguration allgemeine Parameter
| Parameter
|
Beschreibung des Parameters
|
Defaultwert
|
|---|---|---|
| TLS_AUTH_KONNEKTOR
|
Authentifizierung des Clientmoduls gegenüber dem Konnektor bei aktivierter TLS-Verbindung (zertifikatsbasiert, Basic-Authentifizierung, ohne)
|
zertifikats-basiert
|
| KONNEKTOR_TIMEOUT
|
Timeout für Aufrufe von Schnittstellen des Konnektors
|
1 Minute
|
| SMTP_TIMEOUT_SERVER
|
Timeout für Antworten vom SMTP-Server auf SMTP-Kommandos
|
5 Minuten
|
| SMTP_TIMEOUT_CLIENT
|
Timeout für das Warten auf neue SMTP-Kommandos vom Clientsystem
|
5 Minuten
|
| POP3_TIMEOUT_SERVER
|
Timeout für Antworten vom POP3-Server auf POP3-Kommandos
|
5 Minuten
|
| POP3_TIMEOUT_CLIENT
|
Timeout für das Warten auf neue POP3-Kommandos vom Clientsystem
|
5 Minuten
|
| TTL_VZD_DATA
|
Time to Live für gecachte Daten vom VZD wie Verschlüsselungs-zertifikate und Prüfergebnisse und KOM-LE-Versionen (minimaler Wert 1 Stunde; maximaler Wert 24 Stunden)
|
12 Stunden
|
| TTL_AM_DATA | Time to Live für gecachte Nutzer-Konfigurationsdaten (Operation getLimits) vom Account-Manager (minimaler Wert 1 Stunde; maximaler Wert 24 Stunden) | 12 Stunden |
| TTL_EMAIL_ICCSN
|
Time to Live für gecachte Zuordnungen von E-Mail-Adressen der Sender bzw. Empfänger zu ICCSNs von deren HBAs/SM-Bs (minimaler Wert 10 Tage; maximaler Wert 30 Tage)
|
30 Tage
|
| TTL_FD_CERT | Time to Live für gecachte TLS-Server-Zertifikate, nach erfolgreicher OCSP Zertifikats-Prüfung | 24 Stunden |
| TTL_FD_CERT_ERR | Time to Live für gecachte TLS-Server-Zertifikate, nach negativer Zertifikats-Prüfung (minimaler Wert 1 Minute; maximaler Wert 60 Minuten) | 5 Minuten |
| TTL_PROTS
|
Time to Live für Protokolldateien.
|
30 Tage
|
| PROT_PERF
|
Protokolldatei für Performance
|
JA
|
| KONNEKTOR_URI
|
URI des DVD des Konnektors
|
-
|
| CM_KAS_TIMEOUT | Timeout bei Inaktivität der Kommunikation zwischen Clientmodul und KAS | 30 Sekunden |
| TTL_ERR_MSG | Time to Live für gecachte Informationen bzgl. bereits versendeter, gleicher KIM-Fehlerbenachrichtigungen (minimaler Wert 1 Stunde; maximaler Wert 24 Stunden) | 12 Stunden |
| TTL_MSG_AUTH | Zeitliche Gültigkeit des Tokens aus X-KIM-AUTH [A_28582-*] (minimaler Wert 15 Minuten; maximaler Wert 120 Minuten) | 60 Minuten |
geändert (KOM-LE-A_2144-01):
KOM-LE-A_2144-03 - Schritte beim Aufbau der TLS-Verbindung
Beim Aufbau einer TLS-Verbindung MUSS der KOM-LE-Fachdienst folgende Schritte bei der Prüfung des vorgelegten TLS-Zertifikats (C.CM.TLS-CS-Zertifikat des Clientmoduls, C.FD.TLS-C Client-Zertifikat, C.FD.TLS-S Server-Zertifikat eines anderen KOM-LE-Fachdienstes oder C.ZD.TLS-S des Verzeichnisdienstes) durchführen:
Entfällt:
KOM-LE-A_2228-01 - Ausschließliche Akzeptanz von TLS-Client-Zertifikaten von KOM-LE Clientmodulen
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aus CVDP-Meldung, folgendes Szenario
Im Anwendungsfall KAS – Versand KIM-Nachrichten > 15 MiB, werden E-Mail-Daten durch einen "Freigabelink" referenziert und dieser Link innerhalb einer KIM-Nachricht (KAS-Nachricht) übermittelt. Anhand des Links werden auf der Empfänger-Seite die Daten abgerufen. Eine solche KAS-Nachricht kann "missbräuchlich" gefälscht erstellt und mit einem beliebigen "Freigabelink" übermittelt werden. In der KIM-Nachrichtenverarbeitung wird dieser Link adressiert und kann so genutzt werden, um bspw. externe, öffentliche IP-Adressen von KIM-Teilnehmern zu ermitteln oder „bösartige“ Daten/Inhalte bereitzustellen. Voraussetzung ist Zugang zur TI und KIM.
Die nachfolgenden Änderungen stellen sicher, dass die wesentlichen KAS-Endpunkt-Informationen stets ermittelt werden müssen und der empfangene KAS-Link nicht unbehandelt verwendet wird.
geändert:
A_19370-08 - Download von E-Mail-Daten
Das KOM-LE-Clientmodul MUSS die E-Mail-Daten anhand des entnommenen Freigabelinks via der Operation readMailData am KAS des Fachdienstes herunterladenzunächst anhand der Absender-Information aus der empfangenen E-Mail, mittels DNS Service Discovery den "host" und "port" des KAS ermitteln und diese Informationen als "authority"-Komponente [RFC3986] in der URL (Freigabelink) verwenden. Hierzu sind umliegende Festlegungen bzgl. der Absender-Information [A_23422-*] zu beachten. Daten werden in diesem Anwendungsfall stets vom KAS, der dem Absender zugehörig ist, bereitgestellt bzw. abgerufen. Anschließend MUSS das KOM-LE-Clientmodul die E-Mail-Daten anhand des resultierenden Freigabelinks, via der REST-API-Operation readMailData abrufen. Tritt beim Herunterladen der E-Mail-Daten ein Fehler auf, MUSS das Clientmodul eine Fehlernachricht gemäß [A_28602-*] und damit korrespondierendem Fehlertext aus [Tab_Fehlertext_Download] erzeugen. Das subject Header-Element der neuen multipart/mixed Nachricht erhält den Wert „Die E-Mail-Daten konnten nicht abgerufen werden“. [<=]
KAS-LINK Beispiele anpassen, siehe über Abschnitt https://gemspec.gematik.de/docs/gemSpec/gemSpec_CM_KOMLE/latest/#A_19360-02
[RFC3986] in 5.5.2 Weitere Dokumente aufnehmen
Änderungen bzgl. des Fehlerfalls, der Fehlernachricht werden hier im Abschnitt "Änderungen bestehender Anforderungen der E-Mail-Fehlernachrichten" beschrieben.
geändert:
A_19380-04 - KAS – Erzeugung Freigabelink
Der KAS MUSS bei Aufruf der REST-Operation addMailData einen Freigabelink als URL [RFC3986] erzeugen, der aus dem FQDN der Teilkomponente KAS und einer zufälligen und eindeutigen ID der Ressource z. B. einer UUID [RFC4122] besteht und diesen an den aufrufenden Client zurückgeben. Dieser MUSS das Schema „https“, als „host“ den FQDN der Teilkomponente KAS verwenden und die Ressource im „path“ mit einer zufälligen und eindeutigen ID (z. B. einer UUID [RFC4122]) referenzieren. Dieser Freigabelink wird gemäß [AttachmentService.yaml] an den aufrufenden Client zurückgeben.
[<=]
Hinweis:
Bildung Freigabelink KAS, inkl. Festlegungen aus [AttachmentService.yaml]:
https://{KAS-FQDN}/attachments/{version}/attachment/{id}
Beispiel Freigabelink KAS:
https://kas.fqdn/attachments/v2.3/attachment/469bf002-701f-4362-a9bc-6585c1871250
Entfällt:
A_19381 - KAS – Freigabelink Transportsicherheit
[RFC3986] in 6.5.2 Weitere Dokumente aufnehmen
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aus CVDP-Meldung, folgendes Szenario
Gemäß aktueller Spezifikation werden KIM-Fehlernachricht, in Annahme der Generierung durch zugelassene, technische Komponenten, weder signiert noch verschlüsselt übertragen. Eine solche Fehlernachricht kann, "missbräuchlich" erstellt, als reguläre KIM-Nachricht "getarnt" direkt übermittelt werden. Diese Nachrichten müssen sowohl der KIM Fachdienst als auch das empfangende KIM Clientmodul unbehandelt weiterleiten/zustellen. Folglich können "bösartige" (phishing, falsche Daten, ...) Nachrichten, als scheinbar reguläre KIM-Nachrichten ungeprüft, ohne Signatur und Verschlüsselung übermittelt werden. Voraussetzung ist Zugang zur TI und KIM.
Die nachfolgenden Änderungen stellen sicher, dass an zentraler Stelle, durch den KIM Fachdienst jede KIM-Fehlernachricht entsprechend behandelt wird.
geändert:
A_20771-03 - Generierung von Fehlermeldungen am Fachdienst
Der Fachdienst KOM-LE MUSS sicherstellen, dass eine E-Mail-Nachricht vom KOM-LE Clientmodul, auf welche mindestens eines der Prüfkriterien gemäß Tab_Fehlercodes_KOMLE-Fachdienst zutrifft, ausschließlich wie folgt behandelt wird.
Der Fachdienst KOM-LE MUSS eine Fehlernachricht entsprechend Delivery Status Notification gemäß [RFC3461-3464] erzeugen, das Header-Attribut X-KIM-Fehlermeldung mit den Werten aus der folgenden Tabelle befüllen und an den Absender übermitteln. Die originär eingelieferte E-Mail DARF NICHT übermittelt werden. Der Fachdienst KOM-LE MUSS sicherstellen, dass die DSN keine Teile des Bodies der originalen Nachricht enthält, sofern dies nachfolgend nicht näher definiert wurde.
Es gilt die Annahme der Unterscheidung zwischen einer Kommunikation
Tabelle 2: Tab_Fehlercodes_KOMLE-Fachdienst
| Prüfkriterien | Fehler | Wert |
|---|---|---|
| Prüfung der Mailbody-Eigenschaften auf S/MIME-Konformität | Die Mail entspricht nicht dem KOM-LE S/MIME-Profil | fdgerr_1 |
| Subject ungleich "KOM-LE-Nachricht" | Der Betreff der Mail ist ungültig | fdgerr_2 |
| Header "X-KOM-LE-Version" ungültig | Die übergebene X-KOM-LE-Version ist ungültig | fdgerr_3 |
| ContentType beginnt nicht mit "application/pkcs7-mime;" oder enthält nicht "smime-type=authenticated-enveloped-data" | Der ContentType der Mail ist ungültig | fdgerr_4 |
| Prüfung der Mailgröße
|
Die maximale Größe der Mail wurde überschritten
|
fdgerr_5 |
| Fehlernachricht, Benachrichtigung von KOM-LE Clientmodul
Wenn Header "X-KIM-Fehlermeldung" vorhanden, wird nur dieses Prüfkriterium betrachtet. |
Fehlernachricht/Benachrichtigung von KIM-Clientmodul. Prüfen Sie den Inhalt der Fehlernachricht/Benachrichtigung und kontaktieren sie ggf. Ihren/Ihre Systembetreuer*in. Nachfolgend der Text-Inhalt der eingegangenen Nachricht.
<text/plain -Teil der empfangenen Fehlernachricht> |
fdgerr_6 |
Entfällt:
A_20651-02 - Empfang von Fehlernachrichten des Clientmodules, muss entfallen
KOM-LE-A_2146-03 - Verarbeitung von Nachrichten entsprechend S/MIME-Profil, kann entfallen da redundant
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aus CVDP-Meldung, folgendes Szenario
In KIM werden reguläre Nachrichten signiert und verschlüsselt übertragen. Dabei wird technisch nicht sichergestellt oder geprüft, ob die KIM-Absenderadresse zur Signatur bzw. technischen Identität gehört, welche die KIM-Nachricht signiert hat (vgl. S/MIME). Der Versand bietet keinen Nachweis zum Besitz des privaten Schlüsselmaterials → Kein Nachweis, dass Absender (in proximity) der berechtigten LEI angehört. Mit Kenntnis eines KIM-Accounts kann eine beliebige Umgebung mit KIM-Zugang "genutzt" werden, um KIM-Nachrichten zu versenden.
Ursachen
Ziele der Änderung
Einordnung
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Bisher wird der HBA, sofern diesem eine KIM-Adresse zugeordnet ist, lediglich beim Abruf von KIM-Nachrichten, für die Entschlüsselung der Daten benötigt.
Damit ein HBA für entsprechende Operationen des TI-Konnektors genutzt werden kann, wird eine "UserId" als Bestandteil des Aufrufkontextes des TI-Konnektors benötigt.
Folglich muss die "UserId" im SMTP-Benutzernamen, analog dem POP3-Benutzernamen, als optionale Komponente aufgenommen werden. SMTP- und POP3-Benutzername müssen in KIM, aufgrund struktureller Abwärtskompatibilität, weiterhin getrennt betrachtet werden.
geändert:
3.3.2.2 Verbindungsaufbau mit MTA
[...]
Um mit SM-B/HBA über den Konnektor kommunizieren zu können, werden dem KOM-LE-Clientmodul ebenfalls als Teil des SMTP-Benutzernamens, die Parameter
übergeben (siehe Kapitel 3.5 und [gemSpec_Kon] für Details zu MandantId, ClientSystemId, WorkplaceId und UserId). Die Parameter entsprechen denen des aufrufenden Clients und werden voneinander durch das Zeichen ’#’ getrennt. Der optionale Parameter KonnektorId, als Bestandteil des Aufrufkontext für SM-B, ermöglicht die Unterstützung von Multikonnektor-Umgebungen. Er kann entfallen, wenn das Clientmodul nicht mit mehreren Konnektoren kommunizieren muss. Der optionale Parameter UserId wird nur für den Zugriff auf einen HBA benötigt und kann entfallen, wenn kein HBA erforderlich ist.
Der Aufbau des SMTP-Benutzernamens entspricht dem folgenden Muster. Die Reihenfolge entspricht der den Parametern vorangestellten Nummer.
[0] Benutzername
[2] MandantId
[3] ClientsystemId
[4] WorkplaceId
— <optional> —
[1] <Domain Adresse des SMTP-Servers>:<Port>
[5] KonnektorId
[6] UserId
[...]
Abbildung 1: Abb_MTA_Nutzer_Name Format des SMTP-Benutzernamens
Beispiel:
Bei folgenden Informationen
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#13
Das Beispiel ohne den übergebenen Parameter "Domain Adresse des MTAs" sieht wie folgt aus:
erik.mustermann@hrst_domain.kim.telematik#*#1#KOM_LE#7#Konn_1#13
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.
[...]
----------------------------------------------------------
geändert:
A_21387-04 - Prüfung der verwendeten Clientmodul-Version beim Senden
Das KOM-LE-Clientmodul MUSS mindestens einmal am Tag, vor dem Versenden einer Nachricht, die KOM-LE-Version des Absenders mittels des LDAP-Directory Attributs kimData aus dem Verzeichnisdienst [gemSpec_VZD#5] abfragen und in einem Cache gemäß TTL_VZD_DATA vorhalten.
Ist die KOM-LE-Version des Clientmoduls kleiner als die im Verzeichnisdienst eingetragene, so MUSS das Clientmodul den Absender mit einer KIM E-Mail darüber informieren. Aus dem Inhalt der E-Mail MUSS hervorgehen, dass die verwendete Clientmodul Version veraltet ist. Die E-Mail ist weder zu signieren noch zu verschlüsseln und entspricht der Delivery Status Notification gemäß [RFC3461-3464].
Ist die KOM-LE-Version des Clientmoduls größer als die im Verzeichnisdienst abgefragte Version MUSS das Clientmodul die Aktualisierung des LDAP-Directory Attribut kimData für den Absender mit der neuen Version über den Account Manager durch den Aufruf der Operation setAccount veranlassen. Handelt es sich bei der Mail-Adresse um einen HBA-Account, dann erfolgt die Aktualisierung der KOM-LE-Version nachdem ein POP3 Nachrichtenabruf erfolgt ist. [<=]
Hinweis: Das Attribut kimData ist in [gemSpec_VZD] definiert. Für die Aktualisierung der KOM-LE-Version im Verzeichnisdienst ruft das Clientmodul die Operation SetAccount an der Schnittstelle I_AccountManager_Service am Fachdienst des Absenders auf.
Beispiel: empfaenger@hrst_domain.kim.telematik,1.5
Hinweis: Wenn die Mail-Adresse zu einem HBA-Account gehört, dann kann die Aktualisierung der KOM-LE-Version im Verzeichnisdienst erst erfolgen, nachdem ein POP3 Nachrichtenabruf erfolgt ist, da für die Aktualisierung im Verzeichnisdienst die UserID benötigt wird (für den Konnektor-Aufrufkontext zur Erzeugung des jwt).
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Bisher erfolgt in KIM die Transportsignatur ausschließlich als CMS-Signatur mit einer nutzbaren SM-B-Identität (SMC-B). Dies erfolgt unabhängig davon, ob dieser Identität auch die KIM-Adresse des Absender zugeordnet ist.
Die Sicherstellung, dass eine KIM-Nachricht im Kontext einer Identität (SM-B oder HBA) versendet wird, zu der auch die KIM-Absender-Adresse zugeordnet ist, wird nachfolgend beschrieben.
Die Signatur in KIM basiert bisher ausschließlich auf einer nonQES CMS-Signatur mittels SM-B. Eine CMS-Signatur mit HBA wäre nur als QES möglich. Dieser Umstand impliziert verschiedene Probleme und ist in realer Anwendung nicht praktikabel:
QES ist nicht für automatisiert, dunkel-verarbeitende (headless) Prozesse konzipiert, was in KIM häufig der Fall ist.
neu:
A_28582 - Authentisierung einer KIM-Nachricht
Das Clientmodul MUSS anhand der vollständig, vorverarbeiteten, originalen Mail vom Clientsystem, vor der CMS-Signatur gemäß [KOM-LE-A_2299-*], ein JSON-Web-Token gemäß [RFC7519] mit den Elementen aus der folgenden Tabelle erzeugen und in der originalen Mail als Wert des Header-Element "X-KIM-Auth" einfügen.
Das Clientmodul MUSS sicherstellen, dass die Signatur des Tokens mit einem AUT-Zertifikat C.HP.AUT (HBA) oder C.HCI.AUT (SMC-B bzw. HSM-B) erfolgt, welches der gleichen Telematik-ID zugeordnet ist, wie auch die Absender-Adresse aus dem SMTP-Kommando MAIL FROM (RFC 5322 „addr-spec“). Das Clientmodul MUSS entsprechend [KOM-LE-A_2021-*] reagieren, wenn das Signieren des Tokens nicht gemäß der umliegenden Festlegungen möglich ist, oder bei der Erstellung der Signatur ein Fehler auftritt.
Das Clientmodul MUSS sicherstellen, dass dieses Header-Element nur ein mal vorkommt und stets das im Verarbeitungskontext neu-erzeugte Token als Wert dieses Header-Elements angegeben ist.
| JSON Web Token
|
|
|---|---|
| Header | |
| alg | BP256R1 oder PS256 |
| typ | JWT |
| x5c | [BASE-64 kodiertes AUT-Cert] |
| Body
|
|
| nbf | [Gültigkeitsbeginn (Unixzeit)] |
| jti | UUID [RFC4122] |
| iss | Wert von X-KIM-CMVersion gemäß A_21388-* |
| sub | Absender-Adresse aus
SMTP MAIL FROM (RFC 5322 „addr-spec“) |
| aud | Wert ist I_Message_Service |
Schema der Angabe als Header der Mail:
X-KIM-Auth: Bearer <JWT>
Hinweise:
Die Notwendigkeit einer Identifikation eines AUT-Zertifikats zur Token-Signatur, welches der KIM-Adresse/dem KIM-Account zugeordnet ist, besteht bereits äquivalent im Kontext der Nutzung von Operationen des Interface I_AccountManager_Service [A_21387-*, A_21381-*] beim Versand oder Abruf von KIM-Nachrichten.
Die Ermittlung der TID kann anhand der beim Versand zu nutzenden VZD-Daten erfolgen. Darüber hinaus, kann anhand der Daten aus dem VZD ebenfalls eingeschränkt werden, ob eine SMC-B oder ein HBA genutzt werden muss.
Daten aus der dazu notwendigen Ermittlung lokaler Zertifikatsinformationen können synergetisch im Kontext anderer Anforderungen [KOM-LE-A_2061-*] genutzt werden.
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Zwischen KOM-LE-A_2028 und KOM-LE-A_2193 einfügen?
Information zu A_28582 - Authentisierung einer KIM-Nachricht
Eine äquivalente Änderung bzgl. der bestehenden Anforderungslage zur CMS-Signatur mit SM-B (u.a. KOM-LE-A_2052 - Quellen zur Ermittlung der SM-B des Senders beim Signieren) ist nicht zielführend, da diese den HBA-Fall nicht berücksichtigen kann. Ohnehin würden diesbezügliche Änderungen in "alten" Clientmodulen nicht, jedoch in zukünftigen Versionen der Clientmodule, noch vor der CMS-Signatur, für sowohl SM-B als auch HBA wirken. Folglich wird eine allgemeine Lösung für sowohl SM-B als auch die HBA-Variante favorisiert, welche in der realen Nutzung eine geringe Auswirkung hat und abwärtskompatibel ist. Die Signatur mittels AUT-Zertifikat ist sowohl mit HBA als auch mit SM-B nonQES möglich und verhält sich somit analog zu der bisherigen, bekannten KIM-Nutzung.
Mit dieser Lösung wird eine mehrschichtige Authentifizierung abgebildet, da das zusätzliche Token als Authentisierungsinformation innerhalb der CMS-Signatur und E2E-Verschlüsselung übertragen wird. Somit ist erreicht, dass:
Für die Übermittlung des Tokens wurde ein KIM-spezifischer Header "X-KIM-Auth" definiert, da das sonst übliche Header-Element Authorization (RFC 7235) für HTTP-Requests gilt und semantische Inkonsistenz sowie potenzielle Wechselwirkungen mit bspw. Security-, Mail-Gateways vermieden werden soll.
Nachfolgend wird der "aud" claim ebenfalls für die bestehende Anforderung zur Erzeugung eines JWT aufgenommen.
geändert:
A_19457-05 - Client Authentisierung Administrationsmodul
Das Administrationsmodul MUSS bei der initialen Registrierung eine serverseitig gesicherte TLS-Verbindung zum Account Managers des Fachdienstes aufbauen.
Für die Authentisierung am Account Manager MUSS das Administrationsmodul ein JSON-Web-Token gemäß [RFC7519] mit den Elementen aus der folgenden Tabelle erzeugen und zusammen mit dem Passwort des Nutzers an den Account Manager übergeben.
| JSON Web Token
|
|
|---|---|
| Header | |
| alg | BP256R1 oder PS256 |
| typ | JWT |
| x5c | [BASE-64 kodiertes AUT-Cert] |
| Body
|
|
| nbf | [Gültigkeitsbeginn (Unixzeit)] |
| aud | I_AccountManager_Service |
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Die Integritätsprüfung von KIM-Nachrichten im KIM Clientmodul gibt bisher lediglich die Aussage, ob eine KIM-Nachricht nicht verändert und ob diese aus einer berechtigten Leistungserbringer-Institution (LEI) versendet wurde. Dies lässt bisher keine Aussage zu, ob der Absender der KIM-Nachricht der LEI angehört bzw. die Transportsignatur dem Absender zugeordnet ist.
geändert:
KOM-LE-A_2048-02 - Prüfung der Signatur und Integrität einer KOM-LE-Nachricht
Das Clientmodul MUSS die Integrität der KOM-LE-Nachricht prüfen. Dabei müssen die digitale Signatur selbst, der Zertifizierungspfad für das verwendete Signaturzertifikat, die Integrität des Headers der äußeren Nachricht und die Integrität des recipient-emails Attributs geprüft werden.
Bei der Prüfung der Integrität des Headers der äußeren Nachricht sind die Header-Elemente from, sender, reply-to, to und cc mit denen der signierten inneren Nachricht zu vergleichen.
Bei der Prüfung der Integrität des recipient-emails Attributs sind die Werte dieses Attributs aus signerInfos und aus dem enveloped-data CMS-Objekt miteinander zu vergleichen.
Prüfschritte bzgl. des Header-Element „X-KIM-Auth“ [A_28582-*] sind nur dann notwendig, wenn:
Hinweis:
Zur Prüfung korrespondierender Eintrag in "Tabelle 9: Tab_Verm_Sig_Prüf Vermerke mit Ergebnissen der Signaturprüfung" erfolgt in einem nachfolgenden Abschnitt.
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aufgrund der Anforderung "KOM-LE-A_2098-* - Header der äußeren Nachricht" (gemSMIME_KOMLE) wird das Header-Element "X-KIM-Auth" in die äußere Nachricht übernommen, welche zum Mailserver des KIM-Fachdienst übertragen wird. Folglich ist diese Information für u.a. die nachfolgende Zwecke zentral, am KIM Fachdienst auswertbar:
geändert:
A_23422-01 - Sicherstellung Absenderintegrität einer KOM-LE-Nachricht
Der Fachdienst KOM-LE MUSS vor der Verarbeitung einer KOM-LE-Nachricht folgende Prüfregeln umsetzen:
Hinweise:
Nachfolgend wird die Auswertung des "aud" claims bzgl. [A_19457-*] auch in bestehender Anforderung, abwärtskompatibel aufgenommen.
geändert:
KOM-LE-A_2187-07 - Authentifizierung des KOM-LE-Teilnehmers über AUT-Zertifikat am Account Manager
Zur Pflege der Basisdaten des Verzeichnisdienstes und bei der Registrierung und Deregistrierung MUSS der Fachdienst die Authentizität des KOM-LE-Teilnehmers über das AUT-Zertifikat des HBA bzw. der SM-B über das vom Clientmodul übergebene Json-Web-Token prüfen. Hierzu MUSS der Fachdienst folgende Prüfschritte durchführen:
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Aufgrund der Konstellation, dass mit Einführung des Header-Elements "X-KIM-Auth" auch weiterhin KIM-Systemkomponenten im Feld sind, welche diese Information noch nicht kennen sowie im Sicherheitskontext "never trust the client" bzw. dem Sicherheitsparadigma "ZeroTrust", gilt nachfolgende Betrachtung:
Für KIM FD wurde angenommen, dass dieser die Feature bereits zentral bereitgestellt hat.
In Folge der Betrachtung, der sicherheitstechnischen Bewertung des Kontext JWT - "replay attack", ist die Wiederverwendung eines Token aus dem Header-Element "X-KIM-Auth" als unproblematisch anzusehen, da:
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Im Kontext des Abrufs von KIM-Nachrichten erfolgt nach der Entschlüsselung eine Integritätsprüfung. Die aktuelle Umsetzung der Integritätsprüfung lässt es zu, dass im Fall technisch transienter Fehlerbilder KIM-Nachrichten nicht oder immer unbehandelt an den Empfänger ausgegeben werden. Folglich resultieren auch missbräuchlich induzierte, technisch transiente oder gänzlich persistente Fehlerbilder in einem positiven Ergebnis der Integritätsprüfung. Teil der Integritätsprüfung ist u.a. die Signaturprüfung, welche wiederum von einer Vielzahl technischer Komponenten (Konnektor, OCSP, ...) abhängig ist.
Aus Sicht der Sicherheit muss standardmäßig gelten, dass bei einem negativen Ergebnis der Integritätsprüfung, den empfangenen Daten nicht vertraut werden darf. Jedoch müssen auch in diesem Fall stets entsprechende Fehler-Informationen an den Empfänger ausgegeben werden, damit der Fehlerzustand erkannt und behandelt werden kann.
KIM wird zu einem Großteil als Transportschicht von Fachverfahren genutzt, bspw. eAU. Diese Verfahren sehen i.d.R. eine zusätzliche Authentizität des payloads vor, bspw. QES signierter eAU payload. Ein transientes Problem in der Integritätsprüfung, durch bspw. temporäre Störung OCSP, kann folglich zu massenhaften Fehlerfällen in der Verarbeitung der Fachverfahren des Empfangssystems führen. Folglich muss die Ausgabe des entschlüsselten payloads auch bei Fehlern in der Integritätsprüfung, als Teil der Fehlernachricht, konfigurativ möglich sein. Die Authentizität des payloads kann durch das Empfangssystem (nach-)geprüft werden.
Abgeleitet gilt, dass eine KIM-Nachricht nur bei positiven Ergebnis der Integritätsprüfung, ohne nachfolgend beschriebene Fehlernachricht, an den Empfänger ausgegeben werden darf (Positiv-Fall). Die nachfolgenden Änderungen adressieren ebenfalls den Bedarf nach eindeutig identifizierbaren Fehler-Informationen, welche zusätzlich maschinell auswertbar sein sollen. In früheren Iterationen von KIM konnten Informationen zu Fehlern aus der Integrationsprüfung (Signaturprüfungsbericht, Vermerke) nicht eindeutig zugeordnet werden und waren fälschbar, ausblendbar.
Die nachfolgenden Änderungen zur Fehlernachricht aus der Integrationsprüfung sind als abwärtskompatibel anzusehen. Geeignete, maschinenauswertbare Informationen außerhalb des Fließtext werden weitergenutzt und Informationen ergänzt. Es resultieren wiederum mehr Möglichkeiten & Freiheitsgrade der maschinellen Auswertung durch Primärsysteme. Bestehende Sicherheitsmechanismen in Empfänger-Umgebungen werden durch diese Änderung nicht obsolet.
geändert:
A_23165-01 - Verhalten bei fehlgeschlagener Integritätsprüfung
Das Clientmodul MUSS nach einer fehlgeschlagenen Integritätsprüfung eine Fehlernachricht mit folgenden Inhalten generieren und an Stelle der entschlüsselten, originalen Mail an den aufrufenden Client zurückgeben. Entgegen [A_28602-*] gelten für diese Fehlernachricht spezifische Festlegungen.
Das Clientmodul MUSS die Header-Elemente der entschlüsselten, originalen Mail als Header-Elemente der Fehlernachricht übernehmen und diese entsprechend umliegender sowie nachfolgender Anforderungen analog anpassen. Das Header-Element subject ist wie folgt anzugeben: "Fehler bei der Integritätsprüfung festgestellt"
Das Clientmodul MUSS eine UUID [RFC4122] als jene in diesem Fehler-Kontext aktuelle Referenz auf angehängte Daten generieren und diese als Wert des Header-Element X-KIM-IntegrityCheckRefID angeben. Das Clientmodul MUSS sicherstellen, dass dieses Header-Element nur ein mal vorkommt und stets die im Verarbeitungskontext neu-erzeugte UUID als Wert dieses Header-Elements angegeben ist.
Zusätzlich MUSS das Clientmodul das Header-Element X-KIM-IntegrityCheckResult mit der dazugehörigen ID aus der Tabelle "Tab_Verm_Sig_Prüf" befüllen. Kommt es bei der Integritätsprüfung zu Fehlern, die nicht in der Tabelle "Tab_Verm_Sig_Prüf" definiert sind, MUSS das Clientmodul für diese Fehler das Mail-Header-Attribut X-KIM-IntegrityCheckResult mit einem herstellerspezifischen Fehlercode befüllen, welcher mit "X" beginnt.
Alternativ MUSS es möglich sein, über eine Konfiguration im Clientmodul, die entschlüsselte (originale) Nachricht trotz fehlgeschlagener Integritätsprüfung und Beachtung nachfolgender Anforderungen dem Empfänger weiterzuleiten.
Das Clientmodul MUSS gemäß einer Konfiguration im Clientmodul die entschlüsselte, originale Mail der Fehlernachricht als Anhang, mit folgenden Header-Elementen als MIME-Part anfügen können:
Content-Type: message/rfc822; name="<Wert von X-KIM-IntegrityCheckRefID>.eml"
Content-Disposition: attachment; filename="<Wert von X-KIM-IntegrityCheckRefID>.eml"
Diese Konfiguration MUSS standardmäßig deaktiviert sein.
Das Clientmodul MUSS bei negativem Ergebnis der Signaturprüfung den VerificationReport aus dem VerificationResult (oasis-dssx-1.0-profiles-vr-cd1.xsd) der VerifyDocumentResponse entnehmen (sofern vorhanden) und der Fehlernachricht als Anhang, mit folgenden Header-Elementen als MIME-Part anfügen:
Content-Type: application/xml; name="VerificationReport_<Wert von X-KIM-IntegrityCheckRefID>.xml"
Content-Disposition: attachment; filename="VerificationReport_<Wert von X-KIM-IntegrityCheckRefID>.xml"
(Hinweis: Sofern das Format des VerificationReports nicht xml entspricht, kann die Formatangabe in diesem MIME-Part entsprechend angepasst werden.)
Das Clientmodul MUSS im Mail-Body der Fehlernachricht genau einen text/plain MIME-Part mit folgendem Text angeben:
"Bei der Prüfung dieser abgerufenen KIM-Nachricht wurde eine Verletzung der technischen Integrität festgestellt. Somit darf den empfangenen Daten nicht vertraut werden.
Details:
<Angaben zum Prüfschritt und Ursache(n) aus der Integritätsprüfung. Zum Beispiel wenn negatives Ergebnis Zertifikatsprüfung, Details zum Zertifikat angeben, um zu Erkennen ob diese abgelaufen ist.>
Anhänge:
- (wenn vorhanden) Signaturprüfungsbericht „<Wert von X-KIM-IntegrityCheckRefID>.xml“
- (abhängig von Konfiguration) Empfangene KIM-Nachricht „<Wert von X-KIM-IntegrityCheckRefID>.eml“, diese können Sie eigenverantwortlich, nach Prüfung (Virenscanner oder Sonstige) mit E-Mail-Software, oder Andere öffnen und weiterverarbeiten.
Weitere Anhänge dieser Nachricht, welche nicht die Referenz <Wert von X-KIM-IntegrityCheckRefID> ausweisen, sind diesem Fehlerfall nicht zugeordnet.
Bitte kontaktieren sie Ihren/Ihre Systembetreuer*in zum sicheren Umgang bzgl. der angehängten Daten sowie technischen Problembehebung!“
[<=]
Hinweis:
• Es muss sichergestellt werden, dass eine entschlüsselte KIM-Nachricht und damit nutzbarer Payload an den Empfänger ausgegeben wird. U.a. dürfen technisch transiente Ursachen nicht dazu führen, dass ggf. zeitkritischer Payload den Empfänger nicht erreicht. Es gilt in diesen Fällen die Sorgfalt und security policies der Empfängerumgebung einzubeziehen.
• Das Dateiformat ".eml", in dem die entschlüsselte, originale Mail der Fehlernachricht angehängt wird, kann geeignet nachverarbeitet, so auch in marktüblicher E-Mail-Client-Software geöffnet/importiert werden.
• Sollten mehrere negative Ergebnisse aus der Integritätsprüfung hervorgehen KANN das Mail-Header-Attribut X-KIM-IntegrityCheckResult mehrmals verwendet werden.
Beispiel:
X-KIM-IntegrityCheckResult: 08
X-KIM-IntegrityCheckResult: X99
Anpassung Auflistung zu Fehlerfällen der Integritätsprüfung
Aufgrund der Erweiterung der Integrationsprüfung [A_23422-01] sowie Anpassung im Umgang mit Fehlern aus der Integrationsprüfung [A_23165-01], wird nachfolgend die Auflistung entsprechender Zustände angepasst.
geändert:
Tabelle 3: Tab_Verm_Sig_Prüf Vermerke mit Ergebnissen der Signaturprüfung
| ID* | Fehlercode | Ergebnis |
|---|---|---|
| 01 | - | Die Signatur der Nachricht wurde erfolgreich geprüft. |
| 02 | 4115 | Die Integrität der Nachricht wurde verletzt. |
| 03 | 4253 | Die digitale Signatur ist nicht vorhanden. |
| 04 | 4112 | Die digitale Signatur konnte aufgrund des falschen Formats nicht geprüft werden. |
| 05 | 4206 | Der Zertifizierungspfad des Signaturzertifikats kann nicht validiert werden. |
| 06 | [Fehlercode] | Die digitale Signatur konnte aufgrund eines nicht zuordenbaren Fehlercodes des Konnektors nicht geprüft werden.
|
| 07 | 4264- | Die digitale Signatur ist mathematisch korrekt, der Zertifikatsstatus des Signaturzertifikats konnte aber nicht geprüft werden. |
| 08 | - | Die digitale Signatur ist mathematisch korrekt und der Zertifikatsstatus des Signaturzertifikats konnte erfolgreich geprüft werden, aber beim Vergleich der Header-Elemente from, sender, reply-to, to und cc der äußeren Nachricht mit denen der inneren Nachricht wurden Abweichungen festgestellt. |
| 09 | - | Die digitale Signatur ist mathematisch korrekt und der Zertifikatsstatus des Signaturzertifikats konnte erfolgreich geprüft werden, aber das recipient-emails-Attribut aus signerInfos enthält nicht die gleichen Werte wie das recipient-emails-Attribut aus dem enveloped-data CMS-Objekt. |
| 10 | - | Prüfung der Authentisierung der KIM-Nachricht (X-KIM-Auth) schlug fehl.
Hinweis: Fehlertext soll <ergänzende Information zum den Fehler auslösenden Prüfschritt> angeben. |
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Das KIM-Clientmodul (CM) erzeugt im Verlauf technischer Funktionen zwei differenzierbare Typen von E-Mail-Fehlernachrichten:
Problem-Aspekte bzgl. E-Mail-Fehlernachrichten
Problem-Aspekt häufig wiederholter, redundanter E-Mail-Fehlerbenachrichtigung
Diese Problem-Aspekte sollen durch die nachfolgenden neuen Anforderungen adressiert werden. Diese Anforderungen erzeugen eine notwendige Abstraktion und führen zu entsprechenden Änderungen, Vereinfachung sowie Reduktion der Komplexität in bestehenden Anforderungen, ohne jedoch diesbezügliche Bestandsfunktionalität wesentlich zu verändern. Die Menge der veränderten Anforderungen, welche in ihren Teilen die Generierung von E-Mail-Fehlernachrichten behandeln, ist damit begründet, dass redundante Festlegungen in diesen Anforderungen bestehen, welche in die nachfolgenden neuen Anforderungen herausgelöst, abstrahiert werden sollen.
neu:
A_28601 - Vorgaben für zu versendende E-Mail-Fehlernachrichten
Das Clientmodul MUSS eine E-Mail-Fehlernachricht so erzeugen, dass diese einen MIME-Part des Content-Type: text/plain; charset=utf-8 enthält, in dem ein Fehlertext angegeben ist. Das Clientmodul MUSS das Header-Element „X-KIM-Fehlermeldung“ mit einem dem Fehler entsprechenden Wert angeben.
Das Clientmodul MUSS sicherstellen, dass die generierte E-Mail-Fehlernachricht an die Empfängeradresse gesendet wird, welche als Absenderadresse im SMTP-Protokollschritt „MAIL FROM“ (RFC 5322 „addr-spec“) vom Clientsystem angegeben wurde und diese eine Adresse in den Header-Elementen „from“ und „to“ der E-Mail-Fehlernachricht angeben.
Veränderungen des Inhalts dieser E-Mail-Fehlernachricht, bspw. zusätzliche Header-Elemente, fehler-relevante Informationen durch spezifischere Festlegungen, MUSS möglich sein.
Die E-Mail-Fehlernachricht ist entgegen der Festlegung [KOM-LE-A_2019-*] weder zu signieren, noch zu verschlüsseln.
[<=]
neu:
A_28602 - Vorgaben für beim Nachrichten-Abruf generierten E-Mail-Fehlernachrichten
Das Clientmodul MUSS eine E-Mail-Fehlernachricht, die direkt dem aufrufenden Clientsystem zurückgegeben wird, mit dem Content-Type: multipart/mixed und den nachfolgenden Inhalten erzeugen:
Hinweis:
Entsprechend spezifischere Festlegungen existieren bspw. im Kontext von [A_23165-*]
neu:
A_28603 - Caching einer gesendeten E-Mail-Fehlerbenachrichtigung
Das Clientmodul MUSS sicherstellen, dass gleiche, für einen SMTP-Versand bestimmte E-Mail-Fehlerbenachrichtigungen, innerhalb des Zeitraums von TTL_ERR_MSG (siehe Tabelle Tab_Konf_Param Standardkonfiguration allgemeine Parameter), nur einmal an den gleichen Empfänger gesendet werden.
[<=]
Hinweis:
Da Fehlernachrichten veränderlichen Inhalt haben können, wird ein caching anhand der normalisierten Empfängeradresse, des Fehlercodes sowie einem eindeutigen hash des Textinhalts des text/plain MIME-Parts empfohlen. So kann erkannt werden, dass ein Fehlerfall wiederholt, mit gleichem Informationskontext aufgetreten ist und verhindert werden, dass E-Mail-Fehlernachrichten mit gleicher Aussage mehrfach, in kurzem Abstand versendet wird.
A_24020-06 - Größe der auf dem KAS abgelegten Mail-Daten
Das Clientmodul MUSS beim Empfang einer KOM-LE-Nachricht mit einer KIM-Attachment-Datenstruktur die HTTP Head Methode an der Operation readMailData der Schnittstelle I_Attachment_Service aufrufen, um die Größe der auf dem KAS abgelegten Mail-Daten über den Header Content-Length zu ermitteln. Der ausgelesene Wert wird für den Abgleich mit dem im Mail-Header Attribut X-KIM-KAS-EncSize hinterlegten Wert genutzt. Entspricht der Wert nicht dem dort hinterlegten Wert, dann wird der Download nicht durchgeführt und der Empfänger mit einer Fehlernachricht gemäß [A_28602-*] und korrespondierenden Fehlertext aus Tab_Fehlertext_Download informiert. [<=]
A_23512-03 - Auswertung der KOM-LE-Version bei Nachrichten mit KAS-Content
Das Clientmodul MUSS beim Empfang einer KOM-LE-Nachricht mit einer KIM-Attachment-Datenstruktur prüfen, ob für den Empfänger eine Freigabe zum Empfang großer Nachrichten vorliegt. Ist dies nicht der Fall, MUSS das Clientmodul die Weiterverarbeitung der Nachricht und damit dem Abruf der KAS-Daten unterbinden. Das Clientmodul MUSS in diesem Fall eine Fehlernachricht an den Empfänger erzeugen. Als Fehlernachricht MUSS eine multipart/mixed MIME-Nachricht an das Clientsystem übermittelt werden, welche die verschlüsselte KOM-LE-S/MIME-Nachricht als eine message/rfc822 MIME-Einheit beinhaltet. In diesem Fall muss eine Fehlernachricht gemäß [A_28602-*] an das Clientsystem ausgegeben werden. Das subject Header-Element der neuen multipart/mixed NachrichtFehlernachricht erhält den Wert „Die KIM-Nachricht kann nicht empfangen werden, weil der Empfang großer Nachrichten nicht aktiviert wurde“. Im Fehlertext der Nachricht muss der Empfänger darauf hingewiesen werden, dass eine Nachricht empfangen wurde, die aufgrund deren Größe gemäß der Account-Einstellung (KOM-LE-Version) nicht verarbeitet werden darf. Das Header-Element X-KIM-Fehlermeldung MUSS den Fehlercode 4018 enthalten. Es MUSS im Fehlertext darauf hingewiesen werden, wie entsprechende Konfigurationen über den Account-Manager angepasst werden können und wie der Empfänger den Empfang durch Weiterleitung der Fehlernachricht wiederholen kann. So kann, nach Anpassung der KOM-LE-Version, die Nachricht an den Empfänger weitergeleitet und erneut abgerufen werden. Zusätzlich muss diese multipart/mixed MIME-Nachricht eine text/plain MIME-Einheit mit geeignetem Fehlertext enthalten. Die orig-date, from, sender, reply-to, to und cc Header-Elemente der neuen multipart/mixed Nachricht werden aus der empfangenen KOM-LE-S/MIME-Nachricht übernommen. [<=]
Weitere Änderungen von A_19370-08 - Download von E-Mail-Daten (in diesem Dokument in Abschnitt 2.1.2):
Die Unterscheidung zwischen persistentem und transientem Fehler wird entfernt, da:
Tabelle 4: Tab_Fehlertext_Download Fehlertext beim Download von E-Mail-Daten
| Bedingung
|
Fehlertext
|
|---|---|
| E-Mail-Daten konnten nicht heruntergeladen werden.
(transienten Fehler) |
Die E-Mail-Daten dieser Nachricht konnten nicht heruntergeladen werden. Bitte leiten Sie diese Nachricht nach einer angemessenen Zeit an Ihre eigene E-Mail-Adresse (<Email Adresse>) weiter. Beim nächsten Abholen wird der Download wiederholt. Bleibt der Fehler bestehen kontaktieren sie Ihren/Ihre Systembetreuer*in.
|
| E-Mail-Daten konnten nicht entschlüsselt werden.
(persistenter Fehler) |
Die E-Mail-Daten dieser Nachricht konnten nicht entschlüsselt werden, bitte kontaktieren Sie den Absender der Nachricht. |
| E-Mail-Daten auf dem KAS passen nicht zu der, in der KIM-Attachment-Datenstruktur, angekündigten Größe. | Die E-Mail-Daten dieser Nachricht passen nicht zu der vom Sender angekündigten Größe. Eine erneute Abholung ist nicht sinnvoll. |
A_22412-03 - Behandlung von Zugriffs-Limitierung
Das Clientmodul MUSS bei Aufruf der Operation readMailData und der Rückgabe des HTTP-Fehlercodes 429 vom KAS, eine Fehlernachricht gemäß [A_28602-*], mit dem Header-Element X-KIM-Fehlermeldung und Wert 4013 [Tab_Fehlercodes_KOMLE-Clientmodule] erzeugen und an das Clientsystem ausgeben. Als Fehlertext sind die korrespondieren Texte aus den Tabellen [Tab_Fehlercodes_KOMLE-Clientmodule] und [Tab_Fehlertext_Download] anzugeben. Das subject Header-Element Fehlernachricht erhält den Wert „Die E-Mail-Daten konnten nicht abgerufen werden“.
Ebenfalls MUSS das KOM-LE-Clientmodul die empfangene, dem KOM-LE-S/MIME-Profil entsprechende Nachricht, als eine message/rfc822 MIME-Einheit in einer neuen multipart/mixed MIME-Nachricht dem Clientsystem übermitteln. Zusätzlich muss diese neue multipart/mixed MIME-Nachricht eine text/plain MIME-Einheit mit dem Fehlertext gemäß der Tabelle "Tab_Fehlercodes_KOMLE-Clientmodule" enthalten. Die orig-date, from, sender, reply-to, to und cc Header-Elemente der neuen multipart/mixed Nachricht werden aus der empfangenen Nachricht übernommen. Das subject Header-Element der neuen multipart/mixed Nachricht erhält den Wert „Die E-Mail-Daten konnten nicht abgerufen werden“.
[<=]
A_19356-09 - Prüfen der Version des Empfängers
Das Clientmodul MUSS, wenn es vom Clientsystem ein RCPT TO:<recipient-address> Kommando erhält, prüfen, welche KOM-LE-Version für den im Kommando aufgeführten Empfänger im LDAP-Directory Attributs: kimData im Verzeichnisdienst [gemSpec_VZD#5] eingetragen ist. Ist das LDAP-Directory Attribut: kimData für den Empfänger undefiniert, dann muss ein KOM-LE-Clientmodul mit einer Version 1.0 angenommen werden.
Wenn eine Client-Mail größer als 15 MiB versendet werden soll, dann MUSS für jeden Empfänger durch Abfrage des Eintrags im Verzeichnisdienst geprüft werden, ob die KOM-LE-Version des Empfängers mit einem + (zum Beispiel Wert: 1.5+) erweitert wurde. Wenn eine Client-Mail größer als 15 MiB an einen Empfänger mit KOM-LE-Version < 1.5 versendet werden soll, oder die KOM-LE-Version nicht mit einem + (zum Beispiel Wert: 1.5+) erweitert wurde, MUSS das KOM-LE-Clientmodul diesen Empfänger aus der Mail entfernen. Beim Entfernen eines Empfängers MUSS das KOM-LE-Clientmodul den Absender mit einer E-Mail-Fehlernachricht gemäß [A_28601-*] über den Fehlerfall informieren. Aus dem Inhalt der Fehlernachricht müssen alle aus der Mail entfernten Empfänger hervorgehen. Die Fehlernachricht ist weder zu signieren noch zu verschlüsseln und entspricht der Delivery Status Notification gemäß [RFC3461-3464]. Im Positivfall MUSS das Clientmodul das Kommando an den MTA weiterleiten.
Kann die Mail für keinen der Empfänger versendet werden, wird das Senden der Nachricht abgebrochen. Dabei wird dem MTA das RSET-Kommando gesendet und das Clientsystem wird mit dem SMTP-Antwortcode "451" über den Fehlerfall informiert.
[<=]
KOM-LE-A_2192-03 - 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 E-Mail-Fehlernachricht gemäß [A_28601-*] informieren. Die Fehlernachricht ist weder zu signieren noch zu verschlüsseln und entspricht der Delivery Status Notification gemäß [RFC3461-3464].
[<=]
Hinweis: Entgegen [RFC3464] muss bei der Übermittlung der Fehlernachricht im SMTP Kommando MAIL FROM die Absenderadresse angeben werden. Es geht um die Fehlernachricht-Inhalte. Der [RFC3464] gilt nicht normativ.
KOM-LE-A_2024-03 - Information des Absenders über Empfänger, für die nicht verschlüsselt werden kann
Eine Nachricht darf nur an Empfänger versendet werden, für die verschlüsselt werden konnte. Über alle anderen Empfänger, für die aufgrund von fehlenden oder ungültigen Zertifikaten nicht verschlüsselt werden konnte, MUSS das Clientmodul den Absender mit einer E-Mail-Fehlernachricht, gemäß [A_28601-*] und dem Mail-Header-Attribut X-KIM-Fehlermeldung mit dem Wert 4004, über den Fehlerfall informieren. Die Fehlernachricht entspricht der Delivery Status Notification gemäß [RFC3461-3464]. und enthält das Mail-Header-Attribut X-KIM-Fehlermeldung mit dem Wert 4004. Die Fehlernachricht ist weder zu signieren noch zu verschlüsseln.
[<=]
A_21391-04 - Auswertung des X-KOM-LE-Version Header Elements
Das Clientmodul MUSS prüfen, ob das Header-Element X-KOM-LE-Version in der äußeren Nachricht eine vom Clientmodul unterstützte Version enthält. Wenn das nicht der Fall ist, MUSS das Clientmodul eine Fehlernachricht gemäß [A_28602-*], mit dem Fehlertext, "Das verwendete Clientmodul unterstützt die in der empfangenen Nachricht angegebene KIM-Version <KIMVersion> nicht." enthalten, an das Clientsystem zurückgeben. Zusätzlich muss diese neue multipart/mixed MIME-Nachricht eine text/plain MIME-Einheit mit dem Fehlertext, "Das verwendete Clientmodul unterstützt die in der empfangenen Nachricht angegebene KIM-Version <KIMVersion> nicht." enthalten. Die orig-date, from, sender, reply-to, to und cc Header-Elemente der neuen multipart/mixed Nachricht werden aus der empfangenen Nachricht übernommen. Das subject Header-Element neuen multipart/mixed Nachricht Fehlernachricht erhält den Wert „Die KIM-Version der empfangenen Nachricht wird nicht unterstützt“.
[<=]
KOM-LE-A_2046-02 - Aufbau der Fehlernachricht bei fehlgeschlagener Entschlüsselung
Das Clientmodul MUSS eine empfangene, dem KOM-LE-S/MIME-Profil entsprechende Nachricht, die z.B. auf Grund des fehlenden Schlüssels nicht entschlüsselt werden kann, als eine Fehlernachricht gemäß [A_28602-*] dem Clientsystem übermitteln. Zusätzlich muss diese neue multipart/mixed MIME-Nachricht eine text/plain MIME-Einheit mit dem Fehlertext enthalten. Die orig-date, from, sender, reply-to, to und cc Header-Elemente der neuen multipart/mixed Nachricht und alle X-KIM Header Elemente werden aus der empfangenen Nachricht übernommen. Das subject Header-Element der neuen multipart/mixed Nachricht Fehlernachricht erhält den Wert „Die Nachricht konnte nicht entschluesselt werden“. [<=]
A_21381-02 - Automatischer Abruf der PKCS#12-Datei
Das Administrationsmodul MUSS einen Monat vor Ablauf des TLS-Zertifikates automatisch ein neues Zertifikat über die Operation createCert() beantragen und herunterladen. Die zeitliche Gültigkeit des Zertifikats muss vom Clientmodul beim TLS-Verbindungsaufbau geprüft werden. Zusätzlich MUSS geprüft werden, ob für den TLS-Verbindungsaufbau bereits ein ECC (NIST) Zertifikat im Clientmodul hinterlegt ist. Existiert bereits ein ECC (Brainpool) Zertifikat, darf dieses, bis zum Laufzeitende, genutzt werden. Ist dies nicht der Fall, MUSS über die Operation createCert(), ein neues Zertifikat beantragt und heruntergeladen werden.
Wenn während der Aktualisierung ein Fehler auftritt, dann MUSS das KOM-LE-Clientmodul den Absender mit einer E-Mail-Fehlernachricht gemäß [A_28601-*] über den Fehlerfall informieren. Aus dem Inhalt der Fehlernachricht MUSS hervorgehen, dass bei der Aktualisierung der PKCS#12-Datei ein Fehler aufgetreten ist. Die Fehlernachricht ist weder zu signieren noch zu verschlüsseln und entspricht der Delivery Status Notification gemäß [RFC3461-3464]. Zusätzlich muss der vom Account Manager gemeldeter Fehlertext wie folgt eingefügt werden: Fehlertext: <message>.
[<=]
Weitere:
Absatz zum Umgang mit Entschlüsselungsfehler ändert sich wie folgt:
Wenn die Entschlüsselung fehlschlägt, wird dem Clientsystem die verschlüsselte Nachricht im Anhang einer Fehlernachricht gemäß [A_28602-*] übermittelt. Hierzu wird die angekommene KOM-LE-S/MIME-Nachricht als eine message/rfc822 MIME-Einheit in eine multipart/mixed MIME-Nachricht verpackt, die zusätzlich eine text/plain MIME-Einheit mit der Fehlermeldung enthält. Die orig-date, from, sender, reply-to, to und cc Header-Elemente der neuen Nachricht werden aus der ursprünglichen Nachricht übernommen. Der Betreff der neuen Nachricht enthält die Zeichenkette „Die Nachricht konnte nicht entschluesselt werden“.
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Durch KIM 1.5 wurde die Möglichkeit geschaffen E-Mail-Daten bis zu 500 MB zu übermitteln. Die Kommunikation zu diesem Feature bezieht sich auf die Nutzersicht, sodass heterogene Funktionsweisen von E-Mail-Clients einbezogen werden müssen, die in KIM genutzt werden. Da E-Mail-Clients die Daten vor dem Versand, oft für den Nutzer nicht sichtbar "anpassen", nimmt die Brutto-Datenmenge durch bspw. base64-Kodierung (500 MB -> ~700 MB) zu. Daraus würde das Problem-Szenario entstehen, in dem ein Nutzer eine E-Mail mit 500 MB Datei-Anhang erstellt, diese aber nicht versenden kann, da das KIM-Clientmodul nicht die entsprechend größere Datenmenge zulässt. In solchen Fällen wären generell, aus Nutzersicht "nur" ~357 MB, statt der zugesagten 500 MB möglich.
Diese Funktionsweise ist bereits seit KIM 1.5 gegeben. Die nachfolgende Änderung passt lediglich die falsche Angabe des "alten" Werts von 35 MiB auf 700 MiB an, was ebenfalls Konsistenz zur geltenden Spezifikation bzgl. "maxMailSize" in I_AccountLimit_Service schafft.
geändert:
im Kapitel 3.3.2.1 Initialisierung
[...]
Tabelle Tab_SMTP_Ant_Init beschreibt Antworten, die das Clientmodul dem Clientsystem im CONNECT-Zustand sendet.
Tabelle 5: Tab_SMTP_Ant_Init Antworten Clientmodul im CONNECT-Zustand
| SMTP-Kommando
(Clientsystem -> Clientmodul) |
SMTP-Antwortcode
(Clientmodul -> Clientsystem) |
|---|---|
| HELO
|
“250 OK” Antwortcode
|
| EHLO
|
“250 OK” Antwortcode mit folgenden EHLO Kennworten:
SIZE <size> AUTH LOGIN PLAIN 8BITMIME ENHANCEDSTATUSCODES DSN und <size> gleich oder größer als 35882577734003200 |
| 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)
|
[...]
im Kapitel 3.4.2.2 Verbindungsaufbau mit dem POP3-Server
Unter die Anforderung "KOM-LE-A_2033-01 Verbindungsaufbau mit POP3-Server über Adresse und Portnummer" wird der folgende Hinweis ergänzt:
Hinweis: Sind die POP3-Adresse und die zugehörige Portnummer nicht Bestandteil des übergebenen POP3-Benutzernamens, dann ermittelt das Clientmodul diese fehlenden Parameter mit Hilfe des übergebenen Benutzernamens (Domainanteil) und damit ausgelöster DNS Service Discovery [gemSpec_FD_KOMLE#Tab_KOMLE_Service Discovery].
[...]
im Kapitel 4.1.4 Transportsicherung zwischen Clientmodul und Fachdienst
[...]
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Die Anforderung A_23225 - lokales Caching von Sperrinformationen und Toleranzzeiten (gemSpec_PKI) beschreibt Funktionalität, welche bereits Teil der zu nutzenden Operation "VerifyCertificate" ist. Folglich wäre dies redundant zu [A_22348-*], sowie nicht adäquat durch das KIM Clientmodul umsetzbar.
Die Zuordnung der Anforderung A_23225 zum KIM CM/iCM wird gelöscht.
Hinweis:
Für das lokale Caching von Sperrinformationen und für die Toleranzzeiten gilt A_23225 - lokales Caching von Sperrinformationen und Toleranzzeiten.
Die Anforderung ist wie folgt zu interpretieren:
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Für das KIM Clientmodul wird gemäß "A_23554 - Weiterleitung MAIL FROM - SIZE-Parameter" gefordert, dass der Parameter "SIZE" übermittelt werden soll. Die Unterstützung dieses Parameters muss entsprechend vom KIM Fachdienst als SMTP-Response auf SMTP EHLO angegeben werden.
Ähnliches gilt für POP3 UIDL, welches zwingend durch die Primärsysteme zu nutzen ist und durch die KIM Clientmodule weitergeleitet wird.
Folglich werden zur Konsistenzbildung entsprechende Anforderung für den KIM-Fachdienst aufgenommen, die jedoch notwendigerweise bereits technisch umgesetzt sein müssten.
neu:
in Kapitel 4.1.1 Operation send_Message
...
A_28584 - SMTP Begrüßung am Fachdienst KOM-LE
Der Fachdienst KOM-LE MUSS, nachdem die SMTP-Verbindung zwischen dem Fachdienst KOM-LE und dem Clientmodul aufgebaut wurde, den SMTP-Dialog mit dem Clientmodul entsprechend Tabelle "Tab_SMTP_Dialog_Fachdienst_KOM-LE" unterstützen. Um zu signalisieren, dass Extended SMTP unterstützt wird, MUSS die SMTP-Begrüßung „ESMTP“ enthalten.
[<=]
Beispiel Antwort SMTP-Begrüßung: 220 KOM-LE-Fachdienst ESMTP
Table # Tab_SMTP_Dialog_Fachdienst_KOM-LE
| SMTP-Kommando
(Clientmodul -> Fachdienst KOM-LE) |
SMTP-Antwortcode
(Fachdienst KOM-LE -> Clientmodul) |
| HELO
|
“250 OK” Antwortcode
|
| EHLO
|
“250 OK” Antwortcode mit folgenden EHLO Kennworten:
SIZE 22020096 AUTH LOGIN PLAIN 8BITMIME ENHANCEDSTATUSCODES DSN |
neu:
in Kapitel Operation receive_Message
A_28585 - POP3-Dialog mit Clientmodul
Der Fachdienst KOM-LE MUSS, nachdem die POP3-Verbindung zwischen dem Fachdienst KOM-LE und dem Clientmodul aufgebaut wurde den POP3-Dialog mit dem Clientmodul entsprechend Tabelle "Tab_POP3_Dialog_Fachdienst_KOM-LE" unterstützen. [<=]
Table # Tab_POP3_Dialog_Fachdienst_KOM-LE
| Clientmodul -> Fachdienst KOM-LE
|
Fachdienst KOM-LE -> Clientmodul
|
|---|---|
| CAPA
|
“+OK” Antwortcode mit folgenden CAPA Kennworten:
TOP USER SASL PLAIN UIDL |
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Es traten/treten vermehrt Fehlerfälle auf, welche durch Fehladressierung an bspw. ("@xyz.de") E-Mail-Adressen begründet sind. Da eine Verarbeitung dieser Adressen gesichert Fehlerfälle sowie ggf. unnötige Abfragen an zentralen Diensten der TI (VZD) verursachen können, sollten diese Adressen direkt ignoriert und aus der Verarbeitung ausgeschlossen werden.
A_23174-03 - Sicherstellung der Empfängeradressen
Das Clientmodul MUSS sicherstellen, dass nur die vom Clientsystem an das Clientmodul übergebenen E-Mail-Adressen die zuvor im SMTP-Kommando RCPT TO gemäß [A_19356-0x*, KOM-LE-A_2176-0x*] geprüft wurden, im Mail Header to, cc und, wenn vorhanden, bcc in der KOM-LE-Nachricht verbleiben. Das Clientmodul MUSS den Versandvorgang vor der Weiterverarbeitung mit SMTP-Fehlercode "553 Nicht zugelassene Empfängeradresse" abbrechen, wenn ein oder mehrere Empfänger-Adressen angegeben wurden, die keinen Domain-Part gemäß [A_21456-*] ausweisen.
[<=]
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Dienste und Anwendungen wie KIM (inhaltsagnostisches Transportmedium), werden zunehmend auch als Teil automatisierter Prozesse (Dunkelverarbeitung) genutzt. Dies kann zu einer unbekannten Zusatzlast, Fehlfunktionen und Stabilitätsrisiken der involvierten Systemkomponenten führen. Um zukünftig eine bessere Aussage zur Nutzung dieser Dienste und Anwendungen treffen zu können, sollen Produkttypen (in diesem Fall der KOM-LE Fachdienst & Clientmodul), bei der HTTP-Kommunikation ein zusätzliches Header-Feld namens "TI-User-Agent" mit-übermitteln. Für den KIM Fachdienst sind das u.a. die Kommunikationsbeziehungen zum VZD, BDE, TSL und für das KIM Clientmodul zu den KIM Fachdienstteilen Account Manager und KAS. Dieses Header-Feld ist auch in der bzw. für die Zukunft der TI und KIM relevant und notwendig. Folglich leitet sich identischer Nutzen auch für die KIM Fachdienstteile ab.
Generell soll zukünftig die gesamte Infrastruktur entsprechende Informationen liefern, um eine bessere Datengrundlage für Betrachtungen der Stabilität, Sicherheit und Skalierung abzubilden.
Für die Produkttypen
wird nachfolgende Anforderung aus gemSpec_Perf aufgenommen:
A_27784 - User-Agent - Senden eines User-Agents (Clientsysteme)
Das Clientsystem (z.B. FdV) MUSS in allen HTTP-Requests an Dienste der TI ein zusätzliches Header-Feld namens "TI-User-Agent" im Format <Client-ID>/<Version> erstellen und wie folgt befüllen:
Die Client-ID wird über einen gemeinsamen, organisatorischen Prozess den KIM Providern bereitgestellt.
Änderung der Zuordnung der Anforderung A_27098-01 - Verpflichtung zur Umsetzung des TI Security Standards zum KIM Fachdienst wurde korrigiert und ist nur noch dem Anbieter Fachdienste KOM-LE zugewiesen.
"Der Anbieter MUSS die im TI Security Standard (in seiner jeweils aktuell durch die gematik freigegebenen und veröffentlichten Fassung) festgelegten betrieblichen Pflichten in Abhängigkeit der ihm zugewiesenen Security Governance Stufe umsetzen."
Die folgenden Informationen dienen lediglich dem besseren Verständnis und sind nicht Bestandteil der Spezifikation!
Die Performance-Anforderungen an KIM werden aktuell in zwei (A_26323, A_20129), teilweise redundanten, inkonsistenten Anforderungen abgebildet. Die marktanteiligen Spitzenlastvorgaben aus A_20129 können analog auf A_26323 angewendet werden, sodass A_20129 entfallen kann.
entfällt:
A_20129 – Performance – Fachdienst KIM – Spitzenlastvorgaben
Der Anbieter Fachdienst KIM MUSS das System so dimensionieren, dass für seine Nutzer der erwartete Spitzenlast gemäß "Tab_gemSpec_Perf_Fachdienst_KIM: Lastvorgaben" erfüllt werden. Die Lastvorgabe aus dieser Tabelle bezieht sich auf die Anzahl aller KIM-Teilnehmer. <=
Zur Erläuterung zu [A_20129]:
Der Anbieter muss die Anzahl seiner KIM-Teilnehmer kennen und sein System mindestens so dimensionieren, damit die Lastvorgaben eingehalten werden.
Beispielrechnung: Für 210.000 KIM-Teilnehmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Lastvorgabe von mindestens 8 Anfragen pro Sekunde für das senden von Mails mit einer Nachrichtengröße von 100KB. (5% von 160 Anfragen pro Sekunde).
Tabelle : Tab_gemSpec_Perf_Fachdienst_KIM: Lastvorgaben
| Anwendungsfall
|
Datenmenge
in KB |
Lastanforderungen
|
|
Anfragen
[1/sec] |
||
| Nachricht über KIM-Clientmodul empfangen
|
100
|
302
|
|
25.600
|
15
|
|
| Nachricht über KIM-Clientmodul Download
|
100
|
302
|
|
25.600
|
15
|
|
| Nachricht an KIM-FD senden
|
100
|
160
|
|
25.600
|
8
|
|
| Nachricht von KIM-FD empfangen
|
100
|
160
|
|
25.600
|
8
|
|
| Aufbau TLS-Kanal zwischen KIM-Clientmodul und KIM-Fachdienst
|
|
820
|
[...]
Unterhalb der Anforderung A_26323-01 wird eine Erläuterung hinzugefügt.
Erläuterung zu [A_26323-*]:
Der Anbieter muss die Anzahl seiner KIM-Teilnehmer kennen und sein System mindestens so dimensionieren, damit die Lastvorgaben eingehalten werden.
Beispielrechnung: Für 210.000 KIM-Teilnehmer (siehe Tabelle "Tab_Mengengerüst: Annahmen für Modellierung") ergibt sich auf Basis von 10.000 Teilnehmern eines Anbieters eine Lastvorgabe von mindestens 8 Anfragen pro Sekunde für das senden von Mails mit einer Nachrichtengröße von 100KB. (5% von 160 Anfragen pro Sekunde).
geändert:
A_19644-01 - Hashfunktion für Hashwert-Referenzen beim Fachdienst Download-Server (KAS)
Ein KOM-LE-Client und der Fachdienst Download-Server (KAS) MÜSSEN MUSS bei der Erzeugung und Verwendung von Hashwert-Referenzen für Anhänge - die auf dem Fachdienst Download-Server (KAS) abgelegt werden - die Hashfunktion SHA-256 [FIPS-180-4] verwenden. [<=]