Konfigurationsdaten für die PKI der elektronischen Arztausweise, Version 2.3.8

Transkript

1 Bundesärztekammer, Berlin Identifikation des Dokuments: Konfigurationsdaten für die PKI, Bundesärztekammer Revisions-Datum.: :06 Nr.:8 C:\Users\LFriebel\AppData\Local\Temp\notesD7379A\ _Spec_Konfigurationdaten_eA_V2.3.8.doc

2 Seite 2 von 21 Datum Name, Abteilung, Firma Autor, Ansprechpartner Dirk Schladweiler, Georgios Raptis Status (Dezernat Telematik, BÄK) Freigegeben Versionshistorie Version Datum Bearbeiter Änderungen Bemerkungen Georgios Raptis Initiale Version Georgios Raptis Einarbeitung Kommentare (Hr. Stachwitz) QS Dirk Schladweiler Kap. 2 ergänzt, QS und Ergänzungen Dirk Schladweiler Komplette Überarbeitung Dirk Schladweiler Differenzierung der Kartentypen Georgios Raptis Definition: Zertifikatsanforderungen für die Tests Kapitel 2.2, s. 9. Insb. Benennungskonzept für Zertifikate Dirk Schladweiler Löschen des alten Fahrplans und QS Georgios Raptis QS Präzisierung Namenskonzept Georgios Raptis WICHTIG: CV-CA- Kennungen + Kennzeichnung Chipkarten Dirk Schladweiler -Aktualisierung -Kartendifferenzierung und Tab Georgios Raptis -Korrekturen, QS Dirk Schladweiler Hinweis auf Laminierung der Kartenoberfläche nach der Personalisierung und Bedruckung der Aufschrift MUSTER angebracht. Bundesärztekammer :06:00 Seite 2 von 21

3 Seite 3 von Dirk Schladweiler Umstellung und Ergänzung der Tabelleninhalte Esther Freese QS Zeitliche Abbildung der Liefergegenstände auf die gematik-meilensteinplanung Kap. Bereitstellung von Entwicklerkarten[ARZT] für Entwickler Differenzierung *[Arzt] hinzugefügt Vorgehen für die Sicherstellung der Versorgung der Testung mit Komponenten Dirk Schladweiler Finalisierung, QS Georgios Raptis Kap. 5 angepasst, ergänzt Schladweiler Finalisierung, QS Esther Freese QS Schladweiler Fertigstellungszustand und Konfigurations-Data eingefügt Dirk Schladweiler OID eingefügt Dirk Schladweiler Kap. Sizing eingefügt Dirk Schladweiler Kap. Nummerräume und ZDA-Spezifika eingefügt Georgios Raptis QS, Klarstellungen im Kapitel Esther Freese Änderungen opt. Designvorgaben Dirk Schladweiler Aktualisierung, Überarbeitung Georgios Raptis Änderung des Namens, Ergänzungen + HPCqSIG + medisign - Kap. 6 Zeitplan Alter Name ist Fahrplan für die Versorgung mit HBA für die Testmaßnahmen Dirk Schladweiler Final-QS zur Konsolidierung Bundesärztekammer :06:00 Seite 3 von 21

4 Seite 4 von Georgios Raptis Ergänzung Policy-OID für Ausweise für Kammermitarbeiter Dirk Schladweiler Änderung des Namens DGN in dgnservice lt. Mail v Dirk Schladweiler Nummernkreise für ZDA- Webdienste etc Georgios Raptis Konsolidierung zum Paket V2.3.1 NAMENSÄNDERUNG. Alter Name ist: Spezifikation von Kartentypen für Testmaßnahmen, URLs, Nummernräume und OIDs, Version Konfigurationsdaten für Zertifikate aufgenommen TestOID TestFacharzt Georgios Raptis Testkarten[ARZT] ohne Attributzertifikat (gem. Beschluss der ÄK) Getrennte CAs für ENC und AUT sind zulässig Georgios Raptis Ergänzung Verifikationschipkarte Dirk Schladweiler Georgios Raptis Georgios Raptis Dirk Schladweiler Dirk Schladweiler Aktualisierung der Referenzen Seriennummer/ICCSN Präfixe für ÄK und Projekte Präfixe für BezÄK in Rheinland-Pfalz für die Ausweisnummer, Tab. 5-1, Policy- OID für die Zertifikate Nummernkreise für Entwicklerkarten[ARZT] für die Test- und Erprobungsmaßnahmen eingeführt Bundesärztekammer :06:00 Seite 4 von 21

5 Seite 5 von Dirk Schladweiler Änderung der Mailadresse für den Bezug von Entwicklerkarten (telematik@baek.de) Aufteilen der Tabelle für die ICCSN Nummernkreise der ZDA und der Seriennummer-Nummernkreise für die LÄKs für ein leichteres Verständnis Referenzen aktualisiert Erstellung eines gesonderten Kap. ERPROBUNG: Nummernkreise für von den Ärztekammern generierte Vorgangsnummern Tab9.1 Policy-OIDs für die qsig, qattr, QES eingefügt Fertigstellungszustand Lfd Nr. Probleme / Offene Punkte / Defizite Ursachen Maßnahmen / Lösungen Kapitelverweis Bundesärztekammer :06:00 Seite 5 von 21

