A_21383 - Authentifizierung mit Benutzername und Passwort

Der Mail Server MUSS die Authentifizierung mit Benutzername und Passwort ermöglichen.
[<=]

KOM-LE-A_2185-01 - Mail Server darf nur Nachrichten aus der TI verarbeiten

Der Mail Server des KOM-LE-Fachdienstes MUSS ausschließlich Nachrichten, die innerhalb der TI versendet werden, verarbeiten. Der Zugriff auf einen Mail Server außerhalb der TI ist nicht zulässig.
[<=]

A_24022 - Prüfen der tatsächlichen Größe der KOM-LE Nachricht

Der Mail Server des KOM-LE-Fachdienstes MUSS beim Empfang einer KOM-LE Nachricht die tatsächliche Größe der Nachricht prüfen. Ist diese größer als 35 MB, dann MUSS der Mail Server die weitere Verarbeitung der KOM-LE Nachricht ablehnen. [<=]

KOM-LE-A_2131-01 - Fehlernachricht bei fehlerhafter E-Mail-Adresse

Können Nachrichten aufgrund einer fehlerhaften E-Mail-Adresse nicht weitergeleitet werden, MUSS der Mail Server eine Fehlernachricht entsprechend Delivery Status Notification gemäß [RFC3461-3464] erzeugen und diese an den Absender übermitteln.
[<=]

KOM-LE-A_2130 - Generieren einer Zustellbestätigung

Der Ziel-Mail-Server MUSS, wenn die eingehende Nachricht eine Zustellbestätigung anfordert, diese entsprechend Delivery Status Notification vom Typ Success (RFC3461-3464) generieren und an den Absender übermitteln. [<=]

A_21777 - Setzen des Parameters des RET-Kommandos (DSN)

Der Mail Server des KOM-LE-Fachdienstes MUSS, wenn er eine Nachricht mit angeforderter Delivery Status Notification (DSN) erhält, sicherstellen, dass eine DSN keine Teile des Bodies der originalen Nachricht enthält.
[<=]

KOM-LE-A_2223-01 - Unterstützung Autoreply für Abwesenheitsnotiz

Der Mail Server MUSS eine Autoreply-Funktionalität für das Versenden von Abwesenheitsnotizen nach [RFC5230] unterstützen.
[<=]

KOM-LE-A_2278-01 - Aufbau Autoreply für Abwesenheitsnotiz

Der Mail Server MUSS beim Versenden von automatischen Abwesenheitsnotizen folgende Bedingungen erfüllen:
SMTP MAIL FROM = <>
Subject = „Auto: “ + Betreff der Nachricht beim Mailserver
Auto-Submitted field = „auto-replied” (siehe RFC5230, section 5).

Zusätzlich MUSS der Mail Server das Attribut X-KIM-Dienstkennung mit dem Wert "KIM-Mail;Abwesend;V1.0" gemäß [Dienstkennung] befüllen.
[<=]

KOM-LE-A_2224-01 - Einstellen von Abwesenheitsnotizen

Der Mail Server MUSS es dem Nutzer ermöglichen, Abwesenheitsnotizen über die Schnittstelle I_AccountManager_Service - wie in [AccountManager.yaml] definiert - einstellen zu können.
[<=]

KOM-LE-A_2277 - Versenden von Abwesenheitsnotizen ohne Signatur und Verschlüsselung

Der Mail Server MUSS den Nutzer beim Einrichten von automatischen Abwesenheitsnotizen informieren, dass diese nicht als verschlüsselte und signierte Nachrichten versendet werden.

A_25296 - Sicherstellung der SMTP Service Extension for 8-bit MIME Transport

Der Mail Server des KOM-LE-Fachdienstes MUSS, alle durch ihn erzeugten Nachrichten unter Berücksichtigung des RFC 6152: SMTP Service Extension for 8-bit MIME Transport erzeugen. [<=]

A_20978-01 - Erneute Vergabe einer Mailadresse

Der KOM-LE Anbieter MUSS bei der Registrierung eines Teilnehmers prüfen, ob eine Mailadresse bereits vergeben wurde. Die erneute Vergabe einer Mailadresse MUSS vom KOM-LE Anbieter unterbunden werden, es sei denn der Teilnehmer kann nachweisen, dass er bereits früher mit der selben Adresse registriert war. Der KOM-LE Anbieter MUSS hierbei sicherstellen, dass er nur Nachweise auf Basis sicherer Authentisierungsfaktoren akzeptiert.
Der KOM-LE Anbieter MUSS hierbei die Datenschutzkonformität des Nachhaltens hierfür notwendiger Daten sicherstellen.
[<=]

A_21455-01 - Festlegung des Localparts einer KIM-Adresse

Der KIM-Anbieter MUSS bei Vergabe des Localparts einer KIM-Adresse folgenden Zeichensatz verwenden:

• (A-Z, a-z, 0-9) sowie (Punkt, Bindestrich und Unterstrich),
• es wird nicht zwischen der Groß- und Kleinschreibung unterschieden,
• die maximale Länge des Localparts darf 64 Zeichen nicht überschreiten.

A_21456-01 - Festlegung des Domainparts einer KIM-Adresse

Der KIM-Anbieter MUSS für die Beantragung seiner KIM spezifische Subdomain (hrst_domain) einer KIM-Adresse folgenden Zeichensatz verwenden:

• (a-z, 0-9) sowie (Punkt und Bindestrich),
• es wird nicht zwischen der Groß- und Kleinschreibung unterschieden,
• die Gesamtlänge des Domainparts darf maximal 189 Zeichen betragen,
• der Domainpart endet mit der Zeichenkette ".kim.telematik" (Produktivumgebung).

A_21816 - Mail Server als geschlossener SMTP-Relay-Server

Der Mail Server des KOM-LE-Fachdienstes MUSS als ein geschlossener SMTP-Relay-Server konfiguriert werden. Das bedeutet, der Mail Server darf nur E-Mails weiterleiten, für die er als Sender und/oder Empfänger zuständig ist. [<=]

