Elektronische Gesundheitskarte und Telematikinfrastruktur

Spezifikation

TSL-Dienst

    

     

      
Version
      
1.21.0
     
     

      
Revision
      
983085
     
     

      
Stand
      
17.05.2024
     
     

      
Status
      
freigegeben
     
     

      
Klassifizierung
      
öffentlich
     
     

      
Referenzierung
      
gemSpec_TSL
     
    

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende Spezifikation definiert die Anforderungen an den Produkttyp TSL-Dienst und stellt darüber hinaus Anforderungen hinsichtlich Sicherheit und Betrieb des TSL-Dienstes. Es werden übergreifende Festlegungen sowie Anforderungen an die technischen und organisatorischen Schnittstellen zum Betrieb des TSL-Dienstes beschrieben.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter einer TSL, Trust Service Provider sowie Hersteller und Anbieter von Produkttypen, die Zertifikate nutzen.

1.3 Geltungsbereich

Dieses Dokument enthält normative Festlegungen zur Telematikinfrastruktur des deutschen Gesundheitswesens. Der Gültigkeitszeitraum der vorliegenden Version und deren Anwendung in Zulassungsverfahren wird durch die gematik GmbH in gesonderten Dokumenten (z. B. Dokumentenlandkarte, Produkttypsteckbrief, Leistungsbeschreibung) festgelegt und bekannt gegeben.

Schutzrechts-/Patentrechtshinweis

Die nachfolgende Spezifikation ist von der gematik allein unter technischen Gesichtspunkten erstellt worden. Im Einzelfall kann nicht ausgeschlossen werden, dass die Implementierung der Spezifikation in technische Schutzrechte Dritter eingreift. Es ist allein Sache des Anbieters oder Herstellers, durch geeignete Maßnahmen dafür Sorge zu tragen, dass von ihm aufgrund der Spezifikation angebotene Produkte und/oder Leistungen nicht gegen Schutzrechte Dritter verstoßen und sich ggf. die erforderlichen Erlaubnisse/Lizenzen von den betroffenen Schutzrechtsinhabern einzuholen. Die gematik GmbH übernimmt insofern keinerlei Gewährleistungen.

1.4 Abgrenzung des Dokuments

Spezifiziert werden in dem Dokument die von dem Produkttyp TSL-Dienst bereitgestellten (angebotenen) Schnittstellen. Benutzte Schnittstellen werden hingegen in der Spezifikation desjenigen Produkttypen beschrieben, der diese Schnittstelle bereitstellt. Auf das entsprechende Dokument wird referenziert (siehe auch Anhang A).

Die vollständige Anforderungslage für den Produkttyp ergibt sich aus weiteren Konzept- und Spezifikationsdokumenten, diese sind in dem Produkttypsteckbrief des Produkttyps TSL-Dienst verzeichnet.

Nicht Bestandteil des vorliegenden Dokumentes sind die Festlegungen zu folgenden Themenbereichen:

