TIP1-A_3949 - Veröffentlichungspflicht und kritische Informationen

Der Anbieter des TSL-Dienstes MUSS geschäftskritische Informationen, wie z. B. eine Betriebseinstellung, unverzüglich gegenüber der gematik bekannt geben.

TIP1-A_3950 - Mitteilungspflicht bei Änderungen

Der Anbieter des TSL-Dienstes MUSS unverzüglich Änderungen an der Architektur und den organisatorischen Abläufen gegenüber der gematik bekannt geben, sofern die Sicherheit verringert oder das Außenverhalten verändert wird.

TIP1-A_3951 - Vorlage der technischen Dokumentation und des Betriebskonzepts bei der gematik

Der Anbieter des TSL-Dienstes MUSS nach Aufforderung der gematik technisch relevante Dokumentationen, das Sicherheitskonzept und das Betriebskonzept zur Prüfung durch die gematik vorlegen.

TIP1-A_3953 - Anzeige von Änderung an der Gesellschafterstruktur des Betreibers

Der Anbieter des TSL-Dienstes MUSS jede Änderung an seiner Gesellschafterstruktur unverzüglich der gematik anzeigen.

TIP1-A_3954 - Obligatorische Vorgaben für das Rollenkonzept

Der Anbieter des TSL-Dienstes MUSS sein Rollenkonzept umsetzen, und die operative Umsetzung der Vorgaben im Rahmen seines betreiberspezifischen Sicherheitskonzepts darlegen.

TIP1-A_3955 - Revisionssicherheit der Protokollierung

Der Anbieter des TSL-Dienstes MUSS seine Arbeit durch eine revisionssichere Protokollierung gemäß den gesetzlichen und vertraglichen Regelungen nachweisen.

TIP1-A_3956 - Bereitstellung der Protokollierungsdaten

Der Anbieter des TSL-Dienstes MUSS auf Antrag der gematik Einblick in die revisionssichere Protokollierung gewähren.

TIP1-A_5782 - Schlüsselbackup bei der gematik

Der Anbieter des TSL-Dienstes MUSS der gematik das Schlüsselmaterial, welches für das Ausstellen von TSL-Signer-Zertifikaten notwendig ist, gemäß dem zwischen BSI und gematik abgestimmten Verfahren übergeben. 

TIP1-A_3957 - Standort für Backup-HSM

Der Anbieter des TSL-Dienstes MUSS das Backup-HSM an einem sicheren Ort außerhalb des primären Standorts aufbewahren.

TIP1-A_3958 - Verwendung des HSM gemäß Vier-Augen-Prinzip

Der Anbieter des TSL-Dienstes MUSS in seinem betreiberspezifischen Sicherheitskonzept beschreiben, wie sichergestellt wird, dass ein Zugriff auf das Backup-HSM und sein Freischalten im Rahmen des Einbringens in das eigentliche Produktivsystem nur unter Wahrung des Vier-Augen-Prinzips möglich ist.

TIP1-A_3959 - Backup-Konzept

Der Anbieter des TSL-Dienstes MUSS für die im Rahmen des Betriebs benötigte Hardware, Software und den Datenbestand ein Backup-Konzept erstellen und umsetzen.

TIP1-A_3960 - Besetzung von Rollen und Informationspflichten

Der Anbieter des TSL-Dienstes MUSS eine Rollenzuordnung erstellen und umsetzen, so dass zu jeder der relevanten Rollen mindestens ein verantwortlicher Mitarbeiter sowie ein Stellvertreter benannt werden und die Rollenzuordnung initial und fortlaufend bei Änderungen der gematik mitgeteilt wird.

TIP1-A_3961 - Durchgängige Verfügbarkeit spezifischer Rollen

Der Anbieter des TSL-Dienstes MUSS eine Rollenzuordnung derart umsetzen, dass zu jedem Zeitpunkt der festgelegten Betriebszeit für jede der relevanten Rollen mindestens ein für diese Rolle verantwortlicher Mitarbeiter bzw. sein Stellvertreter kurzfristig (höchstens eine Stunde Wartezeit) erreichbar sind.

TIP1-A_3962 - Rollenzuordnung unter Wahrung der Vier-Augen-Prinzips

Der Anbieter des TSL-Dienstes MUSS bei der Zuordnung von Rollen zu Personen (für Aktivitäten mit gefordertem Vier-Augen-Prinzip) gewährleisten, dass eine einzelne Person nicht zwei Rollen ausübt und somit Zugriffe auf das HSM unter Umgehung des Vier-Augen-Prinzips für diese einzelne Person ermöglicht werden.

TIP1-A_3963 - Nutzung des HSM im kontrollierten Bereich

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass das zu realisierende System einschließlich der HSM in einem kontrollierten Bereich der Betriebsstätte untergebracht ist und dass der Zugang zu diesem Bereich nur für berechtigte Personen möglich ist.

TIP1-A_3964 - Zugang zu Systemen für die TSL-Erzeugung

Der Anbieter des TSL-Dienstes MUSS im Rahmen der Zugangskontrolle gewährleisten, dass den Mitarbeitern der gematik bzw. durch die gematik beauftragten Personen nach Ankündigung (ggf. in Begleitung eines Mitarbeiters des Betreibers des TSL-Dienstes) Zugang zu den für die TSL-Erzeugung im Kontext der TI-relevanten Systemen gewährt wird und genaue Regelungen (Vorlaufzeit für die Ankündigung, Mitteilung der berechtigten Personen) festlegen.

TIP1-A_3967 - Vorgaben für die informationstechnische Trennung sicherheitskritischer Bestandteile der Systemumgebung

Der Anbieter des TSL-Dienstes MUSS sicherheitskritische Bestandteile der Systemumgebung informationstechnisch trennen. Falls eine Online-Verbindung zu den sicherheitskritischen Bestandteilen der Systemumgebung besteht, muss durch technische Maßnahmen sichergestellt werden, dass schreibende Zugriffe auf sicherheitskritische Systembestandteile unterbunden werden.

TIP1-A_3968 - Manipulationsschutz veröffentlichter Daten

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass die Internetseite zur Bereitstellung der öffentlichen Schlüssel sowie der File- bzw. Web-Server für den Download der Dateien vor Manipulationen entsprechend dem BSI-Grundschutz-Baustein B 5.4 "Webserver" geschützt wird.

TIP1-A_3969 - Vorgaben zur Betriebsumgebung für sicherheitskritische Bestandteile des Systems

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass sicherheitskritische Bestandteile des Systems in einem kontrollierten Bereich betrieben werden.

TIP1-A_3970 - Gewährleistung des Zugangs zur Betriebsstätte

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass Vertreter der gematik auf Antrag uneingeschränkten Zugang zu den Teilen der Betriebsstätte haben, die für den Betrieb im Kontext der TI relevant sind.

TIP1-A_5382 - Zugang zu HSM-Systemen im Vier-Augen-Prinzip

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass alle Zugriffe auf das HSM und die direkt zur Administration des HSM verwendeten IT-Systeme im Vier-Augen-Prinzip erfolgen.

TIP1-A_3971 - Organisatorische Trennung von anderen Rollen in TI

Der Anbieter des TSL-Dienstes MUSS eine klare organisatorische Trennung zwischen seinen verschiedenen Aufgaben und Rollen mit Interessenskonfliktpotential in der TI gemäß Beurteilung des Sicherheitsbeauftragten umsetzen und dokumentieren.

TIP1-A_3972 - Rollenunterscheidung im organisatorischen Konzept

Der Anbieter des TSL-Dienstes MUSS in seinem Organisationskonzept die relevanten Rollen unter Beachtung von Tab_PKI_702 unterscheiden.

TIP1-A_3973 - Mitteilungspflicht für Zuordnung der Rollen

Der Anbieter des TSL-Dienstes MUSS die Belegung der Rollen mit ihren benannten Mitarbeitern der gematik mitteilen.

TIP1-A_3974 - Obligatorisches 4-Augen-Prinzip für sicherheitsrelevante Tätigkeiten

Der Anbieter des TSL-Dienstes MUSS die Rollenzuordnung der folgenden Tätigkeiten gemäß dem Vier-Augen-Prinzip umsetzen:    
(a) Sämtliche HSM-Operationen für TSL-Signer-CA und TSL-Signer    
(b) Schlüssellebenszyklus-Operationen für OCSP-Responder    
(c) Schlüsselhinterlegung        
(d) Ausstellen des TSL-Signer-Zertifikats    
(e) Sperren des TSL-Signer-Zertifikats    
(f) Technische Vergabe von Berechtigungen    
(g) Registrierungsdienst    
(h) TSL-Eintrags-Dienst

TIP1-A_3975 - Ausschluss von Rollenzuordnungen

Der Anbieter des TSL-Dienstes MUSS bei der Aufteilung der Rollen auf Mitarbeiter unter Beachtung von Tab_PKI_702 und Tab_PKI_703 sicherstellen, dass einer Person keine miteinander unverträglichen Rollen zugewiesen werden.

TIP1-A_3976 - Anforderungen an den Einsatz freier Mitarbeiter

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass freie Mitarbeiter die gleichen Sicherheitsanforderungen erfüllen, wie festangestellte Mitarbeiter.