A_22415 - Mail Server – Löschen von Ressourcen

Der Anbieter des Mail Servers MUSS sicherstellen, dass alle gespeicherten E-Mails eines Accounts mit abgelaufener Gültigkeit (Expires-Header) gelöscht werden.
[<=]

A_23421 - Überprüfung der Absenderadresse

Der Fachdienst KOM-LE MUSS den bei der Authentisierung vom Clientmodule übermittelten Username (SMTP AUTH) mit der Adresse im MAIL FROM Kommando vergleichen. Sollte bei dem Vergleich ein Unterschied festgestellt werden (RFC 5322 „addr-spec“), MUSS der Fachdienst die Verarbeitung der KOM-LE-Mail ablehnen und das Clientmodule mit einem SMTP Fehler informieren.
[<=]

A_23422 - Sicherstellung Absenderintegrität einer KOM-LE-Nachricht

Der Fachdienst KOM-LE MUSS vor der Verarbeitung einer KOM-LE-Nachricht folgende Prüfregeln umsetzen:
 

KOM-LE-A_2133 - Durchführung eines Accountings zur Abrechnung

Führt der Anbieter ein Accounting für die Abrechnung unter Einhaltung der geltenden Anforderungen an Datenschutz und Informationssicherheit durch, KANN der Fachdienst die dafür notwendigen Funktionen implementieren.

KOM-LE-A_2304 - Information an Nutzer zur bcc-Funktionalität

Der KOM-LE-Anbieter  MUSS die KOM-LE-Teilnehmer im Rahmen der Registrierung zu KOM-LE und im KOM-LE-Nutzerhandbuch darüber informieren, dass auf eine Nutzung der bcc-Funktionalität eines E-Mail-Clients verzichtet werden sollte, da es technisch nicht ausgeschlossen ist, dass Nachrichtenempfänger ggf. auch alle bcc (blind carbon copy) Empfänger der Nachricht ermitteln werden können. [<=]

A_19591-02 - Eintrag Clientmodul-Version in VZD, Account Manager

Der Account Manager MUSS die vom Clientmodul übermittelte KIM-Version (kimVersion) im Verzeichnisdienst in den KOM-LE-Fachdaten und in seiner lokalen Datenbank für die betroffene "mail"-Adresse eintragen. [<=]

A_21384 - Sperrung von Zertifikaten

Für die Sperrung eines Zertifikates aus einer PKCS#12-Datei MUSS der KOM-LE-Anbieter einen organisatorischen Prozess definieren, mit dem das Zertifikat im Falle von Verlust, Diebstahl, oder sonstiger Kompromittierung beim Herausgeber gesperrt wird.
[<=]

A_21385 - Änderung des initialen Passwortes

Der Account Manager MUSS bei der Registrierung eines neuen KOM-LE-Teilnehmers den Nutzer zum Wechseln des initialen Passwortes auffordern. Wird keine Passwortänderung durchgeführt, wird der Fehler 420 (W3C - Policy Not Fulfilled) zurück gegeben.
[<=]

A_21376-01 - Eintrag der KOM-LE-Fachdaten in den VZD