6 Seite 6 von 21 Inhalt 1 EINLEITUNG Zielsetzung 6 2 KARTENTYPEN 7 3 OBJECT IDENTIFIER UND ISSUER IDENTIFICATION NUMBER 11 4 URLS IM KONTEXT DER ELEKTRONISCHEN ARZTAUSWEISE 13 5 ICCSN-NUMMERNRÄUME DER ZDAS 13 6 SERIENNUMMER DER KAMMERN FÜR ARZTAUSWEISEN IM ID-1 FORMAT 14 7 NUMMERNRÄUME FÜR VORGANGSNUMMERN DER ZDA-WEBDIENSTE 16 8 ERPROBUNG: NUMMERNKREISE FÜR VON DEN ÄRZTEKAMMERN GENERIERTE VORGANGSNUMMERN 17 9 BEREITSTELLUNG VON HBA-ENTWICKLERKARTEN[ARZT] FÜR ANWENDUNGSENTWICKLER AUßERHALB DER TESTMAßNAHMEN DER GEMATIK KONFIGURATIONSDATEN DER ZERTIFIKATSPROFILE Admission im Basis-Signaturzertifikat Nicht-qualifizierte CA-Zertifikate Policy-OIDs für elektronische Arztausweise der Generation 2 (HPC- Spezifikationsversion ab 3.0.0) CRLDistributionPoints und AuthorityInfoAccess Weitere Spezifische Konfigurationsdaten der X.509-Zertifikate auf HBA- Entwicklerkarten[ARZT] REFERENZEN 21 1 Einleitung 1.1 Zielsetzung Dieses Dokument enthält Konfigurationsdaten zur PKI der elektronischen Arztausweise. Die Version des Dokuments korrespondiert mit der Version der Dokumente ([baekcerts], [baekattr]), welche spezifisch die Zertifikatsprofile definieren. Eine Versionierung dieses Dokumentes erfolgt deshalb über die Revisionsnummer und das Datum. Konfigurationsdaten sind Daten in der PKI der earztausweise, die geändert werden können, ohne die Spezifikationsdokumente anpassen zu müssen. Typischerweise gehören zu den Konfigurationsdaten Eigenschaften der Zertifikatsprofile, wie die Policy-OIDs und URLs, Algorithmen, die Inhalte der Admission (OIDs und professionitem), sowie Eigenschaften von Bundesärztekammer :06:00 Seite 6 von 21

7 Seite 7 von 21 CRL-, OCSP-Profilen und Verzeichnisdienst-Eigenschaften. Das Vorhandensein der Admission-Extension im Public-Key-Signaturzertifikat oder die Existenz und Attributwerte von Attributzertifikaten werden ebenfalls hier festgelegt. Werden in diesem Dokument keine Werte für Konfigurationsdaten definiert, gelten die Ausgangswerte in den Spezifikationen (Def. s. o.). Darüber hinaus können hier Übergangszeiträume für eine Änderung der Konfigurationsdaten definiert werden. In diesem Dokument werden u. a. die von der Bundesärztekammer (BÄK) vergebenen OIDs definiert. 2 Kartentypen Die folgenden Begriffe sind für Karten mit genannten Eigenschaften zu verwenden. Als elektronischer Arztausweis (G2), Wirkbetriebs- oder Echtkarten der Generation 2 werden ausschließlich Chipkarten gemäß der aktuellen HPC-Spezifikation ab Version und mit dem beschlossenen Design für den elektronischen Arztausweis angesehen. Diese Karten sind konform zur Gemeinsamen Policy Version Die optische Personalisierung erfolgte in einem hochwertigen Druckverfahren. Diese Karten enthalten als Sicherheitsmerkmal ein Hologramm, sind mit CV- (G2) und X.509-Schlüsseln und Zertifikaten der Wirkbetriebsumgebung ausgestattet. Diese Karten sind realen Ärzten zugeordnet und über bestätigte Prozesse an diese ausgegeben. Darüber hinaus sind die Karten nach dem deutschen Signaturgesetz bestätigt. Unter diesem Begriff fallen auch sogenannte Ersatzausweise und Reserveausweise (siehe [baekglossar]), soweit sie über qualifizierte Zertifikate verfügen. HPCqSIG, earztausweis (G0) sind nach SigG bestätigte Karten, die bereits vor Aufnahme des TI-Wirkbetriebs an Heilberufler (Ärzte) ausgegeben werden. Diese Karten unterstützen nicht die Authentifizierung gegenüber egks mit Hilfe von CV- Zertifikaten, sondern sollen zielrichtend nach bestätigten Prozessen ausgegeben werden und in sonstigen Telematikprojekten der Ärzteschaft für Authentifizierungen (ESIGN) und digitale Signatur (QES) jeweils mit mind. 2048bit RSA Einsatz finden. Die Karten werden nach dem beschlossenen Design des earztausweises bedruckt und enthalten als Sicherheitsmerkmal ein Hologramm. Sie müssen konform zur HPC- Spezifikation (insbesondere in Bezug auf die Nutzung der X.509-Zertifikate und Schlüssel) mit Ausnahme der Funktionalitäten, die für die Interaktion mit der egk notwendig sind, sowie zur Gemeinsamen Policy Version D. h. sie müssen nicht zwingend CV-Zertifikate enthalten, logische Kanäle unterstützen usw. Diese Karten unterliegen den Anforderungen an das optische Design der elektronischen Arztausweise und enthalten ebenso ein Hologramm. Als HBA-Musterkarten[ARZT] werden alle weiteren Karten, auch solche ohne Chip, aber im optischen Design des elektronischen Arztausweises angesehen. Diese Karten sind klar mit einem Schriftzug MUSTER als solche kenntlich zu machen. Vorgaben für das Druckverfahren bestehen nicht, außer es werden Musterkarten im Rahmen von Produktionstests erstellt. Das Kartenbetriebssystem ist nicht konform zu einer HPC-Spezifikation. Diese Karten haben grundsätzlich kein Hologramm, es sei denn, sie wurden zu dem Zweck der Begutachtung und erster Tests von Kartenkörpern mit Hologramm hergestellt. Bundesärztekammer :06:00 Seite 7 von 21