• CVC-Zertifikate und die Zulassung der TSPs, die CVC-Zertifikate ausgeben, werden in den CVC-spezifischen Dokumenten beschrieben.
• Die Anforderungen an TSPs, die X.509-Zertifikate ausgeben, werden in [gemSpec_X.509_TSP] beschrieben.
• Die zugehörigen Policy-Aspekte, bzw. die Vorgaben für die Vereinheitlichung der Public-Key-Infrastrukturen, werden in [gemRL_TSL_SP_CP] angesprochen.
• Detaillierte Vorgaben zur Validierung und Verarbeitung von Zertifikaten und der hier beschriebenen Trust-service Status List (TSL) der vertrauenswürdigen Herausgeber werden in [gemSpec_PKI#8] gemacht. Dort wird auch der Wechsel des TI-Vertrauensankers auf der Client-Seite beschrieben.
• Die normativen Vorgaben bzgl. verwendbarer kryptographischer Algorithmen trifft das Dokument [gemSpec_Krypt].
• Deshalb wird als Basis zur Referenzierung der kryptographischen Algorithmen auf [gemSpec_Krypt#2.1] für X.509-Zertifikate und [gemSpec_Krypt#3.1] für XML-Signaturen, verwiesen.

1.5 Methodik

Anforderungen als Ausdruck normativer Festlegungen werden durch eine eindeutige ID in eckigen Klammern sowie die dem RFC 2119 [RFC2119] entsprechenden, in Großbuchstaben geschriebenen deutschen Schlüsselworte MUSS, DARF NICHT, SOLL, SOLL NICHT, KANN gekennzeichnet.

Anforderungen werden im Dokument wie folgt dargestellt:
  <AFO-ID> - <Titel der Afo>
Text / Beschreibung
[<=]

Dabei umfasst die Anforderung sämtliche zwischen Afo-ID und Textmarke [<=] angeführten Inhalte.

2 Systemüberblick

2.1 Zweck der TSL

Jedes Zertifikat und somit jeder öffentliche Schlüssel innerhalb der PKI der Telematikinfrastruktur ist durch eine Zertifizierungsstelle bzw. Certification Authority (CA) signiert. Das Vertrauen in eine CA bzw. den sie betreibenden Trust Service Provider (TSP) kann nur bestehen, wenn alle CAs einheitlichen Sicherheitsvorgaben genügen, deren Einhaltung durch eine unabhängige Instanz (die Zulassungs- und Registrierungsstelle der gematik) bestätigt wird.

Um den Vertrauensraum für X.509-Zertifikate in der Telematikinfrastruktur technisch abzubilden, wird die TSL verwendet. Die TSL-Datei ist eine signierte Whitelist der zugelassenen Zertifikatsherausgeber. Das heißt, die TSL-Datei enthält sämtliche nonQES-X.509-CA-Zertifikate, die in der TI verwendet werden. Des Weiteren enthält sie die nötigen Informationen für die Statusprüfung der von den CAs ausgestellten End-Entity-Zertifikate innerhalb der TI. Dies geschieht in Form der Adressen und Zertifikate der zuständigen OCSP-Responder bzw. der Adresse des CRL-Verteilungspunktes für den Sonderfall der Zertifikate des VPN-Zugangsdienstes.

Die TSL dient auch der Verteilung weiterer kryptographischer Infrastruktur-Elemente. Diese sind:

• Die aktuell gültigen CVC-Root-CA-Zertifikate und deren zugehörigen Cross-CV-Zertifikate (bei Root-CAs muss die Aktualisierung durch Ausstellen von Cross-Zertifikaten zwischen zeitlich auf einander folgenden CA-Instanzen erfolgen.).
• Die Signer-Zertifikate der Vertrauensliste der Bundesnetzagentur (BNetzA-VL) und die Downloadpunkte der BNetzA-VL innerhalb der TI
• Der aktuelle TI DNSSEC Trust Anchor (s. Kap. 7.6)
• Weitere TI-Zertifikate (Unspecified Type/s. Kap. 7.9 Weitere TI-Zertifikate (Unspecified ServiceType))

Für die Auswertung der Zertifikate sind die normativen Festlegungen bzgl. der Prüfung des TI-Vertrauensraumes (kommt das Zertifikat aus einer vertrauenswürdigen Quelle?) und des Zertifikatsstatus (ist das Zertifikat gültig oder gesperrt?) in [gemSpec_PKI#8] zu finden.

2.2 TSL als zentraler Vertrauensraum der TI

Alle Komponenten in der Telematikinfrastruktur, die Zertifikate prüfen, müssen dabei die TSL in die Validierung mit einbeziehen. Aus diesem Grund ist der TSL-Dienst als zentraler Dienst in die Telematikinfrastruktur implementiert. Jede Komponente muss in der Lage sein, die notwendigen Daten regelmäßig herunterzuladen und zu validieren.

In den folgenden Abschnitten und Kapiteln wird der TSL-Dienst spezifiziert.

Abbildung 1: Ablauf des Eintrags in TSL

Die Kernfunktionen des TSL-Dienstes sind im Kapitel 4 „Zerlegung des Produkttyps“ beschrieben.

In der Abbildung 1 ist der Kernprozess zur Registrierung (Eintrag in die TSL) eines TSP und seiner Dienste eingezeichnet. In der Produktivumgebung ist ein solcher Eintrag die technische Abbildung des Abschlusses eines erfolgreich verlaufenen Zulassungsverfahrens. Kurz dargestellt sehen diese Prozesse folgendermaßen aus:

Der Ablauf beginnt mit dem Antrag eines TSP an die gematik (Schritt 1). Die gematik erstellt einen TSL-Eintragsantrag (Schritt 2). Der Anbieter des TSL-Dienstes nimmt diese Daten entgegen und verarbeitet sie (Schritt 3). Im nächsten Schritt erzeugt der Anbieter des TSL-Dienstes eine aktualisierte TSL-Datei mit einem neuen Eintrag. Anschließend wird sie zum Download zur Verfügung gestellt (Schritt 5). Die Komponenten der TI können die aktualisierte TSL-Datei herunterladen und validieren (Schritt 6).

2.3 TSL-Dienst im Kontext der ECC-Unterstützung

Der Vertrauensraum der TI sah bisher nur die Verwendung von RSA-2048 als Schlüsselalgorithmus vor. Die TSL enthielt daher nur RSA-Zertifikate.

Im Zuge der ECC-Migration müssen alle Produkttypen so umgestellt werden, dass sie neben RSA-2048 auch ECC-256 unterstützen (vgl. gemSpec_Krypt#Kap.5). Daher wird neben der bisher vorhandenen reinen RSA-basierten TSL (im Folgenden „TSL(RSA)“ genannt) eine zweite TSL bereitgestellt, die sowohl die neuen ECDSA-basierten Zertifikate als auch aus Rückwärtskompatibilitäts-Gründen die weiterhin benötigten RSA-basierten Zertifikate enthält. Diese zweite neue TSL wird im Folgenden als „TSL(ECC-RSA)“ bezeichnet.

Bis zum vollständigen Abschluss der ECC-Migration werden beide TSL-Varianten vom TSL-Dienst bereitgestellt. Technisch sind die beiden Varianten unabhängig voneinander. Der Übergang des Vertrauensraumes von RSA auf ECC+RSA geschieht dabei durch Cross-Zertifizierung der entsprechenden TSL-Signer-CA-Zertifikate.

Neben dem Download-Punkt für die TSL(RSA) gibt es einen weiteren Download-Punkt für die TSL(ECC-RSA). Die TSL(RSA) wird weiterhin mit einem RSA-basierten Zertifikat signiert. Die TSL(ECC-RSA) erhält eine Signatur auf ECDSA-Basis.

Produkttypen, die ausschließlich RSA-Zertifikate prüfen, verwenden die TSL(RSA). Alle Produkttypen, die ECC-Zertifikate prüfen, müssen die TSL(ECC-RSA) verwenden.

Alle Beschreibungen und Anforderungen, die sich im Folgenden an eine TSL richten, sind sowohl für die TSL(RSA) als auch die TSL(ECC-RSA) zu berücksichtigen und umzusetzen. Wenn im Folgenden von TI-Vertrauensraum gesprochen wird, dann handelt es sich sowohl um den Vertrauensraum (RSA) als auch den Vertrauensraum (ECC-RSA). Beide sind durch ihre jeweiligen Vertrauensanker definiert:

• Vertrauensraum (RSA) durch Vertrauensanker (RSA): TSL-Signer-CA (RSA)
• Vertrauensraum (ECC-RSA) durch Vertrauensanker (ECC-RSA): TSL-Signer-CA (ECDSA)

Ein Produkt befindet sich immer entweder im Vertrauensraum (RSA) oder im Vertrauensraum (ECC-RSA).

3 Systemkontext

3.1 Akteure und Rollen

Die Akteure und Rollen sind im Konzept PKI der TI-Plattform beschrieben [gemKPT_PKI_TIP#2.7]. Im Betrieb des TSL-Dienstes gehören hierzu:

• Der Anbieter des TSL-Dienstes
• Die gematik stellt (nach erfolgter Zulassung) eines Trust Service Provider (TSP) und seiner Dienste für X.509-Zertifikate den Antrag für deren Eintrag in die (produktive) TSL-Datei.
  Die gematik beantragt auch die Aufnahme von Infrastruktur-Elementen (DNSSEC-Vertrauensanker, BNetzA-VL-Signer-Zertifikate, CVC-Root-CA-Zertifikate und dazugehörige Cross-CV-Zertifikate, Zertifikate für SGD-HSM).
• Die Anbieter der TSP-X.509 beantragen die Zulassung und damit die Aufnahme ihrer Dienste für X.509-Zertifikate in den TI-Vertrauensraum bei der gematik.
• Der Anbieter der CVC-Root beantragt bei der gematik die Eintragung der CVC-Root-CA-Zertifikate und der dazugehörigen Cross-CV-Zertifikate in die TSL.
• Der Anbieter des Schlüsselgenerierungsdienstes (SGD) beantragt bei der gematik die Eintragung der Zertifikate für SGD-HSM.
• Die Zertifikatsnutzer bzw. die zertifikatsprüfenden Komponenten laden die TSL-Datei herunter und nutzen die darin enthaltenen Informationen im Rahmen der Validierung von X.509-Zertifikaten.

3.2 Übersicht Zertifikatshierarchie