Der Account Manager MUSS die vom Clientmodul übermittelten KOM-LE-Fachdaten (gemäß gemSpec_VZD#Datenmodell) während der Registrierung eines neuen KOM-LE-Teilnehmers in den Verzeichnisdienst und in seiner lokale Datenbank für die betroffene "mail"-Adresse eintragen.

Bei Eintragung der KIM-Version in den Verzeichnisdienst ist folgendes Schema zu verwenden: <Hauptversionsnummer.Nebenversionsnummer>
[<=]

A_26506 - Account Manger - Administration von Verzeichnisdiensteinträgen

Der Account Manager MUSS sicherstellen, dass die Administration von Verzeichnisdiensteinträgen durch ein KIM Clientmodul, bei Aufruf der Operation setAccount(), nur für die durch das Clientmodul aktiv übergebenen Attribute erfolgt. Für nicht geänderte Parameter MUSS der existierende Eintrag im VZD erhalten bleiben. [<=]

A_26819 - Account Manager - Standard Anwendungskennzeichen bei Registrierung

Der Account Manager MUSS bei der Registrierung einer E-Mail Adresse prüfen, ob es sich um die erste E-Mail Adresse handelt, die in einen dafür genutzten Fachdiensteintrag im VZD hinterlegt wird. Ist dies der Fall MUSS das Clientmodul mit dem Fehlercode 424 dahingehend informiert werden. [<=]

A_23718 - Account Manager, Eintragung von Anwendungskennzeichen in den VZD

Der Account Manager MUSS die vom Clientmodul mittels der Operationen registerAccount() oder setAccount() übermittelten Anwendungskennzeichen a) auf Gültigkeit gegenüber dem FHIR Codesystem (https://simplifier.net/app-transport-framework/service-identifier-cs/$download?format=json  ) prüfen und  b) wenn gültig, im Verzeichnisdienst in den KOM-LE-Fachdaten für die betroffene Mail-Adresse eintragen (Schnittstelle: I_Directory_Application_Maintenance, Operationen: add_Directory_FA-Attributes und modify_Directory_FA-Attributes). [<=]

A_25824 - Account Manager, Standard Anwendungskennzeichen im VZD

Der Account Manager MUSS sicherstellen, dass mittels der Operationen registerAccount() oder setAccount() übermittelte Anwendungskennzeichen nicht zur vollständigen Löschung des Standard Anwendungskennzeichens "KIM-Mail" innerhalb eines Fachdiensteintrages des zugehörigen VZD Eintrages führen. Wird der Account Manager über die Operation deregisterAccount() mit der Deregistrierung eines Nutzers beauftragt, MUSS er prüfen, ob dies zur Löschung des Standard Anwendungskennzeichens innerhalb eines Fachdiensteintrages führt und dies in diesem Fall unterbinden. Der Account Manager MUSS solche nicht erlaubten Änderungen dem Administrationsmodul des KIM Clientmoduls mit dem Fehlercode 424 signalisieren. [<=]

A_23722-01 - Account Manager, regelmäßige Aktualisierung der Liste der Anwendungskennzeichen

Der Account Manager MUSS einmal täglich über die Schnittstelle I_Directory_Application_Maintenance, durch Aufrufen der Operation get appTags die aktuelle Version des FHIR CodeSystems mit den Anwendungskennzeichen vom Verzeichnisdienst herunterladen und persistent speichern. [<=]

A_19524-03 - Verwaltung Resource Records Types für Service Discovery, KIM

Der KOM-LE Anbieter MUSS die aufgeführten Resource Records Types im Namensraum der TI gemäß folgender Tabelle verwalten. Zwischen den jeweiligen Fachdiensten MUSS folgender Port benutzt werden:

• SMTPS: 465

Tabelle 1: Tab_KOMLE_Service Discovery

A_19533 - Verwaltung Resource Records FQDN, KIM

Der KOM-LE-Fachdienst MUSS im Namensraum der TI die Resource Records gemäß nachstehender Tabelle verwalten.

Tabelle 2: Tab_KOMLE_FQDN

KOM-LE-A_2134 - Aktionen bei Fehlerzuständen

Der Fachdienst KOM-LE MUSS mindestens die in Tabelle Tab_Fehler_Behandlung beschriebenen Fehlerzustände erkennen und die zugehörigen Aktionen durchführen.

KOM-LE-A_2135-01 - Protokollierung von Vorgängen

Für die Nachvollziehbarkeit der Vorgänge am Fachdienst KOM-LE MÜSSEN Maßnahmen und Verfahren gemäß DSGVO i.V.m. BDSG installiert werden. Die Protokollierung der folgenden Informationen ist dabei zulässig:

KOM-LE-A_2136 - Protokollierung außerhalb gesetzlicher und vertraglicher Pflichten

Der KOM-LE-Fachdienst MUSS sicherstellen, dass eine Protokollierung von personenbezogenen Daten außerhalb der gesetzlichen und vertraglichen Pflichten nur dann erfolgt, wenn dies zum Zwecke der Fehler- bzw. Störungsbehebung erforderlich ist.

KOM-LE-A_2137 - Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung

Falls im KOM-LE-Fachdienst eine Protokollierung zum Zwecke der Fehler- bzw. Störungsbehebung erfolgt, MUSS der KOM-LE-Fachdienst unter Berücksichtigung des Art. 25 Abs. 2 DSGVO sicherstellen, dass in den Protokolldaten entsprechend dem Datenschutzgrundsatz nach Art. 5 DSGVO nur personenbezogene Daten in der Art und dem Umfang enthalten sind, wie sie zur Behebung erforderlich sind und dass die erzeugten Protokolldaten im Fachdienst nach der Behebung unverzüglich gelöscht werden.
[<=]

A_21389 - Übermittlung der Clientmodul- und Produkttypversion an die gematik

Der KIM-Anbieter MUSS der gematik auf Anfrage eine nicht-personenbezogene Gesamtübersicht, der sich im Feld befindenden aktiven KIM-Clientmodule, zur Verfügung stellen. [<=]

KOM-LE-A_2138 - Auskunftsfähigkeit über den Systemzustand

Die Administratoren des KOM-LE-Fachdienstes sind verpflichtet, zu jedem Zeitpunkt auskunftsfähig über den Systemzustand des Fachdienstes zu sein. Zur Unterstützung dieser Auskunftsfähigkeit KANN der KOM-LE-Fachdienst Monitoringfunktionen implementieren.

KOM-LE-A_2139-03 - Konfiguration Fachdienst

Der Fachdienst KOM-LE MUSS dem Anbieter mindestens die in der Tabelle Tab_Konfig_Parameter dargestellten Parameter zur Konfiguration zur Verfügung stellen. [<=]

A_17240-01 - ECC-Migration, Unterstützung verschiedener kryptografischer Verfahren bei der TLS-Verwendung

Der Fachdienst KOM-LE MUSS parallel RSA und ECC unterstützen. Der Fachdienst KOM-LE MUSS bevorzugt ECC verwenden/anbieten. [<=]

KOM-LE-A_2140 - Schnittstelle I_Message_Service

Die Teilkomponente Mail Server des KOM-LE-Fachdiensts MUSS die Schnittstelle I_Message_Service anbieten. I_Message_Service ist eine logische Schnittstelle, die Funktionalitäten zum Versenden und Empfangen von E-Mail-Nachrichten bereitstellt. Die Schnittstelle bietet die folgenden Operationen:

• send_Message(Nachricht, Anmeldedaten) und
  
• receive_Message(Anmeldedaten): Nachricht[ ].
  

KOM-LE-A_2141 - Technische Umsetzung der Schnittstelle I_Message_Service

Die technische Umsetzung der Schnittstelle I_Message_Service erfolgt über die Bereitstellung von entsprechenden TCP-Ports am KOM-LE-Fachdienst für SMTP-bzw. POP3-Verbindungen. Die Schnittstelle MUSS ausschließlich über eine sichere Verbindung unter Verwendung von TLS mit beidseitiger zertifikatsbasierter Authentifizierung zugänglich sein.
[<=]

KOM-LE-A_2226-01 - Zuordnung TLS-Client-Zertifikat für Clientmodul

Der KOM-LE Fachdienst MUSS das KOM-LE Clientmodul mit einem TLS-Client-Zertifikat aus der Komponenten-PKI der TI für die TLS-Kommunikation mit dem KOM-LE Fachdienst ausstatten. Bei diesem Zertifikat MUSS es sich um ein ECC-Zertifikat handeln. [<=]

KOM-LE-A_2227-01 - Zuordnung TLS-Server-Zertifikat für Clientmodul

Der KOM-LE Fachdienst MUSS das KOM-LE Clientmodul mit einem TLS-Server-Zertifikat aus der Komponenten-PKI der TI für die TLS-Kommunikation mit Clientsystemen ausstatten. [<=]

KOM-LE-A_2228-01 - Ausschließliche Akzeptanz von TLS-Client-Zertifikaten von KOM-LE Clientmodulen

Der Fachdienst  MUSS beim Aufbau einer TLS-Verbindung mit dem KOM-LE Clientmodul ausschließlich Client-Zertifikate akzeptieren, die KOM-LE Clientmodulen zugeordnet sind.
[<=]

KOM-LE-A_2186 - Verwendung des C.FD.TLS-S Server-Zertifikats bei der TLS-Authentifizierung mit dem Clientmodul

Beim Aufbau der TLS-Verbindung mit dem Clientmodul MUSS sich der Fachdienst KOM-LE mit seinem C.FD.TLS-S Server-Zertifikat authentifizieren.

KOM-LE-A_2143 - Aufbau der TLS-Verbindung

Der Aufbau der TLS-Verbindung für die Schnittstelle I_Message_Service DARF NICHT über STARTTLS erfolgen.

KOM-LE-A_2144 - Schritte beim Aufbau der TLS-Verbindung

Beim Aufbau der TLS-Verbindung MUSS der KOM-LE-Fachdienst folgende Schritte bei der Prüfung des vorgelegten Clientzertifikats (C.CM.TLS-CS-Zertifikat des Clientmoduls oder C.FD.TLS-C Client-Zertifikat eines anderen KOM-LE-Fachdienstes) durchführen:

• Prüfung des Vertrauensstatus der Aussteller-CA gegen die TSL,
  
• mathematische Prüfung der Zertifikatssignatur,
  
• Prüfung der zeitlichen Gültigkeit des Zertifikats und
  
• Prüfung des Zertifikatsstatus durch Abfrage des relevanten OCSP-Responders.
  

KOM-LE-A_2145 - Validierung der TSL

Unabhängig von der Zertifikatsprüfung MUSS der KOM-LE-Fachdienst in regelmäßigen Zyklen die TSL-Validierung durchführen. Dabei sind folgende Schritte auszuführen:

• Download der aktuellen Liste vom relevanten Downloadpunkt,
  
• Validierung gegen das XML-Schema der TSL,
  
• Prüfung des Vertrauensstatus des TSL-Signaturzertifikats gegen einen sicher verwahrten TSL-Root-Schlüssel und
  
• Prüfung der XML-Signatur.
  

KOM-LE-A_2146-03 - Verarbeitung von Nachrichten entsprechend S/MIME-Profil

Der Mail Server DARF Nachrichten, die nicht entsprechend S/MIME-Profile [gemSMIME_KOMLE] verschlüsselt sind, NICHT weiterleiten bzw. im Postfach des Empfängers hinterlegen. Der Mail Server MUSS gemäß [A_20771] eine Fehlernachricht generieren und diese an den Sender übermitteln. Für alle servergenerierten Nachrichten wie Fehlermeldungen und Abwesenheitsnotizen sowie vom Clientmodul generierte Fehlernachrichten, gilt diese Anforderung nicht.
[<=]

KOM-LE-A_2147-02 - Generierung von Zustellbestätigungen

Erhält der Ziel-Mail-Server eine Nachricht, die eine Zustellbestätigung fordert, MUSS er diese unter Verwendung folgender Informationen aus der empfangenen Nachricht generieren und unverschlüsselt an den Absender weiterleiten:

• Empfänger (alle Empfänger der Original-Nachricht die dem Ziel-Mail-Server zugeordnet sind), pro Empfänger wird ein per-recipient Header Feld befüllt [RFC3464]
  
• Empfangszeitpunkt der originalen Nachricht beim Ziel-Mail-Server im Header Feld Arrival-Date (im Part Content-Type: message/delivery-status) 
  
• Message-ID der äußeren Nachricht im Header Feld In-Reply-To (im Headerbereich der DSN selbst, mit dem Content-Type: multipart/report)
  

A_20771-01 - Generierung von Fehlermeldungen am Fachdienst

Der Mail Server MUSS eine Fehlernachricht entsprechend Delivery Status Notification gemäß [RFC3461-3464] erzeugen und das Header-Attribut X-KIM-Fehlermeldung mit den Werten aus der folgenden Tabelle befüllen.

Tabelle 6 Tab_Fehlercodes_KOMLE-Fachdienst

KOM-LE-A_2148-01 - Herleitung der authorizationID beim PLAIN Authentifizierungsverfahren

Der Mail Server MUSS bei der PLAIN-Authentifizierung von SMTP-Auth beim Empfangen der Parameter "authenticationID" und "password" die optionale "authorizationID" gemäß [RFC 4616] selbständig aus der "authenticationID" herleiten, sofern sie nicht übertragen wurde.
[<=]

KOM-LE-A_2149 - Kein Empfang von Nachrichten bei deregistriertem Konto

Der KOM-LE-Fachdienst MUSS Nachrichten, die an ein deregistriertes Konto gerichtet sind, bei Eingang verwerfen und an den Absender eine Fehler-E-Mail senden.

KOM-LE-A_2150 - Kein Versenden von Nachrichten bei deregistriertem Konto

Der KOM-LE-Fachdienst DARF Nachrichten NICHT von einem deregistrierten Konto aus verschicken.

A_20651-02 - Empfang von Fehlernachrichten des Clientmodules

Der KOM-LE-Fachdienst MUSS Nachrichten vom Clientmodul, die nicht signiert und verschlüsselt sind, nur entgegennehmen wenn das Mail-Header-Attribut X-KIM-Fehlermeldung vorhanden ist. Als zulässige Befüllung dieses Attributs gelten die in der [gemSpec_CM_KOMLE#A_20650] festgelegten Werte. Nicht signierte und verschlüsselte Nachrichten ohne befülltem Mail-Header-Attribut X-KIM-Fehlermeldung werden nicht entgegengenommen. [<=]

KOM-LE-A_2152 - Unterstützung des POP3-Kommandos UIDL

Um die Kompatibilität mit dem KOM-LE-Clientmodul sicherzustellen MUSS der Mail Server das POP3-Kommando UIDL unterstützen.

KOM-LE-A_2154-01 - Versand von Löschbenachrichtigungen

Der KOM-LE-Fachdienst DARF den Sender NICHT über das automatische Löschen einer von ihm versendeten, aber nicht abgeholten Nachricht informieren.
[<=]

KOM-LE-A_2155-01 - Nicht abgeholte Nachrichten nach der Deregistrierung

Der KOM-LE-Fachdienst MUSS bereits eingegangene Nachrichten, die noch nicht vom Teilnehmer abgerufen wurden, auch nach der Deregistrierung des Teilnehmers bis Ablauf eines konfigurierbaren Intervalls zum Abrufen bereit halten und dann löschen. Als Standardwert wird ein Monat vorgesehen. [<=]

A_19375-06 - KAS – Implementierung der Schnittstelle

Der KAS MUSS die Schnittstelle I_Attachment_Services als REST-Webservices über HTTPS gemäß [AttachmentService.yaml] in der Version 2.3.3 implementieren. Des Weiteren MUSS der KAS für alle in der [AttachmentService.yaml] definierten Operationen den Zeichensatz UTF-8 unterstützen.
[<=]

A_19377 - KAS – TLS-gesicherte Verbindung

Der KAS MUSS die Schnittstelle I_Attachment_Service durch Verwendung von TLS mit beidseitiger Authentisierung sichern. Der KAS MUSS für diese TLS-Verbindungen TI-Zertifikate (analog zu Schnittstelle I_Message_Service) nutzen. Der KAS MUSS sich mit der Server-Identität von Schnittstelle I_Attachment_Service authentisieren.
[<=]

A_21386-02 - KAS - HTTP-Basic-Authentifizierung

Der KAS MUSS bei Aufruf der Operationen add_Maildata und delete_Maildata eine HTTP-Basic-Authentifizierung durchführen.
[<=]

A_19378-02 - KAS - prüfen der Größe der verschlüsselten E-Mail-Daten

Der KAS MUSS die Dateigröße der verschlüsselten E-Mail-Daten ermitteln, bevor diese gespeichert werden. Der KAS MUSS die Verarbeitung ablehnen, wenn die Gesamtgröße der verschlüsselten E-Mail-Daten den Konfigurationswert (Quota - zwischen Anbieter und Nutzer vereinbart) des KAS übersteigt.
[<=]

A_19379-01 - KAS – Prüfung Zugriff auf E-Mail-Daten

Der KAS MUSS sicherstellen, dass nur über den dazugehörigen Freigabelink auf die verschlüsselten E-Mail-Daten zugegriffen werden kann.
[<=]

A_19380-02 - KAS – Erzeugung Freigabelink

Der KAS MUSS bei Aufruf der REST-Operation add_Maildata einen Freigabelink 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.
[<=]

A_19381 - KAS – Freigabelink Transportsicherheit

Der KAS MUSS in den Freigabelink das https-Protokoll hinein generieren: "HTTPS://".
[<=]

A_19383 - KAS – Keine Kopien von gelöschten Daten

Der KAS DARF von gelöschten Daten KEINE Kopien speichern.
[<=]

A_22410-01 - KAS – Prüfung: Aufruf des Empfängers

Der KAS MUSS das Herunterladen der E-Mail-Daten mit dem HTTP-Fehlercode 403 ablehnen, wenn beim Abruf der E-Mail-Daten die Empfänger-Adresse (recipient) nicht mit einem für diese E-Mail-Daten beim KAS hinterlegten Empfänger (recipients) übereinstimmt.
[<=]

A_22411-01 - KAS - Zugriffs-Limitierung

Der KAS KANN den Zugriff mit dem HTTP-Fehlercode 429 verweigern, wenn eine Ressource zu oft von einem Client angefragt wird. Der KAS KANN für die Bestimmung der zulässigen Zugriffsrate folgende Faktoren berücksichtigen: Subject-DN des Clientmodul-Zertifikats, Freigabelink-URL, Anzahl der Empfänger der Ressource (E-Mail-Daten), Empfänger E-Mail-Adresse und Anzahl versuchter und erfolgreicher Downloads.
[<=]

A_22418 - KAS - Umgang bei Überschreitung der Quota

Der KAS des KOM-LE-Fachdienstes KANN bei Überschreitung der Quota für einen Nutzer-Account den HTTP-Fehlercode 507 an das Clientmodul zurückgeben.
[<=]

A_22428-01 - KAS - Content-Length beim Download

Der KAS des KOM-LE-Fachdienstes MUSS bei der Übertragung der E-Mail-Daten, das HTTP-Header-Element "Content-Length" immer mit der Gesamt-Länge des Bodys befüllen.
[<=]

A_24002-01 - KAS - Unterstützung der HTTP HEAD Methode

Der KAS MUSS an der Schnittstelle I_Attachment_Service, Operation read_Maildata, die HTTP HEAD Methode gemäß [RFC9110] Kapitel 9.3.2. HEAD unterstützen. [<=]

A_19384 - KAS – Sicher gegen Datenverlust

Der Anbieter des KAS MUSS den Dienst gegen Datenverlust absichern.
[<=]

A_19385-03 - KAS – Löschen von Ressource

Der Anbieter des KAS MUSS sicherstellen, dass alle gespeicherten E-Mail-Daten, mit abgelaufener Gültigkeit (Expires) zuzüglich einer Karenzzeit von einer Stunde gelöscht werden.
[<=]

A_20063-06 - Account Manager - Implementierung der Schnittstelle

Die Teilkomponente Account Manager des Fachdienstes MUSS die Schnittstelle I_AccountManager_Service als REST-Webservice über HTTPS gemäß [AccountManager.yaml] in der Version 2.3.3 implementieren. Des Weiteren MUSS der Account Manager für alle in der [AccountManager.yaml] definierten Operationen den Zeichensatz UTF-8 unterstützen.
[<=]

A_20064-01 - Account Manager - TLS-gesicherte Verbindung

Die Teilkomponente Account Manager des Fachdienstes MUSS die Schnittstelle I_AccountManager_Service durch Verwendung von TLS mit serverseitiger Authentisierung sichern.
[<=]

KOM-LE-A_2187-05 - 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:

• ist das Token korrekt (mit Validierung der erzeugten Signatur),
• ist das Token zeitlich gültig (also die Verarbeitung erfolgt zwischen nbf +  konfigurierter Ablaufzeitspanne (jwtExpiration)),
• sind Username und Passwort korrekt

• bei Aufruf der Operation registerAccount und revokeDeregistration:
  Die Fachdaten des KOM-LE-Teilnehmers müssen während der Registrierung bzw. bei der Rücknahme einer Deregistrierung in den VZD-Datensatz mit der Telematik-ID des AUT-Zertifikats aus dem Token eingetragen werden.
• bei Aufruf der Operation setAccount:
  Wenn über setAccount Daten im VZD geändert werden sollen (z.B. kimVersion), dann muss der - in der Operation angegebene - Parameter username (E-Mail Adresse) in dem VZD-Datensatz mit der Telematik-ID des AUT-Zertifikats aus dem Token im mail Attribut der Fachdaten vorhanden sein.
• bei Aufruf der Operation deregisterAccount:
  Der - in der Operation angegebene - Parameter username (E-Mail Adresse) muss in dem VZD-Datensatz mit der Telematik-ID des AUT-Zertifikats aus dem Token im mail Attribut der Fachdaten vorhanden sein.
  

A_23732 - Account Manager - Aktionen bei Deregistrierung

Der Account Manager MUSS bei einer Deregistrierung eines Accounts folgende Aktionen ausführen:

• Speichern der im VZD für den Account existierenden Fachdaten 
• Löschen der im VZD für den Account existierenden Fachdaten (Schnittstelle I_Directory_Application_Maintenance, Operation delete_Directory_FA-Attributes)

A_23733 - Account Manager - Aktionen bei Rücknahme einer Deregistrierung

Der Account Manager MUSS bei Rücknahme einer Deregistrierung eines Accounts folgende Aktionen ausführen:

• Wiederherstellen der bei der Deregistrierung des Accounts gespeicherten Fachdaten im VZD.

A_23175 - Account Manager - Prüfen des Zeitraumes für die Rücknahme der Deregistrierung

Der KOM-LE Fachdienst MUSS bei Aufruf der Operation revokeDeregistration durch das Administrationsmodul prüfen, ob für den Benutzer-Account das deregDate überschritten wurde. Bei Überschreitung des deregDate ist eine Rücknahme der Deregistrierung zu unterbinden.
[<=]

A_20772 - I_AccountManager_Service Zeichensatz Fachdienst

Der KOM-LE Fachdienst MUSS für die Inhalte aller Operationen (Request und Response) der Schnittstelle  I_AccountManager_Service den UTF-8 Zeichensatz unterstützen.
[<=]

A_20209 - KOM-LE - Erfassung von Teilnehmerdaten und Bereitstellung von Zugangsdaten

Der KOM-LE Anbieter MUSS den KOM-LE Teilnehmern alle nötigen Zugangsdaten auf einem sicheren Weg bereitstellen. [<=]

KOM-LE-A_2305 - Mehrere KOM-LE Postfächer für einen KOM-LE-Teilnehmer

Der KOM-LE Fachdienst MUSS die Möglichkeit anbieten für einen KOM-LE-Teilnehmer, repräsentiert durch dasselbe AUTH Zertifikat, mehrere Postfächer mit jeweils eigener E-Mail-Adresse und eigenen Anmeldecredentials nutzen zu können. [<=]

KOM-LE-A_2158 - Protokollieren von Registrierung und Deregistrierung

Der KOM-LE-Fachdienst MUSS das Registrieren und Deregistrieren von KOM-LE- Teilnehmern protokollieren.
[<=]

KOM-LE-A_2159-01 - Verwendung der Schnittstelle I_Directory_Application_Maintenance

Für die Änderung des Verzeichniseintrages (Eintragen und Löschen der E-Mail-Adresse des KOM-LE-Teilnehmers sowie die vom Clientmodul verwendete KOM-LE-Version) MUSS der KOM-LE-Fachdienst die Schnittstelle I_Directory_Application_Maintenance der TI-Plattform verwenden.
[<=]

A_20212 - Verwendung der Schnittstelle I_Directory_Application_Maintenance, Lokalisierung Verzeichniseintrag

Für die Änderung des Verzeichniseintrages (Eintragen bzw. Löschen der E-Mail-Adresse des KOM-LE-Teilnehmers) MUSS der KOM-LE-Fachdienst zur Lokalisierung des VZD Eintrags die Telematik-ID aus dem AUT Zertifikat nutzen, mit dem sich der KOM-LE Teilnehmer an der Schnittstelle I_AccountManager_Service authentifiziert hat.
[<=]

KOM-LE-A_2160 - Kommunikation mit dem Verzeichnisdienst über TLS

Der Fachdienst KOM-LE MUSS bei der Änderung des Verzeichniseintrages über die Schnittstelle I_Directory_Application_Maintenance immer eine sichere Verbindung unter Verwendung von TLS mit beidseitiger zertifikatsbasierter Authentifizierung benutzen.
[<=]

KOM-LE-A_2189 - Verwendung des C.FD.TLS-C Client-Zertifikats bei der TLS-Authentifizierung mit dem Verzeichnisdienst

Beim Aufbau der TLS-Verbindung mit dem Verzeichnisdienst MUSS sich der Fachdienst KOM-LE mit seinem  C.FD.TLS-C Client-Zertifikat authentifizieren.

KOM-LE-A_2161 - Benutzername der KOM-LE-Teilnehmers

Der KOM-LE-Fachdienst MUSS bei der Registrierung die E-Mail-Adresse des KOM-LE-Teilnehmers als Benutzernamen verwenden.

KOM-LE-A_2162 - Übermittlung der Passwörter zum Fachdienst

Die Fachanwendung KOM-LE MUSS gewährleisten, dass Passwörter der Teilnehmer nur vertraulichkeits-, integritäts- und authentizitätsgeschützt vom Client zum Fachdienst übermittelt werden.

KOM-LE-A_2163-01 - Vorgaben zur Minimum-Qualität des Passwortes

Der KOM-LE-Anbieter MUSS Vorgaben zur Minimum-Qualität des Passwortes (entsprechend [BSI ORP.4] A.8 und A.22) machen und die Einhaltung dieser Vorgaben gewährleisten. [<=]

KOM-LE-A_2164 - Passwörter nicht im Klartext speichern

Der Fachdienst KOM-LE DARF Passwörter der KOM-LE-Teilnehmer NICHT im Klartext speichern.

KOM-LE-A_2165 - Möglichkeit der Änderung des Passwortes

Die Teilkomponente Account Manager des Fachdienstes KOM-LE MUSS dem KOM-LE-Teilnehmer die Möglichkeit anbieten das Passwort für die Anmeldung am KOM-LE-Fachdienst zu ändern.

KOM-LE-A_2166 - Keine Änderung oder Löschung des Passwortes durch Dritte

Der KOM-LE-Fachdienst DARF das Ändern oder Löschen der bei ihm gespeicherten Passwörter der KOM-LE-Konten durch Dritte NICHT zulassen.

KOM-LE-A_2302-03 - Erzeugung Schlüssel und Bezug TLS-Zertifikate für Clientmodule

Der KOM-LE-Anbieter MUSS die Schlüsselpaare für die Zertifikate für KOM-LE-Clientmodule erzeugen und für diese aus der Komponenten-PKI der TI die C.CM.TLS-CS-Zertifikate beziehen, sodass die Zertifikate nach der Registrierung eines Nutzers zur Verfügung stehen. Bei diesem Zertifikat MUSS es sich um ein ECC-Zertifikat handeln.
[<=]

KOM-LE-A_2167-05 - Sperrung des Accounts

Der Fachdienst KOM-LE MUSS den Account eines Teilnehmers nach spätestens drei aufeinanderfolgenden Fehleingaben des Passwortes temporär gegen Brute-Force Angriffe schützen. Hierzu wird spätestens nach der dritten Falscheingabe eine Wartezeit für den nächsten Log-In Versuch vorgegeben, für die weitere Log-in Versuche nicht möglich sind. Die Wartezeit MUSS geeignet gewählt werden, um Brute-Force-Angriffe zu erschweren und gleichzeitig eine akzeptable User-Experience zu erhalten. Im Fall einer Falscheingabe wird dem KOM-LE-Client der Fehlercode 535 (Authentication credentials invalid) gemäß [RFC3463] zurückgegeben.
[<=]

KOM-LE-A_2168-01 - Entsperren des Accounts

Der KOM-LE Anbieter  MUSS einen Prozess implementieren, der es berechtigten Teilnehmern ermöglicht, mit Hilfe des KOM-LE Anbieters seinen gesperrten Account wieder freizuschalten. Der KOM-LE Anbieter MUSS den Teilnehmer mit Vetragsabschluss über diesen Prozess informieren. Der KOM-LE Anbieter ist der Owner des Prozesses.
[<=]

KOM-LE-A_2169 - Authentifizierungsdaten beim Versenden und Empfangen von Nachrichten

Der KOM-LE-Fachdienst MUSS die im Registrierungsprozess vergebenen Daten für Benutzername und Passwort sowohl beim Versenden von Nachrichten über SMTP als auch beim Abholen von Nachrichten über POP3 für die Authentifizierung verwenden.

A_18784-04 - Bereitstellung Schlüssel und Zertifikat für Clientmodul als passwortgeschützte PKCS#12 Datei

Der Account Manager MUSS dem KOM-LE-Clientmodul das ECC-Schlüsselmaterial und -Zertifikat für die Authentifizierung an den KOM-LE-Fachdienst-Schnittstellen über die Schnittstelle I_AccountManager_Service als (optional passwortgeschützte) PKCS#12-Datei zur Verfügung stellen. Die Übermittlung der PKCS#12-Datei muss über eine verschlüsselte, authentifizierte und integritätsgeschützte Verbindung erfolgen. Das KOM-LE-Clientmodul generiert das Passwort für die PKCS#12-Datei und übermittelt es im Request der Operation. Im Response übergibt der KOM-LE Fachdienst die – mit dem übermittelten Passwort geschützte – PKCS#12-Datei.
[<=]

A_19542-02 - Schnittstelle für den Download

Der Account Manager MUSS dem Administrationsmodul eine Operation für die Beantragung und das Herunterladen der PKCS#12-Datei bereitstellen. Wenn vom Clientmodul ein Passwort für die PKCS#12 Datei übergeben wurde, dann MUSS der Account Manager die PKCS#12-Datei vor der Bereitstellung mit einem vom Passwort abgeleiteten symmetrischen Schlüssel verschlüsseln. Für die Verschlüsselung MÜSSEN die Vorgaben aus [gemSpec_Krypt] eingehalten werden. [<=]

A_21377 - Generierung eines One-Time-Passwortes

Der Account Manager MUSS bei Aufruf der Operation getOTP ein One-Time-Passwort gemäß den Kriterien aus [gemSpec_Krypt] generieren. Die Gültigkeit des One-Time-Passworts beträgt 1 Woche und ist an den verwendeten Account gebunden.
[<=]

A_21378 - Wechsel der Telematik-ID

Der Account Manager MUSS die Operation getOTP implementieren, bei der die Authentisierung mit der bisherigen Smartcard erfolgt. Als Ergebnis wird ein One-Time-Passwort geliefert.
Der Account Manager MUSS die Operation setTID implementieren, bei der die Authentisierung mit der neuen Smartcard erfolgt. Als Nachweis für die Benutzung der bisherigen und der neuen Smartcard muss das One-Time-Passwort als Eingangsparameter verwendet werden.
[<=]

A_21379-01 - Aktualisierung der Telematik-ID im Verzeichnisdienst

Der Account Manager MUSS die vom Nutzer verwendete E-Mail-Adresse (KOM-LE-Fachdaten) des KOM-LE-Teilnehmers bei Aufruf der Operation setTID aus dem Verzeichnisdiensteintrag der bisherigen Telematik-ID entfernen und an die neue Smartcard verknüpfen. Ist die verwendete E-Mail-Adresse mit dem Standard Anwendungskennzeichen versehen, dann MUSS die Verknüpfung mit der neuen Smartcard abgelehnt werden und das Clientmodul ist mit dem Fehlercode 424 zu informieren.
[<=]

A_21531 - Eindeutige Zuordnung von KOM-LE Adressen zu VZD-Einträgen

Der Account Manager MUSS sicherstellen, dass jede KOM-LE Adresse nur an maximal einen VZD-Eintrag angehängt wird. Hierzu MUSS er vor einer Eintragung einer KOM-LE Adresse prüfen, ob diese bereits im VZD hinterlegt ist. Ist sie bereits hinterlegt, so verwendet er Fehlercode 500.
[<=]

A_24038 - KIM FD, eingeschränkte Befüllung der mail Attribute im VZD-Eintrag

Der Account Manager MUSS für die Operationen registerAccount und setAccount der Schnittstelle I_AccountManager_Service den Parameter "noVzdMailEntry" auswerten und wie folgt berücksichtigen:
Wenn "noVzdMailEntry" == true, dann wird im VZD-Eintrag die KIM-Adresse nur das Attribut "kimData" befüllt.

• Operation registerAccount (I_Directory_Application_Maintenance, add_Directory_FA-Attributes, noVzdMailEntry = true)
• Operation setAccount (I_Directory_Application_Maintenance, modify_Directory_FA-Attributes, noVzdMailEntry = true)

A_22413-02 - Account Manager – Implementierung der Schnittstelle

Die Teilkomponente Account Manager des Fachdienstes MUSS die Schnittstelle I_AccountLimit_Service als REST-Webservice über HTTPS gemäß [AccountLimit.yaml] in der Version 1.1.3 implementieren. Des Weiteren MUSS der Account Manager für alle in der [AccountLimit.yaml] definierten Operationen den Zeichensatz UTF-8 unterstützen.
[<=]

A_22420-01 - I_AccountLimit_Service – TLS-gesicherte Verbindung

Die Teilkomponente Account Manager des Fachdienstes MUSS die Schnittstelle I_AccountLimit_Service durch Verwendung von TLS mit serverseitiger Authentisierung sichern. Die Teilkomponente Account Manager des Fachdienstes MUSS für diese TLS-Verbindungen TI-Zertifikate (analog zu Schnittstelle I_Message_Service) nutzen. Die Teilkomponente Account Manager des Fachdienstes MUSS sich mit der Server-Identität von Schnittstelle I_AccountLimit_Service authentisieren.

[<=]

A_22414 - Account Manager - HTTP-Basic-Authentifizierung

Der Account Manager MUSS bei Aufruf der Operation getLimits eine HTTP-Basic-Authentifizierung durchführen.
[<=]

A_23753 - Implementierung der Schnittstelle I_ServiceInformation

Der KOM-LE-Fachdienst MUSS die Schnittstelle I_ServiceInformation als REST-Webservice über HTTPS gemäß [ServiceInformation.yaml] in der Version 1.0.2 implementieren. Des Weiteren MUSS der KOM-LE-Fachdienst für alle in der [ServiceInformation.yaml] definierten Operationen den Zeichensatz UTF-8 unterstützen.
[<=]

A_23754 - I_ServiceInformation – TLS-gesicherte Verbindung

Der KOM-LE-Fachdienst MUSS die Schnittstelle I_ServiceInformation durch Verwendung von TLS mit serverseitiger Authentisierung sichern. Der KOM-LE-Fachdienst MUSS für diese TLS-Verbindungen TI-Zertifikate (analog zu Schnittstelle I_Message_Service) nutzen. Der KOM-LE-Fachdienst MUSS sich mit der Server-Identität von Schnittstelle I_ServiceInformation authentisieren. [<=]

KOM-LE-A_2231-01 - Schnittstellen der TI-Plattform

Der Fachdienst KOM-LE MUSS die in der Tabelle Tab_Interface_TIP aufgeführten Schnittstellen der TI-Plattform benutzen. [<=]

A_20189-02 - Übermittlung der benötigten KOM-LE Version des Clientmoduls

Der Anbieter des KOM-LE-Fachdienstes MUSS seinem KOM-LE Teilnehmer bei der Erstellung des Accounts sowie bei einem  relevanten Update des Fachdienstes, die nötige KOM-LE-Version des Clientmoduls mitteilen.
[<=]

KOM-LE-A_2171 - Skalierbarkeit KOM-LE-Fachdienst

Der KOM-LE-Fachdienst MUSS mit einer zunehmenden Anzahl von beteiligten Teilnehmern skalieren.