PKI für das System und Service

Transkript

1 Einführung der Gesundheitskarte PKI für das System und Service Level Monitoring Version: Revision: main/rel_main/17 Stand: Status: freigegeben gematik_pki_x 509_SSL_Monitoring.doc Seite 1 von 42

2 Dokumentinformationen Änderungen zur Vorversion Die zunächst in Kap. 4.3 angeführten Zertifikatsprofile werden im Dokument Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] definiert und demzufolge hier gestrichen. In den Abschnitten 4.3.2, und wurden Formulierungen an andere PKI-Dokumente angepasst. Die Bezeichnungen der Zertifikate, technischen Rollen und Zertifikatstypen wurden an die neuen Vorgaben angepasst. Der offene Punkt bezüglich Suspendierung der Zertifikate wurde entfernt, da diese Funktion erforderlich ist. Der Zertifikatstyp wird nun in der Extension CertificatePolicy kodiert. Die Extension AdditionalInformation wurde gestrichen. In Anhang A2 wird jetzt verbindlich vorgegeben, dass die Zulassungsanforderungen für TSPs um die Berücksichtigung der Vorgaben aus gemsysslm erweitert werden. Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert. Sofern ganze Kapitel bzw. Abschnitte eingefügt wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gempki_mon] gematik: Einführung der Gesundheitskarte - PKI für das System und Service Level Monitoring () Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Neuerstellung gematik, AG AG8-interne QS gematik, AG AG8-interne QS durch SSLM gematik, AG Kap. 5 Inhalt eingefügt gematik, AG Monitoring für einen OCSP-Responder überarbeitet Abb. 1 an neue Version [gemsysslm] angepasst gematik, AG8 gematik, AG8 gematik_pki_x 509_SSL_Monitoring.doc Seite 2 von 42

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Einarbeitung Kommentare gematik-qs altes Kapitel 5 in neues Dok. ausgelagert Bearbeitung gematik, AG Formale Überprüfung gematik QS Einarbeitung Kommentare QS gematik, AG Abs. 2.5 an abgestimmte Formulierung angepasst. Extensionen Admission und Additional- Information zum Zertifikatsprofil hinzugefügt. Liste der Referenzen ergänzt. SPE/ZD freigegeben gematik OID-Referenzen für Rolle und Zertifikatstyp gemäß [gemspec_oid] angepasst und Inhalt common name im Zertifikat in Angabe des FQDN geändert formelle Überarbeitung QM SPE/ZD Einarbeitung Reviewergebnisse SPE/ZD freigegeben gematik Anpassungen Zertifikatstypen, Rollen und Extensions Einarbeitung Reviewergebnisse Kapitel 4.3 stark vereinfacht Anhang A3 aufgenommen SPE/ZD SPE/ZD freigegeben gematik gematik_pki_x 509_SSL_Monitoring.doc Seite 3 von 42

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokuments Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokuments Methodik Verwendung von Schüsselworten Hinweis auf offene Punkte Anforderungen PKI für das System und Service Level Monitoring Grundlagen Vertrauensmodell Zertifikatsaufbau Festlegungen zur Definition der Betreiber- bzw. gematik-identität Übersicht: Attribute im SubjectDN (X.509-Zertifikat für MON) Nutzung der Attribute im SubjectDN Aufbau der serialnumber im Feld SubjectDN Aufbau des gesamten SubjectDN Notwendige Zertifikatsfelder Kennzeichnung von Rollen in Extension Admission Extension Kennzeichnung von Angaben zum Zertifikatstyp in der Extension CertificatePolicy Zertifikatsprofile Zertifikat für einen Betreiber bzw. für die gematik (C.MGMTSS.SSL) CA-Zertifikat der CA-MON (C.MGMTSS.CA) Umgang mit den Zertifikaten für das Monitoring Registrierung/Zertifikatsgenerierung Registrierung der Betreiber und Information des TSP Ausstellen eines X.509-Zertifikats für Monitoring Nutzen/Verifizieren der Zertifikate Suspendieren, Desuspendieren bzw. Sperren der Zertifikate...30 gematik_pki_x 509_SSL_Monitoring.doc Seite 4 von 42

5 4.5 Verzeichnisdienste der CA-MON Vorgaben für die Policy der CA-MON Produktiv-/Test-CA-MON...33 Anhang A...34 A1 Monitoring für einen Broker...34 A2 Monitoring für einen OCSP-Responder...37 A3 Im Rahmen des Monitoring verwendete Rollen...38 Anhang B...39 B1 Abkürzungen...39 B2 Glossar...39 B3 Abbildungsverzeichnis...39 B4 Tabellenverzeichnis...39 B5 Referenzierte Dokumente...40 B6 Klärungsbedarf...41 gematik_pki_x 509_SSL_Monitoring.doc Seite 5 von 42