TIP1-A_3977 - Einsicht in Dokumente für Mitarbeiter

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass seine Mitarbeiter in    
(a) das betreiberspezifische Betriebskonzept,     
(b) das Rollenkonzept,    
(c) das betreiberspezifische Sicherheitskonzept,     
(d) die Prozessbeschreibungen und Formulare für den regulären Betrieb,     
(e) die Verfahrensanweisungen für den Notfall,     
(f) die Dokumentation der IT-Systeme,     
(g) die Bedienungsanleitungen für die eingesetzte Software und     
(h) die Datenschutzerklärung (falls vorhanden)    
Einsicht erhalten.

TIP1-A_3978 - Aufzeichnung von technischen Ereignissen

Der Anbieter des TSL-Dienstes MUSS die folgenden technischen Ereignisse protokollieren:
(a) Bootvorgänge der Hardware,     
(b) Installation und Konfiguration von Software,     
(c) Fehlgeschlagene Login-Versuche,     
(d) Durchführung von Änderungen an Zugriffsrechten    

TIP1-A_3979 - Aufzeichnung von organisatorischen Ereignissen

Der Anbieter des TSL-Dienstes MUSS die folgenden organisatorischen Ereignisse protokollieren:
(a) Vergabe und Entzug von Berechtigungen,    
(b) Änderungen des betreiberspezifischen Betriebshandbuches und der korrespondierenden Richtlinien,    
(c) Änderungen an Rollendefinitionen,    
(d) Änderungen an Prozessbeschreibungen,    
(e) Wechsel von Verantwortlichkeiten,    
(f) Ausscheiden von Mitarbeitern

TIP1-A_3980 - Protokollierung wichtiger TSL-spezifischer Ereignisse

Der Anbieter des TSL-Dienstes MUSS mindestens die folgenden wichtigen TSL-spezifischen Ereignisse protokollieren:    
(a) Das Generieren eines neuen Schlüsselpaares    
(b) Die Aktivierung eines Schlüsselpaares    
(c) Das Generieren, Signieren und Bereitstellen einer neuen TSL    
(d) Das Generieren eines neuen TSP Eintrags, Signieren und Bereitstellen der TSL

TIP1-A_3981 - Protokollierung wichtiger TSL-spezifischer Ereignisse: Angaben

Der Anbieter des TSL-Dienstes MUSS für die wichtigen TSL-spezifischen Ereignisse mindestens die folgenden Angaben protokollieren:    
(a) Das Datum des Auftrags der gematik    
(b) Angaben zur eindeutigen Identifizierung aller an den Schritten und Teilschritten der Ereignisse beteiligten Personen    
(c) Das technische Ergebnis eines Ereignisses

TIP1-A_3982 - Aufbewahrungsfrist für Protokolldaten

Der Anbieter des TSL-Dienstes MUSS Protokolldaten mindestens entsprechend den gesetzlichen und vertraglichen Regelungen aufbewahren.

TIP1-A_3983 - Schutz vor Zugriff, Löschung und Manipulation elektronischer Protokolldaten

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass Protokolldaten trotz privilegierter Berechtigungen der System- und Netzadministratoren gegen unberechtigten Zugriff, Löschung und Manipulation dauerhaft geschützt werden.

TIP1-A_3984 - Archivierung: Relevante Daten

Der Anbieter des TSL-Dienstes MUSS eine sichere Archivierung aller relevanten Daten im Betriebsprozess realisieren. Dazu gehören:    
(a) Alle Versionen der TSL,    
(b) Alle Anträge, Aufträge und Registrierungsunterlagen von der gematik,    
(c) Zertifikate des Anbieters des TSL-Dienstes und    
(d) Protokolldaten.

TIP1-A_3985 - Dokumentationspflicht für Prozesse zum Schlüsselwechsel

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass der Schlüsselwechsel anhand dokumentierter Prozesse erfolgt.

TIP1-A_3986 - Aktionen und Verantwortlichkeit im Rahmen der Notfallplanung

Der Anbieter des TSL-Dienstes MUSS im Rahmen der Notfallplanung gewährleisten, dass    
(a) für den Fall einer Kompromittierung oder eines Desasters Prozesse zur Aufrechterhaltung des Betriebs dokumentiert werden und    
(b) die Bewertung der Sicherheitslage durch den Sicherheitsbeauftragten vollzogen wird.

TIP1-A_3987 - Herausgabe des Schlüsselmaterials

Der Anbieter des TSL-Dienstes MUSS bei der ungeplanten Einstellung seines Betriebes das für den Betrieb erforderliche Schlüsselmaterial in Form des HSMs herausgeben. Dabei MUSS er die Autorisierung der berechtigten Mitarbeiter der gematik prüfen. Der Prozess dieser Prüfung MUSS in seinem betreiberspezifischen Sicherheitskonzept dokumentiert sein. Der Anbieter des TSL-Dienstes MUSS bei einer Herausgabe des Schlüsselmaterials die darin beschriebenen Schritte durchführen.

TIP1-A_3988 - Bewilligung der Herausgabe der Schlüsselmaterials

Der Anbieter des TSL-Dienstes DARF NICHT ohne schriftlichen Antrag der gematik eine Herausgabe des Schlüsselmaterials der TSL-Signer-CA durchführen.

TIP1-A_3989 - Anzeigepflicht bei Beendigung der Dienstleistungen

Der Anbieter des TSL-Dienstes MUSS die Beendigung seiner Dienstleistungen im Kontext der TI als Prozess dokumentieren und die Beendigung seiner Dienstleistungen der gematik unverzüglich anzeigen.

TIP1-A_3990 - Fortbestand von Archiven und die Abrufmöglichkeit aller TSL-Dateien und Zertifikate

Der Anbieter des TSL-Dienstes MUSS den Fortbestand der Archive und die Abrufmöglichkeit aller ausgestellten TSL-Dateien sowie aller verwendeten Zertifikate für den zugesicherten Aufbewahrungszeitraum sicherstellen.

TIP1-A_3991 - Fristen bei Einstellung des Betriebs

Der Anbieter des TSL-Dienstes MUSS die mit der gematik vereinbarte Ankündigungsfrist bei der Einstellung des Betriebs einhalten.

TIP1-A_3992 - Erforderliche Form bei Einstellung des Betriebs

Der Anbieter des TSL-Dienstes MUSS die Einstellung des Betriebs schriftlich gegenüber der gematik ankündigen.

TIP1-A_3993 - TSL-Signer-CA offline

Der Anbieter des TSL-Dienstes MUSS die TSL-Signer-CA vollständig offline initialisieren und betreiben.

TIP1-A_3994 - Schlüsselverwaltung: zwingend unterschiedliche Schlüssel für unterschiedliche Entitäten

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass TSL-Signer-CA, TSL-Signer und OCSP-Responder nicht dasselbe Schlüsselpaar verwenden.

TIP1-A_3995 - Beachtung des betreiberspezifischen Sicherheitskonzepts bei der Erzeugung von Schlüsselpaaren

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass die technischen Sicherheitsmaßnahmen zur Erzeugung und Installation von Schlüsselpaaren die Rahmenbedingungen des eigenen, betreiberspezifischen Sicherheitskonzeptes erfüllen und sich am aktuellen Stand der Technik orientieren.

TIP1-A_3996 - Sicherheitsniveau bei der Generierung von Signaturschlüsseln

Der Anbieter des TSL-Dienstes MUSS Signaturschlüssel in einem von einer akkreditierten Evaluierungsstelle geprüften HSM oder alternativ in einer Chipkarte mit vergleichbarer geforderter Zertifizierungstiefe erzeugen.

TIP1-A_3997 - Verwendung eines Backup-HSM zum Im-/Export von privaten Schlüsseln

Der Anbieter des TSL-Dienstes MUSS ein Backup-HSM zum sicheren Export bzw. Import von privaten Schlüsseln verwenden, wobei zu beachten ist:    
(a) Primäres HSM und Backup-HSM MÜSSEN die gleichen Sicherheitsanforderungen erfüllen,     
(b) zwischen primärem HSM und Backup-HSM MUSS ein kryptographisch gesicherter Transportkanal hergestellt werden, um den privaten Schlüssel aus dem einen HSM sicher zu exportieren und in das andere HSM zu importieren.

TIP1-A_3998 - Unterstützung des sicheren Löschen von Schlüsseln durch HSM

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass alle eingesetzten HSM eine Funktion unterstützen, mit der ein vorhandenes Schlüsselpaar innerhalb des HSM sicher gelöscht werden kann, wobei der sichere Löschvorgang durch ein Überschreiben mit einem vorgegebenen Wert oder durch das interne dauerhafte Sperren aller Zugriffe auf den Schlüssel realisiert werden kann.

TIP1-A_3999 - Generieren und Löschen von Schlüsselpaaren gemäß Vier-Augen-Prinzip

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass das Generieren eines neuen Schlüsselpaares und das Löschen eines Schlüsselpaares nur nach erfolgreicher, gemeinsamer Authentisierung zweier hierfür autorisierter Nutzer (Vier-Augen-Prinzip) durch das Verifizieren einer PIN oder ein gleichwertiges Verfahren ausführbar sind.

TIP1-A_4000 - Berechnungen mit dem privaten Schlüssel gemäß Vier-Augen-Prinzip

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass alle kryptographischen Berechnungen mit dem privaten Schlüssel für das Erstellen eines Zertifikats innerhalb des HSM erfolgen, wobei das HSM diese Berechnungen nur nach erfolgreicher, gemeinsamer Authentisierung zweier hierfür autorisierter Nutzer (Vier-Augen-Prinzip) durch das Verifizieren einer PIN oder ein gleichartiges Verfahren durchführen darf.