8 Seite 8 von 21 Als HBA-Entwicklerkarten[ARZT] werden Chipkarten verstanden, welche nicht im Design des earztausweises bedruckt sind, jedoch elektrisch konform mindestens zur HPC-Spezifikation und bzgl. CV- und X.509-Zertifikaten beschlüsselt bzw. ableitbar aus den übergreifenden Test-Hierarchien personalisiert sind. Diese Karten werden zu Entwicklungszwecken zur Verfügung gestellt. Durch den ZDA erfolgt die Verwaltung der Information, an welche Entwickler (welche) HBA- Entwicklerkarten[ARZT] geliefert wurden. Auf Verlangen ist diese Information der BÄK zur Verfügung zu stellen. Der ZDA soll diese Karten für die Verwaltung geeignet optisch personalisieren. Als HBA-Verifikationschipkarte[ARZT] werden Chipkarten verstanden, die für technische Tests gegenüber egks oder weiteren Systemen verwendet werden. Sie werden NICHT im Design des earztausweises bedruckt, sind mit dem Namen und die Organisation des Anforderers beschriftet und tragen den Schriftzug Verifikationskarte. Diese Karten werden mit CV- und X.509-Zertifikaten aus dem Vertrauensraum von Test-HBA[ARZT] oder Wirkbetriebs- oder Echtkarten personalisiert, jedoch nicht an echte Ärzte ausgestellt. Als Bestätigende Stelle für das Arztattribut im Feld admissionauthority muss O=Verifikationschipkarte,C=DE enthalten sein. In den X.509-Zertifikaten müssen im CN die Zeichenkette Verifikationschipkarte und der Name des Verantwortlichen enthalten sein. Verifikationschipkarten[ARZT] werden nach Genehmigung durch die BÄK von einem ZDA ausgestellt. Der Empfänger der Karte muss dafür erklären, dass er die Karte nur für Test- und Verifikationszwecken einsetzen wird, und dass er organisatorische und technische Maßnahmen treffen wird, damit kein missbräuchlicher Zugriff auf echte Patientendaten erfolgen kann. HPC-Prototypen sind Karten, die nicht dem Design des earztausweises unterliegen, konform zur jeweils aktuellen HPC-Spezifikation sind und nicht über die übergreifende CV-Root und BÄK-Root beschlüsselt sind. Diese Karten unterliegen der Hoheit und Verwaltung des jeweiligen Produzenten. Diese Karten dienen bspw. zur Erlangung des gematik-vorab-prüfsiegels für die Komponente Karte und sind damit die Grundlage für eine spätere Zulassung als Basis für den earztausweis. Arztausweise sind alle sonstigen von Ärztekammern herausgegebenen Ausweise, die die Arzteigenschaft bestätigen. Diese Arztausweise können im Chipkartenformat auch im Design der earztausweise oder auch als Papierausweis ausgegeben werden. Bundesärztekammer :06:00 Seite 8 von 21