6 1 Zusammenfassung Für das System und Service Level Monitoring der Komponenten der Telematikinfrastruktur sammeln und verarbeiten die Betreiber der dezentralen Services die benötigten Daten in ihren eigenen Managementsystemen. Teile dieser Daten müssen aber für eine zentrale Überwachung und Darstellung der Performanz und Verfügbarkeit der dezentralen Services an das zentrale Managementsystem der gematik übermittelt werden. Der Austausch dieser Daten geschieht dabei nicht über das Netzwerk der Telematikinfrastruktur, sondern über ein gesondertes Management-VPN. Die Betreiber der dezentralen Services und die gematik implementieren zu diesem Zweck eine einheitliche Managementschnittstelle gemäß den Vorgaben aus [gemsysslm]. Hinweis: Der Begriff "dezentrale Services" wird in diesem Dokument, wie in [gem- SysSLM] definiert in seiner ursprünglichen allgemeinen Bedeutung verwendet und nicht in der engeren Definition aus [gemgesarch]. Für den Datenaustausch über das Management-VPN müssen sich die Kommunikationspartner gegenseitig authentisieren. Zu diesem Zweck erhalten alle Betreiber dezentraler Services und die gematik spezielle X.509-Zertifikate. Diese Zertifikate werden durch eine spezielle CA (CA-MON) ausgestellt. Die gematik wird nach einer Ausschreibung einen TSP mit dem Betrieb dieser CA beauftragen. Die Anforderungen an die PKI für die Zertifikate des System und Service Level Monitoring sind im Wesentlichen vergleichbar zu den Anforderungen an die PKI für die Komponentenzertifikate der Server und (Fach-) Dienste (siehe [gemx.509_sd]). Aufgrund der sehr einfachen Kommunikationsstruktur über das Management-VPN können die Anforderungen an die PKI (und damit die Anforderungen an den TSP bezüglich des Betriebs der CA- MON) aber zum Teil vereinfacht werden. So ist zum Beispiel eine OCSP-Abfrage im Rahmen des Verifizierens eines Zertifikats nicht notwendig, d. h. der TSP muss für die Zertifikate für das System und Service Level Monitoring keinen OCSP-Responder zur Verfügung stellen. Das vorliegende Dokument enthält in Kap. 4 neben der Festlegung des Aufbaus der X.509-Zertifikate für das System und Service Level Monitoring (im Sinne eines s) die Beschreibung der vereinfachten Anforderungen für einen TSP für den Betrieb der CA-MON. Beschrieben werden u. a. das Zusammenspiel zwischen gematik und TSP bei der Registrierung der Betreiber und bei dem Generieren der Zertifikate, Vorgaben für den Einsatz und das Verifizieren der Zertifikate sowie Regelungen für das Sperren der Zertifikate. Neben den Anforderungen an den Aufbau und Betrieb der CA-MON ergeben sich aus der Spezifikation des System und Service Level Monitoring auch weitere Vorgaben für andere PKI der Telematikinfrastruktur. Diese werden in Anhang A zusammengestellt. gematik_pki_x 509_SSL_Monitoring.doc Seite 6 von 42

