Version
      
1.11.1
     
     

      
Revision
      
548770
     
     

      
Stand
      
18.12.2020
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_FD_KOMLE
     
    

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.
[<=]

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. [<=]

KOM-LE-A_2132 - Identifikation der Originalnachricht

Zur Identifikation der Originalnachricht MUSS eine entsprechend Delivery Status Notification erzeugte Nachricht den Empfänger und das Versanddatum der Ursprungsnachricht enthalten. [<=]

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

Der Mail Server SOLL eine Autoreply-Funktionalität für das Versenden von Abwesenheitsnotizen nach RFC5230 unterstützen.

[<=]

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

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

[<=]

KOM-LE-A_2224 - Einstellen von Abwesenheitsnotizen

Der Mail Server SOLL es dem Nutzer ermöglichen, Abwesenheitsnotizen 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_20978 - 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. [<=]

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 - Eintrag Clientmodul-Version in VZD, Account Manager

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

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

Der KOM-LE-Fachdienst MUSS die aufgeführten Resource Records Types im Namensraum der TI gemäß folgender Tabelle verwalten.

Tabelle 1: Tab_KOMLE_Service Discovery

Resource Record Bezeichner	Resource Record Type	Beschreibung
_accmgr._tcp.kim.telematik	PTR	Ermittlung aller Account Manager Dienste aller KOM-LE-Anbieter.
<accmgr_service_name>.<hrst_domain>.kim.telematik	SRV  und TXT	SRV Resource Record zur Ermittlung der Ports und des  FQDN des Accout Managers
_kas._tcp.kim.telematik	PTR	Ermittlung aller KAS-Dienste aller KOM-LE-Anbieter.
<kas_service_name>.<hrst_domain>.kim.telematik	SRV  und TXT	SRV Resource Record zur Ermittlung der Ports und des  FQDN des KAS

[<=]

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

Resource Record Typ	Beschreibung
FQDN	A Resource Records zur Namensauflösung von FQDN des KOM-LE-Fachdienstes des jeweiligen Anbieters in IP-Adressen

[<=]

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.
[<=]

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 - 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 - ECC-Migration, Unterstützung verschiedener kryptografischer Verfahren bei der TLS-Verwendung

Der Fachdienst KOM-LE MUSS parallel RSA und ECC unterstützen. Als TLS-Client MUSS der Fachdienst KOM-LE bevorzugt ECC verwenden, falls er auf einen TLS-Server, der beide Verfahren unterstützt, trifft. [<=]

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

Die Schnittstelle kann sowohl seitens des KOM-LE-Clientmoduls als auch eines anderen KOM-LE-Fachdienstes (nur send_Message Operation) aufgerufen werden. Erfolgt der Aufruf der Operation send_Message durch einen anderen Fachdienst, entfällt der Parameter Anmeldedaten.
[<=]

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 - Zuordnung TLS-Client-Zertifikat für Clientmodul

Der KOM-LE-Anbieter 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.

[<=]

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

Der KOM-LE-Anbieter 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_2142 - Ports der Schnittstelle I_Message_Service

Die Schnittstelle I_Message_Service MUSS folgende Ports benutzen:

• SMTPS: 465 und
  
• POP3S: 995.
  

[<=]

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.
  

Die Reihenfolge ist empfohlen z. B. hinsichtlich wirtschaftlicher Umsetzbarkeit (Offline-Schritte vor Online-Schritten), aber nicht zwingend vorgegeben. Vorbedingung für die Zertifikatsprüfung ist, dass eine validierte TSL in Form eines Trust Stores vorliegt.
[<=]

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-01 - Generierung von Zustellbestätigungen

Erhält der 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
  
• Empfangszeitpunkt im Header Feld Arrival-Date 
• Message-ID der äußeren Nachricht im Header Feld In-Reply-To

[<=]

A_20771 - 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-KGerr mit den Werten aus der folgenden Tabelle befüllen.

Tabelle 6 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

[<=]

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-01 - 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-KGerr 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-KGerr 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 - 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 der Löschfrist der jeweiligen Nachricht zum Abrufen bereit halten und dann löschen.

[<=]

A_19375-01 - KAS – Implementierung der Schnittstelle

Der KAS MUSS die Schnittstelle I_Attachment_Services als REST-Webservices über HTTPS gemäß [AttachmentServices.yaml] in der Version 1.1.0 implementieren.
[<=]

A_19377 - KAS – TLS-gesicherte Verbindung

Der KAS MUSS die Schnittstelle I_Attachment_Services 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_Services authentisieren.
[<=]

A_19378 - KAS – Dokumentengröße prüfen

Der KAS MUSS die Dateigröße jedes übergebenen Dokumentes ermitteln, bevor das Dokument gespeichert wird. Der KAS MUSS die Verarbeitung ablehnen, wenn die Gesamtgröße des Dokumentes diesen Konfigurationswert des KAS übersteigt. [<=]

A_19519-01 - KAS – Maximale Mailgröße bereitstellen

Der KAS MUSS seinen Clients die maximale Gesamtgröße einer Mail mit Operation read_MaxMailSize bereitstellen. Dieser Wert MUSS konfigurierbar sein. Der Wert für die Gesamtgröße einer Mail MUSS mindestens 500 MB betragen.
[<=]

A_19379 - KAS – Dokumentenzugriff