TIP1-A_4001 - Protokollierung der HSM-Nutzung

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass die Nutzung des HSM revisionssicher protokolliert wird, insbesondere welche Rolle/Person zu welchem Zeitpunkt für welche Funktion das HSM genutzt hat und für welche Profile das HSM konfiguriert ist.     Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass auch die Nutzung und die Übergabe zur Verwahrung des Backup-HSM revisionssicher protokolliert werden.

TIP1-A_4002 - Berücksichtigung des aktuellen Erkenntnisstands bei der Generierung von Schlüsseln

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass bei der Generierung von Schlüsseln jeweils der aktuelle Stand der Technik berücksichtigt wird.

TIP1-A_4003 - Anlass für den Wechsel von Schlüsselpaaren

Der Anbieter des TSL-Dienstes MUSS die verwendeten Schlüsselpaare der TSL-Signer-CA, des TSL-Signers und des OCSP-Responders auswechseln, wenn    
(a) organisatorische Regelungen der gematik dies erfordern,    
(b) die maximale Verwendungsdauer für ein Schlüsselpaar erreicht wurde und    
(c) wenn ein aktuell verwendetes Schlüsselpaar kompromittiert wurde.

TIP1-A_4005 - Sicherung des privaten Schlüssels

Der Anbieter des TSL-Dienstes MUSS die Sicherung des privaten Schlüssels nach dem aktuellen Stand der Technik gewährleisten und die Anforderungen an kryptographische Module im Rahmen ihres betreiberspezifischen Sicherheitskonzeptes definieren.

TIP1-A_4006 - Verwendung von privaten Schlüsseln

Der Anbieter des TSL-Dienstes MUSS gewährleisten, dass    
(a) alle kryptographischen Berechnungen mit einem privaten Schlüssel intern in einem Hardware-Sicherheitsmodul (HSM) durchgeführt werden und    
(b) private Schlüssel des Anbieters des TSL-Dienstes nicht im Klartext aus dem HSM exportiert werden.

TIP1-A_4007 - Vorgaben an HSM-Funktionalität

Der Anbieter des TSL-Dienstes MUSS Hardware-Sicherheitsmodule (HSM) einsetzen, die mindestens Funktionen    
(a) zur Generierung eines neuen Schlüsselpaares,    
(b) zur Aktivierung eines Schlüsselpaares,    
(c) zum kryptographisch abgesicherten Import und Export eines privaten Schlüssels,    
(d) zum sicheren (physikalischen) Löschen eines Schlüsselpaares,    
(e) zur m-von-n-Aktivierung und    
(f) zum Erstellen eines Zertifikats mit interaktiv einzugebenden Zertifikatsdaten beinhalten.

TIP1-A_4008 - Speicherung und Auswahl von Schlüsselpaaren im HSM

Der Anbieter des TSL-Dienstes MUSS ein Hardware-Sicherheitsmodul (HSM) einsetzen, das mehrere Schlüsselpaare speichern kann und über eine Funktion zur Aktivierung eines einzelnen, spezifischen Schlüsselpaares verfügt, dass nach erfolgter Auswahl zur Erzeugung von Zertifikaten verwendet wird.

TIP1-A_4010 - Vorgaben an die Prüftiefe der Evaluierung eines HSM

Der Anbieter des TSL-Dienstes MUSS für alle eingesetzten Hardware-Sicherheitsmodule (HSM) sicherstellen, dass diese nach einer der folgenden Kombinationen aus Evaluierungsschema und Prüftiefe (sowie einem fachlich geeignetem Schutzprofil) oder einem äquivalenten Zertifizierungsstandard evaluiert wurden:    
(a) FIPS 140-2 Level 3,    
(b) CC EAL4+ mit Prüfung gegen hohes Angriffspotenzial oder    
(c) ITSEC E3 der Stärke „hoch“.

TIP1-A_4011 - PKCS#11

Der Anbieter des TSL-Dienstes MUSS die PKCS#11-Kommandos für verschlüsselten Export des Schlüsselmaterials der TSL-Signer-CA unterstützen.

TIP1-A_4012 - Hinterlegung des privaten Schlüssels

Der Anbieter des TSL-Dienstes DARF NICHT den privaten Schlüssel eines Schlüsselpaars ungeschützt bei Dritten hinterlegen.

TIP1-A_4016 - Maximale Gültigkeitsdauer des TSL-Signer-Zertifikats

Der Anbieter des TSL-Dienstes SOLL die Gültigkeitsdauer des TSL-Signer-Zertifikats auf 5 Jahre ansetzen.

TIP1-A_4017 - Sichere Übermittlung von Aktivierungsdaten

Der Anbieter des TSL-Dienstes MUSS Prozesse für die sichere Übermittlung von Aktivierungsdaten definieren und von seinem Sicherheitsbeauftragten bestätigen lassen.

TIP1-A_4018 - Konformität zum betreiberspezifischen Sicherheitskonzept

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass alle Systemkomponenten der PKI bzw. der TSL-Signatur konform zu den Sicherheitsanforderungen seines betreiberspezifischen Sicherheitskonzepts betrieben werden.