7 2 Einführung 2.1 Zielsetzung und Einordnung des Dokuments Beim Datenaustausch im Rahmen des System und Service Level Monitoring müssen sich die Kommunikationspartner gegenseitig authentifizieren. Dabei werden X.509-Zertifikate genutzt, die gemäß den Vorgaben aus [gemsysslm] aus einer gesonderten (von den anderen PKIen der Telematikinfrastruktur getrennten) PKI stammen. In dem vorliegenden Dokument werden im Sinne eines s die wesentlichen Anforderungen an diese PKI beschrieben. Primäres Ziel dieses Dokuments ist es, den Leistungsumfang des TSP festzulegen, der die für das Ausstellen der benötigten X.509-Zertifikate zuständige CA betreibt. Dieses Dokument wird u. a. Bestandteil der Ausschreibung des Betriebs des TSP sein. Anmerkung: Die gematik wird (voraussichtlich) einen externen Dienstleister mit dem Betrieb des zentralen System und Service Level Monitoring beauftragen. Hierauf wird in diesem Dokument nicht weiter eingegangen. Es wird daher immer der Begriff gematik für den Betreiber des zentralen System und Service Level Monitoring verwendet. 2.2 Zielgruppe Das Dokument richtet sich im Wesentlichen an den TSP, der die CA-MON für das Ausstellen der benötigten X.509-Zertifikate für das System und Service Level Monitoring betreibt. Zusätzlich richtet es sich an die Betreiber einer Managementschnittstelle für den Austausch von Daten zwischen einem dezentralen System und Service Level Monitoring und dem zentralen System und Service Level Monitoring der gematik. Anhang A enthält die Beschreibung von Problemen, die sich aus Auswirkungen des System und Service Level Monitoring auf andere PKIen der Telematikinfrastruktur ergeben. Die Lösungen dieser Probleme müssen im Rahmen der Spezifikationen dieser PKIen gelöst werden. Aus den Lösungen werden sich dann Anforderungen an Betreiber eines Brokers und an Betreiber von OCSP-Respondern ergeben. 2.3 Geltungsbereich Die in diesem enthaltenen Vorgaben sind verbindlich für den TSP, der die CA- MON betreibt, sowie für alle Betreiber, die ein durch die CA-MON ausgestelltes X.509- Zertifikat für das System und Service Level Monitoring besitzen und nutzen. 2.4 Arbeitsgrundlagen Die wesentliche Grundlage für die Vorgaben des s bilden die folgenden Dokumente: gematik_pki_x 509_SSL_Monitoring.doc Seite 7 von 42