Der KAS MUSS sicherstellen, dass nur über den dazugehörigen Freigabelink auf das Dokument zugegriffen werden kann. [<=]

A_19380 - KAS – Erzeugung Freigabelink

Der KAS MUSS bei Aufruf der REST-Operation add_Attachment einen Freigabelink erzeugen, die aus dem FQDN der Teilkomponente KAS und einer zufälligen und eindeutigen ID der Ressource (Anhang) 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_19384 - KAS – Sicher gegen Datenverlust

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

A_19385 - KAS – Löschen von Ressource

Der Anbieter des KAS MUSS sicherstellen, dass alle gespeicherten Anhänge gemäß der in [KOM-LE-A_2139] definierten Löschfrist von Nachrichten zu löschen sind.
[<=]

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. [<=]

A_20063 - 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] implementieren.
[<=]

A_20064 - Account Manager - TLS-gesicherte Verbindung

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

KOM-LE-A_2187-01 - Authentifizierung des KOM-LE-Teilnehmers über AUT-Zertifikat am AccountManager

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 des Teilnehmers prüfen. Über die aus dem AUT-Zertifikat ermittelte Telematik-ID ist anschließend der Zugriff auf den Verzeichnisdienst möglich.
Der Fachdienst MUSS vor Ausführung der angefragten HTTP-Methoden den Client erfolgreich über sein AUT-Zertifikat authentisieren. Hierzu MUSS folgende Authentisierungsmethode verwendet werden:
Der Client MUSS eine zufällige 256bit Nonce und einen Unix-Timestamp in die Nachricht einfügen. Die Parameterinhalte der Nachricht müssen zu einem String zusammengefügt werden (in der Reihenfolge der Parameter Beschreibung der Operationen in der Datei [AccountManager.yaml]). Von diesem String MUSS der Hash entsprechend A_19644 [gemSpec_Krypt] gebildet werden. Dieser Hash MUSS mittels der externalAuthenticate Funktion des Konnektors mit dem AUT-Zertifikat des HBA bzw. der SMC-B signiert werden. Als Signature Type MUSS PKCS#1-Signatur gewählt werden (und nach Unterstützung durch alle Konnektoren ECDSA-Signatur). Diese Signatur MUSS ebenfalls in die Nachricht eingefügt werden.
Der Fachdienst MUSS eine Ablaufzeitspanne für I_AccountManager_Service Nachrichten konfigurieren, empfohlen sind 5min. Der Fachdienst MUSS eine Liste mit genutzten Nonces und Zeitstempel pro Nutzer führen. Ein Timestamp und auch die assoziierte Nonce sind zum Zeitpunkt Timestamp+Ablaufzeitspanne abgelaufen.
Bei Erhalt einer Nachricht MUSS der Fachdienst zunächst prüfen

• ob der Timestamp noch gültig ist, also vor weniger Zeit als der Ablaufzeitspanne erzeugt wurde,
• ob der signierte Hash korrekt ist
• ob Username und Passwort korrekt sind
• ob Username zu dem AUT-Zertifikatsinhaber (die Zuordnung von Zertifikat zu mail-Adresse ist durch den VZD Eintrag gegeben) passt und
• ob die Nonce noch nicht in der Liste für diesen Nutzer vorhanden ist.

Ist eine dieser Prüfungen nicht erfolgreich MUSS die Nachricht zurückgewiesen werden. Sind alle Prüfungen erfolgreich, ist die Nachricht valide und MUSS verarbeitet werden. Der Fachdienst MUSS die erhaltene Nonce einer validen Nachricht in die Nonceliste für den jeweiligen Nutzer aufnehmen. Der Fachdienst MUSS nur Nonces aus validen Nachrichten speichern. Nonces MÜSSEN so lange gespeichert werden, bis sie abgelaufen sind.
[<=]

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.
[<=]

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 - 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 vor der Registrierung eines Nutzers zur Verfügung stehen. [<=]

KOM-LE-A_2167-02 - Sperrung des Accounts

Der Fachdienst KOM-LE MUSS den Account eines Teilnehmers nach drei aufeinanderfolgenden Fehleingaben des Passwortes temporär gegen Brute-Force Angriffe schützen. Hierzu wird 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. Für jeden weiteren Log-In Versuch erhöht sich diese Wartezeit exponenziell bis zu einem festen Maximalwert. Steigungsfaktor und Maximalwert MÜSSEN geeignet gewählt werden. [<=]

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 - Bereitstellung Schlüssel und Zertifikat für Clientmodul als passwortgeschützte PKCS#12 Datei

Der KOM-LE-Anbieter MUSS dem KOM-LE-Teilnehmer das Schlüsselmaterial und das Zertifikat für das KOM-LE-Clientmodul im Registrierungsprozess als passwortgeschützte PKCS#12-Datei zur Verfügung stellen. Die Übermittlung des zur p12-Datei gehörigen Passworts muss über eine verschlüsselte, authentifizierte und integritätsgeschützte Verbindung übertragen werden.
[<=]

A_19542 - Schnittstelle für den Download

DerAccount Manager MUSS eine Operation für das Herunterladen der PKCS#12-Datei bereitstellen.
[<=]

KOM-LE-A_2231 - Schnittstellen der TI-Plattform

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

[<=]

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

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

[<=]