TIP1-A_4019 - Härtung von Betriebssystemen

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass alle sicherheitsrelevanten, technischen Abläufe auf Basis gehärteter Betriebssysteme nach IT-Grundschutz-Katalog ([BSI#B3]) ausgeführt werden.

TIP1-A_4027 - Bereitstellung Schnittstelle I_TSL-Management

Der TSL-Dienst MUSS eine technische Schnittstelle I_TSL-Management bereitstellen, welche die TSL-Eintragsanträge (Aufnahme, Änderung oder Löschen eines TSP oder TSP-Dienstes) der gematik entgegennimmt.

TIP1-A_4435 - I_TSL-Management, Zeitstempel

Der TSL-Dienst MUSS die Schnittstelle I_TSL-Management so implementieren, dass diese bei Erhalt eines TSL-Eintragsantrages einen prüffähigen Zeitstempel erstellt.

TIP1-A_4028 - I_TSL-Management, Bestätigung

Der TSL-Dienst MUSS nach erfolgreicher Entgegennahme und nach Verarbeitung eines TSL-Eintragsantrages eine Bestätigung an die gematik senden.

TIP1-A_4030 - Bereitstellung I_TSL-Management:Client

Der Anbieter des TSL-Dienstes MUSS der gematik einen Client für die Schnittstelle I_TSL-Management („I_TSL-Management:Client“) zur Verfügung stellen.

TIP1-A_4031 - I_TSL-Management:Client, TSL-Eintragsanträge

Der I_TSL-Management:Client MUSS sämtliche TSL-Eintragsanträge der gematik an den Anbieter des TSL-Dienstes erzeugen können:    
(a) Hinzufügen    eines neuen TSP und eines dazugehörigen TSP-Dienstes    
(b) Hinzufügen    eines zusätzlichen TSP-Dienstes zu einem bestehenden TSP    
(c) Ändern eines TSP    
(d) Ändern eines TSP-Dienstes    
(e) Löschen eines TSP    
(f) Löschen eines TSP-Dienstes    
(g) Widerruf (auf Status „revoked“ setzen) eines TSP-Dienstes

TIP1-A_4032 - I_TSL-Management:Client, XML-Format

Der I_TSL-Management:Client MUSS die Möglichkeit bieten, die TSL-Eintragsanträge direkt im XML-Format gemäß [ETSI_TS_102_231_V3.1.2#AnhangB] zu erstellen und zu bearbeiten.

TIP1-A_4034 - I_TSL-Management:Client, Qualifizierte Signatur

Der I_TSL-Management:Client SOLL die Funktion anbieten, die TSL-Eintragsanträge qualifiziert elektronisch zu signieren.

TIP1-A_4035 - TSL-Signer-CA-Zertifikat als TSL-Eintrag

Der TSL-Dienst MUSS die aktuelle TSL-Signer-CA als TSP-Dienst in der TSL eintragen.

TIP1-A_4036 - Syntaktische und semantische Prüfung der TSL

Der TSL-Dienst MUSS nach Erstellung der Signatur die Korrektheit der TSL sicherstellen:     
Der TSL-Dienst MUSS eine Prüfung auf Vollständigkeit (Schemaprüfung) durchführen.
Der TSL-Dienst MUSS eine Prüfung auf korrekte Umsetzung der Vorgaben der gematik für inhaltliche Werte durchführen.     
Der TSL-Dienst MUSS eine Signaturprüfung durchführen.

TIP1-A_4037 - Aktualisierungen: Standard und adhoc

Bei der Aktualisierung der TSL-Datei MUSS der Anbieter des TSL-Dienstes zwei verschiedene Prozesse unterstützen:    
(a) Standardaktualisierung    
(b) adhoc-Aktualisierung auf Aufforderung der gematik

TIP1-A_4038 - Standardaktualisierung: periodisch

Die Standardaktualisierung der TSL-Datei MUSS zu konfigurierbaren periodischen Zeitpunkten stattfinden.

TIP1-A_4039 - Standardaktualisierung: Berücksichtigung TSL-Eintragsanträge

Der Anbieter des TSL-Dienstes MUSS bei einer Standardaktualisierung alle TSL-Eintragsanträge der gematik berücksichtigen, die bis zum festgelegten Stichtag eingegangen und noch nicht umgesetzt sind.

Falls keine TSL-Eintragsanträge eingetroffen sind, MUSS der Anbieter des TSL-Dienstes den Aktualisierungsprozess basierend auf den bestehenden Einträgen fortsetzen.

TIP1-A_4042 - Prüfung von TSL-Eintragsanträgen

Der Anbieter des TSL-Dienstes SOLL die mit einem TSL-Eintragsantrag erhaltenen Daten auf Vollständigkeit und Plausibilität (Syntax, Schemavalidierung, erlaubte Werte, Zertifikate etc.) prüfen. Alle korrekten Einträge werden danach in die TSL integriert.

TIP1-A_4043 - Prüfung von Änderungsanträgen

Der Anbieter des TSL-Dienstes MUSS bei Folgeanträgen durch den Vergleich der Betreiberdaten des Ursprungsantrages mit dem Änderungsantrag sicherstellen, dass keine Unstimmigkeiten mit den hinterlegten Informationen vorhanden sind.

TIP1-A_4044 - Prüfung auf ungültige Einträge

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass in der aktuellen Version keine zum Zeitpunkt der TSL-Erstellung abgelaufenen Einträge enthalten sind. Der Anbieter des TSL-Dienstes MUSS abgelaufene Einträge und andere Normabweichungen an gematik melden.
[<=]

TIP1-A_4045 - Übermittlung zur Freigabe

Der Anbieter des TSL-Dienstes MUSS die zu veröffentlichende TSL der gematik zur finalen Freigabe übermitteln.

TIP1-A_4046 - Freigabe vor Veröffentlichung

Der Anbieter des TSL-Dienstes DARF NICHT die TSL ohne Freigabe der gematik veröffentlichen.

TIP1-A_4026 - Service Level

Der Anbieter des TSL-Dienstes MUSS die Produkttyp-spezifischen Service Level für seine Prozesse gemäß Tab_PKI_701 umsetzen.

TIP1-A_4048 - Eintrag in der TSL nach erfolgter Zulassung

Die gematik MUSS den Eintrag eines TSP-Dienstes in der TSL-Datei veranlassen, wenn dieser sämtliche Voraussetzungen dafür erfüllt.

TIP1-A_4438 - TSL-Datei für Testzwecke

Der TSL-Dienst MUSS eine spezifische TSL-Datei erstellen, die den TI-Vertrauensraum für Testzwecke abbildet.

TIP1-A_4439 - Schnittstelle I_TSL-Management für Test

Der TSL-Dienst MUSS eine getrennte Instanz der Schnittstelle I_TSL-Management für Testzwecke implementieren.

TIP1-A_4049 - Prozess für Schlüsselpaargenerierung und Zertifizierung

Der Anbieter des TSL-Dienstes MUSS den Prozess der Schlüsselpaargenerierung und Zertifizierung anstoßen. Der Anbieter des TSL-Dienstes MUSS dies zu einer mit der gematik vereinbarten Frist vor dem Ablauf eines bestehenden Zertifikates tun.

TIP1-A_4440 - Konzept Prozess für Schlüsselpaargenerierung und Zertifizierung

Der Anbieter des TSL-Dienstes MUSS ein Konzept für den Prozess der Schlüsselpaargenerierung und Zertifizierung erstellen.

TIP1-A_4050 - Zertifikatswechsel

Der Anbieter des TSL-Dienstes MUSS zu einem mit der gematik vereinbarten Zeitpunkt den Prozess des Zertifikatswechsels (Erneuerung TSL-Signer-, TSL-Signer-CA- und OCSP-Signer-Zertifikat) anstoßen.    

TIP1-A_4441 - Konzept Zertifikatswechsel

Der Anbieter des TSL-Dienstes MUSS ein Konzept für den Prozess des Zertifikatswechsels (Erneuerung TSL-Signer-, TSL-Signer-CA- und OCSP-Signer-Zertifikat) erstellen.

TIP1-A_4442 - Auftrag für Schlüsselerzeugung TSL-Signer

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass ein neues Schlüsselpaar und das darauf basierende Zertifikat für den TSL-Signer nur im Auftrag der gematik erzeugt werden.

TIP1-A_4051 - Auftrag für Schlüsselerzeugung TSL-Signer-CA und OCSP-Responder

Der Anbieter des TSL-Dienstes MUSS sicherstellen, dass ein neues Schlüsselpaar und der darauf basierende Zertifikats-Request für TSL-Signer-CA und OCSP-Responder nur aufgrund eines geprüften (Authentizität, Autorisierung) Auftrages der gematik erzeugt werden.

TIP1-A_4052 - Auftrag für Schlüsselerzeugung, 2 Mitarbeiter

Der Anbieter des TSL-Dienstes MUSS überprüfen, dass der Auftrag für eine Schlüsselerzeugung der TSL-Signer-CA, des TSL-Signers und des OCSP-Responders durch zwei verantwortliche Mitarbeiter der gematik unterschrieben ist. Er MUSS dabei die Authentizität und Autorisierung dieser Mitarbeiter auf geeignete verlässliche Weise überprüfen.

TIP1-A_4053 - Auftrag für Erzeugung, Inhalt

Der Anbieter des TSL-Dienstes MUSS prüfen, ob der Auftrag der gematik mindestens die folgenden Daten enthält:    
(a) Datum des Auftrags    
(b) Name des verantwortlichen Mitarbeiters 1 der gematik    
(c) Name des verantwortlichen Mitarbeiters 2 der gematik    
(d) Indikator, ob es sich um einen „normalen“ oder einen „notfallmäßigen“ Wechsel bzw. um eine initiale Schlüsselgenerierung handelt    
(e) Vorgabe für die Länge und für den Algorithmus des neuen Schlüsselpaares

TIP1-A_4054 - TI-Vertrauensankerwechsel, Prozess

Der Anbieter des TSL-Dienstes MUSS den TI-Vertrauensankerwechsel (neues TSL-Signer-CA-Zertifikat und spezifischer Eintrag in die TSL) umsetzen können.

TIP1-A_4852 - TI-Vertrauensankerwechsel, Konzept

Der Anbieter des TSL-Dienstes MUSS über ein Konzept verfügen, wie er die folgenden Prozesse rechtzeitig initiiert und korrekt umsetzt:    
(a) Schlüssel- und Zertifikatserneuerung für die TSL-Signer-CA    
(b) Eintragung des neuen TSL-Signer-CA unter TSP-Diensten, markiert als neuer TI-Vertrauensanker
Der Anbieter des TSL-Dienstes MUSS in diesem Konzept die Fristen der jeweiligen Prozessschritte festlegen.

TIP1-A_4443 - TSL-Zertifikate für Testzwecke

Der Anbieter des TSL-Dienstes MUSS pro PKI-Umgebung separate Schlüsselpaare und Zertifikate für die TSL-Signer-CA, den TSL-Signer und seine OCSP-Responder erzeugen.

TIP1-A_4444 - Namen für TSL-Zertifikate für Testzwecke

Der Anbieter des TSL-Dienstes MUSS die Namen (CN: und O:) sämtlicher seiner Zertifikate für Testzwecke entsprechend den korrespondierenden Zertifikatsprofilen der Produktivumgebung verwenden und diese um den String „TEST-ONLY“ im CN-Feld sowie „NOT-VALID“ im O-Feld ergänzen.

TIP1-A_4445 - Profile TSL-Zertifikate für Testzwecke

Der Anbieter des TSL-Dienstes SOLL die Feldattribute (außer CN: und O:) für sämtliche seiner Zertifikate für Testzwecke gemäß den korrespondierenden Profilen der Produktivumgebung setzen.

TIP1-A_4446 - Trennung von Komponenten PU und Test-PKI

Der Anbieter des TSL-Dienstes DARF NICHT ein HSM oder eine andere Komponente aus der Produktivumgebung für die Test-PKI benutzen. Der Anbieter des TSL-Dienstes DARF NICHT ein HSM oder eine andere Komponente aus der Test-PKI für die Produktivumgebung benutzen.

TIP1-A_4055 - Web-Server

Der TSL-Dienst MUSS die Schnittstelle I_TSL_Download und I_BNetzA_VL_Download über einen eigenen, selbstbetriebenen Web-Server zur Verfügung stellen.

TIP1-A_4060 - TSL-Dienst: URIs

Der TSL-Dienst MUSS die URIs, unter denen Produkttypen der TI Dateien herunterladen können, gemäß den Vorgaben für den Namensraum der gematik gestalten.

TIP1-A_5119 - TSL-Dienst: HTTP-Komprimierung unterstützen

Der TSL-Dienst MUSS die Komprimierung der Daten mittels Komprimierung über HTTP „Content Coding“ [RFC7231] mit dem Algorithmus gzip unterstützen.

TIP1-A_5120 - Clients des TSL-Dienstes: HTTP-Komprimierung unterstützen

Clients (Produkttypen der TI, aAdG und aAdG-NetG-TI), die Dateien vom TSL-Dienst herunterladen, SOLLEN die Komprimierung der Daten über HTTP „Content Coding“ [RFC7231] mit dem Algorithmus gzip unterstützen.
[<=]

TIP1-A_4056 - I_TSL_Download: HTTP für TI

Der TSL-Dienst MUSS die Schnittstelle I_TSL_Download gemäß HTTP Version 1.1 [RFC2616] implementieren. Die Schnittstelle MUSS ohne Verwendung des TLS-Protokolls (HTTPS) erreichbar sein.

TIP1-A_4057 - I_TSL_Download: HTTPS für Internet

Der TSL-Dienst MUSS die Schnittstelle I_TSL_Download im Internet gemäß HTTP Version 1.1 [RFC2616] über TLS (HTTPS) implementieren. Dabei MUSS das TLS-Protokoll gemäß [gemSpec_Krypt#GS-A_4385] und [gemSpec_Krypt#GS-A_4386] mit einseitiger Authentifizierung (Server-Authentisierung) implementiert sein.

TIP1-A_4058 - X.509-Zertifikat für HTTPSfür Internet

Der TSL-Dienst MUSS für die HTTPS-Verbindung zum Internet ein X.509-Zertifikat verwenden, welches in keinem marktüblichen Webbrowser (z.B. Firefox, Internet Explorer, Chrome und Safari) zu einer Warn- oder Fehlermeldung führt.

TIP1-A_4059 - EV-SSL-Zertifikat für HTTPS für Internet

Der TSL-Dienst SOLL für die HTTPS-Schnittstelle im Internet ein Extended-Validation-SSL-Zertifikat gemäß [EVSSL] verwenden.

TIP1-A_4062 - I_TSL_Download::download_TSL: GET-Befehl

Der TSL-Dienst MUSS die logische Operation I_TSL_Download::download_TSL so implementieren, dass sie durch den HTTP-GET-Befehl angestoßen werden.

TIP1-A_4063 - I_TSL_Download::download_TSL: Header

Der TSL-Dienst MUSS die logische Operation I_TSL_Download::download_TSL so implementieren, dass die Server-Antwort die notwendigen HTTP-Header-Datenfelder gemäß [RFC2616] enthält.

TIP1-A_4064 - I_TSL_Download::download_TSL: Content-Type

Der TSL-Dienst SOLL die logische Operation I_TSL_Download::download_TSL so implementieren, dass das Datenfeld „Content-Type“ im HTTP-Header der Server-Antwort als Wert den MIME-Type „application/vnd.etsi.tsl+xml“ enthält.

TIP1-A_4065 - I_TSL_Download::download_TSL: Body

Der TSL-Dienst MUSS die logische Operation I_TSL_Download::download_TSL so implementieren, dass die Server-Antwort im HTTP-Body die TSL als XML-Datei enthält.

TIP1-A_6768 - I_BNetzA_VL_Download: HTTPS für TI

Der TSL-Dienst MUSS die Schnittstelle I_BNetzA_VL_Download in der TI gemäß HTTP Version 1.1 [RFC2616] über TLS (HTTPS) implementieren. Dabei MUSS das TLS-Protokoll gemäß [gemSpec_Krypt#GS-A_4385] und [gemSpec_Krypt#GS-A_4386] mit einseitiger Authentifizierung (Server-Authentisierung) implementiert sein und ein Zertifikat gemäß [gemSpec_PKI#GS-A_4615] mit der technischen Rolle "oid_tsl_ti" gemäß [gemSpec_OID#GS-A_4446] verwendet werden. Die Schnittstelle MUSS ausschließlich unter Verwendung des TLS-Protokolls (HTTPS) erreichbar sein.  

TIP1-A_6750 - I_BNetzA_VL_Download: GET-Befehl

Der TSL-Dienst MUSS die logischen Operationen der Schnittstelle I_BNetzA_VL_Download so implementieren, dass sie durch den HTTP-GET-Befehl angestoßen werden.

TIP1-A_6751 - I_BNetzA_VL_Download: Header

Der TSL-Dienst MUSS die logischen Operationen der Schnittstelle  I_BNetzA_VL_Download so implementieren, dass die Server-Antwort die notwendigen HTTP-Header-Datenfelder gemäß [RFC2616] enthält.

TIP1-A_6752 - I_BNetzA_VL_Download::download_VL: Content-Type

Der TSL-Dienst SOLL die logische Operation I_BNetzA_VL_Download::download_VL so implementieren, dass das Datenfeld „Content-Type“ im HTTP-Header der Server-Antwort als Wert den MIME-Type „application/vnd.etsi.tsl+xml“ enthält.

TIP1-A_6753 - I_BNetzA_VL_Download::download_VL: Body

Der TSL-Dienst MUSS die logische Operation I_BNetzA_VL_Download::download_VL so implementieren, dass die Server-Antwort im HTTP-Body die BNetzA-VL als XML-Datei enthält.

TIP1-A_6754 - I_BNetzA_VL_Download::get_Hash

Der TSL-Dienst MUSS die logische Operation I_BNetzA_VL_Download::get_Hash so implementieren, dass der von der BNetzA publizierte SHA-256-Hashwert der BNetzA-VL-Datei heruntergeladen werden kann.

TIP1-A_6755 - I_BNetzA_VL_Download::get_Hash: URI

Der TSL-Dienst MUSS zu jedem Download-URI der BNetzA-VL in der TI einen entsprechenden URI zum Download des SHA-256-Hashwertes der BNetzA-VL anbieten.    
Der TSL-Dienst MUSS diese URIs gemäß [ETSI_TS_119_612], Kap. 6.1 und unter Beachtung der Groß- und Kleinschreibung gestalten. D.h. ein Download-URI des Hashwertes wird dadurch gebildet, dass die String-Endung ‘.xml‘ oder ‘.xtsl‘ eines Download-URI der BNetzA-VL durch ‘.sha2‘ ersetzt wird.

TIP1-A_6756 - BNetzA-VL-Signer-Zertifikate in TSL aufnehmen und entfernen

Der Anbieter des TSL-Dienstes MUSS die EU List of Trusted Lists (EU-LOTL, s. [EU_LOTL]) vor jeder Standardaktualisierung der TSL auf Veränderungen hinsichtlich BNetzA-VL-Signer-Zertifikate überprüfen.    
Der Anbieter des TSL-Dienstes MUSS BNetzA-VL-Signer-Zertifikate aus der TSL entfernen, wenn diese nicht mehr in der EU-LOTL enthalten sind.    
Der Anbieter des TSL-Dienstes MUSS BNetzA-VL-Signer-Zertifikate in die TSL aufnehmen, wenn diese neu in der EU-LOTL enthalten sind.    
Der Anbieter des TSL-Dienstes MUSS eine von ihm verwendete EU-LOTL gem. [ETSI_TS_119_612#Annex A] beziehen und überprüfen.

TIP1-A_6757 - Periodisches Aktualisieren der BNetzA-VL

Der TSL-Dienst MUSS mindestens einmal pro Stunde unter Zuhilfenahme eines offiziellen Downloadpunktes der Bundesnetzagentur überprüfen, ob die im TSL-Dienst vorhandene BNetzA-VL die aktuell gültige ist.    
Bei Feststellung eines Unterschiedes MUSS die neue BNetzA-VL auf den TSL-Dienst heruntergeladen werden. Zusätzlich wird der aktuelle Hashwert der BNetzA-VL auf den TSL-Dienst heruntergeladen.    

TIP1-A_6769 - Gesichertes Herunterladen von Dateien der BNetzA

Der TSL-Dienst MUSS sicherstellen, dass die von der BNetzA bereitgestellte BNetzA-VL und der entsprechende Hashwert nur TLS-gesichert über einen HTTPS-Downloadpunkt heruntergeladen werden. Ein Herunterladen über einen HTTP-Downloadpunkt wird nicht gestattet.     
Der TSL-Dienst MUSS die Vertrauenswürdigkeit des dabei verwendeten TLS-Server-Zertifikats der BNetzA sicherstellen.    

TIP1-A_6758 - Prüfen und Bereitstellen der BNetzA-VL auf dem TSL-Dienst

Der TSL-Dienst MUSS die heruntergeladene BNetzA-VL auf zeitliche Gültigkeit prüfen.
Der TSL-Dienst MUSS eine Prüfung der heruntergeladenen BNetzA-VL auf Vollständigkeit (Schemaprüfung) durchführen.     
Der TSL-Dienst MUSS eine Signaturprüfung der heruntergeladenen BNetzA-VL durchführen gegen ein in der TSL vorhandenes BNetzA-VL-Signer-Zertifikat.    
Der TSL-Dienst MUSS die BNetzA-VL nach erfolgreich durchgeführten Prüfungen auf den dafür vorgesehenen Download-Punkten bereitstellen.    
Neben der Bereitstellung der BNetzA-VL MUSS auch der von der BNetzA heruntergeladene Hashwert auf dem TSL-Dienst bereitgestellt werden.    

TIP1-A_4066 - Web-Server I_Cert_Download

Der TSL-Dienst MUSS die Schnittstelle I_Cert_Download via eigenen, selbstbetriebenen Web-Server zur Verfügung stellen.

TIP1-A_4067 - I_Cert_Download: HTTPS

Der TSL-Dienst MUSS die Schnittstelle I_Cert_Download im Internet gemäß HTTP Version 1.1 [RFC2616] über TLS (HTTPS) implementieren. Dabei MUSS das TLS-Protokoll gemäß [gemSpec_Krypt#GS-A_4385] und [gemSpec_Krypt#GS-A_4386] mit einseitiger Authentifizierung (Server-Authentisierung) implementiert sein.

TIP1-A_4068 - X.509-Zertifikat für HTTPS-Verbindung I_Cert_Download

Der TSL-Dienst MUSS für die HTTPS-Verbindung ein X.509-Zertifikat verwenden, welches in keinem marktüblichen Webbrowser (z.B. Firefox, Internet Explorer, Chrome und Safari) zu einer Warn- oder Fehlermeldung führt.

TIP1-A_4069 - EV-SSL-Zertifikat für HTTPS-Schnittstelle I_Cert_Download

Der TSL-Dienst SOLL für die HTTPS-Verbindung ein Extended-Validation-SSL-Zertifikat gemäß [EVSSL] verwenden.

TIP1-A_4070 - feste URIs I_Cert_Download

Der TSL-Dienst MUSS sicherstellen, dass die Schnittstelle I_Cert_Download über statische, vollständige URIs erreichbar ist.

TIP1-A_4071 - I_Cert_Download::download_Cert

Der TSL-Dienst MUSS für die Schnittstelle I_Cert_Download die logische Operation download_Cert implementieren.

TIP1-A_4072 - I_Cert_Download::download_Cert: GET-Befehl

Der TSL-Dienst MUSS die logische Operation I_Cert_Download::download_Cert so implementieren, dass sie durch den HTTP-GET-Befehl angestoßen wird.
[<=]

TIP1-A_4073 - I_Cert_Download::download_Cert: Body

Der TSL-Dienst MUSS die logische Operation I_Cert_Download::download_Cert so implementieren, dass die Server-Antwort im HTTP-Body das entsprechende DER-codierte Zertifikat enthält.
[<=]

TIP1-A_4074 - TSL-Signer-CA-, TSL-Signer-, Komponenten-CA-Zertifikat: Angaben

Der TSL-Dienst MUSS für das TSL-Signer-CA-Zertifikat und das TSL-Signer-Zertifikat sowie auch für das Komponenten-CA-Zertifikate die folgenden Angaben im Web veröffentlichen:    
(a) Das X.509-Zertifikat an sich    
(b) Den Fingerprint des Zertifikates gemäß [gemSpec_Krypt#GS-A_4393]    
(c) Das Datum, des Beginns der Gültigkeit des zugehörigen Schlüsselpaares für den Einsatz als TSL-Signer-CA (TI-Vertrauensanker), als TSL-Signer oder als Komponenten-CA.

TIP1-A_4075 - Fingerprint TSL-Signer-CA-Zertifikat per Post

Der Anbieter des TSL-Dienstes MUSS auf Anfrage von Herstellern von Produkttypen und anderen berechtigten Teilnehmern in der TI den Fingerprint des TSL-Signer-CA-Zertifikats schriftlich per Post verschicken.

TIP1-A_4447 - Publikation von Test-TSL und -Zertifikaten

Der TSL-Dienst MUSS die TSL-Datei für Testzwecke, sowie seine Zertifikate für Testzwecke und die dazugehörigen Angaben zum Download bereitstellen und publizieren. Der TSL-Dienst MUSS diese Daten als Testdaten kennzeichnen.

TIP1-A_4448 - Eigene Dienstinstanz für Test-Dateien in der TI

Der TSL-Dienst SOLL eine eigene Dienstinstanz für die Downloadschnittstellen der TIfür Testzwecke in der TI betreiben.

TIP1-A_6759 - Bezug einer Pseudo-BNetzA-VL

Der TSL-Dienst MUSS eine Pseudo-BNetzA-VL von der gematik analog zur produktiven BNetzA-VL beziehen und prüfen.

TIP1-A_6760 - Pseudo-BNetzA-VL bereitstellen

Der Anbieter des TSL-Dienstes MUSS eine Pseudo-BNetzA-VL analog zur bestehenden produktiven BNetzA-VL zum Download bereitstellen. Die in der Pseudo-BNetzA-VL verwendeten Pseudo-BNetzA-VL-Signer-Zertifikate müssen in die TU/RU-TSL aufgenommen und bei Ablauf der zeitlichen Gültigkeit oder bei Auftrag durch die gematik entfernt werden.

TIP1-A_4076 - Erreichbarkeit OCSP-Responder

Der TSL-Dienst MUSS sicherstellen, dass der Validierungsdienst in Form eines OCSP-Responders über das Netzwerk der Telematikinfrastruktur erreichbar ist.

TIP1-A_4077 - Organisatorische Trennung für OCSP

Der Anbieter des TSL-Dienstes MUSS eine klare organisatorische Trennung zwischen dem Betrieb und den Verantwortlichkeiten der Prozesse zum Sperren und des OCSP-Responders einerseits und sonstigen Betrieb und Rollen in der TI andererseits umsetzen und dokumentieren.

TIP1-A_4078 - Sperrantrag

Der Anbieter des TSL-Dienstes DARF NICHT Sperranträge von anderen Stellen als von vorgängig bezeichneten Mitarbeitern der gematik entgegennehmen und bearbeiten.

TIP1-A_4079 - Verfahren für Sperrung TSL-Signer-Zertifikat

Der Anbieter des TSL-Dienstes MUSS ein Verfahren für die unverzügliche Sperrung des TSL-Signer-Zertifikats bereitstellen und dokumentieren. Der Anbieter des TSL-Dienstes MUSS in der Dokumentation aufzeigen, dass dieses Verfahren auf höchstem Niveau sicher und stabil ist.

TIP1-A_4449 - OCSP-Responder für Test-TSL-Signerzertifikat

Der TSL-Dienst MUSS einen individuellen OCSP-Responder zur Validierung des TSL-Signer-Zertifikats zu Testzwecken betreiben.

TIP1-A_4081 - ETSI_TS_102_231

Der TSL-Dienst MUSS die TSL gemäß den Vorgaben nach [ETSI_TS_102_231_V3.1.2] erzeugen und befüllen.

TIP1-A_4082 - ETSI_TS_102_231 Annex B und XML-Schema

Der TSL-Dienst MUSS die TSL als XML-Datei gemäß [ETSI_TS_102_231_V3.1.2#B] und somit auch konform zu dem durch [ETSI_TS_102_231_V3.1.2#B] definierten XML-Schema [ts_102231v030102_xsd.xsd] erzeugen.

TIP1-A_5121 - TI-spezifische Vorgaben an die Syntax der TSL-Datei

Der TSL-Dienst MUSS die TSL als XML-Datei gemäß Tab_PKI_710 bis Tab_PKI_716 erstellen.

TIP1-A_4083 - XML-Signatur

Der TSL-Dienst MUSS die Integrität der Inhalte der TSL durch eine Signatur der XML-Datei gemäß [ETSI_TS_102_231_V3.1.2#B.6] gewährleisten.    
Der TSL-Dienst MUSS die Signatur der TSL entsprechend der Vorgaben aus [gemSpec_Krypt#GS-A_4371] wählen.

TIP1-A_4084 - X.509-Zertifikate, Element X509Certificate

Der TSL-Dienst MUSS sämtliche in der TSL referenzierten X.509-Zertifikate (z.B. CA-, OCSP-, CRL- oder TSL-Signer) direkt als Element X509Certificate in der TSL eintragen.

TIP1-A_4085 - ETSI_TS_102_231 Annex B: nur erforderliche Elemente

Der TSL-Dienst SOLL neben den gemäß [ETSI_TS_102_231_V3.1.2#B] zwingend erforderlichen Elementen nur Elemente in die TSL einfügen, die durch Anforderungen explizit verlangt werden.

TIP1-A_4086 - TSL ID

Der TSL-Dienst MUSS das Attribut "Id" im Header der TSL-Datei befüllen und dabei das Erstellungsdatum in den Wert des Attributes einfließen lassen. (Id="IDversionSequenzErstellungsdatumUhrzeit"). Das Attribut "Id" besteht aus mehreren Datentypen in denen das ErstellungsdatumUhrzeit im Attribut "Id" folgendes, von [gemSpec_TSL#TIP1-A_4087] abweichendes Format aufweisen muss: "YYYYMMDDhhmmssZ".

TIP1-A_4087 - TSL Datumsformat

Der TSL-Dienst MUSS Datumsformate nach [ETSI_TS_102_231_V3.1.2] als xsd:dateTime gestalten. Das Format MUSS wie folgt aufgebaut sein: <YYYY-MM-DDThh:mm:ssZ> - Beispiel: 2012-04-12T23:59:59Z

TIP1-A_4088 - TSLType

Der TSL-Dienst MUSS das Element „TSLType“ wie folgt befüllen:
<TSLType>http://uri.etsi.org/TrstSvc/TSLtype/generic</TSLType>

TIP1-A_4089 - TSL SchemeOperatorName

Der TSL-Dienst MUSS das Element SchemeOperatorName wie folgt befüllen:
<SchemeOperatorName>
    <Name xml:lang="DE">gematik Scheme</Name>    
</SchemeOperatorName>

TIP1-A_4090 - TSL SchemeName

Der TSL-Dienst MUSS das Element „SchemeName“ wie folgt befüllen:    
<SchemeName>
    <Name xml:lang="DE">gematik TSL Scheme</Name>    
</SchemeName>

TIP1-A_4091 - TSL SchemeInformationURI

Der TSL-Dienst MUSS das Element „SchemeInformationURI“ wie folgt befüllen:
<SchemeInformationURI>
    <URI xml:lang="DE">http://www.gematik.de</URI>    
</SchemeInformationURI>

TIP1-A_4092 - TSL StatusDeterminationApproach

Der TSL-Dienst MUSS das Element „StatusDeterminationApproach“ wie folgt befüllen:
<StatusDeterminationApproach>
http://uri.etsi.org/TrstSvc/TSLType/StatusDetn/passive
</StatusDeterminationApproach>
[<=]

TIP1-A_4093 - TSL Postalische Adresse

Der TSL-Dienst MUSS das Element „PostalAddress“, welches die postalische Adresse des „SchemeOperator“ enthält, wie folgt befüllen:    
<PostalAddress xml:lang="DE">    
    <StreetAddress>Friedrichstrasse 136</StreetAddress>    
    <Locality>Berlin</Locality>    
    <StateOrProvince>Berlin</StateOrProvince>    
    <PostalCode>10117</PostalCode>    
        <CountryName>DE</CountryName>    
</PostalAddress>
[<=]

TIP1-A_4094 - TSL Policy-Angaben

Der TSL-Dienst MUSS das Element „PolicyOrLegalNotice“ wie folgt befüllen: <PolicyOrLegalNotice>
    <TSLLegalNotice xml:lang="DE">Certificate Policy der gematik, OID {oid_policy_gem_or_cp}</TSLLegalNotice>
</PolicyOrLegalNotice>

Der Anbieter des TSL-Dienstes MUSS den OID (oid_policy_gem_or_cp) der Policy [gemRL_TSL_SP_CP] dem Dokument [gemSpec_OID#Tab_PKI_404] entnehmen.

TIP1-A_4095 - TSL HistoricalInformationPeriod

Der TSL-Dienst SOLL das Element HistoricalInformationPeriod mit dem Wert „0“ als Inhalt befüllen.

TIP1-A_4096 - TSL Lokalisierungspunkte

Der TSL-Dienst MUSS im Element "PointersToOtherTSL“ die Zugriffsadressen für die TSL-Datei integrieren. Er MUSS dieses Element wie folgt befüllen:
<PointersToOtherTSL>
    <OtherTSLPointer>
        <TSLLocation>{URL für TSL-Datei Primary Location}</TSLLocation>
        <AdditionalInformation>
            <TextualInformation xml:lang="DE">{oid_tsl_p_loc}</TextualInformation>
        </AdditionalInformation>
    </OtherTSLPointer>
    <OtherTSLPointer>
        <TSLLocation>{URL für TSL-Datei Backup Location}</TSLLocation>
        <AdditionalInformation>
            <TextualInformation xml:lang="DE">{oid_tsl_b_loc}</TextualInformation>
        </AdditionalInformation>
    </OtherTSLPointer>
</PointersToOtherTSL>
Der TSL-Dienst MUSS sowohl eine primäre als auch eine backup-Downloadadresse vorsehen.
Der TSL-Dienst MUSS den OID der TSLLocation (oid_tsl_p_loc, oid_tsl_b_loc) dem Dokument [gemSpec_OID#Tab_PKI_407] entnehmen.

TIP1-A_4097 - TSL TSPTradeName

Der TSL-Dienst MUSS das Element TSPTradeName für jeden TSP-Eintrag einsetzen und befüllen.

TIP1-A_4098 - TSL TSPTradeName identisch mit TSPName

Der Wert im Element TSPTradeName KANN identisch mit dem Wert des Elementes TSPName sein.

TIP1-A_4099 - TSL ServiceTypeIdentifier

Der TSL-Dienst MUSS pro TSP-Dienst einen der folgenden URIs als Wert in das Element ServiceTypeIdentifier einfügen:  

TIP1-A_4100 - TSL ServiceName: ein Name-Element

Der TSL-Dienst SOLL genau ein Name-Element als Inhalt eines Elementes ServiceName eintragen.

TIP1-A_4102 - TSL ServiceName aus Subject-Feld

Der TSL-Dienst SOLL innerhalb des Name-Elementes, welches innerhalb des Elementes ServiceName verwendet wird, den Inhalt des Subject-Feldes des Zertifikats für den TSP-Dienst eintragen, wenn für den TSP-Dienst ein X.509-Zertifikat eingetragen wird.
Der TSL-Dienst SOLL aus dem Subject-Feld den vollständigen Distinguished Name übernehmen.

TIP1-A_4103 - TSL DigitalId

Der TSL-Dienst MUSS ein Element DigitalId in das Element ServiceDigitalIdentity einfügen.

TIP1-A_4104 - TSL DigitalId: X.509-Zertifikat / Other-Element

Der TSL-Dienst MUSS für jeden TSP-Dienst ein Element X509Certificate oder ein Element Other (für DNSSEC-Trustanchor, CVC-Root-CA-Zertifikate oder Cross-CV-Zertifikate) in das Element DigitalId einfügen.
Der TSL-Dienst MUSS das ihm gelieferte X.509-Zertifikat des TSP-Dienstes in das Element X509Certificate eintragen.

TIP1-A_4105 - TSL ServiceStatus

Der TSL-Dienst MUSS im Element ServiceStatus einen URI einfügen, welcher einem der in [gemSpec_PKI#Tab_PKI_271] aufgeführten Werte entspricht.

TIP1-A_4106 - TSL ServiceSupplyPoints

Der TSL-Dienst MUSS in jedes Element ServiceInformation ein Element ServiceSupplyPoints mit mindestens einem Unterelement ServiceSupplyPoint einfügen, welches einen von der gematik bezeichneten URI enthält.    
Der URI steht für die Adresse eines OCSP-Responders oder CRL-Verteilungspunktes.
Der URI kann in bestimmten Fällen (z. B. beim DNSSEC Trust Anchor) auch für einen Platzhalter stehen (z.B. http://ocsp00.gematik.invalid/not-used).

TIP1-A_4107 - TSL ServiceInformationExtensions

Der TSL-Dienst MUSS für jeden TSP-Dienst-Eintrag das Element ServiceInformationExtensions eintragen.

TIP1-A_4108 - TSL ServiceInformationExtensions: Extension

Der TSL-Dienst MUSS mindestens ein Element Extension in das Element ServiceInformationExtensions einfügen. Falls keine Angaben vorhanden sind, MUSS der TSL-Dienst das Element ServiceInformationExtensions mit dem Platzhalter-OID (oid_tsl_placeholder) gemäß [gemSpec_OID#Tab_PKI_407] erstellen.

TIP1-A_4109 - TSL Extension: Attribut „Critical“

Der TSL-Dienst MUSS dem Attribut „Critical“ eines Elementes Extension den Wert „true“ oder „false“ gemäß den Vorgaben der gematik zuweisen. Der TSL-Dienst MUSS dieser Wert auf „false“ setzen, falls keine spezifischen Vorgaben gemacht werden.

TIP1-A_4110 - TSL Extension: ExtensionOID & ExtensionValue

Der TSL-Dienst MUSS ein Element Extension gemäß Tab_PKI_713 befüllen.     
Der TSL-Dienst MUSS die Inhalte dieser Unterelemente gemäß den Vorgaben der gematik setzen.     
Der TSL-Dienst MUSS ein Element ExtensionOID gemäß Tab_PKI_714, ein Element ExtensionValue gemäß Tab_PKI_715 und Element ExtensionValues gemäß Tab_PKI_716 befüllen.    
Der TSL-Dienst MUSS den Wert für ein ExtensionValue-Element auf die gematik-spezifische Referenz (startend mit „oid_“) gemäß [gemSpec_OID] setzen, falls der Wert für ein ExtensionValue-Element nicht spezifisch vorgegeben ist.

TIP1-A_6761 - BNetzA-VL Element TrustServiceProvider

Der TSL-Dienst MUSS für die Bundesnetzagentur (als Herausgeberin der BNetzA-VL) ein Element TrustServiceProvider einfügen und dieses wie folgt befüllen:

<TrustServiceProvider>

<TSPInformation>

        <TSPName>

            <Name xml:lang="de">Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen</Name>

        </TSPName>    

        <TSPTradeName>

            <Name xml:lang="de">Bundesnetzagentur</Name>

        </TSPTradeName>

        <TSPAddress>

            <PostalAddresses>

                <PostalAddress xml:lang="de">

                    <StreetAddress>Canisiusstr. 21</StreetAddress>

                    <Locality>Mainz</Locality>

                    <StateOrProvince>NW</StateOrProvince>

                    <PostalCode>55122</PostalCode>

                    <CountryName>DE</CountryName>

                </PostalAddress>

            </PostalAddresses>

            <ElectronicAddress>

                <URI>mailto:eIDAS@bnetza.de</URI>

            </ElectronicAddress>

        </TSPAddress>

        <TSPInformationURI>

            <URI xml:lang="de">http://www.bundesnetzagentur.de</URI>

        </TSPInformationURI>

</TSPInformation>
<TSPServices>

{Befüllung gemäß weiterer Anforderungen}
</TSPServices>

<TrustServiceProvider>      

TIP1-A_6762 - BNetzA-VL Element TSPService

Der TSL-Dienst MUSS für die Bundesnetzagentur (als Herausgeberin der BNetzA-VL) ein Element TSPService aufnehmen.  

TIP1-A_6763 - BNetzA-VL ServiceTypeIdentifier

Der TSL-Dienst MUSS für die BNetzA-VL-Signer in die TSL im Element ServiceTypeIdentifier den dafür in [TIP1-A_4099] spezifizierten URI einsetzen.

TIP1-A_6764 - BNetzA-VL Service Name

Der TSL-Dienst MUSS für die BNetzA-VL in die TSL im Element ServiceName mindestens ein Element Name einfügen.

TIP1-A_6765 - BNetzA-VL ServiceDigitalIdentity, DigitalId und X509Certificate

Der TSL-Dienst MUSS für jedes BNetzA-VL-Signer-Zertifikat im Element ServiceDigitalIdentity ein Element DigitalId mit einem Element X509Certificate einfügen und dort das X.509-BNetzA-VL-Signer-Zertifikat in die TSL eintragen. Siehe dazu auch [TIP1-A_4104].

TIP1-A_6766 - BNetzA-VL ServiceSupplyPoints

Der TSL-Dienst MUSS ein Element ServiceSupplyPoints für die BNetzA-VL in die TSL einfügen.    
Der TSL-Dienst MUSS ein Element ServiceSupplyPoint einfügen und dieses mit der primären TI-Download-Adresse der BNetzA-VL befüllen.    
Der TSL-Dienst MUSS ein Element ServiceSupplyPoint einfügen und dieses mit der sekundären TI-Download-Adresse der BNetzA-VL befüllen.    

TIP1-A_6767 - BNetzA-VL ServiceInformationExtensions

Der TSL-Dienst MUSS für die BNetzA-VL im Element ServiceInformationExtensions ein Element Extension eintragen, welches den Platzhalter-OID (oid_tsl_placeholder) gemäß [gemSpec_OID#Tab_PKI_407] enthält.

TIP1-A_7219 - BNetzA-VL AdditionalServiceInformation für Umleitung von OCSP-Responder-Adressen in der TI

Der TSL-Dienst MUSS für jede von der gematik bereitgestellte OCSP-Responder-URL für QES-Zwecke je ein Element AdditionalServiceInformation innerhalb des ServiceInformationExtensions Elementes als Tupel der Elemente URI und InformationValue erstellen.
Das URI-Element MUSS dabei jeweils folgenden Eintrag enthalten: <URI>http://uri.etsi.org/TrstSvc/TrustedList/SvcInfoExt/ForeSignatures/</URI>.
Das InformationValue-Element MUSS jeweils den von der gematik bereitgestellten Text-Eintrag als String (URLs getrennt durch Leerzeichen) enthalten. [<=]

TIP1-A_5122 - TSL DNSSEC Trust Anchor ServiceTypeIdentifier

Der TSL-Dienst MUSS für den DNSSEC Trust Anchor der TI im Element ServiceTypeIdentifier den dafür in [TIP1-A_4099] spezifizierten URI einsetzen.

TIP1-A_5123 - TSL DNSSEC Trust Anchor Name

Der TSL-Dienst MUSS für den DNSSEC Trust Anchor der TI im Element ServiceName ein Element Name einfügen, welches den Inhalt „CN=DNSSEC-Trustanchor, DC=telematik“ enthält.

TIP1-A_5124 - TSL DNSSEC Trust Anchor DigitalId

Der TSL-Dienst MUSS für den DNSSEC Trust Anchor der TI im Element DigitalId (im Element ServiceDigitalIdentity) ein Element Other einfügen. Der TSL-Dienst MUSS in dieses Other-Element ein XML-Fragment gemäß [gemSpec_Net#GS-A_4815] eintragen.

TIP1-A_5125 - TSL DNSSEC Trust Anchor ServiceStatus

Der TSL-Dienst MUSS für den DNSSEC Trust Anchor der TI im Element ServiceStatus den URI gemäß [gemSpec_PKI#Tab_PKI_271] für einen Dienst, der in Betrieb ist, einsetzen.

TIP1-A_5126 - TSL DNSSEC Trust Anchor StatusStartingTime

Der TSL-Dienst SOLL für den DNSSEC Trust Anchor der TI im Element StatusStartingTime den Zeitpunkt, ab dem der DNSSEC Trust Anchor in Betrieb ist, einsetzen.

TIP1-A_5128 - TSL DNSSEC Trust Anchor Extension

Der TSL-Dienst MUSS für den DNSSEC Trust Anchor der TI im Element ServiceInformationExtensions ein Element Extension eintragen, welches den Platzhalter-OID (oid_tsl_placeholder) gemäß [gemSpec_OID#Tab_PKI_407] enthält.

TIP1-A_5990 - Bezug und Nutzung bereitgestellter CVC-Root- und Cross-CV-Zertifikate sowie Prüfung des Fingerprints zum öffentlichen CVC-Root-Schlüssel

Der TSL-Dienst MUSS

(a) die in die TSL aufzunehmenden CV-Root-CA- und Cross-CV-Zertifikate vom offiziellen Downloadpunkt der Internetseite des Anbieters CVC-Root-CA beziehen,

(b) den Fingerprint des in den Zertifikaten enthaltenen öffentlichen Schlüssels per Briefpost vom Anbieter CVC-Root-CA anfordern,

(c) den Fingerprint des öffentlichen Schlüssels vor der Aufnahme der entsprechenden CV-Root-CA- und Cross-CV-Zertifikate erfolgreich prüfen.

TIP1-A_5963 - TSL CV-Zertifikate der CVC-Root-CAs ServiceTypeIdentifier

Der TSL-Dienst MUSS für das ein CVC-Root-CA-Zertifikat oder ein Cross-CV-Zertifikat im Element „ServiceTypeIdentifier“ den dafür in [TIP1-A_4099] spezifizierten URI einsetzen.

TIP1-A_5964 - TSL CV-Zertifikate der CVC-Root-CAs Name

Der TSL-Dienst MUSS für ein CVC-Root-CA-Zertifikat oder für ein Cross-CV-Zertifikat im Element „ServiceName“ ein Element „Name“ einfügen, welches den Inhalt „CHR={CHR}, CAR={CAR}“ gemäß [gemSpec_PKI#6.7.2.2 und #6.7.2.4] enthält.  
Der TSL-Dienst MUSS die Werte {CHR} und {CAR} gemäß dem CHR-Wert und dem CAR-Wert des CVC-Root-CA-Zertifikats oder des Cross-CV-Zertifikats als 11 Zeichen (5 Buchstaben und 6 Ziffern) lange Strings entsprechend [gemSpec_PKI#Tab_PKI_266] eintragen.    
Ist {CHR} gleich {CAR}, handelt es sich um ein CVC-Root-CA-Zertifikat.

TIP1-A_5965 - TSL CV-Zertifikate der CVC-Root-CAs DigitalId

Der TSL-Dienst MUSS für ein CVC-Root-CA-Zertifikat oder für ein Cross-CV-Zertifikat im Element DigitalId (im Element ServiceDigitalIdentity) ein Element „Other“ einfügen. Der TSL-Dienst MUSS in dieses Other-Element ein CVCertificate-Element einfügen, welches das Base64-codierte CV-Zertifikat wie folgt aufnimmt.
<Other>
<CVCertificate>
        Base64-codiertes CV-Zertifikat}    
    </CVCertificate>
</Other>

TIP1-A_5966 - TSL CV-Zertifikate der CVC-Root-CAs ServiceStatus

Der TSL-Dienst MUSS für ein CVC-Root-CA-Zertifikat oder für ein Cross-CV-Zertifikat im Element ServiceStatus den URI gemäß [gemSpec_PKI#Tab_PKI_271] für einen Dienst, der in Betrieb ist, einsetzen.

TIP1-A_5967 - TSL CV-Zertifikate der CVC-Root-CA Extension

Der TSL-Dienst MUSS für ein CVC-Root-CA-Zertifikat oder für ein Cross-CV-Zertifikat im Element ServiceInformationExtensions ein Element Extension eintragen, welches die OID (oid_cv_cert) bzw. OID (oid_cv_rootcert für ein CVC-Root-Zertifikat) gemäß [gemSpec_OID# Tab_PKI_407] enthält.

TIP1-A_4111 - TSL Test SchemeOperatorName

Der TSL-Dienst MUSS in der TSL für die Test- und Referenzumgebungen das Element SchemeOperatorName wie folgt befüllen:    
<SchemeOperatorName>
    <Name xml:lang="DE">TEST-ONLY gematik Scheme</Name>    
</SchemeOperatorName>

TIP1-A_4112 - TSL Test SchemeName

Der TSL-Dienst MUSS in der TSL für die Test- und Referenzumgebungen das Element SchemeName wie folgt befüllen:    
<SchemeName>
    <Name xml:lang="DE">TEST-ONLY gematik TSL Scheme</Name>    
</SchemeName>

TIP1-A_4113 - TSL Test Policy-Angaben

Der TSL-Dienst MUSS in der TSL für die Test- und Referenzumgebungen das Element „PolicyOrLegalNotice“ wie folgt befüllen:    
<PolicyOrLegalNotice>
    <TSLLegalNotice xml:lang="DE">TEST-ONLY Abschnitt der Certificate Policy der gematik, OID {oid_policy_gem_or_cp}</TSLLegalNotice>    
</PolicyOrLegalNotice>
Der TSL-Dienst MUSS den OID (oid_policy_gem_or_cp) der Policy [gemRL_TSL_SP_CP] dem Dokument [gemSpec_OID# Tab_PKI_404] entnehmen.
[<=]

TIP1-A_4114 - TSL Test Lokalisierungspunkte

Der TSL-Dienst MUSS in der TSL-Datei für die Test- und Referenzumgebungen im Element "PointersToOtherTSL“ die Zugriffsadressen für die jeweilige TSL-Datei integrieren. Er MUSS dieses Element wie folgt befüllen:    
<PointersToOtherTSL>
    <OtherTSLPointer>
        <TSLLocation>{URL für Test-TSL-Datei Primary Location}</TSLLocation>
        <AdditionalInformation>
        <TextualInformation xml:lang="DE">{oid_tsl_p_loc}</TextualInformation>
        </AdditionalInformation>
    </OtherTSLPointer>
    <OtherTSLPointer>
        <TSLLocation>{URL für Test-TSL-Datei Backup Location}</TSLLocation>
        <AdditionalInformation>
            <TextualInformation xml:lang="DE">{oid_tsl_b_loc}</TextualInformation>
        </AdditionalInformation>
    </OtherTSLPointer>
</PointersToOtherTSL>
Der TSL-Dienst MUSS sowohl eine primäre als auch eine backup-Downloadadresse vorsehen.    
Der TSL-Dienst MUSS den OID der TSLLocation (oid_tsl_p_loc, oid_tsl_b_loc) dem Dokument [gemSpec_OID#3.6] entnehmen.
[<=]