9 Konform zur Spezifikation der HPC/SMC Ableitbar zur Test- CVC- Root Ableitbar zur Wirk-CVC- Root Ableitbar zur Test-X.509- Root Ableitbar zur Wirk-X.509- Root Ableitbar zur BNetzA für qsig Tabelle 2-1: Übersicht Kartendifferenzierung HPC- Prototypen HBA- Entwicklerkarten [ARZT] HBA- Musterkarten [ARZT] HBA-Verifikationschipkarte [ARZT] X X - X HPCqSIG (earztausweis G0) mit Einschränkungen e-arztausweis (G2) - X X - X - X - (X) (X) (X 1 ) X (X) X X PKI-Dienste - X - X X X gematik Zulassung X (ggf. beschränkte opt. - X - X ggf. dedizierte Root und/oder Policy Identifikation des Dokuments: Konfigurationsdaten für die PKI, Bundesärztekammer Revisions-Datum.: :06 Nr.:8 C:\Users\LFriebel\AppData\Local\Temp\notesD7379A\ _Spec_Konfigurationdaten_eA_V2.3.8.doc

10 Seite 10 von 21 Optische Identifizierung der Karten 2 Design earztausweis HPC- Prototypen Zulassung) Geeignet für Verwaltung durch gematik HBA- Entwicklerkarten [ARZT] Geeignet für Verwaltung durch BÄK (Übernahme der gematik- Vorgaben für HPC- und egk- Prototypen) HBA- Musterkarten [ARZT] Schriftzug MUSTER HBA-Verifikationschipkarte [ARZT] Schriftzug Verifikationschipkarte HPCqSIG (earztausweis G0) e-arztausweis (G2) Schriftzug qsig X 4 - X 2 X 2 Hologramm - - opt. - X X Auf reale Ärzte X X 2 Die ZDA werden gebeten, im optischen Design vorzugsweise in ZDA-spezifischen Feldern (ZDA-Logo, Magnetstreifenfeld) eine geeignete selbstverwaltete Versionierung der Kartenserie vorzunehmen. Eine geeignete optische Identifizierung soll auch für HBA-Entwicklerkarten[ARZT] und HPC-Prototypen (durch Chipkartenhersteller [CKH]) vorgesehen werden. Hierfür gelten die gleichen Anforderungen wie für die egk-testkarten der gematik. 3 der Schriftzug qsig kann als Teil der Versionierungs-Kennzeichnung der Karte aufgebracht werden, d.h. auf der Rückseite 4 Für alle Kartentypen, die das beschlossene Design des Arztausweises tragen, gelten die Bestimmungen der optischen Personalisierung und ggf. Zusatzinformation zur Kennzeichnung des Kartentyps (Aufbringung der MUSTER- bzw. TEST-Kennzeichnung). Zum Schutz der Karten(-bedruckung) ist eine Laminierungsschicht aufzubringen. Bundesärztekammer :06:00 Seite 10 von 21

11 Seite 11 von 21 HPC- Prototypen HBA- Entwicklerkarten [ARZT] HBA- Musterkarten [ARZT] HBA-Verifikationschipkarte [ARZT] HPCqSIG (earztausweis G0) e-arztausweis (G2) bezogen 3 Object Identifier und Issuer Identification Number Der BÄK ist die OID von der IANA zugewiesen. Folgende OIDs werden im Kontext der elektronischen Arztausweise definiert. Tabelle 3-1: Object Identifier OID Name Bemerkung id-baek Bundesärztekammer / BÄK id-baek-cp Certificate Policy >>>> id-baek-cp-hbatestkartearzt alt: HBA-Testkarte[ARZT] (Inhaber ist Ärztin/Arzt) >>>> id-baek-cphbaentwicklerkartearzt HBA-Entwicklerkarte[ARZT] (Inhaber ist KEIN Arzt) >>>> id-baek-cp-earztausweisv1 Policy (Version 1) für den elektronischen Arztausweis (G0, HPCqSIG) mit qualifizierter Signatur, konform zur Gemeinsamen Policy V >>>> id-baek-cpmitarbeiteraerztekammerv id-baek-at (BÄK Attribute) Policy (Version 1) für Ausweise für Mitarbeiter der Ärztekammern, nach dem Dokument Ausweise für Kammermitarbeiter. Kein Heilberufsausweis Bundesärztekammer :06:00 Seite 11 von 21