8 Spezifikation System und Service Level Monitoring [gemsysslm] Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] 2.5 Abgrenzung des Dokuments Die langfristige Bestimmung der Hash-Algorithmen, der Schlüssellängen und der Signatur- und Verschlüsselungsalgorithmen ist nicht Gegenstand der Betrachtung. Hier werden jeweils aktuell die Empfehlungen der international relevanten Gremien bzw. die Anforderungen von SigG/SigV [ALGCAT] berücksichtigt. Die Vorgaben für die Vereinheitlichung der Public-Key-Infrastrukturen, insbesondere hinsichtlich der Policy-Aspekte [gemtsl_sp_cp], werden in gesonderten Dokumenten getroffen. Im vorliegenden Dokument werden ebenfalls keine Aussagen zum Management der kryptographischen Schlüssel getroffen. Diesbezüglich wird auf das übergreifende Sicherheitskonzept der gematik [gemsiko] verwiesen, insbesondere auf Abschnitt F5 [gemsi- Ko#AnhF5]. Die für die Verwendung in der TI zulässigen Algorithmen, Schlüssellängen und maximalen Gültigkeitsdauern von Schlüsseln und Zertifikaten werden in [gemsiko] entsprechend der Technischen Richtlinie für ecard-projekte der Bundesregierung [BSI-TR03116] normativ vorgegeben. Die freie Auswahl aus den hier zugelassenen Algorithmen durch die Hersteller könnte zu Interoperabilitätsproblemen führen, während die Implementierung aller zulässigen Algorithmen erheblichen Aufwand verursacht. Dieser Konflikt wird durch [gemspec_krypt] adressiert. Ziel des Dokumentes Verwendung kryptographischer Algorithmen in der Telematikinfrastruktur [gemspec_krypt] ist es, das Spektrum der zulässigen kryptographischen Algorithmen, sofern sie betreiberübergreifend verwendet werden, einzuschränken, um so mit einer minimalen Anzahl von Algorithmen kryptographische Interoperabilität herzustellen. Deshalb wird als Basis zur Referenzierung der kryptographischen Algorithmen auf o. g. Dokument, Abschnitt [gemspec_krypt#5.1.1] bzw. relevante Unterabschnitte verwiesen. Detaillierte Vorgaben zur Validierung von Zertifikaten und der Listen der vertrauenswürdigen Herausgeber werden in [gemverw_zert_ti] gemacht. Das vorliegende Dokument trifft nicht die Festlegungen zu den tatsächlich einzutragenden OIDs, sondern verwendet stattdessen eine gematik-oid-referenz. Die normative Festlegung der OIDs trifft das Dokument [gemspec_oid], dort ist die jeweilige Zuordnung der hier verwendeten OID-Referenz zur registrierten OID ersichtlich. Aktuell behandelt dieses nur die Aspekte der Nutzung der PKI im Rahmen des System und Service Level Monitoring. Die Nutzung im Rahmen weiterer Anwendungen wie z. B. Zertifikate über Schlüssel für Signaturen über Code bzw. Konfigurationen werden dagegen aktuell nicht betrachtet. Dieses geht auf alle PKI-relevanten Aspekte ein, die sich aus dem System und Service Level Monitoring ergeben. Die aufgeführten Vorgaben werden dabei jedoch nicht im Detail ausgearbeitet. Dies muss vielmehr in folgenden weiteren Tätigkeiten erfolgen: gematik_pki_x 509_SSL_Monitoring.doc Seite 8 von 42

9 Für den Aufbau und Betrieb der CA-MON muss eine Feinspezifikation erstellt werden. Dies muss gemäß Ausschreibung der gematik durch den Auftragnehmer durchgeführt werden, der als TSP für alle Komponenten-PKIen durch die gematik beauftragt wird. In der gematik müssen Prozesse für die Registrierung der beteiligten Betreiber etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. In der gematik müssen Prozesse für die Sperrung (ggf. auch die Suspendierung und Desuspendierung) von Zertifikaten etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. In der gematik müssen Prozesse für eine unverzügliche Information aller Betreiber im Falle der Änderung ihres eigenen MON-Zertifikats etabliert werden. Hierfür muss die gematik entsprechende Konzepte erstellen und umsetzen. Für das zentrale System und Service Level Monitoring muss der Umgang mit der White-List der MON-Zertifikate der Betreiber spezifiziert werden. Dies muss im Rahmen der Konzeption und Umsetzung des zentralen System und Service Level Monitoring erfolgen. Die in Anhang A zusammengestellten Probleme, die sich aus dem System und Service Level Monitoring für andere PKIen ergeben, müssen im Rahmen der Spezifikationen dieser PKIen gelöst werden. 2.6 Methodik Verwendung von Schüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschen Schlüsselworte verwendet: MUSS bedeutet, dass es sich um eine absolutgültige und normative Festlegung bzw. Anforderung handelt. DARF NICHT bezeichnet den absolutgültigen und normativen Ausschluss einer Eigenschaft. SOLL beschreibt eine dringende Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. SOLL NICHT kennzeichnet die dringende Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. Wird die Anforderung nicht umgesetzt, müssen die Folgen analysiert und abgewogen werden. KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. gematik_pki_x 509_SSL_Monitoring.doc Seite 9 von 42

10 2.6.2 Hinweis auf offene Punkte Offene Punkte, die bis zur nächsten Dokumentenversion bearbeitet werden, sind vorläufig nach der folgenden Konvention gekennzeichnet. Das Kapitel wird in einer späteren Version des Dokumentes ergänzt. gematik_pki_x 509_SSL_Monitoring.doc Seite 10 von 42

11 3 Anforderungen Die Anforderungen müssen noch mit dem Anforderungsmanagement abgestimmt werden. Dieses Kapitel wird in einer späteren Version des Dokuments dann entsprechend vollständig überarbeitet. Die Notwendigkeit für eine PKI für die, für das System und Service Level Monitoring benötigten, X.509-Zertifikate ergibt sich direkt aus [gemsysslm]. Dabei müssen die folgenden wesentlichen Anforderungen berücksichtigt werden: Über die Managementschnittstelle DÜRFEN nur hierfür autorisierte Systeme kommunizieren. Teilnehmer des Management-VPN MÜSSEN sich authentisieren. Die gematik hat die Verantwortung für die Registrierung der berechtigten Teilnehmer. Die gematik MUSS die Interoperabilität dieser PKI sicherstellen. Es MUSS für die benötigten X.509-Zertifikate eine separate PKI aufgebaut und betrieben werden. Die X.509-Zertifikate werden nur im Rahmen der Kommunikation über die Managementschnittstelle zu dem Management-VPN genutzt. Die folgende Tabelle enthält die entsprechenden, bereits durch das Anforderungsmanagement erfassten relevanten Eingangsanforderungen: Tabelle 1: Bereits erfasste Eingangsanforderungen Quelle Anforderungsnummer Anforderungslevel Beschreibung gempolicy A_01298 MUSS gematik MUSS die Interoperabilität aller Telematikkomponenten sicherstellen. Dies gilt im Sinne der: * Spezifikationsverantwortung * Verantwortung für das Test- und Zulassungsverfahren * Betriebsverantwortung (Betriebsprozesse sowie das einzuhaltende Sicherheitsniveau) * Sicherstellung der Interoperabilität über alle PKI- Strukturen der Telematikinfrastruktur des Gesundheitswesens gemgesarch A_01260 MUSS Es MUSS sichergestellt sein, dass nur autorisierte Personen und Systeme über die Managementschnittstelle kommunizieren. gemsysslm A_01370 MUSS Das der Managementschnittstelle zugrunde liegende Netzwerk MUSS das System Management VPN sein. gemsysslm A_01399 MUSS Eine separate PKI MUSS zur Abdeckung sicher- gematik_pki_x 509_SSL_Monitoring.doc Seite 11 von 42

12 Quelle Anforderungsnummer Anforderungslevel Beschreibung heitsrelevanter Funktionalität im System und Service Level Monitoring System implementiert werden. Die für die Anwendungen der egk implementierten PKI der Telematikinfrastruktur DÜRFEN NICHT verwendet werden. gemsysslm A_01400 MUSS Die Registrierungsverantwortung der internen PKI zur Abdeckung sicherheitsrelevanter Funktionalität im System und Service Level Monitoring MUSS durch die zentralen Betriebsprozesse der gematik wahrgenommen werden. Neben den genannten Anforderungen MÜSSEN bei der PKI für das System und Service Level Monitoring auch die Vorgaben der Zertifizierungsrichtlinie der gematik [gemtsl_sp_cp] berücksichtigt werden. gematik_pki_x 509_SSL_Monitoring.doc Seite 12 von 42

13 4 PKI für das System und Service Level Monitoring 4.1 Grundlagen Gemäß [gemsysslm] sammeln die einzelnen Betreiber der dezentralen Services, die für das System und Service Level Monitoring (im Folgenden abkürzend mit MON bezeichnet) benötigten Daten in ihren eigenen Managementsystemen. Die für das zentrale System und Service Level Monitoring der gematik benötigten Daten, werden dann durch die einzelnen Betreiber an die gematik weitergeleitet. Die Betreiber und die gematik realisieren für diesen Datenaustausch die in [gemsysslm] spezifizierte Managementschnittstelle. Die folgende Abbildung (entnommen aus [gemsysslm]) zeigt die dabei verwendete Netzwerkarchitektur: Abbildung 1: Netzarchitektur dezentrales System und Service Level Monitoring Der Datenaustausch zwischen den Betreibern und der gematik erfolgt über ein separates Management-VPN. Durch [gemsysslm] sind hierfür die folgenden Vorgaben gegeben: Als Protokoll wird HTTPS verwendet. gematik_pki_x 509_SSL_Monitoring.doc Seite 13 von 42

14 Beim Verbindungsaufbau wird eine gegenseitige Authentisierung der beiden Kommunikationspartner durchgeführt. Bei der Authentisierung werden X.509-Zertifikate verwendet, die durch eine speziell hierfür zu betreibende PKI erzeugt werden. Im Rahmen der Authentisierung muss jede Seite die aktuelle Gültigkeit des Zertifikats der anderen Seite überprüfen. Bei dem Datenaustausch über die gematik-managementschnittsstelle ist die Größe der auszutauschenden Daten auf 10 MB beschränkt. Für große Datenmengen stellen die Betreiber und die gematik eine Up- und Download-Funktionalität für Software und Dateien zur Verfügung. Als Protokolle kommen HTTPS und SFTP dabei zum Einsatz. Eine Authentisierung der Kommunikationspartner findet ebenfalls statt, wobei X.509-Zertifikate aus der gleichen PKI genutzt werden. Beim Datenaustausch für das System und Service Level Monitoring findet eine Kommunikation immer zwischen einem Betreiber einerseits und der gematik andererseits statt. Eine direkte Kommunikation zwischen zwei Betreibern findet nicht statt. Aus logischer Sicht hat das Management VPN daher eine Sterntopologie mit der gematik als zentralen Knoten. Die folgende Abbildung zeigt die möglichen direkten Kommunikationswege: Management Schnittstelle Betreiber 2 Management Schnittstelle Betreiber 1 Management Schnittstelle Betreiber n Management Schnittstelle gematik Abbildung 2: Netztopologie für das dezentrale System und Service Level Monitoring Aus dieser logischen Sterntopologie können Vorgaben für die benötigte PKI abgeleitet werden, die den Aufbau und Betrieb insbesondere in Bezug auf das Verifizieren der Zertifikate wesentlich vereinfachen. Diese Punkte werden in den folgenden Abschnitten näher beschrieben. gematik_pki_x 509_SSL_Monitoring.doc Seite 14 von 42

15 4.2 Vertrauensmodell Alle X.509-Zertifikate für das System und Service Level Monitoring werden von einem zentralen TSP ausgestellt. Die gematik wird hierfür einen geeigneten Betreiber auswählen und mit dem Betrieb der CA beauftragen. Der TSP setzt für die Ausgabe der Zertifikate für das MON eine gesonderte (Sub-) CA- MON auf, die getrennt von CAs für andere PKIen der Telematikinfrastruktur betrieben wird. Das Zertifikat über den öffentlichen Schlüssel dieser (Sub-) CA-MON wird durch die Root-CA (Komponenten PKI) desselben TSP mit ihrem privaten Schlüssel signiert. Es ergibt sich somit folgende Hierarchie für die PKI für das System und Service Level Monitoring: TSP Root-CA Sub-CA Zertifikat Sub-CA Zertifikat Sub-CA Zertifikat Sub-CA PKI x CA-MON Sub-CA PKI y X.509 Zertifikat für SSLM X.509 Zertifikat für SSLM X.509 Zertifikat für SSLM Betreiber 1 Management Schnittstelle Betreiber n Management Schnittstelle gematik Management Schnittstelle Abbildung 3: Hierarchie PKI für System und Service Level Monitoring Alle Zertifikate für die Absicherung der Kommunikation zwischen dezentralem und zentralem System und Service Level Monitoring werden durch die gleiche CA-MON ausgestellt. Die Zertifikate werden auch nur zur Absicherung dieser Kommunikation eingesetzt. Die Anzahl der beteiligten Betreiber und damit die Anzahl der benötigten X.509-Zertifikate ist gering. Für die Verteilung dieser Zertifikate wird daher das folgende vereinfachte Vorgehen umgesetzt: Das aktuell gültige CA-Zertifikat der CA-MON wird auf der Webseite des TSP für einen Download zur Verfügung gestellt. Jeder beteiligte Betreiber (mit einem dezentralen System und Service Level Monitoring) sowie die gematik laden dieses Zertifikat von dieser Webseite. Die CA-MON stellt einen Fingerprint über sein CA-Zertifikat auf Anfrage schriftlich zur Verfügung. Siehe dazu auch den Abschnitt gematik_pki_x 509_SSL_Monitoring.doc Seite 15 von 42

16 gematik und Betreiber erhalten ihr X.509-Zertifikat für das Monitoring der CA-MON. Siehe dazu Abschnitt Das aktuell gültige X.509-Zertifikat für das Monitoring der gematik wird (zusätzlich) auf der Webseite der gematik und auf der Webseite des TSP für einen Download zur Verfügung gestellt. Jeder beteiligte Betreiber (mit einem dezentralen System und Service Level Monitoring) lädt dieses Zertifikat von einer dieser Webseiten. Die gematik informiert alle Betreiber per , falls sich ihr Zertifikat geändert hat. Die Betreiber laden dann das neue Zertifikat von einer der genannten Webseiten. Die gematik erhält von dem TSP eine White-List mit allen aktuell gültigen X.509-Zertifikaten für MON aller beteiligten Betreiber. Das genaue Vorgehen bei dem Austausch dieser White-List wird zwischen gematik und TSP bilateral abgestimmt. Die im Rahmen des Verbindungsaufbaus zwischen der gematik und einem Betreiber notwendige Überprüfung des Zertifikats des jeweiligen Kommunikationspartners kann bei diesem Vorgehen rein lokal geschehen. Eine Online-Überprüfung z. B. durch eine OCSP- Abfrage wird nicht benötigt. 4.3 Zertifikatsaufbau Der Aufbau der Zertifikate für Betreiber bzw. für die gematik MUSS dem Zertifikatsprofil C.SF.SSL entsprechen. Für das CA-Zertifikat MUSS das Profil C.SF.CA mit den Festlegungen für CAs von SSL- Zertifikaten eingerichtet werden. Diese Profile werden im Dokument Festlegungen zu den X.509-Komponentenzertifikaten der Server und (Fach-) Dienste [gemx.509_sd] definiert. Sie beschreiben Inhalt und Kodierung der Zertifikatsfelder bzw. Extensions. In diesem Kapitel werden nur die Zertifikatseigenschaften aufgeführt, deren Definition für System und Service Level Monitoring präzisiert werden muss Festlegungen zur Definition der Betreiber- bzw. gematik-identität Die Identität eines Betreibers bzw. der gematik ist durch den Inhalt des Feldes SubjectDN (subject distinguishedname) des X.509-Zertifikats für MON gegeben Übersicht: Attribute im SubjectDN (X.509-Zertifikat für MON) Tabelle 2: Attribute im SubjectDN Attribut OID Kodierung max. String-Länge Art commonname {id-at 3} UTF8 64 Pflicht givenname {id-at 42} UTF8 64 P serialnumber {id-at 5} PrintableString 64 P gematik_pki_x 509_SSL_Monitoring.doc Seite 16 von 42

17 streetaddress {id-at 9} UTF8 128 Option postalcode {id-at 17} UTF8 40 O localityname {id-at 7} UTF8 128 O stateorprovincename {id-at 8} UTF8 128 O organizationalunitname {id-at 11} UTF8 64 O organizationname {id-at 10} UTF8 64 P countryname {id-at 6} PrintableString 2 (ISO 3166 Code) P Die Eindeutigkeit der Identität eines Betreibers (bzw. der gematik) innerhalb der Telematikinfrastruktur ist bereits durch den Inhalt des Attributs commonname innerhalb des SubjectDN gegeben ([gemsysslm]). Zusätzlich enthält SubjectDN noch den Namen und das Land des Betreibers als weitere Pflichtangaben. Optionale Felder mit der Anschrift des Betreibers bzw. dem Namen einer relevanten Abteilung können ebenfalls in einem X.509-Zertifikat für das Monitoring enthalten sein Nutzung der Attribute im SubjectDN commonname Datenfeld: FQDN. Es MUSS der durch die gematik für die Managementschnittstelle des Betreibers vergebene FQDN eingetragen werden (näheres siehe 4.4.1). Feld Länge Kardinalität Datentyp Format Durch die gematik vergebener FQDN der Managementschnittstelle givenname AN UTF-8 Datenfeld: Name des Services. Zurzeit MUSS hier der konstante Wert "Managementschnittstelle" eingetragen werden. Zukünftig kann es hier zu Erweiterungen kommen. Feld Länge Kardinalität Datentyp Format Zurzeit konstanter Wert "Managementschnittstelle" serialnumber AN UTF-8 Datenfeld: Laufende Nummer der Komponente. Zurzeit MUSS der Wert "1" eingetragen werden. Zukünftig kann es hier zu Erweiterungen kommen. Feld Länge Kardinalität Datentyp Format Zurzeit konstanter Wert "1" AN Printable- String streetaddress Datenfeld: Straßenanschrift des Betreibers gematik_pki_x 509_SSL_Monitoring.doc Seite 17 von 42

18 Feld Länge Kardinalität Datentyp Format Straße Hausnummer (mehrere Wörter sind durch Blank getrennt) AN UTF-8 postalcode Datenfeld: Postleitzahl des Betreibers Feld Länge Kardinalität Datentyp Format Postleitzahl Deutsche Postleitzahlen werden in einer Länge von 5 Byte abgebildet localityname Datenfeld: Stadt des Betreibers AN UTF-8 Feld Länge Kardinalität Datentyp Format Stadt AN UTF-8 stateorprovincename Datenfeld: Bundesland der Anschrift des Betreibers Feld Länge Kardinalität Datentyp Format Bundesland AN UTF-8 organizationalunitname Datenfeld: Name der relevanten Einheit des Betreibers. Feld Länge Kardinalität Datentyp Format Name der relevanten Einheit des Betreibers. organizationname AN UTF-8 Datenfeld: Name des Betreibers. Es MUSS der gleiche Name eingetragen werden, wie er im Rahmen der Zulassung/Registrierung des Betreibers durch die gematik genannt wurde. Feld Länge Kardinalität Datentyp Format Name des Betreibers: Angabe wie bei der Registrierung durch die gematik (Ist die maximal zulässige Länge des Namens überschritten, muss dieser zusätzlich in die X.509-Extension SubjectAltNames (GeneralDN) eingetragen werden.) AN UTF-8 gematik_pki_x 509_SSL_Monitoring.doc Seite 18 von 42

19 countryname Datenfeld: Land der Anschrift des Betreibers Feld Länge Kardinalität Datentyp Format countryname AN Printable String Aufbau der serialnumber im Feld SubjectDN Zurzeit MUSS immer der konstante Wert "1" in das Attribut serialnumber aufgenommen werden, da bereits durch den Inhalt des Attributs commonname eine Managementschnittstelle eindeutig identifiziert wird (siehe auch [gemsysslm]). Zukünftig kann es hier jedoch zu Erweiterungen kommen, z. B. falls die Managementschnittstelle (aus Gründen der Hochverfügbarkeit) redundant mehrfach bei einem Betreiber vorhanden ist. Von der eindeutigen Seriennummer der Komponente muss die eindeutige Nummer des X.509-Zertifikats unterschieden werden. Diese wird durch die ausstellende CA (ganze Zahl, 1<=serialNumber<= ) definiert und ist nur innerhalb der Domäne der CA eindeutig zuzuordnen Aufbau des gesamten SubjectDN Der SubjectDN eines Betreibers bzw. der gematik setzt sich wie folgt zusammen (Optionale Daten sind grau hinterlegt): commonname = [FQDN], givenname = Managementschnittstelle, serialnumber = 1, streetaddress = [Straße und Hausnummer], postalcode = [Postleitzahl], localityname = [Stadt] stateorprovincename = [Bundesland], organizationalunitname = [Relevante Einheit des Betreibers], organizationname = [Name des Betreibers], countryname = [Herkunftsland des Betreibers, z. B. DE] Die Werte der Attribute givenname und serialnumber enthalten zurzeit die angegebenen konstanten Werte. Zukünftig kann es hier zu Erweiterungen kommen Notwendige Zertifikatsfelder Abweichend von Kapitel 5.3 Notwendige Zertifikatsfelder aus dem Dokument Festlegungen zu den Komponentenzertifikaten der Server- und (Fach-) Dienste [gemx.509_sd#5.3] ist die Extension AuthorityInfoAccess in allen Monitoring-Zertifikaten optional. Die folgende Tabelle gibt einen Überblick über die möglichen Extensions, die in einem Zertifikat enthalten sein MÜSSEN (P) bzw. enthalten sein KÖNNEN (O): Tabelle 3: Überblick der im Zertifikat enthaltenen Extensions Betreiberzertifikat (C.MGMTSS.SSL) CA-Zertifikat (C.MGMTSS.CA) SubjectKeyIdentifier O O gematik_pki_x 509_SSL_Monitoring.doc Seite 19 von 42

20 Betreiberzertifikat (C.MGMTSS.SSL) CA-Zertifikat (C.MGMTSS.CA) BasicConstraints - P KeyUsage P P SubjectAltNames O O CertificatePolicy P P CRLDistributionPoint O O AuthorityKeyIdentifier O O Admission P O AdditionalInformation P O ExtendedKeyUsage P O Die Extension BasicConstraints MUSS für das CA-Zertifikat den Wert "CA:true enthalten. Die Extension KeyUsage MUSS für ein Betreiberzertifikat den Wert "digitalsignature enthalten. Zusätzlich KANN der Wert "keyencipherment enthalten sein. Für das CA-Zertifikat MUSS die Extension den Wert "keycertsign enthalten. Die Extension ExtendedKeyUsage MUSS für ein Betreiberzertifikat die Werte "serverauth und "clientauth enthalten. Für die OIDs der anzugebenden Werte siehe [ISIS-MTT]. In allen Komponentenzertifikaten wird in der Extension Admission die technische Rolle des Zertifikatsinhabers (hier Management Schnittstelle [gemgesarch#anhb1]) angegeben. Die genaue Festlegung der OID erfolgt verbindlich im Dokument [gemspec_oid]. Zur Unterscheidung von Endnutzerzertifikaten wird neben den Referenzen auf die Policies auch der jeweilige Zertifikatstyp (OID) in der Extension AdditionalInformationCertificatePolicy gespeichert. Die genaue Festlegung der Inhalte erfolgt nun verbindlich im Dokument [gemspec_oid]. Die Kennzeichnung des Zertifikatstyps in der Extension AdditionalInformation kann sicherheitsrelevant sein. Es MUSS daher eine entsprechende Schutzbedarfsfeststellung im Rahmen des übergreifenden Sicherheitskonzepts der gematik durchgeführt werden. Die Schutzbedarfsfeststellung MUSS durchgeführt werden. Bis auf die Extension KeyUsage werden alle Extensions auf "nicht kritisch" gesetzt. Dieses ermöglicht den Einsatz der Zertifikate auch außerhalb der TI und innerhalb von ggf. zum Einsatz kommender Standardsoftware. Falls der Wert einer Extension für die Ablaufsteuerung einer Komponente der TI benötigt wird, MUSS diese Komponenten der TI jedoch die Extension korrekt auswerten. Dieses MUSS durch die Ablaufsteuerung dieser Komponenten sichergestellt werden. gematik_pki_x 509_SSL_Monitoring.doc Seite 20 von 42