12 Seite 12 von 21 OID Name Bemerkung id-baek-atnamingauthorityärzteschaft >>>> id-baek-at- namingauthorityärzteschaft- Ärztin/Arzt >>>> id-baek-at- namingauthorityärzteschaft- TestFacharzt (gemeinsames Attribut für alle Ärztekammern) (OID für das Berufsgruppenattribut ÄRZTIN/ARZT) (OID für Testzwecken, kennzeichnet ein fiktives Attribut TestFacharzt >>>> hpcfield (Fachrichtung) >>>> hpc hpceainhaberid (eainhaberid (bundeseinheitliche Arztnummer, BAN)) >>>> hpcenccertificateserial- Number (Seriennummer des Verschlüsselungszertifikats) >>>> hpcenccertificateissuer (Aussteller des Verschlüsselungszertifikats) id-baek-oc (BÄK Objektklassen) >>>> hpcperson (Objektklasse für Attribute der HPC) id-baek-nf (BÄK Name Forms) Alle OIDs, die mit " >>>>" gekennzeichnet sind, werden entweder in Zertifikaten oder im LDAP-Schema produktiv eingesetzt. Eine Issuer Identification Number wird als Bestandteil einer ICC Serial Number nach EN1867 gemäß der jeweils aktuellen HPC-Spezifikation in sämtlichen elektronischen Arztausweisen sowie Test- und Entwicklerkarten eingesetzt. Die BÄK hat folgende Issuer Identification Number: Bundesärztekammer :06:00 Seite 12 von 21

13 4 URLs im Kontext der elektronischen Arztausweise URL für die Signaturpolicy (Version 1) des elektronischen Arztbriefes nach [extern1] URL für die Policy der Root-Zertifikate der BÄK URL für die Policy der CA-, CROSS-, CRLSigner- und OCSPSigner-Zertifikate, die von der BÄK ausgestellt werden. URL für die Policy der Zertifikate der elektronischen Arztausweise URL für den LDAP-Server des Trustcenters der BÄK (nur G0-eArztausweise) ldap://ldap.e-arztausweis.de:389 URL für den LDAP-Server des Trustcenters der BÄK für die Entwickler- und TesteArztausweise (nur G0-eArztausweise) ldap://testldap.e-arztausweis.de:389 URL für den OCSP-Responder des Trustcenters der BÄK (nur G0-eArztausweise) URL für den OCSP-Responder des Trustcenters der BÄK für die Entwickler- und TesteArztausweise (nur G0-eArztausweise) 5 ICCSN-Nummernräume der ZDAs Es besteht die Anforderung nach ZDA-übergreifender Eindeutigkeit der ICCSNs aller earztausweise. Diese soll durch eine für alle zugelassenen ZDA verbindliche Verwendung von Nummernräumen erfolgen. Identifikation des Dokuments: Konfigurationsdaten für die PKI, Bundesärztekammer Revisions-Datum.: :06 Nr.:8 C:\Users\LFriebel\AppData\Local\Temp\notesD7379A\ _Spec_Konfigurationdaten_eA_V2.3.8.doc

14 Seite 14 von 21 Für earztausweise: Auf Kartenebene sind die Nummernräume (2 BCD-Stellen) in die ICCSN als führender Bestandteil der SerialNumber, direkt hinter dem Issuer Identifier der BÄK, zu integrieren. Auf Zertifikatsebene ist die ZDA-übergreifende Eindeutigkeit durch die Verwendung desselben Nummernraumes an führender Stelle des Attributes "serialnumber" in allen Zertifikaten sicherzustellen. Tabelle 5-1: ICCSN-Nummernräume Lfd. Nr. bzw. Kammercode Zertifizierungsdiensteanbieter 0 D-TRUST (Bundesdruckerei) 10 1 Signtrust 11 2 T-Systems Telesec 12 3 S-Trust 13 4 Cybertrust 14 5 DGNservice 15 6 medisign 16 7 Entwicklerkarten[ARZT]: D-TRUST (Bundesdruckerei) 8 Entwicklerkarten[ARZT]: T-Systems Telesec 22 9 Entwicklerkarten[ARZT]: DGNservice Entwicklerkarten[ARZT]: medisign 26 Nummernkreis 11 earztausweis light (ÄKNo & ÄKWL) und Beispiel-ICCSN: (siehe auch Tabelle F.1 HPC-Part II) '80' '276' '00108' ' ' D-TRUST '80' '276' '00108' ' ' Signtrust Die ICCSN wie auch das SubjectDN-Attribut serialnumber werden vom ZDA durch Variation des Nummernteils nach dem Präfix vergeben und eindeutig gehalten. Anmerkung: Sobald die Nummernräume erschöpft sind, wird die BÄK weitere Bereiche zuordnen. 6 Seriennummer der Kammern für Arztausweisen im ID-1 Format Entsprechend der Präfixe für die ICCSNs der ZDA sollen die Arztausweise im ID-1-Format (Plastikkarten), die von den Kammern selbst produziert und ausgegeben werden, die Se- Bundesärztekammer :06:00 Seite 14 von 21

15 Seite 15 von 21 riennummer analog bilden. Hierfür wurden u.g. Nummernkreise eingerichtet, die den verschiedenen Nummerncodes der Kammern zugeordnet sind. Somit besteht die Anforderung nach Ärztekammer-übergreifender Eindeutigkeit der Seriennummer aller (nichtelektronischen) Arztausweise. Diese soll durch eine für alle Ärztekammern verbindliche Verwendung von Nummernräumen erfolgen: Für Arztausweise im ID-1 Format: die Eindeutigkeit der Seriennummer ist nach demselben Prinzip wie die ICCSN der earztausweisen zu bilden Tabelle 6-1: Nummernräume der Seriennummer Kammercode Ärztekammer Nummernkreis 010 ÄK Schleswig-Holstein ÄK Hamburg ÄK Niedersachsen ÄK Bremen ÄK Nordrhein ÄK Westfalen-Lippe LÄK Hessen LÄK Rheinland-Pfalz LÄK Baden-Württemberg Bayerische LÄK ÄK Saarland ÄK Berlin ÄK Mecklenburg-Vorpommern LÄK Brandenburg ÄK Sachsen-Anhalt LÄK Thüringen Sächsische LÄK Bezirksärztekammer Rheinhessen Bezirksärztekammer Pfalz Bezirksärztekammer Trier Bezirksärztekammer Koblenz 70 Beispiel-Seriennummer: '80' '276' '00108' ' ' '80' '276' '00108' ' ' LÄK Thüringen ÄK Westfalen-Lippe Bundesärztekammer :06:00 Seite 15 von 21

16 Seite 16 von 21 Anmerkung: Sobald die Nummernräume erschöpft sind, wird die BÄK weitere Bereiche zuordnen. 7 Nummernräume für Vorgangsnummern der ZDA-Webdienste Es besteht die Anforderung nach Eindeutigkeit der Vorgangsnummern, die von den ZDA- Webdiensten oder den KammerClients (bei Vorbefüllung) erzeugt werden. Um dies zu erreichen, sind die u. g. Nummernräume eingerichtet, die an entsprechender Stelle in die Vorgangsnummer einzubinden sind. Diese ZDA-spezifischen Nummernräume werden ebenso in eine spätere Version der Technischen Richtlinie der Ärztekammern übernommen. Für die Kammerspezifischen Nummernräume werden die Nummern aus Kap der Technischen Richtlinie der Ärztekammern verwendet. Falls in einer Ärztekammer mehrere KammerClient-Installationen betrieben werden, muss die betreibende Ärztekammer durch sich an den Nummernkreis anschließende unterschiedliche 2-stellige, alphanumerische Kammerclient-IDs eine Eindeutigkeit herstellen. Die vergebenen Kammerclient-IDs müssen nicht im Rahmen des Konfigurationsmanagements nachgehalten werden, da sie lediglich dafür dienen, die Eindeutigkeit der Vorgangsnummern bei mehreren KammerClient-Instanzen innerhalb einer Ärztekammer zu gewährleisten. Tabelle 7-1: Vorgangsnummernräume Lfd. Nr. Zertifizierungsdiensteanbieter 0 D-TRUST Signtrust T-Systems Telesec S-Trust Cybertrust dgnservice medisign Erprobungsumgebung: D-TRUST (Bundesdruckerei Erprobungsumgebung: T-Systems Telesec Erprobungsumgebung: DGNservice Erprobungsumgebung: medisign 616 Nummernkreis Bundesärztekammer :06:00 Seite 16 von 21

17 Seite 17 von 21 8 ERPROBUNG: Nummernkreise für von den Ärztekammern generierte Vorgangsnummern Das folgende Kap. beschreibt die Bildungsregel für Vorgangsnummern im Rahmen der Erprobung der gematik. D.h. die an den Tests teilnehmenden Ärztekammern müssen ggü. den beauftragten Zertifizierungsdiensteanbietern aus den Losen 3&4 der G2-Ausschreibung die Vorgangsnummer für Vorbefüllungen wie u.g. bilden. Folgende Anforderungen sind zu berücksichtigen: Wenn der Kartenherausgeber bei der Vorbefüllung eine Vorgangsnummer erzeugt und im Vorbefüllungsdatensatz mitliefert, dann MUSS diese Vorgangsnummer innerhalb des jeweiligen Kartenherausgebers eindeutig sein. Wenn der Kartenherausgeber keine Vorgangsnummer mitliefert, dann MUSS der TSP eine losübergreifend einheitliche Vorgangsnummer erzeugen und an den Kartenherausgeber zurückliefern. Die folgende Bildungsregel MUSS vom TSP und von den Kartenherausgebern bei der Erzeugung von Vorgangsnummern umgesetzt werden: Die Vorgangsnummer hat 18 Stellen. 10 Stellen als Klartext-Referenz zum Antrag, die sich wiederum aus zwei Blöcken zusammen setzen: o 5 Stellen Kennung des Kartenherausgebers oder TSP: Eindeutige Identifizierung des Kartenherausgebers im Fall der Erzeugung der Vorgangsnummer durch den Kartenherausgeber, welche sich aus dem einstelligen Präfix der TelematikID des Sektors, dem Kartentyp (HBA oder SMC-B, einstellig) und einem dreistelligen Kartenherausgeberspezifischen Nummernraum zusammensetzt (z.b. Kammercode oder vergleichbare bereits vorhandene Kennungen) ZDA-Kennung im Fall der Erzeugung der Vorgangsnummer durch den TSP. o 5 Stellen: eindeutiges Identifizierungsmerkmal des Kartenherausgebers oder des TSP für die Vorgangsnummer z.b. eine fortlaufende Nummer oder eine Zuordnungssnummer aus den Bestandssystemen oder eine sonstige Nummer 8 Stellen Zufallszahl, um einen gezielten Zugriff auf Vorbefüllungsdaten durch Unberechtigte auszuschließen. Die Erzeugung der Zufallszahlen obliegt dem jeweiligen Kartenherausgeber bzw. TSP. Die folgende Abbildung illustriert die Bildungsregel (am Beispiel einer vom Kartenherausgeber gebildeten Vorgangsnummer): Stelle Bundesärztekammer :06:00 Seite 17 von 21

18 Seite 18 von 21 Wert Sektorkennzeichen: Präfix der Telematik ID gemäß gemkpt_pki_tip#tab_pki_101 Kartentyp: "1" für HBA, "2" für SMC B Kartenherausgeberspezifischer Nummernraum, z.b. Kammercode oder vergleichbare ggf. bereits vergebene Kennungen Identifizerungsmerkmal für den Vorgang 8 stellige Zufallszahl Hinweis der gematik bzgl. Zufallszahl: Der 14stellige Crypto-Key als Teil des Webtokens wurde von der BÄK als Schlüssel für die Verschlüsselung der vorbefüllten Daten definiert. Zu diesem Zweck ist viel Entropie erforderlich, deshalb die 14 alphanumerische Stellen. In den jetzt definierten Prozessen werden die Vorbefüllungsdaten nicht mit einer PB-Encryption verschlüsselt, sondern über eine TLS- Transportverschlüsselung abgesichert. Die Zufallszahl dient nur noch der Authentisierung und hat die Qualität eines Passworts. 14 Stellen sind für diesen Zweck nicht erforderlich. Für ein gutes Passwort dürften 8 Stellen ausreichend sein. Die Länge der Zufallszahl ist auf das notwendige Maß (8 Stellen) reduziert worden. Für den earztausweis sind damit folgende Werte bei der Generierung der Vorgangsnummer durch die Ärztekammer vorgegeben: 1. Stelle: 1 (entspricht Ärzteschaft ) 2. Stelle: 1 (entspricht HBA) 3-5 Stelle: Kammercode gemäß TR, siehe auch ebenda Tabelle 6-1: Nummernräume der Seriennummer 6-10 Stelle: eindeutige, bspw. fortlaufende Nummer für den Vorgang Stelle: 8-stellige Zufallszahl Beispiel-Vorgangsnummer: '1' '1' '150' '12345' ' ' LÄK Thüringen 9 Bereitstellung von HBA-Entwicklerkarten[ARZT] für Anwendungsentwickler außerhalb der Testmaßnahmen der gematik Zur Akzeptanzherstellung und -erhöhung soll neben den durch die egk bedingten Anforderungen an den earztausweis parallel in ausgewählten Projekten eine Integration der Karten in weitere medizinische (und ggf. andere) Anwendungen erfolgen. Bundesärztekammer :06:00 Seite 18 von 21

19 Seite 19 von 21 Aus diesem Grund sind Regelungen für die Bereitstellung von HBA-Entwicklerkarten[ARZT] für Projekte zu definieren, um Inkompatibilitäten bspw. durch Nutzung unterschiedlicher CV-Root-Hierarchien von vornherein zu umgehen. Die Bedarfe werden zentral über die BÄK aufgenommen und an interessierte Zertifizierungsdiensteanbieter weitergereicht. Für die Bereitstellung von HBA-Entwicklerkarten[ARZT] durch die ZDA soll grundsätzlich eine Vergütung der Leistungen in angemessenem Umfang erfolgen. Die Kosten für HBA-Entwicklerkarten[ARZT] außerhalb der gematik-testmaßnahmen müssen durch die anfragenden Entwickler / Firmen selbst getragen werden. Die Rechnungsstellung erfolgt durch die ZDA. Interessierte Entwickler wenden sich bei Bedarf direkt an die Bundesärztekammer: telematik@baek.de. Die ZDA werden gebeten, auch bzgl. HBA-Entwicklerkarten[ARZT] Preis-Angebote abzugeben, damit das Dezernat Telematik der BÄK gegenüber interessierten Entwicklern aussagefähig ist. Auch HBA-Entwicklerkarten[ARZT] sollen ein geeignetes optisches Merkmal enthalten, um eine Verwaltung der Karten leicht zu ermöglichen. Bspw. kann die ICCSN der ausgelieferten Karten für die Verwaltung rückgemeldet werden. Den Entwicklern sollten ggf. drei HBA-Entwicklerkarten[ARZT] zur Verfügung gestellt werden, die den unterschiedlichen Status-Antworten des OCSP ((unknown, good, revoked) bezogen einheitlich auf alle Zertifikatstypen) entsprechen. Die Karten sind zusätzlich mit Informationen zu den personalisierten Testdaten, PINs, PUKs und Adressen (URL) der Infrastrukturdienste zu liefern. Folgende Anforderungen gelten für die technische Ausgestaltung der Zertifikatsinhalte. Für Anwendungsentwickler bereitzustellende Infrastrukturdienste (LDAP, OCSP) sollen gemäß der beschriebenen Anforderungen der BÄK betrieben werden. 10 Konfigurationsdaten der Zertifikatsprofile 10.1 Admission im Basis-Signaturzertifikat Die Extension Admission muss in Basis-Signaturzertifikaten von Generation-2 Entwickler- HBA[Arzt], Test-HBA[Arzt] der HPC-Spezifikationsversion gesetzt werden. Sie muss das Arzt-Attribut enthalten und strukturell dem Admission-Attribut des Attributzertifikats entsprechen. Das bedeutet auch, dass die Extension die Telematik-ID NICHT enthalten darf. Entwicklerkarten und Testkarten der Generation 0 (HPC-Spezifikationsversion 2.1.1) sind von dieser Regelung nicht betroffen, d. h. Signaturzertifikate dieser Karten enthalten weiterhin keine Admission-Extension. Auch echte elektronische Arztausweise der Generation 2 enthalten die Admission-Extension im Basis-Signaturzertifikat mit dem Ärztin/Arzt -Attribut. Dies ist allerdings abhängig von der allgemeinen Unterstützung von Attributzertifikaten mit generischen Attributen durch den Konnektor (bei einer Signatur wählbar im Ermessen des Anwenders), die von der gematik zugesagt und derzeit auch realisiert worden ist. Bundesärztekammer :06:00 Seite 19 von 21

20 Seite 20 von Nicht-qualifizierte CA-Zertifikate Es ist zulässig, jeweils unterschiedliche CA-Zertifikate für die Erstellung von ENC- und AUT- Zertifikaten für Entwicklerkarten[ARZT] sowie für earztausweise einzusetzen. Diese sollen zur besseren Unterscheidung entsprechende Namen (z. B. CN= {ZDA} Test ENC-CA für Ärzte {x}:pn, O={ZDA}, C=DE) haben Policy-OIDs für elektronische Arztausweise der Generation 2 (HPC- Spezifikationsversion ab 3.0.0) In [baekcerts] und [baekattr] ist die Policy-OID für elektronische Arztausweise der Generation 2 (HPC-Spezifikationsversion ab 3.0.0) nicht definiert. Folgende Policy-OIDs gelten dafür: Tabelle 10-1: Policy-OIDs Karte Zertifikatstyp PolicyOID HPC Version ab AUT : policy-hba cp : hba-aut HPC Version ab ENC : policy-hba cp : hba-enc HPC Version ab SIG, ATTR : policy-hba cp : hba-sig HPC Version ab qsig, qattr, QES : policy-hba cp : hba-qes Der OID : policy-hba cp kennzeichnet die Gemeinsame Policy ([leogempolicy], in der Version 1.0.5), deren Regelungen für diese Karten gelten. Für HPCqSIG gilt die Gemeinsame Policy in der Version 1.0.0, OIDs sind im Kap. 3 definiert. Für elektronische Arztausweise der Generation 2 muss zudem in allen Zertifikatsklassen die OID der Europäischen eid-policy für Ärzte "CPME European eid- Policy for Physicians" Version vom aufgenommen werden CRLDistributionPoints und AuthorityInfoAccess Die Felder "CRLDistributionPoints" und "AuthorityInfoAccess" in den jeweiligen Zertifikaten müssen durch die ZDA, gemäß dem vorgegebenen Zertifikatsprofil der BÄK, strukturiert und gefüllt werden. Werden die (optionalen) CRLs für eine Zertifikatsklasse vom ZDA nicht ausgestellt, darf der CRLDistributionPoint in den entsprechenden Zertifikaten nicht gesetzt sein. Bundesärztekammer :06:00 Seite 20 von 21

21 Seite 21 von 21 Die Feld-Inhalte (bspw. URL) müssen in Übereinstimmung zu den entsprechenden Infrastrukturdiensten korrekt durch den Zertifizierungsdiensteanbieter gesetzt sein Weitere Spezifische Konfigurationsdaten der X.509-Zertifikate auf HBA- Entwicklerkarten[ARZT] X.509-Trustcenter-Zertifikate (Root-, CA, CRL-Signer, OCSP, ggf. TSS-Zertifikate) sowie Enduser-Zertifikate auf HBA-Entwicklerkarten[ARZT] sollen folgende Bezeichnungen und Inhalte haben: o Die Trustcenter-Zertifikate werden nach folgenden Schema benannt (das Wort {ZDA} wird durch die jeweilige Bezeichnung des Trustcenters ersetzt, ein {x} durch eine fortlaufende Ganzzahl): CA-Zertifikate für HBA-Entwicklerkarten[ARZT]: CN= {ZDA} Entwickler CA für Ärzte {x}:pn, O={ZDA}, C=DE CRL-Signer, OCSP-Signer, ggf. TSS-Signer: CN= {ZDA} Test {OCSP CRL TSS}-Signer{x}, O={ZDA}, C=DE o Enduser-Zertifikate dürfen keine QC-Statements enthalten, optionale Extensions dürfen fehlen. Die Policy cp-isismtt-accredited darf nicht gesetzt werden. o Als admissionauthority für HBA-Entwicklerkarten[ARZT] wird O=Landesärztekammer Beispielland, C=DE verwendet werden. o Es dürfen beliebige -Adressen ins Zertifikat aufgenommen werden. Die Haftung dafür liegt beim Aussteller (z. B. bei unautorisierter Benutzung eines fremden domain-namens). o Alle HBA-Entwicklerkarten[ARZT] müssen in der Restriction-Extension den Text Nur zu Testzwecken. Der Inhaber ist kein Arzt. enthalten. 11 Referenzen [extern1] Erstellung von XML-Signaturen für Dokumente nach Clinical Documents Architecture R2 (Elektronische Signatur von Arztbriefen), BÄK, ÄKNo, ÄKWL, Version 1.0 [baekglossar] [baekcerts] Abkürzungsverzeichnis und Glossar Zertifikatsprofile für X.509 Basiszertifikate [baekattr] [leogempolicy] Zertifikatsprofile für X.509 Attributzertifikate Gemeinsame Policy für die Herausgabe der HPC Bundesärztekammer :06:00 Seite 21 von 21