Elektronische Gesundheitskarte und Telematikinfrastruktur

 

 

 

 

Übergreifende Spezifikation

Spezifikation PKI

 

   

   

Version	2.910.0
Revision	548770
Stand	30.0612.11.2020
Status	freigegeben
Klassifizierung	öffentlich
Referenzierung	gemSpec_PKI

 

Dokumentinformationen

Änderungen zur Vorversion

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

Dokumentenhistorie

Inhaltsverzeichnis

DokumentinformationenDokumentinformationen

InhaltsverzeichnisInhaltsverzeichnis

1 Einordnung des Dokumentes

1.1 Zielsetzung

1.2 Zielgruppe

1.3 Geltungsbereich

1.4 Abgrenzungen

1.5 Methodik

1.5.1 Hinweis auf offene Punkte

2 Notation kryptographischer Objekte

2.1 Basis-Bezeichner

2.2 Optionale Bezeichnung der technischen Ausprägung

2.3 Optionales Unterscheidungsmerkmal bei gleicher technischer Ausprägung

2.4 Allgemeine Notationsvorschrift

2.5 Type (Objekttyp)

2.6 Holder (Objektbesitzer)

2.7 Usage (Objektverwendung)

2.8 n (lfd. Nummer)

2.9 Instance (Ausprägung)

2.10 Beispiele zur Umsetzung

2.10.1 Beispiele für asymmetrische Objekte

2.10.2 Beispiele für symmetrische Objekte

3 CA-Strukturen

3.1 Übergreifende Festlegung für CA der TI

3.1.1 Übersicht der Identitäten/Zertifikate

3.1.2 Laufzeiten der CA

3.1.3 Unterstützung verschiedener Schlüsselgenerationen

3.2 TI-Betriebsumgebungen

3.2.1 PKI-Sicht auf die Produktivumgebung

3.2.2 PKI-Sicht auf Test- u. Referenzumgebung (PKI-TeRe)

3.2.3 Pseudo-QES PKI in Test- u. Referenzumgebung

3.3 Zentrale Aussteller-CAs in der TI für nonQES-Zertifikate

3.4 Spezifische Aussteller-CA in der TI

4 Kodierung von X.509-Identitäten

4.1 Namensregeln und -formate

4.1.1 Verarbeitung von Sonderzeichen

4.1.2 Definition der Subject-DNs für Personen und Komponenten

4.1.3 SubjectDN von CA-Zertifikaten und von OCSP-Responder-Zertifikaten

4.2 Schlüssel der Versichertenidentität (eGK)

4.3 Pseudonym der Versichertenidentität (eGK)

4.3.1 Versicherten-Pseudonym in X.509-Zertifikaten der eGK

4.3.2 Eindeutigkeit des Pseudonym

4.3.3 Pseudonym-Erstellungsregel

4.3.4 Hs-ZW – Herausgeberspezifischer Zufallswert (hs-ZW)

4.3.5 Kodierung des Pseudonyms

4.4 Berufsgruppen-ID der Leistungserbringer

4.4.1 Berufsgruppe des Heilberuflers

4.5 ID der Organisation/Einrichtung des Gesundheitswesens

4.5.1 Typ und Exemplar der Organisation/Einrichtung des Gesundheitswesens

4.6 Technische Rolle von Komponenten und Diensten

4.6.1 Technische Rolle im Komponentenzertifikat

4.7 Telematik-ID

4.7.1 Abbildung der Telematik-ID im X.509-Zertifikat

4.7.2 Aufbau der Telematik-ID

4.7.2.1 Sektoraler Präfix

4.7.2.2 Separator

4.7.2.3 Fortsatz der Telematik-ID

4.8 Kodierung der Zertifikate

4.8.1 Kodierung der Attribute

4.8.2 Stringlänge der Attribute

4.8.3 Struktur

4.8.3.1 serialNumber

4.8.3.2 Admission

4.8.3.3 CertificatePolicies

4.8.3.4 CRLDistributionPoints

4.8.3.5 SubjectAltNames

4.9 Erläuterungen zu Zertifikatsprofilen

4.9.1 Allgemeine Erläuterungen

4.9.2 Berufs-/Rollenattribute und Sperrbarkeit

4.9.3 Benennung der Zertifikatsprofile

4.9.4 Distinguished Name

4.10 Kodierung der Betriebsumgebungen in Zertifikaten

4.11 Kartenverlust und Deaktivierung von Chipkarten

5 X.509-Zertifikate

5.1 eGK – Versichertenkarte

5.1.1 Definition der Versichertenidentität

5.1.2 Belegung der Felder im SubjectDN

5.1.3 X.509-Zertifikatsprofile der eGK

5.1.3.1 C.CH.AUT und C.CH.AUT_ALT – Authentisierung eGK

5.1.3.2 C.CH.ENC – Verschlüsselung eGK

5.1.3.3 C.CH.QES – Qualifizierte Signatur eGK (optional)

5.1.3.4 C.CH.AUTN - Technische Authentisierung eGK

5.1.3.5 C.CH.ENCV - Technische Verschlüsselung eGK

5.2 HBA – Heilberufsausweis

5.2.1 X.509 Zertifikatsprofile des HBA

5.2.1.1 C.HP.AUT – Authentisierung HBA

5.2.1.2 C.HP.ENC – Verschlüsselung HBA

5.2.1.3 C.HP.QES – Qualifizierte Signatur HBA

5.3 SMC-B – Ausweis einer Organisation/Einrichtung des Gesundheitswesens

5.3.1 Definition der Organisationsidentität

5.3.2 Aufbau Anschriftzone nach [DIN5008]

5.3.3 Umgang mit überlangen Attributen im SubjectDN

5.3.4 X.509 Zertifikatsprofile der SMC-B

5.3.4.1 C.HCI.AUT – Authentisierung SMC- B

5.3.4.2 C.HCI.ENC – Verschlüsselung SMC-B

5.3.4.3 C.HCI.OSIG – Signatur SMC-B

5.4 HSM-B – Ausweis einer Organisation/Einrichtung des Gesundheitswesens

5.5 gSMC-KT – eHealth-Kartenterminal

5.5.1 Definition der Kartenterminalidentität

5.5.2 X.509 Zertifikatsprofile der gSMC-KT

5.5.2.1 C.SMKT.AUT – Identität der gSMC-KT

5.6 gSMC-K – Konnektor

5.6.1 Definition und Zuweisung der Konnektoridentität

5.6.2 Aufbau des SubjectDN

5.6.3 Statusprüfung von Konnektorzertifikaten

5.6.4 X.509 Zertifikatsprofile des Konnektors

5.6.4.1 C.NK.VPN – VPN-Authentisierung Netzkonnektor

5.6.4.2 C.AK.AUT - Authentisierung Anwendungskonnektor

5.6.4.3 C.SAK.AUT - Authentisierung Signaturdienst

5.7 VPN-Zugangsdienst

5.7.1 Definition und Zuweisung der Zugangsdienstidentitäten

5.7.2 Aufbau des SubjectDN

5.7.3 X.509-Zertifikatsprofile des Zugangsdienstes

5.7.3.1 C.VPNK.VPN - VPN-Authentisierung Zugangsdienst TI

5.7.3.2 C.VPNK.VPN-SIS - VPN-Authentisierung Zugangsdienst Sicherer Internetzugang

5.8 ZD – Zentrale Dienste

5.8.1 Definition der Identität der Zentralen Dienste

5.8.2 Aufbau des SubjectDN

5.8.3 X.509 Zertifikatsprofile der Zentralen Dienste

5.8.3.1 C.ZD.TLS-S Server-Authentisierung (ehemals C.SF.SSL-S)

5.9 FD – Fachanwendungsspezifische Dienste

5.9.1 Definition der Identität der Fachanwendungsspezifischen Dienste

5.9.2 Aufbau des SubjectDN

5.9.3 X.509 Zertifikatsprofile der Fachanwendungsspezifischen Dienste

5.9.3.1 C.FD.TLS-C Client-Authentisierung (ehemals C.SF.SSL-C)

5.9.3.2 C.FD.TLS-S Server-Authentisierung (ehemals C.SF.SSL-S)

5.9.3.3 C.FD.SIG Signatur Fachdienst

5.9.3.4 C.FD.AUT Authentisierung Fachdienst

5.9.3.5 C.FD.ENC Verschlüsselung Fachdienst

5.10 CM – Clientmodul

5.10.1 Definition der Identität eines Clientmoduls

5.10.2 Aufbau des SubjectDN

5.10.3 X.509 Zertifikatsprofil des Clientmoduls

5.10.3.1 C.CM.TLS-CS Clientmodul-Authentisierung

5.11 SGD-HSM – Schlüsselgenerierungsdienst-HSM

5.11.1 Beschreibung der Identität

5.11.2 X.509 Zertifikatsprofil der SGD-HSM

5.12 CA - Zertifikatsprofile

5.12.1 GEM.RCA<n> - Zentrale Root-CA_nonQES

5.12.2 <tsp>.<usage>-CA<n> - Aussteller-CA_nonQES

5.12.3 <tsp>.HBA-qCA<n> - Aussteller-CA_QES

5.13 OCSP – Statusauskunftsdienst

5.13.1 Definition der OCSP-Signer-Identität

5.13.2 Aufbau des SubjectDN

5.13.3 X.509-Profil des OCSP-Signer-Zertifikates

5.13.3.1 C.GEM.OCSP OCSP-Signer-Zertifikat

5.14 CRL – Statusauskunftsdienst

5.14.1 Definition der CRL-Signer-Identität

5.14.2 Aufbau des SubjectDN

5.14.3 X.509 Profil des CRL-Signer-Zertifikates

5.14.3.1 C.GEM.CRL CRL-Signaturzertifikat

5.15 TSL - Zertifikatsprofile

5.15.1 Definition der TSL-Signer-Identität

5.15.2 Aufbau des SubjectDN

5.15.3 X.509 Zertifikatsprofil der TSL-Signer-CA

5.15.4 TSL-Signer- Zertifikat

5.15.5 TSL-OCSP-Responder-Zertifikat

6 CV-Zertifikate

6.1 Festlegungen zur Abgrenzung

6.2 Namensregeln und -formate

6.3 Rollen und Profile

6.3.1 Rollenauthentisierung

6.3.2 Authentisierung einer Funktionseinheit

6.4 CV-Zertifikatsprofile der Generation 2

6.4.1 Berechtigung einer CVC-CA zur Zertifikatserstellung

6.4.2 Aufbau und Bestandteile der CV-Zertifikate der Generation 2

6.4.3 Zertifikatsprofil eines CV-Zertifikates für ELC-Schlüssel

6.4.3.1 Certificate Profile Identifier (CPI)

6.4.3.2 Certification Authority Reference (CAR)

6.4.3.3 Öffentlicher Schlüssel

6.4.3.4 Certificate Holder Reference (CHR)

6.4.3.5 Certificate Holder Authorization Template (CHAT)

6.4.3.6 Certificate Effective Date (CED)

6.4.3.7 Certificate Expiration Date (CXD)

6.4.3.8 Zu signierende Nachricht M eines CV-Zertifikates der Generation 2

6.4.4 Struktur und Inhalt eines CV-Zertifikates für ELC-Schlüssel der Generation 2

6.4.5 Struktur und Inhalt eines CV-Zertifikates für ELC-Schlüssel der Generation 2

6.4.5.1 Struktur und Inhalt von CA CV-Zertifikaten für ELC-Schlüssel

6.4.5.2 Struktur und Inhalt von Cross-CV-Zertifikaten für ELC-Schlüssel

6.4.5.3 Struktur und Inhalt von Endnutzer-CV-Zertifikaten für ELC-Schlüssel

6.4.6 Flagliste mit Berechtigungen in CV-Zertifikaten für ELC-Schlüssel

7 Festlegung von OIDs

8 Prüfung von Zertifikaten

8.1 Vertrauensraum der TI

8.1.1 TSL im Kontext der ECC-Migration

8.1.2 Initialisierung TI-Vertrauensraum

8.1.2.1 TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“

8.1.3 Geplanter Wechsel TI-Vertrauensanker

8.1.3.1 TUC_PKI_013 „Import TI-Vertrauensanker aus TSL“

8.1.3.2 TSL-Einträge für die Bereitstellung neuer TI-Vertrauensanker

8.1.3.3 Prüfung der TSL nach Wechsel des TI-Vertrauensanker

8.1.4 Ungeplanter Wechsel des TI-Vertrauensanker

8.2 TSL-Prüfung

8.2.1 Erreichbarkeit und Download der TSL

8.2.1.1 TUC_PKI_017 „Lokalisierung TSL Download-Adressen“

8.2.1.2 TUC_PKI_016 „Download der TSL-Datei“

8.2.2 Vertrauensstatus und Authentifizieren der TSL

8.2.2.1 TUC_PKI_019 „Prüfung der Aktualität der TSL“

8.2.2.2 TUC_PKI_020 „XML-Dokument validieren“

8.2.2.3 TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“

8.2.2.4 TUC_PKI_012 „XML-Signatur-Prüfung“

8.2.3 TSL-Sicherheitsaspekte

8.2.4 TSL-Zeitparameter

8.2.5 ServiceTypeIdentifier "unspecified"

8.3 Zertifikatsprüfung X.509 nonQES

8.3.1 Zertifikatsprüfung in der TI

8.3.1.1 TUC_PKI_018 „Zertifikatsprüfung in der TI“

8.3.1.2 TUC_PKI_002 „Gültigkeitsprüfung des Zertifikats“

8.3.1.3 TUC_PKI_003 „CA-Zertifikat in TSL-Informationen finden“

8.3.1.4 TUC_PKI_004 „Mathematische Prüfung der Zertifikatssignatur“

8.3.2 Statusprüfung

8.3.2.1 TUC_PKI_005 „Adresse für Status- und Sperrprüfung ermitteln“

8.3.2.2 TUC_PKI_006 „OCSP-Abfrage“

8.3.2.3 TUC_PKI_021 „CRL-Prüfung“

8.3.2.4 Szenarien für Offline und Timeout von OCSP

8.3.2.5 Statusprüfung von eGK-Zertifikaten

8.3.3 Ermittlung von Autorisierungsinformationen

8.3.3.1 Bestätigte Zertifikatsinformationen

8.3.3.2 TUC_PKI_009 „Rollenermittlung“

8.3.3.3 TUC_PKI_007 „Prüfung Zertifikatstyp“

8.3.4 Weitere Prüfungen

8.3.4.1 Umgang mit kritischen Extensions

8.4 Überprüfung der Zertifikate auf Netzwerk- und Transportebene

8.4.1 TLS-Verbindungsaufbau

8.4.2 IPsec-Verbindungsaufbau

8.5 Zertifikatsprüfung X.509 QES

8.5.1 TUC_PKI_030 „QES-Zertifikatsprüfung“

8.5.2 TUC_PKI_036 „BNetzA-VL Aktualisierung“

8.6 Fehlercodes bei TSL- und Zertifikatsprüfung X.509

8.7 Zertifikatsprüfung CV-Zertifikate der 2. Generation

9 OCSP-Statusinformation

9.1 Statusprüfung

9.1.1 Schnittstelle I_OCSP_Status_Information

9.1.1.1 Schnittstellendefinition

9.1.1.1.1 OCSP-Request

9.1.1.1.2 OCSP-Response

9.1.1.2 Umsetzung

9.1.1.3 Nutzung

9.1.2 Artefakte

9.1.2.1 OCSP-Response – Response Status

9.1.2.2 OCSP-Response - Zeiten

9.1.2.3 OCSP-Response - CertStatus

9.1.2.4 OCSP-Response - CertID

9.1.2.5 OCSP-Response – Sperrzeitpunkt und Sperrgrund

9.1.2.6 OCSP-Response – CertHash

9.1.2.7 OCSP-Response – Responder-Zertifikate

9.1.3 Testunterstützung

9.1.4 Hardwaremerkmale

10 Anhang A – Sektorspezifische Ausprägungen der SMC-B-Zertifikate

10.1 KZBV

10.2 KBV

10.3 DKG

10.4 GKV-Spitzenverband

10.5 Apothekerschaft

10.6 AdV-Umgebung im Auftrag der Kostenträger

10.7 SMC-B-ORG

10.8 Weitere Leistungserbringerinsitutionen

10.9 Weitere Ärztliche Institutionen

11 Anhang B – Verzeichnisse

11.1 Abkürzungen

11.2 Glossar

11.3 Abbildungsverzeichnis

11.4 Tabellenverzeichnis

11.5 Referenzierte Dokumente

11.5.1 Dokumente der gematik

11.5.2 Weitere Dokumente

12 Anhang C – Sektorspezifische Ausprägungen der HBA Zertifikate

12.1 BÄK

12.2 BZÄK

12.3 BPtK

12.4 Apothekerschaft

12.5 Weitere Leistungserbringer

1 Einordnung des Dokumentes

1.1 Zielsetzung

Die vorliegende übergreifende Spezifikation definiert Anforderungen für den Themenbereich PKI, die bei der Realisierung (bzw. dem Betrieb) von Produkttypen der TI zu beachten sind. Diese Anforderungen sind als übergreifende Regelungen relevant für Interoperabilität und Verfahrenssicherheit.

1.2 Zielgruppe

Das Dokument richtet sich an Hersteller und Anbieter von Produkten der TI, die Zertifikate verwalten oder 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 Abgrenzungen

Im vorliegenden Dokument werden Verfahren und Profile für digitale Zertifikate (X.509, CVC für die Generation G2), beschrieben. Nicht beschrieben werden die Prozesse und Verfahren zur Personalisierung der Karten selbst.

Die normativen Vorgaben bzgl. verwendbarer kryptographischer Algorithmen trifft das Dokument [gemSpec_Krypt].

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

Sie 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.

Folgende Namenskonvention gilt für TSP als Adressaten für spezifische Anforderungen, die im vorliegenden Konzept definiert werden:

• TSP-X.509
  Übergreifende Bezeichnung für alle Herausgeber von X.509-Zertifikaten, dies sind die Produkttypen TSP-X.509 QES, TSP-X.509 nonQES und gematik Root-CA

1.5.1 Hinweis auf offene Punkte

Themen, die noch intern geklärt werden müssen oder eine Entscheidung benötigen, sind wie folgt im Dokument gekennzeichnet:

2 Notation kryptographischer Objekte

2.1 Basis-Bezeichner

Folgende Notation wird verwendet, um Schlüssel und Zertifikate einheitlich zu benennen und zu identifizieren. Die Notation besteht aus drei durch einen Punkt „.“ getrennten Teilen mit folgender Bedeutung:

<Objekttyp>.<Objektbesitzer>.<Objektverwendung>

Im weiteren Dokument werden dafür die kürzeren englischen Begriffe verwendet:

<type>.<holder>.<usage>

Für den Objekttyp wird eine zusammenfassende Ebene mit dem Kürzel „ID“ eingeführt. Alle Notationen zu einem Objekt (Schlüssel, Zertifikate) werden unter diesem Kürzel „ID“ zusammengefasst, wobei die Bezeichner in allen Teilen übereinstimmen.

Mittels dieser Notation wird jeweils ein Typ eines Objektes, wie z. B. der Verschlüsselungsschlüssel einer eGK, benannt, nicht ein einzelnes spezifisches Objekt. Deshalb beschreibt diese Notation keine Laufzeiten konkreter Objekte oder deren Zuordnung zu spezifischen Anwendungsschichten oder Kartengenerationen. 

2.2 Optionale Bezeichnung der technischen Ausprägung

Kann ein bestimmtes Objekt in verschiedenen technischen Ausprägungen auftreten, wird das o. g. dreistufige Bezeichnungsschema um ein 4. Element mit der Bezeichnung der technischen Ausprägung (Algorithmen, Schlüssellänge) ergänzt (siehe Kapitel 2.9).

Im weiteren Dokument ist das 4. Element, soweit aufgeführt, jeweils kursiv dargestellt. 

<Objekttyp>.<Objektbesitzer>.<Objektverwendung><lfd. Nummer>.<Ausprägung>

<type>.<holder>.<usage><n>.<instance>

Auf diese Weise werden z. B. bei mehreren in einer Karte angelegten Schlüsseln die Schlüssel- und korrespondierenden Zertifikatsreferenzen eindeutig hergestellt.

2.3 Optionales Unterscheidungsmerkmal bei gleicher technischer Ausprägung

Zur Differenzierung von Krypto-Objekten – bei sonst identischer technischer Ausprägung – kann im Element „Objektverwendung“ (Usage) zum eigentlichen Verwendungskürzel eine laufende Nummer ergänzt werden.

Beispiel:
PrK.CH.ENCn.R2048, wobei n mit 1 beginnt und fortlaufend nummeriert wird 

Ein Anwendungsfall ist bspw., dass Objekte auf Karten in Vorbereitung bzw. zur Unterstützung kommender Kartengenerationen bereits vorgesehen werden und diese in der gleichen technischen Ausprägung implementiert werden.

2.4 Allgemeine Notationsvorschrift

Die Benennung kryptographischer Objekte erfolgt gemäß der Notationsvorschrift in Tab_PKI_201.

Tabelle 1: Tab_PKI_201 Allgemeine Notationsvorschrift für kryptographische Objekte 

<Objektbezeichner>    ::= <type>.<holder>.<usage><n>.<instance>

Die Verwendung von instance (Ausprägung) bzw. von n (laufende Nummer) ist jeweils optional und wird anhand der Notwendigkeit der Unterscheidung verschiedener technischer Ausprägungen bzw. bei gleicher technischer Ausprägung entschieden.

2.5 Type (Objekttyp)

Der Objekttyp (type) wird bei der Benennung kryptographischer Objekte entsprechend Tab_PKI_202 gekennzeichnet.

Tabelle 2: Tab_PKI_202: Notationsvorgaben für Objekttyp 

<type>        ::= <key> | <certificate> | <ID>

<key> ::= <private key> | <public key> | <secret key> | <individual key> | <shared secret>

<certificate> ::= <X.509v3 certificate> | <card verifiable certificate>

<ID> ::= <X.509v3 ID> | <card verifiable ID>

Wertebereich von <key>

<private key>	::=	PrK (asym.)
<public key>	::=	PuK (asym.)
<secret key>	::=	SK (sym.)
<individual key>	::=	IK (sym.)
<shared secret>	::=	ShS (sym.) (Pairing Geheimnis)

Wertebereich von <certificate>

Die Differenzierung von X.509- und CV-Zertifikaten wird im jeweiligen Verwendungszweck („Usage“) vorgenommen. Somit entfällt die Notwendigkeit nach getrennten Bezeichnern für das Feld „certificate“.

<X.509v3 certificate>	::=	C
<card verifiable certificate>	::=	C

Wertebereich von <ID>

Die Differenzierung von X.509- und CV-Identitäten wird analog der Vorgehensweise bei Zertifikaten im jeweiligen Verwendungszweck („Usage“) vorgenommen. Es entfällt die Notwendigkeit nach getrennten Bezeichnern für „ID“.

<X.509v3 ID>            ::=     ID
<card verifiable ID>        ::=     ID 

2.6 Holder (Objektbesitzer)

Die Definition der Holder unterscheidet zwischen X.509- und CVC-Objekten. Die möglichen Holder für symmetrische Objekte entsprechen i. A. den X.509-Objekten. Dabei versteht sich die Liste als Aufzählung aller möglichen, nicht aller erlaubten Holder. Welche im Falle der einzelnen Objekte sinnvoll sind und verwendet werden, wird durch die Definition der Objekte in den jeweiligen Architekturen und Spezifikationen bestimmt.

Objektbesitzer (im technischen Sinne) können Personen, Organisationen, Chipkarten oder auch Sicherheitsmodule sowie unterschiedliche Dienste im Rahmen der TI sein.

Während des Lebenszyklus eines Objektes können sich die Holder ändern. Im vorliegenden Dokument ist mit dem Holder immer der Holder während der Betriebsphase gemeint.

Bei der Benennung von kryptographischen Objekten wird der Objektbesitzer (holder) gemäß Tab_PKI_203 gekennzeichnet. Holder MUSS für alle drei Bereiche Schlüssel, Zertifikat und ID einheitlich verwendet werden.

Tabelle 3: Tab_PKI_203 Notationsvorgaben für Objektbesitzer 

<holder> ::= <holder X.509 | SK> | <holder CVC>

<holder X.509 | SK> ::= <root certification authority> | <health professional> | <card holder> | <Clientmodul>| <health care institution> | <security module Kartenterminal> | <Anwendungskonnektor> | <Netzkonnektor> | <VPN Zugangsdienst> | <gematik Trust-service Status List> | <Trust Service Provider> | <Signatur Anwendungs Komponente> | <Fachanwendungsspezifischer Dienst> | <Zentraler Dienst> | <Generischer Holder>

<holder CVC> ::= <root certification authority> | <certification authority> | <certification authority eGK> | <certification authority HPC> | <certification authority SMC> | <certification authority SAK> | <health professional card> | <health professional card role> | <health professional card device> | <electronic health card> | <security module card> | <security module card role> | <security module card device> | <certification authority CAMS_HPC> | <certification authority CAMS_SMC> | <CAMS of HPC> | <CAMS of SMC> | <Kostenträger AdV>

Zu beachten bei kartenrelevanten Objekten, wie eGK und HBA sind unterschiedliche Bezeichnung der Holder in der X.509-Welt gegenüber CVC: bspw. wird bei der eGK der Holder für X.509 als „card holder“ bezeichnet (da es sich um eine Person handelt), während der Holder für CVC bei der gleichen Karte als „eGK“ bezeichnet wird (da der Holder nicht die Person, sondern die Karte selbst ist).

Wertebereich von <holder X.509 | SK>

<root certification authority>        ::=      RCA

<health professional>         ::=     HP

<card holder>             ::=     CH (Versicherte)

<Clientmodul>            ::=     CM

<health care institution>        ::=     HCI

<security module Kartenterminal>     ::=     SMKT

<Anwendungskonnektor>        ::=     AK

<Netzkonnektor>            ::=     NK

<VPN Zugangsdienst>         ::=     VPNK

<gematik Trust-service Status List>    ::=     TSL

<Signatur Anwendungs Komponente>::=     SAK

<TLS>                    ::=    TLS

<Fachdienst VSD>            ::=    VSD

<Zentraler Dienst>            ::=    ZD

<Trust Service Provider>        ::=     <Generischer Holder>| <tsp> 

<Generischer Holder>        ::=    GEM (anbieter- u. diensteunabhängig)

<tsp> (<tsp> wird hier nicht weiter formal beschrieben. Dieser Platzhalter steht für einen mit der gematik vereinbarten Bezeichner für einen spezifischen TSP-X.509. Der Bezeichner kann bis zu 40 Zeichen enthalten, bzw. die Konkatenation <tsp>.<usage>-CA<n> darf nicht mehr als 64 Zeichen [im UTF-8-Format] enthalten, da sie in den Common Name von CA-Zertifikaten eingetragen wird. S. a. Tab_PKI_229.)

Wertebereich von <holder CVC>

<root certification authority>         ::=     RCA

<certification authority>         ::=     CA

<certification authority eGK>         ::=     CA_eGK

<certification authority HPC>         ::=     CA_HPC

<certification authority SMC>         ::=     CA_SMC

<certification authority SAK>         ::=     CA_SAK

<certification authority for CAMS of HPC> ::=     CA_CAMS_HPC (opt.)

<certification authority for CAMS of SMC> ::=     CA_CAMS_SMC (opt.)

<CAMS of HPC>            ::=     CAMS_HPC (opt.)

<CAMS of SMC>            ::=     CAMS_SMC (opt.)

<health professional card>          ::=     HPC

<health professional card role>     ::=     HPC_Role

<health professional card device>     ::=     HPC_Device

<electronic health card>         ::=     eGK (elektronische Gesundheitskarte)

<security module card>         ::=     SMC

<security module card role>         ::=     SMC_role

<security module card device>     ::=     SMC_device

<Signatur Anwendungs Komponente>::=     SAK

<Komfort-Merkmal>            ::=    KM (RFID-Token)

<Kostenträger AdV>           ::=    KTRADV

2.7 Usage (Objektverwendung)

Bei der Benennung von kryptographischen Objekten wird die Objektverwendung (usage) gemäß des vorgesehenen Einsatzzweckes anhand Tab_PKI_204 bezeichnet. Usage wird dabei für alle drei Bereiche Schlüssel, Zertifikat und ID einheitlich verwendet.

Tabelle 4: Tab_PKI_204 Notationsvorgaben für Objektverwendung 

<usage> ::= <usage X.509 | SK> | <usage CVC>

<usage X.509 | SK> ::= <qualified electronic signature> | <electronic signature> | <electronic signature of an organization > | <encipherment> | <authentication X509> |  <authentication X509 alternative-id> | <certsign X509> | <VPN Tunnel> | <VPN-Tunnel secure internet service> | <TLS> | <TLS-Client> | <TLS-Server> | <TLS-Clientmodul> | <authentication message X509> | <authentication X509 organisation> | <encipherment prescription> | <OCSP> | <CRL> | <calculation message auth. code> | <key generation>| <certification authority component> | <certification authority VPNservice> | <certification authority SMC-B> | <certification authority HBA> |

usage CVC> ::= <authentication CVC> | <authentication role CVC> | <authentication device CVC> | <certsign CVC> | <authentication device CVC RPE> | <authentication device CVC RPS> | <authentication device CVC SUK>

Schlüssel, Zertifikate und IDs zu CVC werden grundsätzlich mit einem Suffix „_CVC“ im Feld „Objektverwendung“ (usage) versehen. Implikation daraus: ist kein „_CVC“ in usage angehängt, handelt es sich um ein Objekt im X.509-Kontext. Beispiel: PrK.SAK.AUTD_CVC

Wertebereich von <usage X.509 | SK>

<qualified electronic signature>    ::=     QES

<electronic signature>        ::=     SIG

<electronic signature of an organization>::= OSIG

<encipherment>            ::=     ENC

<encipherment prescription>        ::=     ENCV

<authentication X509>        ::=     AUT

<authentication X509 organisation>    ::=     AUTO (opt.)

<authentication message X509>    ::=     AUTN

<authentication X509 alternative-id>        ::=     AUT_ALT

<certsign X509>            ::=    CA

<VPN-Tunnel>            ::=     VPN

<VPN-Tunnel secure internet service>::=     VPN-SIS

<TLS>                    ::=     TLS

<TLS-Client>                ::=     TLS-C

<TLS-Server>                ::=     TLS-S

<TLS-Clientmodul>            ::=     TLS-CS

<OCSP>                ::=     OCSP

<calculation message auth. code>    ::=     MAC

<key generation>            ::=     KG

<CRL>                    ::=     CRL

<certification authority component>    ::=     KOMP

<certification authority VPNservice>    ::=     VPNK

<certification authority SMC-B>    ::=     SMCB

<certification authority HBA>        ::=     HBA

Wertebereich von <usage CVC>

<certsign CVC>            ::=     CS

<authentication CVC>        ::=     AUT_CVC

<authentication role CVC>        ::=     AUTR_CVC

<authentication device CVC>    ::=     AUTD_CVC

<authentication device CVC AKS>    ::=     AUTD_AKS_CVC (Auslösung Komfortsignatur)

<authentication device CVC RPE>    ::=     AUTD_RPE_CVC (Remote-PIN-Empfänger)

<authentication device CVC RPS>    ::=     AUTD_RPS_CVC (Remote-PIN-Sender)

<authentication device CVC SUK>    ::=     AUTD_SUK_CVC (Stapel- und komfortfähige SSEE)

2.8 n (lfd. Nummer)

Bei der Benennung von kryptographischen Objekten erfolgt bei Gleichartigkeit eine Unterscheidung durch Durchnummerieren der Elemente mittels laufender Nummer. Die laufende Nummer wird für alle drei Bereiche Schlüssel, Zertifikat und ID einheitlich verwendet.

Wertebereich von <lfd. Nummer>

n ist eine positive natürliche Zahl grösser 0 und ohne vorangestellte 0. n ist auf 4 Stellen begrenzt.

2.9 Instance (Ausprägung)

Besteht die Notwendigkeit der Unterscheidung kryptographischer Objekte anhand deren technischer Ausprägung, wird in der Notation dieser Objekte das jeweilige Kryptosystem mit der Schlüssellänge gemäß Tab_PKI_205 angegeben.

Tabelle 5: Tab_PKI_205-01 Notationsvorgaben für Ausprägung 

<instance>::= <instance X.509> | <instance CVC> | <instance SYM>
Asymmetrische Objekte	<instance X.509> ::= <X.509 RSA 2048 > | <X.509 RSA 3072 >| <X.509 ECC 256 > | <X.509 ECC 384 > | <X.509 ECC 512 >
	<instance CVC> ::= <CVC ECC 256> | <CVC ECC 384> | <CVC ECC 512 >
Symmetrische Objekte	Bei symmetrischen Objekten wird das verwendete Verfahren genannt, wenn die Bedingungen aus Abschnitt 2.2 vorliegen.
	<instance SYM> ::= <2KeyTripleDES> | <3KeyTripleDES> | <AES mit 128 Bit> | <AES mit 256 Bit>

Hinweis: Die normativen Vorgaben bzgl. verwendbarer kryptographischer Algorithmen trifft das Dokument [gemSpec_Krypt]. Die nachfolgenden Listen für Wertebereiche geben deren Verwendung im Kontext der Notation kryptographischer Objekte an.

Wertebereich von <instance X.509>

<X.509 RSA 2048 >    ::=     R2048

<X.509 RSA 3072 >    ::=     R3072

<X.509 ECC 256 >    ::=     E256

<X.509 ECC 384 >    ::=     E384

<X.509 ECC 512 >    ::=     E512

Wertebereich von <instance CVC>

<CVC ECC 256 >    ::=     E256

<CVC ECC 384 >    ::=     E384

<CVC ECC 512 >    ::=     E512

Wertebereich von <instance SYM>

<2KeyTripleDES>            ::=     2DES

<3KeyTripleDES>            ::=    3DES

<AES mit 128 Bit>            ::=    AES128

<AES mit 256 Bit>            ::=     AES256

2.10 Beispiele zur Umsetzung

2.10.1 Beispiele für asymmetrische Objekte

Tabelle 6: Tab_PKI_206-01 Beispiele für asymmetrische Objekte 

Komp- onente	Fachliche Beschreibung	Name des Zertifikats	Name des privaten Schlüssels	Name des öffentlichen Schlüssels mit einer konkreten technischen Ausprägung
eGK	X.509- Zertifikat/Schlüssel des Versicherten für die Verschlüsselung	C.CH.ENC	PrK.CH.ENC	PuK.CH.ENC2.R2048
	CV-Zertifikat der eGK zur C2C- Authentisierung	C.eGK.AUT_ CVC	PrK.eGK.AUT_CV C	PuK.eGK.AUT_CVC.E256
HBA	X.509- Zertifikat/Schlüssel des Heilberuflers für eine QES	C.HP.QES	PrK.HP.QES	PuK.HP.QES.R2048
	CV-Zertifikat des HBA zur C2C- Geräteauthentisierung	C.HPC.AUT D_SUK_CV C	PrK.HPC.AUTD_S UK_CVC	PuK.HPC.AUTD_SUK_CV C.E256
SMC	X.509- Zertifikat/Schlüssel der Institution für eine elektronische Signatur	C.HCI.OSIG	PrK.HCI.OSIG	PuK.HCI.OSIG.E256
	CV-Zertifikat der SMC zur C2C- Rollenauthentisierung	C.SMC.AUT R_CVC	PrK.SMC.AUTR_C VC	PuK.SMC.AUTR_CVC.E256
VPN- Zugangs- dienst	X.509-Zertifikat/Schlüssel des VPN- Zugangsdienstes	C.VPNK.VPN	PrK.VPNK.VPN	PuK.VPNK.VPN.R2048
Fachanw. spez. Dienst allgem.	X.509-Zertifikat/Schlüssel eines Fachanwendungs- spez. Dienstes als Server für TLS- Verbindung	C.FD.TLS-S	PrK.FD.TLS-S	PuK.FD.TLS-S.R2048
Fach- dienst VSD	X.509-Zertifikat/Schlüssel des VSD- Fachdienstes zum Signieren einer Nachricht	C.VSD.AUT	PrK.VSD.AUT	PuK.VSD.AUT R2048

2.10.2 Beispiele für symmetrische Objekte

Tabelle 7: Tab_PKI_207 Beispiele für symmetrische Objekte 

Komponente	Fachliche Beschreibung	Name des geheimen Schlüssels	Name des geheimen Schlüssels mit einer konkreten technischen Ausprägung
eGK	Kartenindividueller Schlüssel für die Authentifizierung zwischen eGK und CMS	SK.CMS.AUT	SK.CMS.AUT.3DES
	Kartenindividueller Schlüssel für Verschlüsselung zwischen eGK und VSD	SK.VSD.ENC	SK.VSD.ENC.AES256
Fachdienst VSD	Masterschlüssel zur Ableitung der kartenindividuellen Schlüssel SK.VSD.AUT	SK.VSD.KG	SK.VSD.KG.AES128

3 CA-Strukturen

Für die Anforderungen aus dem operativen Produktivbetrieb der TI sowie den davon verschiedenen Anforderungen für Entwicklung, Test und Zulassung andererseits werden in der TI jeweils getrennte, in sich abgeschlossene PKIen implementiert.

Nachfolgend werden folgende Aspekte der CA-Strukturen der TI spezifiziert:

• Betriebsumgebungen
• CA-Gültigkeitszeiträume
• Definition der CA-Namen
  • für Produktivumgebung
  • Test- und Referenzumgebungen

3.1 Übergreifende Festlegung für CA der TI

In diesem Kapitel werden Aspekte der CA-Strukturen in der TI beschrieben.

GS-A_4257 - Hauptsitz und Betriebsstätte

Die gematik Root-CA, ein TSP-X.509 nonQES, ein TSP-X.509 QES, ein TSP-CVC die CVC-Root und der TSL-Dienst MÜSSEN ihren Hauptsitz und die Betriebsstätten für den tatsächlichen Betrieb in einem Land der Europäischen Union haben.

[<=]

3.1.1 Übersicht der Identitäten/Zertifikate

Für eine Übersicht der kryptographischen Identitäten, für die entsprechende CA-Strukturen zu bilden sind, siehe [gemKPT_PKI_TIP#3.1.1].

3.1.2 Laufzeiten der CA

Die zulässigen Gültigkeitszeiträume für CA-Zertifikate sind in der Policy [gem-RL_TSL_SP_CP#7.3.2] spezifiziert.

3.1.3 Unterstützung verschiedener Schlüsselgenerationen

Beim Betrieb der CAs in der TI werden Zertifikate verschiedener Schlüsselgenerationen parallel unterstützt (vgl. [gemKPT_PKI_TIP#TIP1-A_6878]). Die Schlüsselgeneration eines Zertifikats wird durch dessen Schlüsselalgorithmus und Signaturalgorithmus festgelegt.

GS-A_5511 - Unterstützung der Schlüsselgeneration RSA durch TSP-X.509 nonQES

Die gematik Root-CA und ein TSP-X.509 nonQES MÜSSEN die Schlüsselgeneration RSA (gemäß [gemSpec_Krypt#GS-A_4357]) unterstützen.

[<=]

Hinweis: Derzeit existieren für die Schlüsselgeneration „RSA“ der gematik Root-CA die Zertifikate C.GEM.RCA1 und C.GEM.RCA2. Da letzteres bis Januar 2027 gültig ist, ist kein weiterer Schlüsselversionswechsel innerhalb dieser Schlüsselgeneration vorgesehen.

GS-A_5528 - Unterstützung der Schlüsselgeneration ECDSA durch TSP-X.509 nonQES

Die gematik Root-CA und ein TSP-X.509 nonQES, der Zertifikate für die Kartengeneration G2.1 erstellt oder verwendet, MÜSSEN die Schlüsselgeneration ECDSA (gemäß [gemSpec_Krypt#GS-A_4357]) unterstützen.

[<=]

GS-A_5512 - Unterstützung der Schlüsselgeneration RSA durch TSP-X.509 QES

Ein TSP-X.509 QES MUSS die Schlüsselgeneration RSA gemäß [gemSpec_Krypt#GS-A_4358] unterstützen.

[<=]

GS-A_5529 - Unterstützung der Schlüsselgeneration ECDSA durch TSP-X.509 QES

Ein TSP-X.509 QES, der Zertifikate für die Kartengeneration G2.1 erstellt oder verwendet, MUSS die Schlüsselgeneration ECDSA gemäß [gemSpec_Krypt#GS-A_4358] unterstützen.

[<=]

GS-A_5513 - Wahl des Signaturalgorithmus für Zertifikate

Die gematik Root-CA, die TSP-X.509 QES und die TSP-X.509 nonQES MÜSSEN Zertifikate mit dem Signaturalgorithmus der Schlüsselgeneration des Zertifikats signieren. Ausgenommen davon sind die Crosszertifikate der gematik Root-CA.

[<=]

3.2 TI-Betriebsumgebungen

Für die Anforderungen von Entwicklung, Test, Zulassung und Wirkbetrieb sind folgende Betriebsumgebungen durch eine PKI zu unterstützen.

• 1..n Testumgebungen    
  für z. B. Produkt- und produktübergreifende Tests im Rahmen der Zulassung von Komponenten und Diensten.
• 1..n Referenzumgebungen    
  für eigenverantwortliche Tests seitens der Hersteller und Diensteanbieter.
• Produktivumgebung
  Es wird genau eine Produktivumgebung für den Wirkbetrieb implementiert.

 

Abbildung 1: Betriebsumgebungen aus Sicht der PKI 

3.2.1 PKI-Sicht auf die Produktivumgebung

Grundlagen und Anforderungen der CA-Struktur für die Produktivumgebung sind in [gemKPT_PKI_TIP#3] ausgeführt.

3.2.2 PKI-Sicht auf Test- u. Referenzumgebung (PKI-TeRe)

Die gemeinsame PKI-TeRe unterstützt und vereinfacht die abgestuften Test-, Freigabe- und Zulassungsprozesse über diese beiden Umgebungen hinweg, d. h. die verwendeten Identitäten und die damit ausgestatteten Karten, Geräte und Dienste können in beiden Umgebungen gleichermaßen betrieben werden.

Neben den in der PKI-TeRe gemeinsam genutzten Produkttypen (gematik Root-CA, TSP-X.509 nonQES) werden einige andere Elemente aus Gründen der besseren Abbildbarkeit von Test-Szenarien für Test- und Referenzumgebung separat zur Verfügung gestellt. Dazu gehört der TSL-Dienst.

Die PKI-TeRe verfügt über keinerlei Übergänge zur Produktivumgebung - weder netzwerktechnisch noch hinsichtlich des TI-Vertrauensraumes.

GS-A_4695 - Zentrale Root-CA für Test- und Referenzumgebung

Der Anbieter der gematik Root-CA MUSS in der Test- und Referenzumgebung eine zentrale TeRe-Root-CA bereitstellen und hieraus TeRe-CAs der zweiten Ebene zertifizieren.

[<=]

GS-A_4696 - OCSP-Responder für gematik TeRe-Root-CA im Internet

Der Anbieter der gematik Root-CA MUSS einen OCSP-Responder für die CA-Zertifikate der TeRe-Root-CA im Internet bereitstellen.

[<=]

GS-A_4697 - PKI für Test- und Referenzumgebung

Der TSP-X.509 nonQES MUSS für jede von ihm betriebene CA der Produktivumgebung eine korrespondierende CA für die Test- und Referenzumgebung implementieren.

[<=]

Die CA-Struktur entspricht insgesamt derjenigen der Produktivumgebung.

3.2.3 Pseudo-QES PKI in Test- u. Referenzumgebung

In der Test- und in der Referenzumgebung werden auch QES-Komponenten getestet, es wird darum eine zur Produktivumgebung analoge Infrastruktur für QES-Zertifikate aufgebaut, die „Pseudo-QES PKI“. Dies beinhaltet:

• Ein Zertifikatsherausgeber für HBA-Zertifikate muss eine separate Pseudo-QES PKI zur Ausgabe von Pseudo-QES-Zertifikaten für HBA-Testkarten und HBA-Entwicklerkarten aufbauen.
• Zur Abbildung der BNetzA-VL in der Test- und Referenzumgebung wird eine Pseudo-BNetzA-VL verwendet. Diese ist analog zur BNetzA-VL strukturiert und enthält die zusätzlichen CAs, die als funktionales QES-Äquivalent in der Test- und Referenzumgebung dienen.

GS-A_4698 - Pseudo-QES PKI für PKI-TeRe

Der TSP-X.509 QES SOLL für jede von ihm betriebene QES-CA der Produktivumgebung eine funktional äquivalente CA in der PKI-TeRe implementieren.

[<=]

GS-A_5483 - Aufnahme der Pseudo-QES CA in die Pseudo-BNetzA-VL

Der TSP-X.509 QES MUSS jede von ihm in der PKI-TeRe betriebene CA in die Pseudo-BNetzA-VL aufnehmen lassen.

[<=]

3.3 Zentrale Aussteller-CAs in der TI für nonQES-Zertifikate

Die TI-Plattform stellt zentrale Aussteller-CAs für nonQES-Zertifikate der verschiedenen Anwendungsbereiche zur Verfügung.

GS-A_4702 - Zentrale Aussteller-CA für nonQES-Zertifikate

Der TSP-X.509 nonQES, der eine zentrale Aussteller-CA in der TI für die Ausgabe von nonQES-X.509-Zertifikaten für Komponenten oder Dienste bereitstellt, MUSS (1) die Zertifikatsstruktur gemäß Tab_PKI_212 und (2) im commonName die <usage> = KOMP, sowie (3) im organizationalUnitName den <usageName> = ’Komponenten’ umsetzen.

[<=]

Davon ausgenommen ist die Aussteller-CA für die Ausgabe von X.509-Zertifikaten für VPN-Zugangsdienste.

GS-A_5212 - Zentrale Aussteller-CA für VPN-Zugangsdienst-Zertifikate

Der TSP-X.509 nonQES, der eine zentrale Aussteller-CA in der TI für die Ausgabe von nonQES-X.509-Zertifikaten für VPN-Zugangsdienste bereitstellt, MUSS (1) die Zertifikatsstruktur gemäß Tab_PKI_212 und (2) im commonName die <usage> = VPNK, sowie (3) im organizationalUnitName den <usageName> = ’VPN-Zugangsdienst’ umsetzen.

[<=]

3.4 Spezifische Aussteller-CA in der TI

Alternativ können TSP-X.509 nonQES auch dienstespezifische Aussteller-CAs, für definierte Einsatzbereiche (bspw. Konnektor) betreiben.

GS-A_4703 - CA-Zertifikatsprofil für nonQES-Zertifikate

Ein TSP-X.509 nonQES und der Anbieter des TSL-Dienstes MÜSSEN für die Beantragung einer Aussteller-CA unterhalb der zentralen gematik-Root-CA die Zertifikatsstruktur gemäß Tab_PKI_212 und einem CA-Namen entsprechend der Tabelle Tab_PKI_213 umsetzen.

[<=]

GS-A_4704 - Nutzung von CA mit spezifischem Verwendungszweck

Ein TSP-X.509 nonQES, TSP-X.509 QES und der Anbieter des TSL-Dienstes DÜRFEN aus einer Aussteller-CA mit einem spezifischen Verwendungszweck NICHT weitere EE-Zertifikate für andere Zwecke ausgeben.
[<=]

GS-A_4828 - Vorgaben zur Bildung von nonQES-CA-Namen

Ein TSP-X.509 nonQES MUSS für eine Aussteller-CA unterhalb der zentralen gematik-Root-CA (1) die Zertifikatsstruktur gemäß Tab_PKI_212 umsetzen und (2) für die Bildung des subjectDN im Feld subject.commonName die Einträge aus der Spalte <usage> sowie (3) im Feld organizationalUnitName die korrespondierenden Einträge aus der Spalte <usageName> aus der Tabelle Tab_PKI_213 umsetzen.

[<=]

Tabelle 8: Tab_PKI_213 Erlaubte Werte für <usage> und <usageName> 

Spezifischer CA-Einsatzbereich	<usage> im Feld commonName	<usageName> im Feld organizationalUnitName
Heilberufsausweis	HBA	Heilberufsausweis
Berufsausweis	BA	Berufsausweis
Institutionskarten	SMCB	Institution des Gesundheitswesens
eHealth-Kartenterminals	SMKT	Kartenterminal
Konnektor	KON NK AK SAK	Konnektor Netzkonnektor Anwendungskonnektor SigAnwendKomponente
Zentrale Dienste	ZD	ZentraleDienste
Fachanwendungsspezif. Dienst	FD	Fachanwendungsspezifischer Dienst
OCSP-Dienst	OCSP	OCSP-Signer
CRL-Dienst	CRL	CRL-Signer
TSL-Dienst	TSL	TSL-Signer
VPN-Zugangsdienst	VPNK	VPN-Zugangsdienst
Elektronische Gesundheitskarte	EGK	Elektronische Gesundheitskarte
Elektronische Gesundheitskarte (alternative Versichertenidentitäten)	EGK-ALVI	eGK alternative Vers-Ident
Komponenten (Geräte und Dienste)	KOMP	Komponenten

4 Kodierung von X.509-Identitäten

4.1 Namensregeln und -formate

Die Abbildung einer realen Identität (Person, Dienst, Komponente) in ein X.509-Zertifikat erfolgt durch den Inhalt der Felder SubjectDN (subject distinguishedName). 

4.1.1 Verarbeitung von Sonderzeichen

GS-A_4705-01 - Verarbeitung von Sonderzeichen in PKI-Komponenten

gematik-Root-CA, TSP-X.509 QES und TSP-X.509 nonQES MÜSSEN sicherstellen, dass von ihnen eingesetzte Komponenten in der Lage sind, Sonderzeichen wie ä, ü, ö, ß etc. anhand eines Zeichensatzes gemäß Tab_PKI_229-01 in den einzelnen Namenselementen zu verarbeiten und darzustellen.
[<=]

Aufgrund der weit verbreiteten 8-Bit-Kodierung (z.B. MS Windows, Apache Server) kann alternativ der Zeichensatz [ISO8859-1] zur Darstellung der Sonderzeichen verwendet werden.

Distinguished Names können daher generell mit diesen Sonderzeichen gebildet werden. Bei Kommunikationspartnern außerhalb Deutschlands kann die Verwendung von Umlauten zu Problemen führen, z. B. bei der Darstellung von Distinguished Names. Die zuständigen Instanzen für die Namensgebung müssen diese Problematik berücksichtigen.

Für TI-interne TLS-Server und TLS-Client-Zertifikate können Umlaute und UTF-8-Codierungen verwendet werden, da auch für diese Komponenten eine Unterstützung eines Zeichensatzes (s. GS-A-4705-01) gefordert ist.

4.1.2 Definition der Subject-DNs für Personen und Komponenten

• Definition der Versichertenidentität in Kap 5.1.15.11
• Definition der Organisationsidentität in Kap 5.3.1
• Definition der Identitäten von Konnektor und SMKT in Kap. 5.5.1 bzw. 5.6.1
• Definition der Identitäten der Zentralen Dienste und Fachanwendungsspezifischen Dienste in Kap. 5.8.1 und 5.9.1

4.1.3 SubjectDN von CA-Zertifikaten und von OCSP-Responder-Zertifikaten

GS-A_4706 - Vorgaben zu SubjectDN von CA- und OCSP-Zertifikaten

gematik-Root-CA, TSP-X.509 QES und TSP-X.509 nonQES MÜSSEN bzgl. Aufbau des SubjectDN in CA-Zertifikaten und OCSP-Responder-Zertifikaten folgende Vorgaben umsetzen: (a) Der subjectDN einer CA bzw. eines OCSP-Responders muss diese eindeutig innerhalb der TI identifizieren. (b) Das Attribut commonName muss enthalten sein und den relevanten Namen der CA bzw. des OCSP-Responders enthalten. (c) Das Attribut organizationName muss enthalten sein und den Namen des TSP enthalten. (d) Das Attribut countryName muss enthalten sein und das Herkunftsland des TSP (Land der Anschrift des TSP) enthalten. (e) Die Attribute serialNumber und organizationalUnitName können enthalten sein, sollen jedoch nur dann verwendet werden, falls sie für die Eindeutigkeit des subjectDN notwendig sind. (f) Das Attribut organizationIdentifier kann enthalten sein. (g) Darüber hinaus sollen keine weiteren Attribute enthalten sein.
[<=]

4.2 Schlüssel der Versichertenidentität (eGK)

Gemäß SGB § 290 definieren die Spitzenverbände der Krankenkassen die Struktur der Krankenversichertennummer, die aus einem unveränderbaren Teil zur Identifikation des Versicherten und einem veränderbaren Teil, der bundeseinheitliche Angaben zur Kassenzugehörigkeit enthält.

In den Zertifikaten C.CH.AUT, C.CH.ENC und C.CH.QES der eGK sowie C.CH.AUT_ALT der alternativen Versichertenidentitäten , wird in zwei OU-Feldern jeweils ein eindeutiger Schlüssel für den Versicherten sowie die Versicherungs-Institution aufgenommen:

• OU = unveränderbarer Teil der KV-Nummer
• OU = Institutionskennzeichen

Abbildung 2: Aufbau der Krankenversichertennummer 

4.3 Pseudonym der Versichertenidentität (eGK)

In den Zertifikaten C.CH.AUTN bzw. C.CH.ENCV der eGK (Schlüssel ohne PIN-Eingabe nutzbar) wird im Feld commonName des SubjectDN anstelle der personenbezogenen Klartextdaten ein Pseudonym verwendet. 

4.3.1 Versicherten-Pseudonym in X.509-Zertifikaten der eGK

GS-A_4572 - Abbildung Pseudonym in X.509-Zertifikaten der eGK

Der TSP-X.509 nonQES (eGK) MUSS im Feld commonName der Zertifikatstypen C.CH.AUTN bzw. C.CH.ENCV das Pseudonym des Versicherten aufnehmen.

[<=]

4.3.2 Eindeutigkeit des Pseudonym

Das Pseudonym dient als Ordnungskriterium (Primärschlüssel) für die Ablage von medizinischen Objekten und muss daher innerhalb der Herausgeber-Domäne über die Versicherten hinweg eindeutig sein. In Verbindung mit dem Herausgeber ist das Pseudonym so innerhalb der gesamten TI eindeutig.

GS-A_4573 - Eindeutigkeit des Pseudonyms innerhalb Herausgeber-Domäne

Der TSP-X.509 nonQES (eGK) MUSS das im AUTN- und ENCV-Zertifikat des Versicherten gespeicherte Pseudonym innerhalb der Herausgeber-Domäne (IssuerDomain) eindeutig gestalten.

[<=]

4.3.3 Pseudonym-Erstellungsregel

Die Bildung des Pseudonyms erfolgt nach einer Ableitungsregel aus bereits vorliegenden personenbezogenen Daten (KVNR) sowie durch ein herausgeberspezifisches Geheimnis. So kann auf den Einsatz eines technisch-organisatorischen Hintergrundsystems zur Verwaltung der Zuordnung von Pseudonymen zu Klaridentitäten verzichtet werden.

GS-A_4574 - Pseudonym-Erstellungsregel

Der TSP-X.509 nonQES (eGK) MUSS das Pseudonym des Versicherten nach folgender Regel bilden: SHA-256 Hashwert über die Konkatenierung der Datenfelder (1) Nachname des Versicherten, (2) unveränderbarer Teil der KVNR des Versicherten und (3) einer vom Herausgeber (Kostenträger) verwendeten Zusatzinformation (herausgeberspezifischer Zufallswert).

[<=]

Durch Verwendung dieses Verfahrens kann der Nachweis erbracht werden, dass eine bestimmte KVNR zu einem bestimmten Inhaber und dem entsprechenden Zertifikatsherausgeber gehört, ohne dass die KVNR in einem (öffentlichen) Zertifikats-Verzeichnis gespeichert werden muss.

Bei Kenntnis des Nachnamens sowie der KVNR eines Versicherten und sofern der vom Herausgeber verwendete Zufallswert zur Verfügung gestellt wird, kann das Pseudonym nachgerechnet werden. Dabei ist ein auch im Negativ-Fall zuverlässiges Prüfungsergebnis nur möglich, wenn die Anzahl der zu verwendenden Iterationsschritte beschränkt wird.

Beispiel:

Nachname =     
„Mustername1“ 

KVNR (unveränderlicher Teil, 10-stellig, AN) =     
„M331784849“ 

herausgeberspezifischer Zufallswert (16-stellig, h) =     
„A32C93C6946314A9“ 

Konkatenation =     
„Mustername1M331784849A32C93C6946314A9“ 

SHA-256- Hashwert =    
“E3F3555165491A7FBE3F355516549E3F3555165902BFAF254518C469E584A793” 

Für den commonName werden die ersten 20 Hex-Zeichen (Variationsbreite 80 Bit) verwendet: 

commonName =    
“E3F3555165491A7FBE3F” 

GS-A_4575 - Prüfung auf Eindeutigkeit des Pseudonyms

Der TSP-X.509 nonQES (eGK) MUSS nach Erzeugung des Pseudonyms prüfen, ob dieses Pseudonym vom Kartenherausgeber bereits vergeben wurde. Ist dies der Fall, MUSS das Pseudonym mit inkrementiertem hs-ZW neu generiert und erneut auf Eindeutigkeit geprüft werden.

[<=]

GS-A_4576 - Pseudonym auf eGK-Ersatzkarten

Der TSP-X.509 nonQES (eGK) MUSS bei Ausstellung eines eGK-Ersatzausweises innerhalb der definierten Verwendungsperiode des herstellerspezifischen Zufallswertes (hs-ZW) dasselbe Pseudonym verwenden wie auf der vorgängigen Karte.

[<=]

GS-A_4577 - Pseudonym auf eGK-Folgekarten

Der TSP-X.509 nonQES (eGK) MUSS bei Ausstellung eines eGK-Ersatzausweises nach Ablauf der definierten Verwendungsperiode des hs-ZW oder bei Ausstellung einer Folgekarte nach Ablauf des Gültigkeitszeitraums der vorgängigen Karte ein neues Pseudonym auf Grundlage des geänderten hs-ZW vergeben.

[<=]

4.3.4 Hs-ZW – Herausgeberspezifischer Zufallswert (hs-ZW)

Da der herausgeberspezifische Zufallswert für alle Versicherten eines Herausgebers identisch ist, muss dieser periodisch, z. B. jährlich gewechselt werden.

GS-A_4578 - eGK hs-ZW Bildungsregel

Der eGK-Herausgeber MUSS einen individuellen herausgeberspezifischen Zufallswert (hs-ZW) aus mindestens 16 Hexadezimal-Ziffern (64 Bit) festlegen, der jeweils kollisionsfrei zu allen vorherigen hs-ZW dieses eGK-Herausgebers ist.

[<=]

GS-A_4579 - eGK hs-ZW Verwendung/Wechsel

Der eGK-Herausgeber MUSS den aktuellen hs-ZW für alle Versichertenzertifikate für eine bestimmte Verwendungsperiode verwenden und mindestens einmal jährlich wechseln.

[<=]

GS-A_4580 - eGK hs-ZW Archivierung

Der eGK-Herausgeber MUSS alle nicht mehr verwendeten hs-ZW für Zwecke der Rekonstruktion von Pseudonymen für mindestens 10 Jahre sicher speichern und berechtigten Teilnehmern der TI verfügbar machen.

[<=]

4.3.5 Kodierung des Pseudonyms

Für das eGK-Pseudonym gilt folgende Systematik für Erstellung und Verwendung.

 

Abbildung 3: Pseudonym Kodierung in X.509-Versichertenzertifikaten 

 

GS-A_4582 - Pseudonym-Personalisierung im X.509-SubjectDN

Der eGK-Herausgeber MUSS das Pseudonym im UTF-8-Zeichensatz codiert in das Zertifikat der eGK einbringen.

[<=]

4.4 Berufsgruppen-ID der Leistungserbringer

4.4.1 Berufsgruppe des Heilberuflers

Die Admission Extension der HBA beinhaltet die Berufsgruppe des Heilberuflers als Text und in Form einer maschinenlesbaren OID sowie zusätzlich einen Schlüsselwert für die einzelne Person in Form der Telematik-ID (s. Abschnitt 4.7.1). Optional können weitere Berufsgruppenmerkmale des Heilberuflers in diese Struktur aufgenommen werden.

Die konkreten OID-Werte sind in [gemSpec_OID#3.5.1.1] definiert.

GS-A_4583 - Berufsgruppenkennzeichen für HBA

Der HBA-Herausgeber MUSS die Berufsgruppe(n) des Heilberuflers in Form einer textuellen Bezeichnung und einer OID gemäß Tab_PKI_221 in jedes Zertifikat eines HBA gleichlautend einbringen und dabei die Werte aus [gemSpec_OID#GS-A_4442] verwenden.

[<=]

GS-A_4584 - Verwendung von Berufsgruppenkennzeichen

TSP-X.509 nonQES und TSP-X.509 QES DÜRFEN NICHT Berufsgruppenkennzeichen, für deren Verwendung sie nicht zugelassen und beauftragt sind, in HBA-Zertifikate einbringen.

[<=]

Tabelle 9: Tab_PKI_221 Berufsgruppenkennzeichnung 

Art der ID	Ort	X.509 Feldname	Format	Inhalt	Beispiel
Berufsgruppe / Rolle	Admission	ProfessionItem	Text	<Berufsgruppe>	Ärztin/Arzt
		ProfessionOID	OID	oid_<berufsgruppe>	1.2.276.0.76.4.30
Einzelne Person	Admission	RegistrationNumber	AN	<Telematik-ID>	1-1a25sd-d529

4.5 ID der Organisation/Einrichtung des Gesundheitswesens

4.5.1 Typ und Exemplar der Organisation/Einrichtung des Gesundheitswesens

Die Admission Extension der SMC-B beinhaltet die Art der Organisation/Einrichtung des Gesundheitswesens als Text und in Form einer maschinenlesbaren OID sowie zusätzlich die einzelne Institution in Form der Telematik-ID (s. Abschnitt 4.7.1).

Die konkreten OID-Werte sind in [gemSpec_OID#3.5.1.3] definiert.

GS-A_4585 - Typ der Organisation/Einrichtung des Gesundheitswesens für SMC-B

Der SMC-B-Herausgeber MUSS den Typ der Organisation/Einrichtung des Gesundheitswesens in Form einer textuellen Bezeichnung und einer OID gemäß Tab_PKI_222 in jedes Zertifikat einer SMC-B gleichlautend einbringen und dabei die Werte aus [gemSpec_OID#GS-A_4443] verwenden.

[<=]

GS-A_4586 - Verwendung von Institutionskennzeichen

TSP-X.509 nonQES DÜRFEN Institutskennzeichen, für deren Verwendung sie nicht zugelassen und beauftragt sind, NICHT in SMC-B-Zertifikate einbringen.

[<=]

Tabelle 10: Tab_PKI_222 Institutionstypkennzeichnung 

Art der ID	Ort	X.509 Feldname	Format	Inhalt	Beispiel
Institutionstyp	Admission	ProfessionItem	Text	<Institutionstyp>	Zahnarztpraxis
		ProfessionOID	OID	oid_<institutionstyp>	1.2.276.0.76.4.51
Einzelne Institution	Admission	RegistrationNumber	AN	<Telematik-ID>	2- 2a25sd-d529

4.6 Technische Rolle von Komponenten und Diensten

4.6.1 Technische Rolle im Komponentenzertifikat

Die Admission Extension der Komponentenzertifikate beinhaltet die technische Rolle der Komponente bzw. des Dienstes als Text und in Form einer maschinenlesbaren OID, aber keine zusätzliche Kennung einer einzelnen Instanz vergleichbar der Telematik-ID.

Die konkreten OID-Werte sind in [gemSpec_OID#3.5.4] definiert.

GS-A_4707 - Kennzeichen für Technische Rolle für Komponenten und Dienste

Der Kartenherausgeber MUSS die technische Rolle einer Komponente bzw. eines Dienstes in Form einer textuellen Bezeichnung und einer OID gemäß Tab_PKI_230 in jedes Zertifikat der Komponente bzw. des Dienstes gleichlautend einbringen und dabei die Werte aus [gemSpec_OID#GS-A_4446] verwenden.

[<=]

GS-A_4708 - Verwendung von Kennzeichen für Technische Rolle

TSP-X.509 nonQES für gSMC MÜSSEN ausschließlich solche Kennzeichen für technische Rollen in Komponentenzertifikate einbringen, für die der Antragsteller nachweislich berechtigt ist.

[<=]

Tabelle 11: Tab_PKI_230 Kennzeichnung Technische Rolle 

Art der ID	Ort	X.509 Feldname	Format	Inhalt	Beispiel
Technische Rolle	Admission	ProfessionItem	Text	<Technische Rolle>	Netzkonnektor
		ProfessionOID	OID	oid_<Technische Rolle>	1.2.276.0.76.4.104

4.7 Telematik-ID

Die Telematik-ID repräsentiert als eineindeutiges Merkmal die Identität eines Teilnehmers, also eines Leistungserbringers im HBA respektive einer Organisation/Einrichtung des Gesundheitswesens in einer SMC-B. Die Telematik-ID muss daher über alle Sektoren hinweg eineindeutig bezogen auf die elektronische Identität der betroffenen Teilnehmer in der Telematikinfrastruktur sein. Die Zuordnung der Telematik-ID zum Teilnehmer wird in [gemKPT_PKI_TIP] beschrieben.

Für Ersatzkarten und Austauschkarten wird die Telematik-ID der Originalkarte verwendet.

Für Folgekarten muss die Telematik-ID nicht identisch zur Vorgängerkarte sein. Der Arzt und die medizinische Institution können eine neue Telematik-ID beantragen oder auch die bisherige in der Folgekarte wieder verwenden.

GS-A_4958 - Neue Telematik-ID bei Folgekarten

Der Kartenherausgeber MUSS bei der Ausgabe von Folgekarten dem Antragsteller die Möglichkeit bieten, eine neue Telematik-ID zu beziehen.

[<=]

GS-A_4960 - System für Sektorkennzeichen

Der Gesamtbetriebsverantwortliche der TI MUSS zur Sicherstellung der Eindeutigkeit der Telematik-ID über die verschiedenen Sektoren des Gesundheitswesens hinweg ein System für Sektorkennzeichen als Bestandteil (Präfix) der Telematik-ID etablieren und verwalten.

[<=]

4.7.1 Abbildung der Telematik-ID im X.509-Zertifikat

Die Telematik-ID wird im Feld registrationNumber der Extension Admission hinterlegt, vgl. Beispiel in Tabelle 12. 

GS-A_4709 - Abbildung der Telematik-ID in Admission-Struktur

TSP-X.509 nonQES MÜSSEN zur Abbildung der Telematik-ID in HBA- sowie SMC-B-Zertifikaten eine Admission Extension aufnehmen, die eine oder mehrere Struktur(en) „ProfessionInfo“ und darin im Feld „registrationNumber“ die Telematik-ID enthalten muss.

[<=]

GS-A_4901 - Einheitliche Admission in Zertifikaten einer Karte

TSP-X.509 QES und TSP-X.509 nonQES SOLLEN die Admission Extension in allen X.509-Zertifikaten einer Karte identisch einbringen. In den Herausgabe-Policies können Ausnahmen hiervon definiert sein.

[<=]

Tabelle 12: Tab_PKI_224 Telematik-ID-Kennzeichnung 

Art der ID	Ort	X.509 Feldname	Format	Inhalt	Beispiel
Berufsgruppe / Rolle	Admission	ProfessionItem	Text	<Berufsgruppe>	Ärztin/Arzt
		ProfessionOID	OID	oid_<berufsgruppe>	1.2.276.0.76.4.30
Einzelne Person / Institution	Admission	registrationNumber	AN	<Telematik-ID>	1-1a25sd-d529

4.7.2 Aufbau der Telematik-ID

GS-A_4587 - Gesamtlänge der Telematik-ID

Herausgeber von HBA und SMC-B MÜSSEN sicherstellen, dass die Gesamtlänge der Telematik-ID (Präfix, Separator und Fortsatz) 128 Zeichen nicht überschreitet.

[<=]

Tabelle 13: Tab_PKI_223 Aufbau der Telematik-ID 

Bestandteil	Inhalt	Länge	Format
Präfix	Nummernkreis der jeweiligen Organisation (Unterscheidung der Sektoren)	nicht festgelegt	N
Separator	Trennzeichen zwischen Präfix und Fortsatz	„-“
Fortsatz	eindeutige Nummer, sektorspezifisch (z. B. Betriebsstätten-Nr. o. ä.)	nicht festgelegt	AN

Anmerkung zur Darstellung des Formats: N=numerisch, AN=alphanumerisch

4.7.2.1 Sektoraler Präfix

GS-A_4710 - Präfix der Telematik-ID

Herausgeber von HBA und SMC-B MÜSSEN die in Tab_PKI_101 festgelegten Präfixe der Telematik-ID verwenden.

[<=]

Tabelle 14: Tab_PKI_101-01 Normative Festlegung für das Präfix der Telematik-ID. 

Präfix	Sektor	Zuständige Organisationen
1	Ärzteschaft	BAEK, KBV
2	Zahnärzteschaft	BZÄK, KZBV
3	Apothekerschaft	BAK
4	Psychotherapeutenschaft	BPTK
5	Krankenhaus	DKG
6	(Reserved for future use)
7	KTR-AdV
8	Kostenträger	GKV-SV
9	Weitere Organisationen des Gesundheitswesens	gematik
10	Weitere Leistungserbringer des Gesundheitswesens und deren Institutionen	eGBR
11	Gesundheitshandwerke	ZDH

Hinweis: Kassenärztliche Vereinigungen (KVen) geben SMC-Bs für die Betriebsstätten ihrer Mitglieder aus. Dies betrifft neben den Praxen der Kassenärzte auch solche von Vertragspsychotherapeuten. Als Mitglied der KBV teilt eine KV dabei eine Telematik-ID mit Präfix „1“ zu, auch wenn es sich um die Betriebsstätte eines Psychotherapeuten handelt.

Die gematik teilt den von ihr herausgegebenen Identitäten bzw. Karten SMC-B ORG das Präfix "9" zu, auch wenn die berechtigten Organisationen den in Tab_PKI_101-01 gelisteten Sektoren mit den Präfixen "1-8" zuzurechnen sind. Darüber hinaus sind für eine Übergangszeit, voraussichtlich bis 2025, im Bereich der Kassenzahnärztlichen Vereinigungen noch Karten SMC-B ORG im produktiven Einsatz, die das Präfix "2" tragen.

Der Nummernraum des Präfixes wird durch die gematik GmbH verwaltet.

4.7.2.2 Separator

GS-A_4711 - Separator der Telematik-ID

Herausgeber von HBA und SMC-B MÜSSEN sicherstellen, dass bei der Abbildung der Telematik-ID das Präfix vom Rest der Telematik-ID durch einen Separator getrennt wird und als Separator das Minuszeichen „-“ mit ASCII-Wert 45 dezimal beziehungsweise 0x2D hexadezimal verwendet wird.

​​

[<=]

4.7.2.3 Fortsatz der Telematik-ID

GS-A_4712 - Definition und Eindeutigkeit der Telematik-ID

Kartenherausgeber von HBA und SMC-B in den jeweiligen Sektoren MÜSSEN Syntax, Semantik und Vergabe des Fortsatzes der Telematik-ID so definieren, dass die Eindeutigkeit des sektorspezifischen Anteils der Telematik-ID gewährleistet ist.

[<=]

Beispiele für die weiterführende Unterteilung für den Bereich der Ärzteschaft:

• Die Telematik-ID beginnt mit 1-1 bei einem eArztausweis (HPC),
• Die Telematik-ID beginnt mit 1-2 bei einem ePraxisausweis (SMC).

GS-A_4713 - Zeichensatz für den Fortsatz der Telematik-ID

TSP-X.509 QES und TSP-X.509 nonQES MÜSSEN den vom jeweiligen Sektor vorgegebenen Zeichensatz für den Fortsatz der Telematik-ID verwenden.

[<=]

4.8 Kodierung der Zertifikate

4.8.1 Kodierung der Attribute

In diesem Kapitel werden die für alle X.509-Zertifikate einheitlich geltenden Felder und ihre Kodierung aufgeführt. Ergänzende profilspezifische Kodierungsvorgaben sind bei den jeweiligen Profilen ausgeführt.

GS-A_4714-01 - Kodierung der Attribute in X.509-Zertifikaten

TSP-X.509 und der Anbieter des TSL-Dienstes MÜSSEN bei der Kodierung der Attribute in X.509-Zertifikaten die Vorgaben aus Tab_PKI_229-01 umsetzen. Die Vorgaben sind unabhängig davon, ob das jeweilige Attribut innerhalb eines issuer (Typ Name)-, subject (Typ Name)- oder eines extension (Typ Extension)-Elementes im Zertifikat verwendet wird
 

Tabelle 15: Tab_PKI_229-01 Kodierung der Attribute in X.509-Zertifikaten 

Attribut / Attribut-OID	Kodierung	Max. Stringlänge (Zeichen)
commonName {id-at 3}	UTF8String[RFC3629] *)	64
surName {id-at 4}	UTF8String[RFC3629] *)	64
localityName {id-at 7}	UTF8String[RFC3629] *)	128
stateOrProvinceName {id-at 8}	UTF8String[RFC3629] *)	128
streetAdress {id-at 9}	UTF8String[RFC3629] *)	128
organizationName {id-at 10}	UTF8String[RFC3629] *)	64
organizationalUnitName {id-at 11}	UTF8String[RFC3629] *)	64
title {id-at 12}	UTF8String[RFC3629] *)	64
postalCode {id-at 17}	UTF8String[RFC3629] *)	40
givenName {id-at 42}	UTF8String[RFC3629] *)	64
serialNumber {id-at 5}	PrintableString [ RFC5280]	64
countryName {id-at 6}	PrintableString [ RFC5280] gültiger "ISO 3166-1 alpha-2 country code" [ISO 3166-1] (s.a. [X.520] Kap. 6.3.1)	2
organizationIdentifier {id-at 97}	UTF8String [X.520] Annex A und [ETSI EN 319 412-1] Kap. 5.1.4 (juristische Person)	-
*) Einschränkung des erlaubten Zeichensatzes auf dedizierte ISO-Subsets gemäß Vorgaben der jeweiligen Kartenherausgeber

[<=]

4.8.2 Stringlänge der Attribute

GS-A_4715-01 - Maximale Stringlänge der Attribute im SubjectDN

TSP-X.509 und der Anbieter des TSL-Dienstes MÜSSEN bzgl. der maximalen Stringlänge der Attribute in X.509-Zertifikaten die Vorgaben aus Tab_PKI_229-01 umsetzen. Die Vorgaben sind unabhängig davon, ob das jeweilige Attribut innerhalb eines issuer (Typ Name)-, subject (Typ Name)- oder eines extension (Typ Extension)-Elementes im Zertifikat verwendet wird. [<=]

GS-A_4716 - Umgang mit überlangen Organisationsnamen im SubjectDN

Der TSP-X.509 nonQES für Komponenten, die gematik Root-CA und der Anbieter des TSL-Dienstes MÜSSEN für den Fall, dass der Wert des Attributs organizationName {id-at 10} in X.509-Zertifikaten eine String-Länge größer als 64 Zeichen hat, sicherstellen, dass die Angabe im subject auf 64 Zeichen abgekürzt wird und die Extension SubjectAltNames {2 5 29 17} mit der ungekürzten Angabe in das Zertifikat eingefügt wird.

[<=]

Hinweis:
Die TSP-X.509 nonQES für SMC-B nehmen eine etwaige Befüllung der Extension SubjectAltNames gemäß den Vorgaben des jeweiligen Sektors vor. Diese sind den jeweiligen sektorspezifischen SMC-B Zertifikatsprofilen zu entnehmen.

4.8.3 Struktur

Für einige Extensions (Zertifikatserweiterungen) definiert [RFC5280] Kap. 4.2 mehrere unterschiedliche Ausprägungen der Strukturen. Um die Verwendung von Zertifikaten in der TI zu vereinfachen werden spezifisch einschränkende Festlegungen für Extensions gemäß Tab_PKI_226-01 festgelegt. Die Spalte „ASN.1 Definition“ beschreibt die ASN.1 Struktur. Die Spalte „TI-spezifische Vorgaben“ trifft Festlegungen für einzelne Elemente. Für nicht aufgeführte Extensions stellt die TI keine über die Standarddefinition hinausgehenden Anforderungen.

4.8.3.1 serialNumber

Wird zur Eindeutigkeit von Zertifikaten innerhalb der TI und zur Identifizierung von Zertifikaten verschiedener TSPs das Präfix TSP-ID innerhalb der subjectSerialNumber genutzt, so werden die Werte folgender Tabelle Tab_PKI_109 verwendet. 

Tabelle 16: Tab_PKI_109 Werte für das Präfix <TSP-ID> 

Präfix <TSP-ID>	Zertifizierungsdiensteanbieter
10	D-TRUST
11	Signtrust
12	T-Systems Telesec
13	S-Trust
14	TC TrustCenter
15	DGN
16	medisign
19	atos

Der Nummernraum des Präfixes wird durch die gematik GmbH verwaltet.

Im Falle der Clusterung von Diensten besteht evtl. die Notwendigkeit jeder Instanz ein eigenes Zertifikat auszustellen. Damit die Eindeutigkeit des SubjectDN im jeweiligen Zertifikat gewährleistet ist, kann die Ausprägung der Instanz in das Feld serialNumber übernommen werden.

GS-A_4725 - Eindeutiger SubjectDN durch serialNumber

Ein TSP-X.509 nonQES KANN die Eindeutigkeit des SubjectDN in einem X.509-Zertifikat für Zentrale Dienste und Fachanwendungsspezifischen Dienste durch die Verwendung des Attributes serialNumber {id-at-serialNumber} gewährleisten.

[<=]

GS-A_4726 - Verwendung von serialNumber zur Schaffung eindeutiger SubjectDNs

TSP-X.509 nonQES MÜSSEN bei Verwendung des Attributs serialNumber in X.509-Zertifikaten für Zentrale Dienste und Fachanwendungsspezifische Dienste den Inhalt entsprechend dem folgenden Format aufbauen: Instanz (fünfstellige Dezimalzahl) + “-“ + Unterscheidung Zertifikat (alphanumerischer Wert).

[<=]

4.8.3.2 Admission

Die Extension Admission enthält Angaben zur Registrierung und zu der beruflichen Zulassung (und somit auch zu daraus ableitbaren Autorisierungsinformationen) sowohl als Text als auch in Form einer maschinenlesbaren OID.     
Für die verschiedenen Zertifikatstypen sind dies jeweils: 

• die Berufsgruppen (HBA/BA),
• der Status als Versicherte/-r (eGK und alternative Versichertenidentitäten ),
• der Typ der Organisation/Institution (SMC-B) oder
• die technische Rolle (Komponentenzertifikate).

Außerdem können die Telematik-ID und die registrierende bzw. zulassende Stelle (admissionAuthority) in Admission eingetragen werden (in HBA-, BA- und SMC-B-Zertifikaten).

GS-A_4717-01 - TI-spezifische Vorgabe zur Nutzung der Extension Admission

TSP-X.509 nonQES und TSP-X.509 QES MÜSSEN bei Verwendung der Extension Admission {1 3 36 8 3 3} die Struktur in X.509-Zertifikaten entsprechend Tab_PKI_226-01 erstellen

Tabelle 17: Tab_PKI_226-01 Struktur Admission 

[<=]

4.8.3.3 CertificatePolicies

Die Extension CertificatePolicies enthält in X.509-Zertifikaten der TI zwei unterschiedliche Informationstypen:

• es werden ein oder mehrere Bezeichner für die Policies aufgenommen, die Festlegungen für Herausgabe und Einsatz dieser Zertifikate enthalten
• es wird ein Element eingefügt, das den Bezeichner für den Zertifikatstyp enthält (nur bei EE-Zertifikaten).

GS-A_4718 - TI-spezifische Vorgabe zur Nutzung der Extension CertificatePolicies

TSP-X.509 MÜSSEN bei Verwendung der Extension CertificatePolicies {2 5 29 32} die Struktur in X.509-Zertifikaten entsprechend Tab_PKI_227 erstellen.

[<=]

Tabelle 18: Tab_PKI_227 Struktur CertificatePolicies 

4.8.3.4 CRLDistributionPoints

Zertifikate des Zugangsdienstes C.VPNK.VPN und C.VPNK.VPN-SIS können im Internet mittels einer CRL auf ihren Sperrstatus geprüft werden. Daneben gibt es die übliche Prüfbarkeit des Sperrstatus über einen OCSP-Responder.

GS-A_5074 - Bereitstellung CRL und OCSP für Zertifikate des VPN-Zugangsdienstes

Der TSP-X.509 nonQES, der eine Aussteller-CA für die Ausgabe von C.VPNK.VPN und C. VPNK.VPN-SIS Zertifikaten betreibt, MUSS für diese Zertifikate eine CRL im Internet bereitstellen. Er MUSS ebenfalls für die Verteilung der Sperrinformationen der eben genannten Zertifikate über OCSP im Internet Statusinformationen zur Verfügung stellen. [<=]

Innerhalb der TI sind CRLs für die Statusprüfung von Zertifikaten nicht vorgesehen.

GS-A_5516 - Schlüsselgenerationen der CRL für Zertifikate des VPN-Zugangsdienstes

Der TSP-X.509 nonQES, der eine Aussteller-CA für die Ausgabe von C.VPNK.VPN und C. VPNK.VPN-SIS-Zertifikaten betreibt, MUSS für jede Schlüsselgeneration eine CRL bereitstellen und mit einem CRL-Signer-Zertifikat derselben Schlüsselgeneration (gemäß [gemSpec_Krypt] #GS-A_4357) bestätigen.

[<=]

4.8.3.5 SubjectAltNames

GS-A_4719 - TI-spezifische Vorgabe zur Nutzung der Extension SubjectAltNames

TSP-X.509 MÜSSEN bei Verwendung der (optionalen) Extension SubjectAltNames {2 5 29 17} die Struktur in X.509-Zertifikaten entsprechend Tab_PKI_228 erstellen.

[<=]

Tabelle 19: Tab_PKI_228 Struktur SubjectAltName 

Erläuterung:

Überlange Attribute des Subject Distinguished Name (SubjectDN) werden gekürzt, um die für sie geltenden Längenvorgaben einzuhalten (s. Tab_PKI_229 „Kodierung der Attribute in X.509-Zertifikaten“). Sie werden aber in der Extension „SubjectAltNames“ in voller Länge abgebildet.

Felder des „SubjectAltNames“ werden als „GeneralName“ gespeichert. Für die Verwendung von überlangen Namen wird der GeneralName-Typ OtherName benutzt. Dessen Struktur ist wie folgt aufgebaut: 

OtherName ::= SEQUENCE {

  type-id  OBJECT IDENTIFIER,

  value   [0] EXPLICIT ANY DEFINED BY type-id }

}

Die type-id entspricht der OID des zu verlängernden Feldes: 

• commonName        {id-at 3}
• organizationalUnitName    {id-at 11}
• organizationName    {id-at 10}

Bei Bedarf kann die beschriebene Struktur auch verwendet werden, um Alternativnamen oder Ergänzungen zum Namen aufzunehmen, welcher im durch ‚type-id‘ bezeichneten Attribut des SubjectDN enthalten ist, auch wenn dieser nicht gekürzt werden musste.

Für weitere Informationen, siehe auch ITU-T Rec. X.501 | [ISO/IEC9594-2]. Das Format des value wird entsprechend demjenigen des Attributes festgelegt, bei den Attributen commonName, organizationalUnitName und organizationName handelt es sich dabei immer um UTF8String. 

4.9 Erläuterungen zu Zertifikatsprofilen

Dieses Kapitel enthält eine Reihe von Erläuterungen und Hilfestellungen zum Verständnis der in Kapitel 5 dargestellten Zertifikatsprofile sämtlicher X.509-Zertifikate.

4.9.1 Allgemeine Erläuterungen

Die Angabe Kardinalität gibt an, wie oft ein Element in einem Zertifikat enthalten sein muss. Ein optionales Feld hat so z. B. eine Kardinalität von 0-1. Eine Kardinalität von 1 bezeichnet ein Pflichtfeld, das nur ein Mal auftreten darf.

Die Bezeichner „ZD, FD“ werden in den Festlegungen zu X.509-Zertifikaten als Kurzbezeichnungen für die Rollen von Zentralen Diensten und Fachanwendungsspezifischen Diensten verwendet.

Die Attribute einer Berufsgruppe, einer medizinischen Institution oder technischen Rolle werden in den X.509-Zertifikaten anhand einer maschinenlesbaren OID und einem textuellen Bezeichner beschrieben. Siehe hierzu auch Kap 4.4 bis 4.6.

Die normative Festlegung der Werte der Felder professionItems und professionOIDS erfolgt in den Tabellen Tab_PKI_402, Tab_PKI_403 und Tab_PKI_406 in [gemSpec_OID#3.5]. 

Für die Festlegung des Zertifikatstyps in der Extension CertificatePolicies wird eine OID-Referenz verwendet. Die normative Festlegung der durch diese Referenz dargestellten OIDs trifft das Dokument [gemSpec_OID# Tab_PKI_405].

4.9.2 Berufs-/Rollenattribute und Sperrbarkeit

GS-A_4721 - Beantragung Rollenattribute im X.509-Zertifikatsrequest

Der TSP-X.509 nonQES der Komponenten-PKI MUSS bei der Erstellung von X.509-Zertifikate für Dienste sicherstellen, dass ein Diensteanbieter nur Zertifikate für die Rollen beantragen kann, für die dieser Diensteanbieter in der TI von der gematik zugelassen ist.

[<=]

GS-A_4961 - Verwendung zugewiesener Berufs- und Rollenattribute

Die Kartenherausgeber MÜSSEN genau die Berufs- und Rollenattribute verwenden, die den zertifizierten Identitäten entweder auf gesetzlicher Grundlage oder durch Zuweisung einer gesetzlich autorisierten Standesvertretung zugewiesen wurden. Für die codierte Form dieser Attribute MÜSSEN die von der TI-Plattform verwalteten Berufs- und Rollencodes verwendet werden.

[<=]

GS-A_4722 - Belegung der Felder professionInfos

Der TSP-X.509 nonQES MUSS bei der Erstellung von X.509-Zertifikaten sicherstellen, dass die Werte professionItems und professionOIDS den Festlegungen für den Typ des beantragten Zertifikats entsprechen.

[<=]

GS-A_4724 - Komplettsperrung aller Zertifikate einer Karte

TSP-X.509 nonQES und TSP-X.509 QES MÜSSEN sicherstellen, dass alle Zertifikate auf einem Kartenexemplar durch einen Sperrauftrag gesperrt werden können (sofern für die jeweiligen Zertifikatstypen die Statusinformationsbereitstellungen gefordert sind).

[<=]

4.9.3 Benennung der Zertifikatsprofile

Mit den Zertifikatsprofilen sind in den folgenden Unterabschnitten auch einheitliche Namen für die Zertifikate genannt. Das Benennungsschema ist in Kap. 2 beschrieben.

4.9.4 Distinguished Name

Die Bezeichnung von Entitäten in X.509-Zertifikaten (in den Feldern „Subject“, „Issuer“ oder „admissionAuthority“) erfolgt über eine Datenstruktur, welche „Distinguished Name“ genannt wird. Beispiel:    
“CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US”

Ein Distinguished Name diente ursprünglich zur eindeutigen Bezeichnung eines Eintrages in einem X.500- (bzw. LDAP-) Verzeichnis. Der entsprechende Datentyp wird deshalb auch als „directoryName“ bezeichnet, und da der Aufbau eines solchen Verzeichnisses einer hierarchischen Baumstruktur folgt, ist auch ein Distinguished Name hierarchisch aufgebaut, auch wenn ein Distinguished Name in einem Zertifikat unabhängig von einem Verzeichnis und dessen Struktur erstellt werden kann.

Distinguished Names werden in X.509-Zertifikaten binär als „Sequence“, also als geordnete Folge codiert. Das hierarchisch höchste Element ist das erste in der Sequenz. Dabei handelt es sich in Distinguished Names gemäß den Zertifikatsprofilen, wie sie in Kapitel 5 dargestellt werden, üblicherweise um das Element „countryName=DE“ bzw. „C=DE“.

Die Textdarstellung eines Distinguished Name wird in [RFC4514] („Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names“) standardisiert:
Objekte bzw. Knoten in der Hierarchie werden durch Kommas getrennt, und das hierarchisch höchstes Element steht ganz hinten. Das Beispiel im einleitenden Absatz ist gemäß der RFC4514-Notation dargestellt. 

Distinguished Names können auch tabellarisch dargestellt werden. Dabei wird das hierarchisch höchste Element zuunterst aufgeführt. Die Reihenfolge in den Subject-Feldern in den Zertifikatsprofilen in Kapitel 5 folgt auch der tabellarischen Darstellung. Das hierarchisch tiefste Element (commonName bzw. CN) wird jeweils zuoberst notiert, „C=DE“ ganz unten in der Tabelle.

Für den Aufbau der Hierarchie von Distinguished Names existieren keine starren Regeln. Es gibt aber eingespielte Best-Practices dazu, und im Annex B von [X.521] werden Empfehlungen zum Aufbau formuliert. Z. B. soll ein countryName-Element, sofern vorhanden, als oberstes Element unter der Wurzel des Baumes eingefügt werden, organizationalUnitName (OU) soll hierarchisch immer unterhalb des organizationName (O) liegen etc.

Die in diesem Dokument (insbesondere in Kapitel 5) spezifizierten Distinguished Names sind ausnahmslos gemäß diesen Empfehlungen aufgebaut.

A_15676 - Reihenfolge der Elemente im SubjectDN von X.509-Zertifikaten

Der TSP-X.509 und der TSL-Dienst SOLLEN die Reihenfolge der Elemente im SubjectDN von erstellten X.509-Zertifikaten gemäß der Zertifikatsprofiltabellen in [gemSpec_PKI] umsetzen. Dabei sind die Elemente in den Zertifikatsprofiltabellen in aufsteigender Hierarchie angeordnet. In den X.509-Zertifikaten sind die Elemente in der Reihenfolge der entsprechenden absteigenden Hierarchie zu realisieren.

[<=]

Beispiel für einen SubjectDN mit absteigender Hierarchie in einem C.HCI.AUT-Zertifikat gemäß Tab_PKI_238 (dort in aufsteigender Hierarchie aufgelistet):

SubjectDN (String)

C=DE, O=2-29999999999 NOT-VALID, serialNumber=12.80276002791200027011, CN=Zahnarztpraxis Prof. Dr. Dr. Dr. med. rer. nat. Dip:PN TEST-ONLY

SubjectDN (ASN.1-Codierung)

SEQUENCE {
  SET {
    SEQUENCE {
      OBJECT IDENTIFIER countryName (2 5 4 6)
      PrintableString 'DE'
      }
    }
  SET {
    SEQUENCE {
      OBJECT IDENTIFIER organizationName (2 5 4 10)
      UTF8String '2-29999999999 NOT-VALID'
      }
    }
 SET {
   SEQUENCE {
     OBJECT IDENTIFIER serialNumber (2 5 4 5)
     PrintableString '12.80276002791200027011'
     }
   }
 SET {
   SEQUENCE {
     OBJECT IDENTIFIER commonName (2 5 4 3)
     UTF8String
       'Zahnarztpraxis Prof. Dr. Dr. Dr. med. rer. nat. '
       'Dip:PN TEST-ONLY'
     }
   }
}

4.10 Kodierung der Betriebsumgebungen in Zertifikaten

Zertifikate für Test- und Referenzumgebungen werden je TSP aus genau einer vollständig separaten Test-PKI ausgestellt. Siehe hierzu auch Kap 3.

GS-A_4727 - PKI-Separierung von Test- und Produktivumgebung in der TI

Der TSP-X.509 und der Anbieter des TSL-Dienstes DÜRFEN für die Generierung von EE-Zertifikaten der Produktivumgebung NICHT eine CA der Testumgebung verwenden. Umgekehrt DÜRFEN der TSP-X.509 und der Anbieter des TSL-Dienstes für die Generierung von EE-Zertifikaten der Testumgebung NICHT eine CA der Produktivumgebung verwenden.

[<=]

GS-A_4588 - CA-Namen für Test-PKI der TI

Der TSP-X.509 und der Anbieter des TSL-Dienstes MÜSSEN die Namen (CN: und O:) sämtlicher CAs in der Test-PKI entsprechend den korrespondierenden CAs der Produktivumgebung vergeben und diese um den String „TEST-ONLY“ im CN-Feld sowie „NOT-VALID“ im O-Feld ergänzen.

[<=]

GS-A_4589 - EE-Namen für Test-PKI der TI

TSP-X.509 nonQES (außer eGK) und TSP-X.509 QES MÜSSEN die Namen (CN: und O:) der EE-Zertifikate in der Test-PKI entsprechend den korrespondierenden Zertifikatsprofilen der Produktivumgebung verwenden und ergänzen:
(a) für HBA-, Institutions- und Signer-Zertifikate um den String „TEST-ONLY“ im CN-Feld sowie um den String „NOT-VALID“ im O-Feld,     
(b) für Komponentenzertifikate um den String "TEST-ONLY - NOT-VALID" im O-Feld.
​​
​​

[<=]

Die Fallunterscheidung in GS-A_4589 rührt daher, dass die Markierung als Testzertifikat prominent im Common Name (CN) erfolgen soll, wenn immer dies möglich ist. Falls dem Inhalt des Common Name eine funktionale Bedeutung zukommen kann (z. B. bei einem TLS-Server-Zertifikat mit FQDN im Common Name), muss aber darauf verzichtet werden. Dies ist bei Zertifikaten für Komponenten (Dienste und Geräte/gSMC) der Fall.

Die folgende Tabelle dient der Detaillierung dieses Sachverhaltes:

Tabelle 20: Common Name (CN) der End-Entity-Zertifikate Test-PKI 

Zertifikatstyp	Halter / Art	CN Test-PKI gleich CN Produktiv-PKI?
C.HCI.AUT	Organisation/Institution	Nein
C.HCI.ENC	Organisation/Institution	Nein
C.HCI.OSIG	Organisation/Institution	Nein
C.HP.AUT	Person	Nein
C.HP.ENC	Person	Nein
C.HP.QES	Person	Nein
C.GEM.OCSP	Signer	Nein
C.GEM.CRL	Signer	Nein
C.TSL.SIG	Signer	Nein
C.SMKT.AUT	Gerät	Ja
C.NK.VPN	Gerät	Ja
C.AK.AUT	Gerät	Ja
C.SAK.AUT	Gerät	Ja
C.VPNK.VPN	Dienst	Ja
C.VPNK.VPN-SIS	Dienst	Ja
C.ZD.TLS-C	Dienst	Ja
C.ZD.TLS-S	Dienst	Ja
C.FD.TLS-C	Dienst	Ja
C.FD.TLS-S	Dienst	Ja
C.FD.SIG	Dienst	Ja
C.FD.AUT	Dienst	Ja
C.FD.ENC	Dienst	Ja
C.CM.TLS-CS	Dienst	Ja
C.SGD-HSM.AUT	Dienst	Ja

 

GS-A_4590 - Zertifikatsprofile für Test-PKI

Der TSP-X.509 und der Anbieter des TSL-Dienstes SOLLEN die Feldattribute (außer CN: und O:) für sämtliche Zertifikate in der Test-PKI gemäß den korrespondierenden Profilen der Produktivumgebung setzen.
[<=]

4.11 Kartenverlust und Deaktivierung von Chipkarten

GS-A_4962 - Verhalten bei Kartenverlust und Änderung persönlicher Daten

Der Kartenherausgeber MUSS den Zertifikatsnehmer verpflichten, Sperrungen seiner Karte bzw. seines Sicherheitsmoduls bei dem Kartenherausgeber oder bei einer von ihm benannten Stelle durchführen zu lassen. Sperrgründe können beispielweise der Verlust der Karte bzw. des Sicherheitsmoduls sowie Änderungen zu registrierungsrelevanten persönlichen Daten sein (z. B. Änderung der Zugehörigkeit zu einer Berufsgruppe).

[<=]

GS-A_4963 - Deaktivierung von Chipkarten nach Gültigkeitsende

Der Kartenherausgeber MUSS Vorgaben definieren, wie eine Chipkarte sowie die enthaltenen kryptographischen Schlüssel nach Ablauf ihrer definierten Gültigkeitsdauer dauerhaft unbrauchbar gemacht werden.

[<=]

5 X.509-Zertifikate

In diesem Kapitel werden die Anforderungen an X.509-Zertifikate formuliert, wobei die generischen Festlegungen aus Kap. 3 für alle Zertifikatsprofile gelten, soweit anwendbar.

Bei Verwendung der keyUsage „nonRepudiation“ und „contentCommitment“ wird technisch dasselbe KeyUsage-Bit gesetzt. In dieser Spezifikation wird einheitlich die Bezeichnung „nonRepudiation“ verwendet.

Eine Gesamtübersicht aller kryptographischen Identitäten (X.509- und CV-) mit deren Einsatzfeldern findet sich in [gemKPT_Arch_TIP#AnhB].

GS-A_4965 - Keine Suspendierung von X.509-Zertifikaten (außer für eGK)

Ein TSP-X.509 DARF für X.509-Zertifikate – außer denen der eGK – eine Suspendierung NICHT implementieren.

[<=]

Die Bedingungen für Sperrung und Suspendierung (nur bei eGK) von Zertifikaten werden in [gemRL_TSL_SP_CP#5.9] beschrieben.

Für Zertifikate, die auf Karten gespeichert werden, sind Größenbeschränkungen zu beachten.

GS-A_5337 - Größenbeschränkung von X.509 Zertifikaten auf Karten

Ein TSP X.509 (außer ein TSP X.509 für eGK) MUSS sicherstellen, dass die von ihm erzeugten Zertifikate, die für die Speicherung auf Karten vorgesehen sind, die Maximalgröße der dafür vorgesehenen Kartenobjekte - gemäß der relevanten Objektsystemspezifikationen - nicht überschreiten. Wenn zu lange Eingangsdaten vorliegen sind diese in Abstimmung mit dem Antragsteller/Kartenherausgeber zu ändern.

[<=]

5.1 eGK – Versichertenkarte

Die Festlegungen in diesem Kapitel gelten sowohl für die Zertifikate bzw. Identitäten auf der eGK selbst als auch für die alternativen Versichertenidentitäten, die nicht auf der eGK-Smartcard gespeichert sind.

5.1.1 Definition der Versichertenidentität

Folgende Datenfelder bilden die Namensidentität des Versicherten

1. Vorname des Versicherten
2. Familienname des Versicherten
3. Titel des Versicherten
4. Namenszusatz
5. Vorsatzwort

Diese Daten werden in den folgenden Feldern des SubjectDN des Versicherten im Zertifikat abgebildet: 

• commonName
• title
• givenName
• surname

GS-A_4966 - Nutzung bestehender Versichertendatensätze für eGK-Zertifikate

Für die Erstellung von Versichertenzertifikaten SOLL der Kartenherausgeber bestehende Versichertendatensätze für die Registrierung von Zertifikatsnehmern verwenden.

[<=]

5.1.2 Belegung der Felder im SubjectDN

Die zwei Namenszeilen, die auf die eGK optisch personalisiert werden, bestehen aus jeweils 28 Zeichen, die beide zusammen mit einem zusätzlichen Leerzeichen als Trennzeichen den commonName des Versicherten bilden. Die Begrenzung auf 64 Zeichen wird erfüllt. 

Für die Bildung der anderen Felder wird der Name des Versicherten in der natürlichen Schreibweise und Reihenfolge herangezogen.

Titel Vorname Namenszusatz Vorsatzwort Familienname

GS-A_4967 - Vergabe und Übermittlung eindeutiger Versicherten-ID

Die Kostenträger MÜSSEN für den Versicherten eine eindeutige ID vergeben und zur Zertifikatserstellung an den Zertifikatsherausgeber zur Einbringung in die Zertifikate übermitteln.

[<=]

GS-A_4968 - Erzeugung und Einbringung der KVNR

Der eGK-Kartenherausgeber MUSS als eindeutigen Identifier des Versicherten die KVNR gemäß gesetzlicher Vorgaben erzeugen und Festlegungen treffen, welche Anteile der KVNR in die Versichertenzertifikate einzubringen sind.

[<=]

GS-A_4592 - Bildung des surname im SubjectDN eGK-Zertifikat

Der Kartenherausgeber MUSS für das Feld surname im SubjectDN der eGK-Zertifikate das Attribut Familienname verwenden und MUSS bei erforderlichen Kürzungen bis zur maximal zulässigen Länge des Feldes folgende Regel anwenden: (a) ein ggf. vorhandener dritter Familienname ist ggf. bis auf den Anfangsbuchstaben zu kürzen und die Kürzung durch einen Punkt kenntlich zu machen. Ist die Kürzung nicht ausreichend, MUSS zusätzlich gelten: (b) ein zweiter Familienname ist ggf. bis auf den Anfangsbuchstaben zu kürzen und die Kürzung durch einen Punkt kenntlich zu machen.

[<=]

GS-A_4593 - Bildung des givenName im SubjectDN eGK-Zertifikat

Der Kartenherausgeber MUSS für das Feld givenName im SubjectDN der eGK-Zertifikate die Attribute Vorname Namenszusatz Vorsatzwort verwenden und MUSS bei erforderlichen Kürzungen bis zur maximal zulässigen Länge des Feldes folgende Regel anwenden: (a) ein ggf. vorhandener dritter Rufname ist auf den Anfangsbuchstaben zu verkürzen und die Kürzung durch Punkt kenntlich zu machen. Ist die Kürzung nicht ausreichend, MUSS zusätzlich gelten: (b) ein zweiter Rufname ist ggf. bis auf den Anfangsbuchstaben zu kürzen und die Kürzung durch Punkt kenntlich zu machen.

[<=]

GS-A_4594 - Bildung des title im SubjectDN eGK-Zertifikat

Der Kartenherausgeber MUSS für das Feld title im SubjectDN der eGK-Zertifikate das Attribut Titel verwenden. Kürzungen können bei Überschreitung der maximal zulässigen Länge vorgenommen werden; Kürzungsregeln sind nicht definiert.

[<=]

Beispielsatz der Feldinhalte

Name: Dr.-Ing. Peter-Wilhelm Markgraf von Meckelburg-Vorpommeln

Im Zertifikat wären folgende Attribute zu verwenden:

Tabelle 21: Tab_PKI_231 Personennamen im subjectDN 

Feld	Inhalt
commonName	Dr. Peter-W. Markgraf von Meckelburg-Vorpommeln
title	Dr.-Ing.
givenName	Peter-Wilhelm Markgraf von
surname	Meckelburg-Vorpommeln

5.1.3 X.509-Zertifikatsprofile der eGK

Nach den Vorgaben des Lastenheftes kann die Suspendierung von nonQES-Zertifikaten der eGK als unter Bestandsschutz stehend interpretiert werden. Mangels eines praktischen Nutzens soll die Suspendierung von Zertifikaten in der TI generell nicht als obligatorische Anforderung gelten. Bestandssysteme der eGK können ggf. vorhandene Schnittstellen und Prozesse zur Suspendierung und Desuspendierung für die nonQES-Zertifikate der eGK jedoch beibehalten. Dies gilt nicht für die Zertifikate der alternativen Versichertenidentitäten.

GS-A_4969 - Suspendierung von eGK-Zertifikaten (nonQES)

Ein Kartenherausgeber SOLL für die X.509-Zertifikate der eGK eine Suspendierung und Desuspendierung von nonQES-Zertifikaten NICHT implementieren. Für das optional auf der eGK befindliche QES-Zertifikat und die AUT_ALT-Zertifikate ist eine Suspendierung/Desuspendierung nicht möglich.
[<=]

In den folgenden Unterkapiteln sind die Zertifikatsprofile der Zertifikate auf der eGK und der alternativen Versichertenidentitäten aufgelistet. Einziger Unterschied der alternativen Versichertenzertifikate zu den Zertifikaten auf der eGK ist ein abweichender Zertifikatstyp im Feld CertificatePolicies.

5.1.3.1 C.CH.AUT und C.CH.AUT_ALT – Authentisierung eGK

GS-A_4595 - Umsetzung Zertifikatsprofil C.CH.AUT

Der TSP-X.509 nonQES (eGK) MUSS C.CH.AUT gemäß Tab_PKI_232 umsetzen.
[<=]

A_17989 - Umsetzung Zertifikatsprofil C.CH.AUT_ALT

Der TSP-X.509 nonQES (eGK) MUSS C.CH.AUT_ALT gemäß Tab_PKI_232 umsetzen.

[<=]

Tabelle 22: Tab_PKI_232 C.CH.AUT  und C.CH.AUT_ALT Authentisierung eGK 

Element				Inhalt	Kar.
certificate				C.CH.AUT, C.CH.AUT_ALT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			CommonName	CN = Aufgedruckte Namenszeilen der Karte	1
			title	Titel des Versicherten	0-1
			givenName	Vorname des Versicherten	1
			surname	Nachname des Versicherten	1
			organizationalUnitName	OU = unveränderbarer Teil der KV-Nummer	1
			organizationalUnitName	OU = Institutionskennzeichen	1
			organizationName	O = Herausgeber	1
			countryName	C = DE	1
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers	1
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Versicherten	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 0-1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) Für Zertifikate der eGK: policyIdentifier = <oid_egk_aut> Für Zertifikate der alternativen Versichertenidentitäten: policyIdentifier = <oid_egk_aut_alt>	1 0-1 1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_versicherter> gemäß [gemSpec_OID#GS-A_4442] professionOID = OID <oid_versicherter> gemäß gemSpec_OID#GS-A_4442	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth	0-1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.1.3.2 C.CH.ENC – Verschlüsselung eGK

GS-A_4596 - Umsetzung Zertifikatsprofil C.CH.ENC

Der TSP-X.509 nonQES (eGK) MUSS C.CH.ENC gemäß Tab_PKI_233 umsetzen.
[<=]

Tabelle 23: Tab_PKI_233 C.CH.ENC Verschlüsselung eGK 

Element				Inhalt	Kar.
certificate				C.CH.ENC
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt# GS-A_4362]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			CommonName	CN = Aufgedruckte Namenszeilen der Karte	1
			title	Titel des Versicherten	0-1
			givenName	Vorname des Versicherten	1
			surname	Nachname des Versicherten	1
			organizationalUnitName	OU = unveränderbarer Teil der KV-Nummer	1
			organizationalUnitName	OU = Institutionskennzeichen	1
			organizationName	O = Herausgeber	1
			countryName	C = DE	1
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4362] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers	1
		extensions		Erweiterungen		critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Versicherten	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: keyEncipherment dataEncipherment Für Schlüsselgeneration ECDSA: keyAgreement	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_egk_enc>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_versicherter> gemäß [gemSpec_OID#GS-A_4442] professionOID = OID <oid_versicherter> gemäß gemSpec_OID#GS-A_4442	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt# GS-A_4362]
	signature			Wert der Signatur

5.1.3.3 C.CH.QES – Qualifizierte Signatur eGK (optional)

Tabelle 24: Tab_PKI_234 C.CH.QES Qualifizierte Signatur eGK 

Element				Inhalt	Kar.
certificate				C.CH.QES
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt# GS-A_4358]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			CommonName	CN = Aufgedruckte Namenszeilen der Karte	1
			title	Titel des Versicherten	0-1
			givenName	Vorname des Versicherten	1
			surname	Nachname des Versicherten	1
			organizationalUnitName	OU = unveränderbarer Teil der KV-Nummer	1
			organizationalUnitName	OU = Institutionskennzeichen	1
			organizationName	O = Herausgeber	1
			countryName	C = DE	1
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4358] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers	1
		extensions		Erweiterungen		critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Versicherten	1	FALSE
			KeyUsage {2 5 29 15}	nonRepudiation	1	TRUE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_egk_qes>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			SubjectDirectoryAttributes (2.5.29.9)	Angaben, die den Zertifikatsinhaber zusätzlich zu den Angaben unter 'subject' eindeutig identifizieren: Titel (optional), Geburtstag (optional), Geburtsort (optional), Geburtsname (optional)	0-1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_versicherter> gemäß [gemSpec_OID#GS-A_4442] professionOID = OID <oid_versicherter> gemäß gemSpec_OID#GS-A_4442	1 1	FALSE
			QCStatements (1.3.6.1.5.5.7.1.3)	id-qcs-pkixQCSyntax-v1(1.3.6.1.5.5.7.11.1) Konformität zu Syntax und Semantik nach [RFC3739] (optional) id-etsi-qcs-QcCompliance (0.4.0.1862.1.1) Ausgabe des Zertifikats erfolgte konform zur Europäischen Richtlinie 1999/93/EG und nach dem Recht des Landes, nach dem die CA arbeitet. (obligatorisch)	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt# GS-A_4358]
	signature			Wert der Signatur

5.1.3.4 C.CH.AUTN - Technische Authentisierung eGK

GS-A_4598 - Umsetzung Zertifikatsprofil C.CH.AUTN

Der TSP-X.509 nonQES (eGK) MUSS C.CH.AUTN gemäß Tab_PKI_235 umsetzen.

[<=]

Tabelle 25: Tab_PKI_235 C.CH.AUTN Technische Authentisierung eGK 

Element				Inhalt	Kar.
certificate				C.CH.AUTN
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			CommonName	CN = Pseudonym der Versichertenidentität	1
			organizationalUnitName	OU = Institutionskennzeichen	1
			organizationName	O = Herausgeber	1
			countryName	C = DE	1
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers	1
		extensions		Erweiterungen		critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Versicherten	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 0-1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_egk_autn>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_versicherter> gemäß [gemSpec_OID#GS-A_4442] professionOID = OID <oid_versicherter> gemäß gemSpec_OID#GS-A_4442	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth	1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.1.3.5 C.CH.ENCV - Technische Verschlüsselung eGK

GS-A_4599 - Umsetzung Zertifikatsprofil C.CH.ENCV

Der TSP-X.509 nonQES (eGK) MUSS C.CH.ENCV gemäß Tab_PKI_236 umsetzen.

[<=]

Tabelle 26: Tab_PKI_236 C.CH.ENCV Technische Verschlüsselung eGK 

Element				Inhalt	Kar.
certificate				C.CH.ENCV
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4362]
		issuer		DN der ausstellenden CA)
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			CommonName	CN = Pseudonym der Versichertenidentität	1
			organizationalUnitName	OU = Institutionskennzeichen	1
			organizationName	O = Herausgeber	1
			countryName	C = DE	1
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt# GS-A_4362] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers	1
		extensions		Erweiterungen		critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Versicherten	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: keyEncipherment dataEncipherment Für Schlüsselgeneration ECDSA: keyAgreement	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_egk_encv>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_versicherter> gemäß [gemSpec_OID#GS-A_4442] professionOID = OID <oid_versicherter> gemäß gemSpec_OID#GS-A_4442	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4362]
	signature			Wert der Signatur

5.2 HBA – Heilberufsausweis

GS-A_5042 - Kodierung der X.509-Zertifikate für HBA und SMC-B

TSP-X.509 QES und TSP-X.509 nonQES MÜSSEN bei der Herausgabe von Zertifikaten für HBA und SMC-B die übergreifenden Kodierungsvorschriften aus [gemSpec_PKI#4] umsetzen.

 

[<=]

5.2.1 X.509 Zertifikatsprofile des HBA

5.2.1.1 C.HP.AUT – Authentisierung HBA

GS-A_5531-01 - Umsetzung Zertifikatsprofil C.HP.AUT

Der TSP-X.509 nonQES MUSS C.HP.AUT gemäß Tab_PKI_268_1 umsetzen. [<=]

Tabelle 27: Tab_PKI_268_1 C.HP.AUT Authentisierung HBA 

Element				Inhalt *)	Kar.
certificate				C.HP.AUT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		Distinguished Name (DN) der Aussteller-CA gemäß [gemSpec_PKI# GS-A_4737]
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName **)	Vor- und Nachname des Inhabers (bei Kürzung ev. Suffix :PN)	1
			title **)	nicht gesetzt	0
			givenName **)	Vornamen des Inhabers	1
			surName **)	Nachname des Inhabers	1
			serialNumber **)	Eindeutige Identifikationsnummer (dieselbe wie in ENC und QES)	1
			organizationalUnitName	nicht gesetzt	0
			organizationName	nicht gesetzt	0
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Inhabers	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature keyAgreement	1 1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name =  E-Mail-Adresse	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_hba_cp> gemäß [gemSpec_OID#GS-A_4444] policyQualifierInfo = <URL zur Publikation der Zertifikatsrichtlinie(n)> policyIdentifier = <oid_hba_aut> gemäß [gemSpec_OID#GS-A_4445] policyIdentifier =<OID der TSP-spezifischen Policy> policyQualifierInfo = URL der TSP-spezifischen Zertifikatsrichtlinie ggf. weitere sektorspezifische policyIdentifier und policyQualifierInfo	1 0-1 1 0-1 0-1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	admissionAuthority = {O=< zuständige Registrierungsstelle gemäß sektorspezifischer Ausprägung*>,C=DE} professionItem = gemäß [gemSpec_OID#GS-A_4442] professionOID = gemäß [gemSpec_OID#GS-A_4442] registrationNumber = Telematik-ID des Inhabers	1 1 1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth keyPurposeId = id-kp- emailProtection	1 1	FALSE
			ValidityModel {1 3 6 1 4 1 8301 3 5}	nicht gesetzt	0	FALSE
			QCStatements {1 3 6 1 5 5 7 1 3}	nicht gesetzt	0	FALSE
			additionalInformation {1 3 36 8 3 15}	nicht gesetzt	0	FALSE
			Restriction {1 3 36 8 3 8}	nicht gesetzt	0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

*) Sektorspezifische Ausprägungen der HBA-Zertifikate sind dem Anhang C zu entnehmen.

**) Kodierung in einem SET als einziges Multivalued Relative Distinguished Name Element (multivaluedRDN) (siehe Hinweis unten unter Zusatzinformationen)

5.2.1.2 C.HP.ENC – Verschlüsselung HBA

GS-A_5532-01 - Umsetzung Zertifikatsprofil C.HP.ENC

Der TSP-X.509 nonQES MUSS C.HP.ENC gemäß Tab_PKI_269_1 umsetzen. [<=]

Tabelle 28#28:  Tab_PKI_269_1 C.HP.ENC Verschlüsselung HBA 

Element				Inhalt *)	Kar.
certificate				C.HP.ENC
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		Distinguished Name (DN) der Aussteller-CA gemäß [gemSpec_PKI# GS-A_4737]
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			commonName **)	Vor- und Nachname des Inhabers (bei Kürzung ev. Suffix :PN)	1
			title **)	nicht gesetzt	0
			givenName **)	Vornamen des Inhabers	1
			surName **)	Nachname des Inhabers	1
			serialNumber **)	Eindeutige Identifikationsnummer (dieselbe wie in AUT und QES)	1
			organizationalUnitName	nicht gesetzt	0
			organizationName	nicht gesetzt	0
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4362] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Inhabers	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: keyEncipherment dataEncipherment Für Schlüsselgeneration ECDSA: keyAgreement	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name = E-Mail-Adresse	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_hba_cp> gemäß [gemSpec_OID#GS-A_4444] policyQualifierInfo = <URL zur Publikation der Zertifikatsrichtlinie(n)> policyIdentifier = <oid_hba_enc> gemäß [gemSpec_OID#GS-A_4445] policyIdentifier =<OID der TSP-spezifischen Policy> policyQualifierInfo = URL der TSP-spezifischen Zertifikatsrichtlinie ggf. weitere sektorspezifische policyIdentifier und policyQualifierInfo	1 0-1 1 0-1 0-1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	admissionAuthority = {O=< zuständige Registrierungsstelle gemäß sektorspezifischer Ausprägung*>,C=DE} professionItem = gemäß [gemSpec_OID#GS-A_4442] professionOID = gemäß [gemSpec_OID#GS-A_4442] registrationNumber = Telematik-ID des Inhabers	1 1 1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	nicht gesetzt	0	FALSE
			ValidityModel {1 3 6 1 4 1 8301 3 5}	nicht gesetzt	0	FALSE
			QCStatements {1 3 6 1 5 5 7 1 3}	nicht gesetzt	0	FALSE
			additionalInformation {1 3 36 8 3 15}	nicht gesetzt	0	FALSE
			Restriction {1 3 36 8 3 8}	nicht gesetzt	0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

*) Sektorspezifische Ausprägungen der HBA-Zertifikate sind dem Anhang C zu entnehmen.

**) Kodierung in einem SET als einziges Multivalued Relative Distinguished Name Element (multivaluedRDN) (siehe Hinweis unten unter Zusatzinformationen)

5.2.1.3 C.HP.QES – Qualifizierte Signatur HBA

GS-A_5533-01 - Umsetzung Zertifikatsprofil C.HP.QES

Der TSP-X.509 QES MUSS C.HP.QES gemäß Tab_PKI_270_1 umsetzen. [<=]

Tabelle 29: Tab_PKI_270_1 C.HP.QES Qualifizierte Signatur HBA 

Element				Inhalt *)	Kar.
certificate				C.HP.QES
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4358]
		issuer		Distinguished Name (DN) der Aussteller-CA gemäß [gemSpec_PKI# GS-A_4948]
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName **)	Vor- und Nachname des Inhabers (bei Kürzung ev. Suffix :PN)	1
			title **)	nicht gesetzt	0
			givenName **)	Vorname des Inhabers	1
			surName **)	Nachname des Inhabers	1
			serialNumber **)	Eindeutige Identifikationsnummer (dieselbe wie in AUT und ENC)	1
			organizationalUnitName	nicht gesetzt	0
			organizationName	nicht gesetzt	0
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4358] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Inhabers	1	FALSE
			KeyUsage {2 5 29 15}	nonRepudiation (laut RFC5280 alternative Bezeichnung „contentCommitment“)	1	TRUE
			SubjectAltNames {2 5 29 17}	nicht gesetzt	0	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_hba_cp> gemäß [gemSpec_OID#GS-A_4444] policyQualifierInfo = <URL zur Publikation der Zertifikatsrichtlinie(n)> policyIdentifier = <oid_hba_qes> gemäß [gemSpec_OID#GS-A_4445] policyIdentifier = <id-etsi-qcp-natural-qscd> {0.4.0.194112.1.2} policyIdentifier =<OID der TSP-spezifischen Policy> policyQualifierInfo = URL der TSP-spezifischen Zertifikatsrichtlinie ggf. weitere sektorspezifische policyIdentifier und policyQualifierInfo	1 0-1 1 1 0-1 0-1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst URL des CA-Zertifikats (vgl. EN 319 412-2 Kap. 4.4.1)	1 0-1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	admissionAuthority = {O=< zuständige Registrierungsstelle gemäß sektorspezifischer Ausprägung*>,C=DE} professionItem = gemäß [gemSpec_OID#GS-A_4442] professionOID = gemäß [gemSpec_OID#GS-A_4442] registrationNumber : Details dazu jeweils in den sektorspezifischen Profilen in Anhang C	1 1 1 0-1	FALSE
			ExtendedKeyUsage {2 5 29 37}	nicht gesetzt	0	FALSE
			ValidityModel {1 3 6 1 4 1 8301 3 5}	id-validity-Model-chain {1 3 6 1 4 1 8301 3 5 1}	1	FALSE
			QCStatements {1 3 6 1 5 5 7 1 3}	esi4-qcStatement-1 mit id-etsi-qcs-QcCompliance  {0 4 0 1862 1 1}, statementInfo nicht gesetzt esi4-qcStatement-2 mit id-etsi-qcs-QcLimitValue {0  4  0  1862  1  2}, statementInfo (currency = “EUR”, amount (INT), exponent (INT)) esi4-qcStatement-3 mit id-etsi-qcs-QcRetentionPeriod {0 4 0 1862 1 3} esi4-qcStatement-4 mit id-etsi-qcs-QcSSCD {0 4 0 1862 1 4}, statementInfo nicht gesetzt esi4-qcStatement-5 mit  id-etsi-qcs-QcPDS {0  4  0  1862 1 5} esi4-qcStatement-6 mit id-etsi-qct-esign {0  4  0  1862 1 6 1}	1 0-1 0-1 1 0-1 0-1	FALSE
			additionalInformation {1 3 36 8 3 15}	nicht gesetzt	0	FALSE
			Restriction {1 3 36 8 3 8}	Falls das optionale esi4-qcStatement-2 gesetzt und/ oder hier ein Freitext enthalten ist, muss diese Erweiterung mindestens die folgende Ergänzung enthalten: Jegliche Beschränkungen gelten nicht für Anwendungen gemäß § 291a SGB V.	0-1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4358]
	signature			Wert der Signatur

*) Sektorspezifische Ausprägungen der HBA-Zertifikate sind dem Anhang C zu entnehmen.

**) Kodierung in einem SET als einziges Multivalued Relative Distinguished Name Element (multivaluedRDN) (siehe Hinweis unten unter Zusatzinformationen)

Zusatzinformationen zu einzelnen Feldern:

• SubjectDN
  
  Bildungsregel-Vorschlag gemäß Informationen aus bisherigen Sektor-Spezifikationen:

CN=[Vollst.Name (:PN)] + GN=[Vornamen]+SN=[Nachname]+SerNr=[int],C=DE

Hinweis: Die Plus- und Komma-Zeichen sind in der Kodierung des SubjectDN nicht enthalten – dienen hier lediglich als Trenn-Markierung zwischen den Feldinhalten (siehe auch [RFC4514]).

    Kürzungsregel-Hinweis für den CN (entnommen aus bisheriger Sektor-Spezifikation): 

„Der commonName enthält den vollständigen Namen des Inhabers, ohne akademische Titel (auch wenn sie im Personalausweis des Antragstellers eingetragen sind). Die Länge des Attributes ist auf 64 Zeichen beschränkt. Falls der vollständige Name nicht aufgenommen werden kann (z. B. weil er zu lang ist), dann muss, nur dann, wenn dies aus gesetzlichen Bestimmungen hervorgeht, der commonName als Pseudonym gekennzeichnet werden. In diesem Fall muss der Zusatz „:PN“ (ohne Anführungsstriche) aufgenommen werden; die effektive Länge reduziert sich damit auf 61 Zeichen. Falls eine Kürzung vorgenommen werden soll, entsprechen die Kürzungsregeln den Regelungen in der eGK-Spezifikation:

• Rufname und Nachname bleiben vollständig, Vornamen werden auf den ersten Buchstaben plus Punktzeichen gekürzt
• falls immer noch >61 bzw. 64 Zeichen: der Nachname wird gekürzt und mit Punktzeichen gekennzeichnet, so dass die Gesamtlänge (ggf. inkl. :PN) 64 Zeichen beträgt“

• SubjectSerialNumber
  
  Zusätzliche Hinweise gemäß Informationen aus bisherigen Sektor-Spezifikationen:

Das Attribut serialNumber im ENC und AUT-Zertifikat soll den gleichen Wert wie im QES-Zertifikat haben. Hiermit soll ermöglicht werden, dass mit einem präsentierten AUT-Zertifikat leichter das entsprechende ENC-Zertifikat desselben HBAs, mittels Konstruktion des DN, aufgefunden werden kann.

Bildungs-Vorschlag für subjectSerialNumber: 

subjectSerialNumber = <TSP-ID>.<ICCSN>

(<TSP-ID> gemäß Tab_PKI_109 Werte für das Präfix <TSP-ID>)

Hinweis: Statt der ICCSN in der Bildungsregel können auch andere TSP-spezifische IDs verwendet werden, die der Länge der ICCSN entsprechen.

• serialNumber,  givenName,  surname,  title  und  commonName  als SET-OF

Die Attribute serialNumber, givenName, surname, ggf. title und commonName werden in einem SET-OF als ein einziges multivaluedRDN kodiert. Die entsprechenden Kodierungsregeln von X.690 Abs. 11.6 "Set-of components" und RFC_5280 Anhang B (Reihenfolge im SET) müssen berücksichtigt werden. Attribute im RDN müssen anhand der String-Länge der Attribut-Werte, in aufsteigender Reihenfolge sortiert, in die Kodierung einfließen.

5.3 SMC-B – Ausweis einer Organisation/Einrichtung des Gesundheitswesens

Die SMC Typ B definiert die Identität einer Organisation oder Einrichtung des Gesundheitswesens (z. B. Arztpraxis, Krankenhaus, Apotheke, Betriebsstätte nicht-ärztlicher Psychotherapeut oder auch Geschäftsstellen von Kostenträgern) und wird deshalb auch „Institutionenkarte“ genannt.

Bzgl. Nutzung bestehender LE-Datensätze für SMC-B-Zertifikate ist die Anforderung GS-A_4970 (s. Kap. 5.2) zu berücksichtigen.

5.3.1 Definition der Organisationsidentität

Der eindeutige Identitätsname der Organisation wird durch folgende Felder gebildet:

• commonName
• organizationName
• countryName

Die serialNumber kann weiterhin als technisches Unterscheidungsmerkmal (falls mittels commonName und organizationName bei einem Issuer keine Eindeutigkeit des Subjects erreicht werden kann) im SubjectDN dienen.

Der eindeutige Identitätsschlüssel der Organisation oder Einrichtung des Gesundheitswesens wird durch die Telematik-ID in der Zertifikatserweiterung „Admission“ abgebildet; s. Abschnitt 4.6.

GS-A_4971 - Zuordnung von SMC-B zur Institution

Die Kartenherausgeber MÜSSEN die eindeutige Zuordnung von SMC-B zur berechtigten Institution sicherstellen.

[<=]

Der Zugriff eines Leistungserbringers auf medizinische Daten von Anwendungen der elektronischen Gesundheitskarte gemäß §291a SGB V mit einer SMC-B darf nur in Verbindung mit einem HBA erfolgen.

A_15190 - HBA als Grundlage zur Nutzung von medizinischen Anwendungen

Die Kartenherausgeber von SMC-B, welche Leistungserbringern den Zugriff auf Daten von Anwendungen der elektronischen Gesundheitskarte gemäß §291a SGB V ermöglicht, MÜSSEN mittels organisatorischer oder technischer Maßnahmen sicherstellen, dass der Nutzer der SMC-B entweder selbst über einen HBA verfügt oder zu einer Institution gehört, der ein HBA zur Verfügung steht. [<=]

Hinweis 1: Von dieser Regelung sind SM-B für Gesellschafterorganisationen (ohne CVC) oder Kostenträger (Zugriffsprofil CHA.8 [gemSpec_PKI#Tab_PKI_254]) nicht betroffen, da sie keinen Zugriff auf die entsprechenden Daten erlauben. Ebenso sind SM-B mit Zugriffsprofil CHA.1 [gemSpec_PKI#Tab_PKI_254) nicht betroffen, da sie dem Zugriff des Versicherten selbst in der KTR-AdV-Umgebung dienen.

Hinweis 2: Ein HBA im Sinne dieser Anforderung ist ein HBA oder eine HBA-Vorläuferkarte (HBA-qSig und ZOD_2.0).

5.3.2 Aufbau Anschriftzone nach [DIN5008]

Die ersten zwei Zeilen der Anschriftzone werden für den Inhalt des commonName verwendet. 

Der commonName beinhaltet somit den „Kurzname“ der Institution, so wie sie sich selbst auf dem Anschriftenfeld findet. Da dieses Feld von der Institution frei gestaltet werden kann, ist nachfolgend nur eine exemplarische Variante abgebildet. Die Art der Institution ist eindeutig in der Admission Extension hinterlegt. 

 

Abbildung 4: Das Anschriftenfeld nach DIN5008 

Hinweis: Für den Sonderfall der „Berufsausübungsgemeinschaften“ (ehemals „Gemeinschaftspraxen“) gilt die Ausnahme, dass die Zeile 2 der Anschriftzone [DIN5008] optional ist. Somit ist Zeile 1 Pflichtfeld, die Zeilen 3 und/oder 4 sind wie Zeile 2 optional, um darüber die Praxisbezeichnung (Bsp. „Praxis Bülowbogen“) mit aufzunehmen.

5.3.3 Umgang mit überlangen Attributen im SubjectDN

Siehe Kapitel 4.8.3.5 „SubjectAltNames“.

5.3.4 X.509 Zertifikatsprofile der SMC-B

5.3.4.1 C.HCI.AUT – Authentisierung SMC- B

GS-A_4600 - Umsetzung Zertifikatsprofil C.HCI.AUT

Der TSP-X.509 nonQES MUSS C.HCI.AUT gemäßTab_PKI_238 umsetzen.

[<=]

Tabelle 30: Tab_PKI_238 C.HCI.AUT Authentisierung SMC-B 

Element				Inhalt *)	Kar.
certificate				C.HCI.AUT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		Distinguished Name (DN) der Aussteller-CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Erste zwei Zeilen des Anschriftenfeldes	1
			title	Titel des Verantwortlichen/Inhabers	0-1
			givenName	Vorname des Verantwortlichen/Inhabers	0-1
			surName	Nachname des Verantwortlichen/Inhabers	0-1
			serialNumber	Ti-weit eindeutige Identifikationsnummer	0-1
			organizationalUnitName	Organisationseinheit der Organisation/Einrichtung des Gesundheitswesens	0-1
			organizationName	Name der Organisation/Einrichtung des Gesundheitswesens	0-1
			streetAddress	Strasse, Hausnummer	0-1
			postalCode	Postleitzahl	0-1
			localityName	Stadt	0-1
			stateOrProvinceName	Bundesland	0-1
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels der Organisation/Einrichtung des Gesundheitswesens	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name ggf. überlange Institutionsnamen, Alternativnamen oder Ergänzungen	0-1 0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_smc_b_aut> policyIdentifier = <OID d. TSP-spezifischen Policy>	1 0-1 1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	admissionAuthority = {O=<zuständige Registrierungsstelle gemäß sektorspezifischer Ausprägung*)>,C=DE} professionItem = Beschreibung der Institution gemäß [gemSpec_OID#GS-A_4443] professionOID = OID der Institution gemäß [gemSpec_OID#GS-A_4443] registrationNumber = Telematik-ID der Institution	0-1 1 1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth	1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

*) Sektorspezifische Ausprägungen der SMC-B Zertifikate sind dem Anhang A zu entnehmen

5.3.4.2 C.HCI.ENC – Verschlüsselung SMC-B

GS-A_4601 - Umsetzung Zertifikatsprofil C.HCI.ENC

Der TSP-X.509 nonQES MUSS C.HCI.ENC gemäß Tab Tab_PKI_239 umsetzen.

[<=]

Tabelle 31: Tab_PKI_239 C.HCI.ENC Verschlüsselung SMC-B 

Element				Inhalt *)	Kar.
certificate				C.HCI.ENC
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4362]
		issuer		Distinguished Name (DN) der Aussteller-CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Erste zwei Zeilen des Anschriftenfeldes	1
			title	Titel des Verantwortlichen/Inhabers	0-1
			givenName	Vorname des Verantwortlichen/Inhabers	0-1
			surName	Nachname des Verantwortlichen/Inhabers	0-1
			serialNumber	TI-weit eindeutige Identifikationsnummer	0-1
			organizationalUnitName	Organisationseinheit der Organisation/Einrichtung des Gesundheitswesens	0-1
			organizationName	Name der Organisation/Einrichtung des Gesundheitswesens	0-1
			streetAddress	Strasse, Hausnummer	0-1
			postalCode	Postleitzahl	0-1
			localityName	Stadt	0-1
			stateOrProvinceName	Bundesland	0-1
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt# GS-A_4362] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels der Organisation/Einrichtung des Gesundheitswesens	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: keyEncipherment dataEncipherment Für Schlüsselgeneration ECDSA: keyAgreement	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name ggf. überlange Institutionsnamen, Alternativnamen oder Ergänzungen	0-1 0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_smc_b_enc> policyIdentifier = <OID d. TSP-spezifischen Policy>	1 0-1 1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	admissionAuthority = {O=<zuständige Registrierungsstelle gemäß sektorspezifischer Ausprägung*)>,C=DE} professionItem = Beschreibung der Institution gemäß [gemSpec_OID#GS-A_4443] professionOID = OID der Institution gemäß [gemSpec_OID#GS-A_4443] registrationNumber = Telematik-ID der Institution	0-1 1 1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4362]
	signature			Wert der Signatur

*) Sektorspezifische Ausprägungen der SMC-B Zertifikate sind dem Anhang A zu entnehmen

5.3.4.3 C.HCI.OSIG – Signatur SMC-B

GS-A_4602 - Umsetzung Zertifikatsprofil C.HCI.OSIG

Der TSP-X.509 nonQES MUSS C.HCI.OSIG gemäß Tab_PKI_240 umsetzen.

[<=]

Tabelle 32: Tab_PKI_240 C.HCI.OSIG Signatur SMC-B 

Element				Inhalt *)	Kar.
certificate				C.HCI.OSIG
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		Distinguished Name (DN) der Aussteller-CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Erste zwei Zeilen des Anschriftenfeldes	1
			title	Titel des Verantwortlichen/Inhabers	0-1
			givenName	Vorname des Verantwortlichen/Inhabers	0-1
			surName	Nachname des Verantwortlichen/Inhabers	0-1
			serialNumber	Ti-weit eindeutige Identifikationsnummer	0-1
			organizationalUnitName	Organisationseinheit der Organisation/Einrichtung des Gesundheitswesens	0-1
			organizationName	Name der Organisation/Einrichtung des Gesundheitswesens	0-1
			streetAddress	Strasse, Hausnummer	0-1
			postalCode	Postleitzahl	0-1
			localityName	Stadt	0-1
			stateOrProvinceName	Bundesland	0-1
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4357] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels der Organisation/Einrichtung des Gesundheitswesens	1	FALSE
			KeyUsage {2 5 29 15}	nonRepudiation	1	TRUE
			SubjectAltNames {2 5 29 17}	rfc822Name ggf. überlange Institutionsnamen, Alternativnamen oder Ergänzungen	0-1 0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_smc_b_osig> policyIdentifier = <OID d. TSP-spezifischen Policy>	1 0-1 1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	admissionAuthority = {O=<zuständige Registrierungsstelle gemäß sektorspezifischer Ausprägung*)>,C=DE} professionItem = Beschreibung der Institution gemäß [gemSpec_OID#GS-A_4443] professionOID = OID der Institution gemäß [gemSpec_OID#GS-A_4443] registrationNumber = Telematik-ID der Institution	0-1 1 1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

*) Sektorspezifische Ausprägungen der SMC-B Zertifikate sind dem Anhang A zu entnehmen

5.4 HSM-B – Ausweis einer Organisation/Einrichtung des Gesundheitswesens

Bestehen höhere Performance-Anforderungen an eine SMC-B (z. B. in Krankenhäusern), kann als funktionales Äquivalent eine HSM-basierte Lösung eingesetzt werden. Gemäß Anforderung [gemKPT_PKI_TIP#TIP1-A_2084] sind die X.509-Zertifikate eines HSM-B entsprechend den Festlegungen der X.509-Zertifikate für SMC-B auszuführen.

5.5 gSMC-KT – eHealth-Kartenterminal

Für gSMC-KT ausgestellte Zertifikate werden nicht statusgeprüft. Für diese Zertifikate muss ein TSP somit keinen Sperrdienst und keine Statusauskünfte bereitstellen.

Siehe dazu auch Anhang A der [gemRL_TSL_SP_CP#AnhA].

Das Zertifikat eines gSMC-KT enthält nur Informationen über die Identität des SMKT, des Geräteherstellers sowie des Zertifikateherausgebers. Die Bedeutung des Zertifikats beschränkt sich auf folgende Aspekte:

• die gSMC-KT basiert auf einer hierfür durch die gematik zugelassenen Chipkartenplattform
• das Zertifikat wurde durch einen hierfür durch die gematik zugelassenen TSP-X.509 nonQES an einen KT-Hersteller ausgestellt

Das Zertifikat eines gSMC-KT repräsentiert nach dem Pairing die Identität eines eHealth-Kartenterminals.

5.5.1 Definition der Kartenterminalidentität

Die Identität einer gSMC-KT ist durch den SubjectDN (subject distinguishedName) des Zertifikats gegeben mit folgendem Aufbau: 

• commonName = [ICCSN des gSMC-KT]
• organizationName = [Name des Kartenterminal-Herstellers],
• countryName = [Herkunftsland des Kartenterminal-Herstellers]

5.5.2 X.509 Zertifikatsprofile der gSMC-KT

5.5.2.1 C.SMKT.AUT – Identität der gSMC-KT

GS-A_4604 - Umsetzung Zertifikatsprofil C.SMKT.AUT

Der TSP-X.509 nonQES MUSS C.SMKT.AUT gemäß Tab_PKI_241 umsetzen.

[<=]

Tabelle 33: Tab_PKI_241 C.SMKT.AUT gSMC-KT 

Element				Inhalt	Kar.
certificate				C.SMKT.AUT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	ICCSN der gSMC-KT	1
			organizationalUnitName	Relevante Einheit des Kartenterminal-Herstellers	0-1
			organizationName	Name des Kartenterminal-Herstellers	1
			countryName	Herkunftsland des Kartenterminal-Herstellers	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Kartenterminals	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Kartenterminal-Herstellers	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_smkt_aut>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}		0	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}		0	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_kt> gemäß [gemSpec_OID#GS-A_4446] professionOID = OID <oid_kt> gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-serverAuth	1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.6 gSMC-K – Konnektor

5.6.1 Definition und Zuweisung der Konnektoridentität

Die Identität einer gSMC-K wird durch die ICCSN in Verbindung mit dem Datum der erstmaligen Zertifizierung der gSMC-K gebildet.

GS-A_4605 - Verwendung registrierter Daten für gSMC-K-Zertifikatsbeantragung

Der Konnektor-Hersteller MUSS sicherstellen, dass bei der Beantragung von X.509-Zertifikaten für Konnektoren für die Felder SubjectDN nur die Werte verwendet werden, die im Rahmen seiner Zulassung registriert sind.

[<=]

GS-A_4606 - Identischer ICCSN in allen Zertifikaten einer gSMC-K

Der Konnektor-Hersteller MUSS sicherstellen, dass bei der Beantragung der X.509-Zertifikate für die zu einer gSMC-K gehörenden Zertifikate der Wert ICCSN für das Feld commonName in allen drei zu einer gSMC-K gehörenden Zertifikaten identisch angeben wird.

[<=]

GS-A_4607 - Zuordnung Konnektorinstanz zu verbauter gSMC-K

Der Konnektorhersteller MUSS den Zusammenhang zwischen Konnektorinstanz sowie der darin verbauten gSMC-K dokumentieren und hierüber gegenüber der gematik jederzeit Auskunft geben können.

[<=]

5.6.2 Aufbau des SubjectDN

Der SubjectDN (subject distinguishedName) des Zertifikats verbindet die ICCSN mit der Identität des Herstellers und sichert damit die Rückverfolgbarkeit jeder Zertifikatsverwendung eines der Konnektorzertifikate: 

• commonName = [ICCSN der gSMC-K] + "-" + [ Kartenausgabedatum in der Form JJJJMMTT]    
• organizationName = [Name des Konnektor-Herstellers],
• countryName = [Herkunftsland des Konnektor-Herstellers]

5.6.3 Statusprüfung von Konnektorzertifikaten

GS-A_4608 - Statusprüfung von Konnektorzertifikaten

Der TSP-X.509 nonQES MUSS für die von ihm ausgestellten X.509-Zertifikate des Konnektors eine Statusprüfung per OCSP gemäß Tabelle Tab_PKI_237 sowohl in der TI als auch im Internet vorsehen. [<=]

Tabelle 34: Tab_PKI_237 Statusprüfung von Konnektorzertifikaten 

Konnektorzertifikat	Statusprüfung per OCSP	Bereitstellung Statusinformation
C.NK.VPN	Ja	MUSS
C.AK.AUT	Ja	MUSS
C.SAK.AUT	Ja	MUSS

5.6.4 X.509 Zertifikatsprofile des Konnektors

5.6.4.1 C.NK.VPN – VPN-Authentisierung Netzkonnektor

Die Identität des Netzkonnektors dient der Authentisierung gegenüber den zentralen Netzwerkdiensten und wird für die Anmeldung an den VPN-Konzentratoren genutzt.

GS-A_4609 - Umsetzung Zertifikatsprofil C.NK.VPN

Der TSP-X.509 nonQES MUSS C.NK.VPN gemäß Tab_PKI_242 umsetzen.

[<=]

Tabelle 35: Tab_PKI_242 Zertifikatsprofil C.NK.VPN VPN-Authentisierung Netzkonnektor 

Element				Inhalt	Kar.
certificate				C.NK.VPN
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4360]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	<ICCSN der gSMC-K>-<Kartenausgabedatum in der Form JJJJMMTT >	1
			organizationalUnitName	Relevante Einheit des Konnektor-Herstellers	0-1
			organizationName	Name des Konnektor-Herstellers	1
			streetAddress	Anschrift des Konnektor-Herstellers	0-1
			postalCode	Postleitzahl der Anschrift des Konnektor-Herstellers	0-1
			localityName	Stadt der Anschrift des Konnektor-Herstellers	0-1
			stateOrProvinceName	Bundesland der Anschrift des Konnektor-Herstellers	0-1
			countryName	Herkunftsland des Konnektor-Herstellers	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt# GS-A_4360] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Konnektors	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Konnektor-Herstellers	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_nk_vpn>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_nk> gemäß [gemSpec_OID#GS-A_4446] professionOID = OID <oid_nk> gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth keyPurposeId = id-kp-serverAuth	1 1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4360]
	signature			Wert der Signatur

5.6.4.2 C.AK.AUT - Authentisierung Anwendungskonnektor

Die Identität des Anwendungskonnektors dient der Authentisierung für TLS-Verbindungen gegenüber dem Primärsystem.

GS-A_4610 - Umsetzung Zertifikatsprofil C.AK.AUT

Der TSP-X.509 nonQES MUSS C.AK.AUT gemäß Tab_PKI_243 umsetzen.

[<=]

Tabelle 36: Tab_PKI_243 Zertifikatsprofil C.AK.AUT Authentisierung Anwendungskonnektor 

Element				Inhalt	Kar.
certificate				C.AK.AUT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	<ICCSN der gSMC-K>-< Kartenausgabedatum in der Form JJJJMMTT >	1
			organizationalUnitName	Relevante Einheit des Konnektor-Herstellers	0-1
			organizationName	Name des Konnektor-Herstellers	1
			streetAddress	Anschrift des Konnektor-Herstellers	0-1
			postalCode	Postleitzahl der Anschrift des Konnektor-Herstellers	0-1
			localityName	Stadt der Anschrift desKonnektor-Herstellers	0-1
			stateOrProvinceName	Bundesland der Anschrift des Konnektor-Herstellers	0-1
			countryName	Herkunftsland des Konnektor-Herstellers	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Konnektors	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	dNSName = „konnektor.konlan“ bei überlangem organizationName: Langname des Konnektor-Herstellers	1 0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_ak_aut>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_ak> gemäß [gemSpec_OID#GS-A_4446] professionOID = OID <oid_ak> gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth keyPurposeId = id-kp-serverAuth	1 1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.6.4.3 C.SAK.AUT - Authentisierung Signaturdienst

Die Identität des Signaturdienstes dient zur Authentisierung gegenüber den Kartenterminals. Darüber hinaus muss sich der Signaturdienst des Konnektors gegenüber dem Heilberufsausweis mittels eines CV-Zertifikats (C.SAK.AUTD_CVC) mit einer spezifischen Rolle (Profil) ausweisen, um Stapelsignaturen durchführen zu können.

GS-A_4611 - Umsetzung Zertifikatsprofil C.SAK.AUT

Der TSP-X.509 nonQES MUSS C.SAK.AUT gemäß Tab_PKI_244 umsetzen.

[<=]

Tabelle 37: Tab_PKI_244 Zertifikatsprofil C.SAK.AUT Authentisierung SAK 

Element				Inhalt	Kar.
certificate				C.SAK.AUT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	<ICCSN der gSMC-K>-< Kartenausgabedatum in der Form JJJJMMTT >	1
			organizationalUnitName	Relevante Einheit des Konnektor-Herstellers	0-1
			organizationName	Name des Konnektor-Herstellers	1
			streetAddress	Anschrift des Konnektor-Herstellers	0-1
			postalCode	Postleitzahl der Anschrift des Konnektor-Herstellers	0-1
			localityName	Stadt der Anschrift des Konnektor-Herstellers	0-1
			stateOrProvinceName	Bundesland der Anschrift des Konnektor-Herstellers	0-1
			countryName	Herkunftsland des Konnektor-Herstellers	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Konnektors	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Konnektor-Herstellers	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_sak_aut>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_sak> gemäß [gemSpec_OID#GS-A_4446] professionOID = OID <oid_sak> gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth keyPurposeId = id-kp-serverAuth	1 1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.7 VPN-Zugangsdienst

Der VPN-Zugangsdienst ermöglicht den Konnektoren einerseits einen IPsec-Tunnel über ein Transportnetz zum VPN-Zugangsdienst und verbindet darüber die Organisationen des Gesundheitswesens mit dem zentralen Netz der TI, zusätzlich ermöglicht er den Konnektoren den Aufbau eines separaten IPsec-Tunnels über das Transportnetz, durch den der sichere Internetzugang erreichbar ist. Für diesen Zweck ist eine separate kryptographische Identität vorgesehen.

5.7.1 Definition und Zuweisung der Zugangsdienstidentitäten

Die beiden Identitäten des Zugangsdienstes werden durch den jeweiligen FQDN des Dienstes in Verbindung mit einem zusätzlichen Instanzenkennzeichen gebildet.

Bzgl. Verwendung des FQDN ist die Anforderung GS-A_4720 (s. Kap. 5.9.1) zu berücksichtigen.

5.7.2 Aufbau des SubjectDN

Siehe Tab_PKI_245.

5.7.3 X.509-Zertifikatsprofile des Zugangsdienstes

5.7.3.1 C.VPNK.VPN - VPN-Authentisierung Zugangsdienst TI

GS-A_4613 - Umsetzung Zertifikatsprofil C.VPNK.VPN

Der TSP-X.509 nonQES MUSS C.VPNK.VPN gemäß Tab_PKI_245 umsetzen.

[<=]

Tabelle 38: Tab_PKI_245 Zertifikatsprofil C.VPNK.VPN VPN-Authentisierung Zugangsdienst TI 

Element				Inhalt	Kar.
certificate				C.VPNK.VPN
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4360]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	FQDN des Zugangsdienstes gemäß Festlegung aus Dienstezulassung	1
			serialNumber	Zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des Zugangsdienstanbieters	1
			countryName	Land der Anschrift des Zugangsdienstanbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4360] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Konzentrators	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Zugangsdienstanbieters dNSName = FQDN des Dienstes gemäß Zuweisung (Hinweis: siehe CommonName oben)	0-1 1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_vpnk_vpn>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	URL für CRL-Statusdienst DN d. CRL-Ausstellers (f. indirekte CRL, s. RFC5280#4.2.1.13) reasons	1 1 0	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_vpnz_ti> gemäß [gemSpec_OID#GS-A_4446] professionOID = OID <oid_vpnz_ti> gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth keyPurposeId = id-kp-serverAuth	1 1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4360]
	signature			Wert der Signatur

5.7.3.2 C.VPNK.VPN-SIS - VPN-Authentisierung Zugangsdienst Sicherer Internetzugang

GS-A_4830 - Umsetzung Zertifikatsprofil C.VPNK.VPN-SIS

Der TSP-X.509 nonQES MUSS C.VPNK.VPN-SIS gemäß Tab_PKI_265 umsetzen.

[<=]

Tabelle 39: Tab_PKI_265 Zertifikatsprofil C.VPNK.VPN-SIS VPN-Authentisierung Zugangsdienst Sicherer Internetzugang 

Element				Inhalt	Kar.
certificate				C.VPNK.VPN-SIS
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4360]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	FQDN des Zugangsdienstes gemäß Festlegung aus Dienstezulassung	1
			serialNumber	Zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des Zugangsdienstanbieters	1
			countryName	Land der Anschrift des Zugangsdienstanbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4360] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Konzentrators	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Zugangsdienstanbieters dNSName = FQDN des Dienstes gemäß Zuweisung (Hinweis: siehe CommonName oben)	0-1 1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_vpnk_vpn_sis>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	URL für CRL-Statusdienst DN d. CRL-Ausstellers (f. indirekte CRL, s. RFC5280#4.2.1.13) reasons	1 1 0	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung zu <oid_vpnz_sis> gemäß [gemSpec_OID#GS-A_4446] professionOID = OID <oid_vpnz_sis> gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth keyPurposeId = id-kp-serverAuth	1 1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4360]
	signature			Wert der Signatur

5.8 ZD – Zentrale Dienste

5.8.1 Definition der Identität der Zentralen Dienste

Die Identität des Zentralen Dienstes wird durch den Fully Qualified Domain Name (FQDN) des Dienstes in Verbindung mit einem zusätzlichen Instanzenkennzeichen gebildet.

5.8.2 Aufbau des SubjectDN

Siehe Tab_PKI_247.

Die Eindeutigkeit der Identität des Dienstes innerhalb der Telematikinfrastruktur MUSS bereits durch den Inhalt der folgenden Attribute innerhalb des SubjectDN gegeben sein: 

• subject.commonName
• subject.serialNumber

5.8.3 X.509 Zertifikatsprofile der Zentralen Dienste

5.8.3.1 C.ZD.TLS-S Server-Authentisierung (ehemals C.SF.SSL-S)

GS-A_4615 - Umsetzung Zertifikatsprofil C.ZD.TLS-S

Der TSP-X.509 nonQES MUSS C.ZD.TLS-S gemäß Tab_PKI_247 umsetzen.

[<=]

Tabelle 40: Tab_PKI_247 C.ZD.TLS-S Server-Authentisierung Zentrale Dienste 

Element				Inhalt	Kar.
certificate				C.ZD.TLS-S
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	FQDN des Dienstes gemäß Zuweisung	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Zentralen Dienstes	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters dNSName = FQDN des Dienstes gemäß Zuweisung (Hinweis: siehe CommonName oben)	0-1 1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_zd_tls_s>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-serverAuth	1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.9 FD – Fachanwendungsspezifische Dienste

5.9.1 Definition der Identität der Fachanwendungsspezifischen Dienste

Gemäß übergreifender Definition beinhaltet der Begriff „Fachanwendungsspezifischer Dienst“ die Fachdienste und Intermediäre.

Als Erweiterung eines fachanwendungsspezifischen Dienstes gelten weiterhin Clientmodule, die in der Consumerzone (LE-Umgebung) auf den lokalen Systemen Teilfunktionalitäten des Dienstes bereitstellen oder unterstützen (s. a. Kap. 5.10).

Die Identität des Fachanwendungsspezifischen Dienstes wird durch den Fully Qualified Domain Name (FQDN) des Dienstes in Verbindung mit einem zusätzlichen Instanzenkennzeichen gebildet.

GS-A_4720 - Verwendung registrierter Werte für subjectDN

Anbieter von zentralen und fachanwendungsspezifischen Diensten in der TI MÜSSEN bei der Beantragung von X.509-Zertifikaten für den FQDN im SubjectDN ausschließlich einen FQDN aus dem zugehörigen Namensraum der TI unter Beachtung des zugewiesenen Domainnamen verwenden. Dabei MUSS der verwendete FQDN mit dem FQDN der zugewiesenen Komponente übereinstimmen.
[<=]

5.9.2 Aufbau des SubjectDN

Siehe Tab_PKI_249 oder Tab_PKI_250.

Die Eindeutigkeit der Identität des Dienstes innerhalb der Telematikinfrastruktur MUSS bereits durch den Inhalt der folgenden Attribute innerhalb des SubjectDN gegeben sein: 

• subject.commonName
• subject.serialNumber

5.9.3 X.509 Zertifikatsprofile der Fachanwendungsspezifischen Dienste

5.9.3.1 C.FD.TLS-C Client-Authentisierung (ehemals C.SF.SSL-C)

GS-A_4617 - Umsetzung Zertifikatsprofil C.FD.TLS-C

Der TSP-X.509 nonQES MUSS C.FD.TLS-C gemäß Tab_PKI_249 umsetzen.

[<=]

Tabelle 41: Tab_PKI_249 C.FD.TLS-C Client-Authentisierung Fachanwendungsspezifische Dienste 

Element				Inhalt	Kar.
certificate				C.FD.TLS-C
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	FQDN des Dienstes gemäß Zuweisung	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Fachanwendungsspezifischen Dienstes	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters dNSName = FQDN des Dienstes gemäß Zuweisung (Hinweis: siehe CommonName oben)	0-1 1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_fd_tls_c>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth	1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.9.3.2 C.FD.TLS-S Server-Authentisierung (ehemals C.SF.SSL-S)

GS-A_4618 - Umsetzung Zertifikatsprofil C.FD.TLS-S

Der TSP-X.509 nonQES MUSS C.FD.TLS-S gemäß Tab_PKI_250 umsetzen.

[<=]

Tabelle 42: Tab_PKI_250 C.FD.TLS-S Server-Authentisierung Fachanwendungsspezifische Dienste 

Element				Inhalt	Kar.
certificate				C.FD.TLS-S
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	FQDN des Dienstes gemäß Zuweisung	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Fachanwendungsspezifischen Dienstes	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters dNSName = FQDN des Dienstes gemäß Zuweisung (Hinweis: siehe CommonName oben)	0-1 1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_fd_tls_s>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-serverAuth	1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.9.3.3 C.FD.SIG Signatur Fachdienst

A_15172 - Umsetzung Zertifikatsprofil C.FD.SIG

Der TSP-X.509 nonQES MUSS C.FD.SIG gemäß Tab_PKI_251 umsetzen.  [<=]

Tabelle 43: Tab_PKI_251 C.FD.SIG Signatur fachanwendungsspezifische Dienste 

Element				Inhalt	Kar.
certificate				C.FD.SIG
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Name des Dienstes gemäß Festlegung aus Dienstezulassung	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Fachanwendungsspezifischen Dienstes	1	FALSE
			KeyUsage {2 5 29 15}	digitalSignature	1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_fd_sig>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.9.3.4 C.FD.AUT Authentisierung Fachdienst

A_15591 - Umsetzung Zertifikatsprofil C.FD.AUT

Der TSP-X.509 nonQES MUSS C.FD.AUT gemäß Tab_PKI_275 umsetzen. [<=]

Tabelle 44: Tab_PKI_275  C.FD.AUT  Authentisierung  fachanwendungsspezifische Dienste 

Element				Inhalt	Kar.
certificate				C.FD.AUT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Name des Dienstes gemäß Festlegung aus Dienstezulassung	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Fachanwendungsspezifischen Dienstes	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_fd_aut>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.9.3.5 C.FD.ENC Verschlüsselung Fachdienst

A_16213 - Umsetzung Zertifikatsprofil C.FD.ENC

Der TSP-X.509 nonQES MUSS C.FD.ENC gemäß Tab_PKI_276 umsetzen. [<=]

Tabelle 45: Tab_PKI_276 C.FD.ENC Verschlüsselung fachanwendungsspezifische Dienste 

Element				Inhalt	Kar.
certificate				C.FD.ENC
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Name des Dienstes gemäß Festlegung aus Dienstezulassung	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Fachanwendungsspezifischen Dienstes	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: keyEncipherment dataEncipherment Für Schlüsselgeneration ECDSA: keyAgreement	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_fd_enc>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.10 CM – Clientmodul

5.10.1 Definition der Identität eines Clientmoduls

Der Identitätsbereich „Fachanwendungsspezifischer Dienst“ umfasst Dienste und Intermediäre innerhalb der TI sowie zusätzlich damit in funktionalem Zusammenhang stehende Clientmodule in der Consumerzone (LE-Umgebung).

Die Identität eines Clientmoduls wird durch den Anbieter des zugehörigen Fachanwendungsspezifischen Dienstes nach dessen eigener Systematik festgelegt. Seitens der TI-Plattform werden hierzu keine Vorgaben definiert, da diese Zertifikate keine Plattformleistung der TI darstellen, sondern die gegenseitige Authentisierung zwischen einem spezifischen Dienst und seinem zugehörigen lokalem Clientmodul unterstützen.

Ein berechtigter Antragsteller für ein C.FD.TLS-* Zertifikat kann auf der Grundlage derselben Berechtigung zusätzlich auch C.CM.TLS-CS-Zertifikate beziehen.

Ein Clientmodul-Zertifikat wird von der CA für Fachdienstzertifikate ausgestellt.

Ein Clientmodul-Zertifikat kann als Exemplar- oder Gattungszertifikat ausgestellt werden.

5.10.2 Aufbau des SubjectDN

Siehe Tab_PKI_267.

Die Eindeutigkeit der Identität des Clientmoduls ist durch den Anbieter des Dienstes nach eigener Systematik sicher zu stellen:

• subject.commonName
• subject.serialNumber

5.10.3 X.509 Zertifikatsprofil des Clientmoduls

5.10.3.1 C.CM.TLS-CS Clientmodul-Authentisierung

GS-A_5280 - Umsetzung Zertifikatsprofil C.CM.TLS-CS

Der TSP-X.509 nonQES MUSS C.CM.TLS-CS gemäß Tab_PKI_267 umsetzen.

[<=]

Tabelle 46: Tab_PKI_267 C.CM.TLS-CS Clientmodul-Authentisierung 

Element				Inhalt	Kar.
certificate				C.CM.TLS-CS
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	keine Festlegung	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen (z.B. Release-Nr.)	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Clientmoduls	1	FALSE
			KeyUsage {2 5 29 15}	Für Schlüsselgeneration RSA: digitalSignature keyEncipherment Für Schlüsselgeneration ECDSA: digitalSignature	1 1 1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_cm_tls_c>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	keine Festlegung	0-1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}	keyPurposeId = id-kp-clientAuth keyPurposeId = id-kp-serverAuth	1 1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.11 SGD-HSM – Schlüsselgenerierungsdienst-HSM

5.11.1 Beschreibung der Identität

Ein HSM mit einem speziellen Firmware-Modul ist zentraler Bestandteil eines Schlüsselgenerierungsdienstes [gemSpec_SGD]. Ein solches als SGD-HSM bezeichnetes HSM muss eine für einen Client (bspw. ein ePA-Frontend des Versicherten (FdV) oder ein FM ePA) prüfbare Identität besitzen. Diese Identität wird verwendet um damit öffentliche ECDH-Schlüssel zu authentisieren, die für die Schlüsselgenerierungsfunktionalität benötigt werden. Dabei ist es wichtig, dass es verschiedene SGD-HSM gibt, jeweils solche mit einer Identität entweder vom Typ 1 (oid_sgd1_hsm) und solche vom Typ 2 (oid_sgd2_hsm) (vgl. professionItem in C.SGD-HSM.AUT und , und vgl. auch ).  

Die Identität wird von der Komponenten-PKI ausgegeben. Ein solches Zertifikat wird jedoch explizit in der TSL aufgeführt (vgl. ) und wird daher von den Clients über einen speziellen Weg geprüft (vgl. ). Durch die direkte Aufführung in der TSL ist die Identität unabhängig von der Sicherheitsleistung der Komponenten-PKI. 

5.11.2 X.509 Zertifikatsprofil der SGD-HSM

A_17844 - Umsetzung Zertifikatsprofil C.SGD-HSM.AUT

Der TSP-X.509 nonQES MUSS das Zertifikatsprofil C.SGD-HSM.AUT nach Tab_PKI_296 umsetzen.
​​

[<=]

Tabelle 47: Tab_PKI_296  C.SGD-HSM.AUT  Authentisierung SGD-HSM 

Element				Inhalt	Kar.
certificate				C.SGD-HSM.AUT
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	<SGD>-<Namensteil des Dienstes (frei wählbar)>	1
			serialNumber	bei Bedarf zur Unterscheidung gleichartiger Instanzen	0-1
			organizationName	Name des verantwortlichen Anbieters	1
			countryName	Land der Anschrift des verantwortlichen Anbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4359] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des Dienstes	1	FALSE
			KeyUsage {2 5 29 15}	digitalSignature	1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) policyIdentifier = <oid_sgd_hsm_aut>	1 0-1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}	professionItem = Beschreibung der technischen Rolle gemäß [gemSpec_OID#GS-A_4446] professionOID = OID der technischen Rolle gemäß [gemSpec_OID#GS-A_4446]	1 1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4359]
	signature			Wert der Signatur

5.12 CA - Zertifikatsprofile

GS-A_4730 - Eindeutige Identifizierung der CA-Zertifikate

Der TSP-X.509 nonQES und TSP-X.509 QES MUSS bei der Beantragung von X.509-CA-Zertifikaten sicherstellen, dass der subjectDN die CA eindeutig innerhalb der TI identifiziert.

[<=]

GS-A_4731 - Attribute der CA-Zertifikate

Der TSP-X.509 nonQES und TSP-X.509 QES SOLL bei der Beantragung von X.509-CA-Zertifikaten nur die Attribute mit der Kardinalität 1 verwenden.

[<=]

GS-A_4732 - Extension der CA-Zertifikate

Der TSP-X.509 nonQES (eGK) und die gematik Root-CA SOLLEN bei der Erstellung eines Root- bzw. self-signed CA-Zertifikats die Extension AuthorityKeyIdentifier entfallen lassen.

[<=]

Die eindeutige Benennung der CA-Zertifikate im Feld commonName erfolgt gemäß Kap. 2.2 nach dem Schema: 

<holder>.<usage>-CA<n>

(Analog zum Schema <type>.<holder>.<usage><n>, welches in Kap. 2.2 beschrieben wird.)

Der Suffix <n> kennzeichnet hierbei die fortlaufende Nummerierung innerhalb eines Typs von CA-Zertifikaten – beginnend ab dem Wert 1. Dabei wird <n> auch bei Schlüsselgenerations-Wechseln fortgesetzt.

GS-A_4735 - Namenskonvention für CA-Zertifikate

Der TSP-X.509 nonQES und TSP-X.509 QES MUSS für jede von ihm betriebene CA die Namenskonventionen gemäß [GS-A_4588], [GS-A_4590] umsetzen sowie die Namensbildung im Feld commonName nach dem Schema <holder>.<usage>-CA<n> vornehmen.

[<=]

5.12.1 GEM.RCA<n> - Zentrale Root-CA_nonQES

GS-A_4736 - Umsetzung Zentrale nonQES-Root-CA-Zertifikat

Die gematik-Root-CA MUSS die Namenskonvention und Attributsbelegung der Felder für folgende CA-Zertifikate umsetzen gemäß:
a) Tab_PKI_211 für gematik-Root-CA,
b) Tab_PKI_212 für i) Zentrale Aussteller-CA_nonQES, ii) Aussteller-CA_nonQES, iii) TSL-Signer-CA. [<=]

Tabelle 48: Tab_PKI_211 GEM.R-CA<n> – Zentrale gematik Root-CA_nonQES der TI 

Element				Inhalt	Kar.
certificate				C.GEM.RCA<n>
	tbsCertificate
		version		2 (v3)
		CertificateSerialNumber		gemäß [RFC5280#4.1.2.2]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		derselbe DN wie unter "subject" aufgeführt
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			commonName	GEM.RCA<n>	1
			serialNumber	Zur Unterscheidung gleichartiger Instanzen	0-1
			organizationalUnitName	Zentrale Root-CA der Telematikinfrastruktur	1
			organizationName	gematik GmbH	1
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4357] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels der Zentralen gematik Root-CA, für die dieses Zertifikat ausgestellt wird.	1	FALSE
			KeyUsage {2 5 29 15}	keyCertSign crlSign	1 0-1	TRUE
			SubjectAltNames {2 5 29 17}		0	FALSE
			BasicConstraints {2 5 29 19}	ca = TRUE pathLength	1 0	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie)	1 1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}		0	FALSE
			Admission {1 3 36 8 3 3}		0	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

5.12.2 <tsp>.<usage>-CA<n> - Aussteller-CA_nonQES

GS-A_4737 - Umsetzung nonQES-CA-Zertifikate

Der TSP-X.509 nonQES MUSS für die von ihm betriebenen CAs die Attributsbelegung der Felder gemäß Tab_PKI_212 und die Namenskonvention gemäß Tab_PKI_213 umsetzen.
[<=]

Tabelle 49: Tab_PKI_212 <tsp>.<usage>-CA<n> –Aussteller- CA_nonQES der TI 

Element				Inhalt	Kar.
certificate				C.<tsp>.<usage>-CA<n>
	tbsCertificate
		version		2 (v3)
		CertificateSerialNumber		gemäß [RFC5280#4.1.2.2]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			commonName	<tsp>.<usage>-CA<n> *) **)	1
			serialNumber	Zur Unterscheidung gleichartiger Instanzen	0-1
			organizationalUnitName	<usageName>-CA der Telematikinfrastruktur **)	0-1
			organizationName	<tspName> *)	1
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4357] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels der CA, für die dieses Zertifikat ausgestellt wird	1	FALSE
			KeyUsage {2 5 29 15}	keyCertSign crlSign	1 0-1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = TRUE pathLength = 0	1 1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie) ODER davon abweichend: CAs für HBA-AUT/ENC-Zertifikate: policyIdentifier = <oid_policy_hba_cp> policyQualifierInfo = URL der Zertifikatsrichtlinie	1 1 1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}		0	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

*) Für CA-Zertifikate der zentralen PKI wird für <tsp> die Bezeichnung "GEM" und für <tspName> "gematik GmbH" eingesetzt; für von TSPs betriebene Sub-CAs wird das jeweilige TSP-Kürzel sowie der vollständige TSP-Name eingefügt.

**) Die erlaubten Werte für <usage> und <usageName> werden in Tab_PKI_213 aufgeführt.

5.12.3 <tsp>.HBA-qCA<n> - Aussteller-CA_QES

GS-A_4948 - Umsetzung QES-CA-Zertifikate

Der TSP-X.509 QES MUSS für die Zertifikate der von ihm betriebenen CAs die Attributsbelegung der Felder gemäß Tab_PKI_215 umsetzen.

[<=]

Tabelle #50:  Tab_PKI_215 <tsp>.HBA-qCA<n> – Aussteller- CA_QES der TI 

Element				Inhalt	Kar.
certificate				C.<tsp>.HBA-qCA<n>
	tbsCertificate
		version		2 (v3)
		CertificateSerialNumber		gemäß [RFC5280#4.1.2.2]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4358]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von - bis)
		subject
			commonName	<tsp>.HBA-qCA <n> *)	1
			organizationalUnitName	Qualifizierter VDA der Telematikinfrastruktur	0-1
			organizationIdentifier	Vom VDA verwendeter organizationIdentifier gemäß [ETSI EN 319 412-2] und [X.520]	0-1
			organizationName	Name des VDA für QES	1
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4358] und individueller Wert des öffentlichen Schlüssels des Zertifikatsinhabers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels der CA, für die dieses Zertifikat ausgestellt wird	1	FALSE
			KeyUsage {2 5 29 15}	keyCertSign crlSign	1 0-1	TRUE
			SubjectAltNames {2 5 29 17}		0	FALSE
			BasicConstraints {2 5 29 19}	ca = TRUE pathLength = 0	1 1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <id-etsi-qcp-natural-qscd> {0.4.0.194112.1.2} policyQualifierInfo = URL der Zertifikatsrichtlinie policyIdentifier = <oid_policy_hba_cp> policyQualifierInfo = URL der Zertifikatsrichtlinie Ggf. weitere policyIdentifier Ggf. weitere policyQualifierInfo	0-1 0-1 1 0-1 0-n 0-n	FALSE
			CRLDistributionPoints {2 5 29 31}	CDP	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	0-1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			Admission {1 3 36 8 3 3}		0	FALSE
			ValidityModel {1 3 6 1 4 1 8301 3 5}	id-validity-Model-chain {1  3  6  1  4  1  8301  3  5  1}	1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			QCStatements {1.3.6.1.5.5.7.1.3}	<id-etsi-qcs-QcCompliance> {0.4.0.1862.1.1} Ggf. weitere Einträge	0-1 0-n	FALSE
			andere Erweiterungen	Ggf. weitere Erweiterungen durch die BNetzA gesetzt, die hier jedoch nicht spezifiziert sind.
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4358]
	signature			Wert der Signatur

*) Der Name kann mit oder ohne Leerzeichen vor der laufenden Nr. <n> geschrieben werden.

5.13 OCSP – Statusauskunftsdienst

5.13.1 Definition der OCSP-Signer-Identität

Die Identität eines OCSP-Responders wird durch den commonName gebildet, zur Sicherstellung der Eindeutigkeit bedarfsweise ergänzt um ein Merkmal im Feld subject.serialNumber. 

GS-A_4738 - Eindeutige Identifizierung der OCSP-Signer-Zertifikate

Der TSP-X.509 nonQES und der Anbieter des TSL-Dienstes MÜSSEN bei der Beantragung von X.509-OCSP-Signer-Zertifikaten sicherstellen, dass der subjectDN das OCSP-Signer-Zertifikat eindeutig innerhalb der TI identifiziert.

[<=]

GS-A_4739 - Attribute der OCSP-Signer-Zertifikate

Der TSP-X.509 nonQES und der Anbieter des TSL-Dienstes SOLLEN bei der Beantragung von X.509-OCSP-Signer-Zertifikaten nur die Attribute mit der Kardinalität 1 verwenden.

[<=]

GS-A_5514 - Verwendung separater OCSP-Signer-Zertifikate

Ein TSP-X.509 nonQES, die gematik Root-CA und der Anbieter des TSL-Dienstes MÜSSEN für jede unterstützte Schlüsselgeneration (gemäß [gemSpec_Krypt#GS-A_4357]) jeweils ein separates OCSP-Signer-Zertifikat verwenden.

[<=]

Hinweis: Neue OCSP-Signer-Zertifikate sollten gemäß [RFC6960] signiert werden. Zu beachten ist, dass OCSP-Signer-Zertifikate zur Verwendung in der TI in die TSL eingebracht werden müssen. (vgl. [gemSpec_TSL#TIP1-A_4084] sowie TUC_PKI_006 „OCSP-Abfrage", Schritt 5.)

5.13.2 Aufbau des SubjectDN

Siehe Tab_PKI_253.

5.13.3 X.509-Profil des OCSP-Signer-Zertifikates

5.13.3.1 C.GEM.OCSP OCSP-Signer-Zertifikat

GS-A_4741 - Umsetzung Zertifikatsprofil C.GEM.OCSP

Der TSP-X.509 nonQES, die gematik-Root-CA und der TSL-Dienst MÜSSEN C.GEM.OCSP gemäß Tab_PKI_253 umsetzen.
[<=]

Tabelle 5051: Tab_PKI_253 C.GEM.OCSP Zertifikatsprofil OCSP-Signer 

Element				Inhalt	Kar.
certificate				C.GEM.OCSP
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Name des OCSP-Responders	1
			serialNumber	Zur Unterscheidung gleichartiger Instanzen	0-1
			organizationalUnitName	Name der Abteilung für den Betrieb des OCSP	0-1
			organizationName	Name des OCSP-Dienstanbieters	1
			countryName	Land der Anschrift des OCSP-Dienstanbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4357] und individueller Wert des öffentlichen Schlüssels des Zertifikatsbesitzers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des OCSP-Signers	1	FALSE
			KeyUsage {2 5 29 15}	nonRepudiation	1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie)	1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	0-1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			ExtendedKeyUsage {2 5 29 37}	KeyPurposeId = id-kp-OCSPSigning	1	FALSE
			id-pkix-ocsp-nocheck {1.3.6.1.5.5.7.48.1.5}	OCSP-Nocheck = NULL	0-1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

5.14 CRL – Statusauskunftsdienst

GS-A_5066-01 - Indirekte CRL gemäß Standards

Der TSP-X.509 nonQES für Komponenten MUSS CRLs für X.509-Zertifikate als indirekte CRLs gemäß [RFC5280] und [X.509] unter Verwendung eines dedizierten CRL-Signers erzeugen.
[<=]

Weitere relevante Referenzen sind im Rahmen der CRL-Prüfung gemäß GS-A_4900-01 detailliert angegeben.

5.14.1 Definition der CRL-Signer-Identität

Die Identität eines CRL-Signers wird durch den commonName gebildet, zur Sicherstellung der Eindeutigkeit bedarfsweise ergänzt um ein Merkmal im Feld subject.serialNumber. 

GS-A_4935 - Eindeutige Identifizierung der CRL-Signer-Zertifikate

Der TSP-X.509 nonQES MUSS bei der Beantragung von X.509-CRL-Signer-Zertifikaten sicherstellen, dass der subjectDN das CRL-Signer-Zertifikat eindeutig innerhalb der TI identifiziert.

[<=]

GS-A_4936 - Attribute der CRL-Signer-Zertifikate

Der TSP-X.509 nonQES SOLL bei der Beantragung von X.509-CRL-Signer-Zertifikaten nur die Attribute mit der Kardinalität 1 verwenden.

[<=]

GS-A_4937 - Ableitung des CRL-Signer-Zertifikates

Ein TSP-X.509 nonQES MUSS das CRL-Signer-Zertifikat der jeweiligen Schlüsselgeneration für die von ihm be­triebenen CRL-Dienste aus der VPNK-CA derselben Schlüsselgeneration beziehen.
[<=]

GS-A_5515 - Bezug separater CRL-Signer-Zertifikate

Ein TSP-X.509 nonQES, der CRL-Dienste betreibt, MUSS für jede unterstützte Schlüsselgeneration (gemäß [gemSpec_Krypt#GS-A_4357]) jeweils ein separates CRL-Signer-Zertifikat beziehen.

[<=]

5.14.2 Aufbau des SubjectDN

Siehe Tab_PKI_214.

5.14.3 X.509 Profil des CRL-Signer-Zertifikates

5.14.3.1 C.GEM.CRL CRL-Signaturzertifikat

GS-A_4939 - Umsetzung Zertifikatsprofil C.GEM.CRL

Der TSP-X.509 nonQES MUSS C.GEM.CRL gemäß Tab_PKI_214 umsetzen.

[<=]

Tabelle 5152: Tab_PKI_214 C.GEM.CRL Zertifikatsprofil CRL-Signer 

Element				Inhalt	Kar.
certificate				C.GEM.CRL
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	Name des CRL-Signers	1
			serialNumber	Zur Unterscheidung gleichartiger Instanzen	0-1
			organizationalUnitName	Name der Abteilung für den Betrieb des CRL-Signer	0-1
			organizationName	Name des CRL-Dienstanbieters	1
			countryName	Land der Anschrift des CRL-Dienstanbieters	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4357] und individueller Wert des öffentlichen Schlüssels des Zertifikatsbesitzers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des CRL-Signers	1	FALSE
			KeyUsage {2 5 29 15}	crlSign	1	TRUE
			SubjectAltNames {2 5 29 17}	bei überlangem organizationName: Langname des Anbieters	0-1	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_or_cp> policyQualifierInfo = http://www.gematik.de/go/policies (URL zur Publikation der Zertifikatsrichtlinie)	1 0-1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	keine Festlegung	0-1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			ExtendedKeyUsage {2 5 29 37}		0	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

5.15 TSL - Zertifikatsprofile

5.15.1 Definition der TSL-Signer-Identität

Die Identität des TSL-Signers wird durch einen eindeutigen commonName bedarfsweise ergänzt um ein Merkmal im Feld subject.serialNumber gebildet. 

GS-A_4742 - Eindeutige Identifizierung der TSL-Signer-Zertifikate

Der Anbieter des TSL-Dienstes MUSS bei der Beantragung von X.509-TSL-Signer-Zertifikaten sicherstellen, dass der subjectDN das TSL-Signer-Zertifikat eindeutig innerhalb der TI identifiziert.

[<=]

GS-A_4743 - Attribute der TSL-Signer-Zertifikate

Der Anbieter des TSL-Dienstes SOLL bei der Beantragung von X.509-TSL-Signer-Zertifikaten nur die Attribute mit der Kardinalität 1 verwenden.

[<=]

5.15.2 Aufbau des SubjectDN

Siehe Tab_PKI_252_01.

5.15.3 X.509 Zertifikatsprofil der TSL-Signer-CA

GS-A_4744 - Zentrale TSL-Signer-CA-Zertifikate

Der Anbieter des TSL-Dienstes MUSS für die von ihm betriebenen TSL-Signer-CAs die Attributsbelegung der Felder gemäß Tab_PKI_212 und die Namenskonvention für den TSL-Dienst gemäß Tab_PKI_213 umsetzen.

[<=]

A_17686 - TSL-Signer-CA Cross-Zertifikate (ECC-Migration)

Der TSL-Dienst MUSS für die TSL-Signer-CA der Schlüsselgeneration ECDSA beidseitige Cross-Zertifikate zu der aktiven TSL-Signer-CA der Schlüsselgeneration RSA bereitstellen und dabei die folgenden Punkte berücksichtigen:

• das bereits existierende Schlüsselmaterial (PublicKey) der TSL-Signer-CA (ECDSA) wird durch die TSL-Signer-CA (RSA) mit deren PrivateKey signiert und damit das Cross-Zertifikat mit dem Namen C.GEM.TSL-CA<Index der ECDSA-CA>-CROSS<Index der RSA-CA> erzeugt
• das bereits existierende Schlüsselmaterial (PublicKey) der TSL-Signer-CA (RSA) wird durch die TSL-Signer-CA (ESCDA) mit deren PrivateKey signiert und damit das Cross-Zertifikat mit dem Namen C.GEM.TSL-CA<Index der RSA-CA>-CROSS<Index der ECDSA-CA> erzeugt

[<=]

A_17687 - TSL-Signer-CA Cross-Zertifikate – Attributsbelegung (ECC-Migration)

Der TSL-Dienst MUSS für die zu erstellenden Cross-Zertifikate die Attributsbelegung der Felder gemäß Tab_PKI_212 umsetzen, wobei Abweichungen bei folgenden Elementen vorzunehmen sind:

• <certificate> = C.GEM.TSL-CA<X>-CROSS<Y>
• <commonName> = GEM.TSL-CA<X>-CROSS<Y>

Dabei ist jeweils <X> der Index des zu signierenden TSL-Signer-CA-Schlüssels (PublicKey) und <Y> der Index des signierenden TSL-Signer-CA-Schlüssels (PrivateKey).

[<=]

Beispiele für TSL-Signer-CA Cross-Zertifikate:

• C.GEM.TSL-CA1-CROSS3

Erklärung: Das Cross-Zertifikat ist für TSL-Signer-CA1 (RSA Public Key) ausgestellt und von TSL-Signer-CA3 (ECDSA) signiert.

• C.GEM.TSL-CA3-CROSS1

Erklärung: Das Cross-Zertifikat ist für TSL-Signer-CA3 (ECDSA Public Key) ausgestellt und von TSL-Signer-CA1 (RSA) signiert.

5.15.4 TSL-Signer- Zertifikat

GS-A_4745-01 - Umsetzung Zertifikatsprofil C.TSL.SIG für TSL-Dienst

Der TSL-Dienst MUSS das TSL-Signer-Zertifikat C.TSL.SIG gemäß Tab_PKI_252_01 umsetzen.
[<=]

Tabelle 5253: Tab_PKI_252_01 C.TSL.SIG Zertifikatsprofil TSL-Signer 

Element				Inhalt	Kar.
certificate				C.TSL.SIG
	tbsCertificate
		version		2 (v3)
		serialNumber		gemäß [RFC5280#4.1.2.2.]
		signature		zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
		issuer		DN der ausstellenden CA
		validity		Gültigkeit des Zertifikats (von – bis)
		subject
			commonName	TSL Signing Unit <n>	1
			serialNumber	Zur Unterscheidung gleichartiger Instanzen	0-1
			organizationalUnitName	Name der Abteilung für den Betrieb des TSL-Dienstes	0-1
			organizationName	gematik GmbH	1
			countryName	DE	1
			andere Attribute		0
		subjectPublicKeyInfo		Algorithmus gemäß [gemSpec_Krypt#GS-A_4357] und individueller Wert des öffentlichen Schlüssels des Zertifikatsbesitzers
		extensions				critical
			SubjectKeyIdentifier {2 5 29 14}	keyIdentifier = ID des öffentlichen Schlüssels des TSL-Signers	1	FALSE
			KeyUsage {2 5 29 15}	nonRepudiation	1	TRUE
			SubjectAltNames {2 5 29 17}		0	FALSE
			BasicConstraints {2 5 29 19}	ca = FALSE	1	TRUE
			CertificatePolicies {2 5 29 32}	policyIdentifier = <oid_policy_gem_tsl_signer>	1	FALSE
			CRLDistributionPoints {2 5 29 31}	keine Festlegung	0-1	FALSE
			AuthorityInfoAccess {1 3 6 1 5 5 7 1 1}	URL für OCSP-Statusdienst	1	FALSE
			AuthorityKeyIdentifier {2 5 29 35}	keyIdentifier = ID des öffentlichen Schlüssels der ausstellenden CA	1	FALSE
			ExtendedKeyUsage {2 5 29 37}	KeyPurposeId = id-tsl-kptslSigning gemäß [ETSI_TS_102_231_v3.1.2#6.2]	1	FALSE
			andere Erweiterungen		0
	signatureAlgorithm			zur Signatur des Zertifikats verwendeter Algorithmus gemäß [gemSpec_Krypt#GS-A_4357]
	signature			Wert der Signatur

5.15.5 TSL-OCSP-Responder-Zertifikat

GS-A_4747 - Umsetzung Zertifikatsprofil C.GEM.OCSP für TSL-Dienst

Der TSL-Dienst MUSS für die OCSP-Prüfung des TSL-Signer-Zertifikats ein OCSP-Signer-Zertifikat C.GEM.OCSP gemäß Tab_PKI_253 umsetzen.
​​

[<=]

GS-A_4918 - Ableitung des OCSP-Signer-Zertifikates für TSL-Dienst

Der TSL-Dienst MUSS das OCSP-Signer-Zertifikat der jeweiligen Schlüsselgeneration gemäß [RFC6960] von der TSL-Signer-CA derselben Schlüsselgeneration beziehen. [<=]

6 CV-Zertifikate

Dieses Kapitel enthält Anforderungen an die Profilattribute für CV-Zertifikate sowie deren Verwendung. Hierzu gehört auch die Festlegung von Vorgaben zur Identifizierung der ausgebenden CA bzw. des Zertifikatsinhabers sowie die Definition von Rollen- und Geräteprofilen mit denen Zugriffsrechte des Karteninhabers bzw. die Verfügbarkeit von Funktionseinheiten eines Gerätes verbunden sind.

GS-A_4972 - Bezug des CV-Zertifikat

Ein Kartenherausgeber KANN das nicht-personenbezogene CV-Zertifikat nach entsprechender Registrierung vom TSP-CVC-CA beziehen.

[<=]

GS-A_4973 - Ausstellung aller CV-Zertifikate einer Karte durch gleiche CVC-Sub-CA

Der Kartenherausgeber MUSS sicherstellen, dass alle zu einer Chipkarte gehörenden CV-Zertifikate durch dieselbe CA der zweiten Ebene erzeugt werden.

[<=]

6.1 Festlegungen zur Abgrenzung

Grundsätzlich sind CV-Zertifikatsprofile zu unterscheiden für

• CVC-CAs, die als Herausgeber von CV-Zertifikaten für Endteilnehmer fungieren, und
• Endteilnehmer, d. h. Kartentypen wie eGK, HBA, SM-B und gSMC.

Der öffentliche Root-Schlüssel der PKI für CV-Zertifikate wird direkt als Datenfeld in den Karten hinterlegt. Die Bereitstellung des öffentlichen Root-Schlüssels in Form eines CV-Zertifikates ist nicht erforderlich.

GS-A_4974 - CV-Ausstattung von Smartcards der TI

Ein Kartenherausgeber, der Smartcards für Einsatzbereiche der TI herausgeben will, MUSS sicherstellen, dass die Karten über folgende CV-Ausstattung verfügen: (a) mindestens ein CV-Schlüsselpaar mit zugeordnetem CV-Zertifikat. Es können mehrere Schlüsselpaare mit jeweils eigenem CV-Zertifikat und unterschiedlichen Profilattributen enthalten sein, die die Karte für unterschiedliche Funktionen in der TI-Anwendungslandschaft autorisieren können (b) das CV-CA-Zertifikat der zweiten Ebene sowie (c) der öffentliche Schlüssel der CV-Root.

[<=]

6.2 Namensregeln und -formate

Anforderungen an Namensregeln und -formate ergeben sich aus der Identifikation von Herausgebern von CV-Zertifikaten sowie von Zertifikatsinhabern.

Der Herausgeber eines CV-Zertifikats wird über das Datenelement Certificate Authority Reference (CAR) identifiziert. Anforderungen an die Formatierung und den Inhalt der CAR sind im Abschnitt  6.4.3.2 beschrieben. 

Der Inhaber eines CV-Zertifikats wird im Datenelement Certificate Holder Reference (CHR) angegeben. Anforderungen an die Formatierung und den Inhalt der CHR sind im Abschnitt 6.4.3.4 beschrieben. 

6.3 Rollen- und gerätebasierte Zugriffsprofile

6.3 Rollen und Profile

In einem CV-Zertifikat einer Chipkarte ist das Zugriffsprofil dieser Chipkarte enthalten. Dabei wird gemäß [gemKPT_PKI_TIP#5.1] unterschieden zwischen einem Zugriffsprofil für eine

• Authentisierung einer Rolle (CV-Rollen-Zertifikate) bzw. für eine
• Authentisierung einer Funktionseinheit eines Gerätes (CV-Gerätezertifikate).

Die technische Umsetzung der Zuordnung zu Zugriffsprofilen in CV-Zertifikaten erfolgt für Karten der Generation 2 über eine Flagliste, die die Berechtigungen steuert und im Feld CHAT gespeichert ist (siehe Kapitel 6.4.6). 

6.3.1 Rollenauthentisierung

GS-A_4620 - Zugriffsprofil einer eGK

Der Kartenherausgeber MUSS sicherstellen, dass das CV-Rollen-Zertifikat einer eGK als Zugriffsprofil CHAT.0 den Wert ´00 0000 0000 0000´ hat.

[<=]

GS-A_4621 - Zugriffsprofil von HBA und SM-B (SMC-B, HSM-B)

Der Kartenherausgeber MUSS sicherstellen, dass bei einem HBA bzw. einer SM-B das Zugriffsprofil in einem CV-Zertifikat der Rolle des Karteninhabers bzw. der Organisation gemäß Tabelle Tab_PKI_254 entspricht.     
Eine Ausnahme hiervon ist die SM-B für Gesellschafterorganisationen, da sie keine CV-Rollenzertifikate erhält.

[<=]

A_16179 - Zugriffsprofil einer KTR-AdV

Der Kartenheraugeber für SM-B KTR-AdV MUSS sicherstellen, dass die CV-Rollen-Zertifkate für eine KTR-AdV jeweils das Zugriffsprofil CHAT.1 bzw. CHAT.0 gemäß [gemSpec_PKI#Tab_PKI_254] besitzen.
[<=]

In der folgenden Tabelle werden die Zugriffsprofile im Kontext der sie nutzenden fachlichen Akteure dargestellt. Der Kern der Tabelle wurde mit den LEOs, Kostenträgern und dem BMG abgestimmt. Sie bilden die Basis für die Rechtezuweisung auf den Smartcards der Generation 2.

Die Tabelle enthält auch, welche Organisation als sog. „Qualifizierende Stelle“ (vgl. Tab_PKI_254) die Berechtigung für die Zugriffsprofile in CV-Zertifikaten vergibt und damit die Betreiber von CVC-CAs der zweiten Ebene autorisiert, diese Profile in die CV-Zertifikate einzubringen. Für derzeit nicht verwendete Profile ist diese Zuordnung offen.

Es werden die Zugriffsprofile 0 – 9 für eine Rollenauthentisierung unterschieden:

Tabelle 5354: Tab_PKI_254 Zugriffsprofile für eine Rollenauthentisierung 

6.3.2 Authentisierung einer Funktionseinheit

Es werden die Zugriffsprofile CHAT.51, CHAT.53 – CHAT.55 für eine Authentisierung einer Funktionseinheit unterschieden (CV-Gerätezertifikate). Es handelt sich dabei um CV-Zertifikate der Generation 2:

Tabelle 5455: Tab_PKI_255 Zugriffsprofile G2 für eine Authentisierung einer Funktionseinheit 

Zugriffsprofil		CV-Zertifikate für	Funktionseinheit
CHAT.51		gSMC-K	Signaturanwendungskomponente (SAK)
CHAT.53		HBA	Stapelfähige SSEE und Remote-PIN-Empfänger
CHAT.54		gSMC-KT	Remote-PIN-Sender
CHAT.55		SM-B	Remote-PIN-Empfänger

Hinweis 1: Das Zugriffsprofil CHAT.52 war für die SMC-RFID vorgesehen, diese wird derzeit nicht verwendet.    

GS-A_4622 - Zugriffsprofil einer gSMC-K

Der Kartenherausgeber MUSS sicherstellen, dass das CV-Gerätezertifikat einer gSMC-K als Flagliste den Wert ’0000 0000 0001’ hat (Zugriffsprofil 51 für G2 gemäß Tab_PKI_918).
[<=]

GS-A_5126 - Zugriffsprofil einer gSMC-KT

Der Kartenherausgeber MUSS sicherstellen, dass das CV-Gerätezertifikat einer gSMC-KT als Flagliste den Wert ’00 0000 0000 0002’ hat (Zugriffsprofil 54 für G2 gemäß Tab_PKI_918).

[<=]

GS-A_4623 - Zugriffsprofil eines HBA

Der Kartenherausgeber MUSS sicherstellen, dass das CV-Gerätezertifikat eines HBA als Flagliste den Wert ’00 0000 0000 000C’ hat (Zugriffsprofil 53 für G2 gemäß Tab_PKI_918).

[<=]

GS-A_4624 - Zugriffsprofil einer SM-B

Der Kartenherausgeber MUSS sicherstellen, dass das CV-Gerätezertifikat einer SM-B als Flagliste den Wert ’00 0000 0000 0004’ hat (Zugriffsprofil 55 für G2 gemäß Tab_PKI_918).

[<=]

GS-A_5335 - Zugriffsprofil einer gSMC-K für Administrationszwecke

Der Kartenherausgeber MUSS sicherstellen, dass die Flagliste des CV-Zertifikats für die Authentisierung einer gSMC-K gegenüber einem Aktualisierungssystem den Wert ’00 0000 0000 0000’ hat (Zugriffsprofil 0 für G2 gemäß Tab_PKI_918).

[<=]

6.4 CV-Zertifikatsprofile der Generation 2

Für G2-Karten ist der Einsatz von elliptischen Kurven (ELC) in CV-Zertifikaten vorgesehen, basierend auf den Festlegungen in [EN 14890-1]. Die CV-Zertifikate erhalten eine komplett neue Struktur, es erfolgt ein Umstieg von nicht selbstbeschreibenden, RSA-basierten Zertifikaten auf selbstbeschreibende, ELC-basierte Zertifikate mit Anhang (Appendix).

Im Gegensatz zu den nicht selbstbeschreibenden Zertifikaten werden die selbstbeschreibenden Zertifikate durch Konkatenation der Datenobjekte gebildet. Dabei wird jedem Datenfeld ein Tag und ein Längenfeld vorangestellt, damit jedes Datenfeld eindeutig interpretiert werden kann (Tag, Length, Value-Prinzip (TLV)). Der zu signierende Teil ist die Konkatenation der Datenobjekte.

6.4.1 Berechtigung einer CVC-CA zur Zertifikatserstellung

TSP-CVC, die zur Ausstellung von CV-Zertifikaten für

• genau einen Kartentyp mit einem oder mehreren zugehörigen CV-Gerätezertifikaten
• und genau ein Rollen-Zugriffsprofil (nur bei HBA u. SMC-B)

berechtigt sind, erhalten ein CV-CA-Zertifikat, in dem nur genau diese Zugriffsprofile über die hinterlegte Flaglist abgebildet sind.

TSP-CVC, die zur Ausstellung von CV-Zertifikaten für mehrere Kartentypen berechtigt sind, können ein CV-CA-Zertifikat mit kombinierten Zugriffsprofilen nach folgendem Schema beantragen:

• CVC-CA für eGK
  Diese CV-Zertifikate sind immer aus einer dedizierten CVC-CA zu erstellen. Eine Kombination mit anderen Zugriffsprofilen ist nicht zulässig.
• CVC-CA für HBA und SMC-B
  Die Ausstellung von CV-Zertifikaten dieser Kartentypen in allen Ausprägungsformen kann durch eine einzige CVC-CA mit kombinierten Zugriffsprofilen (veroderte Flaglist) erfolgen.
• CVC-CA für gSMC-x
  Die Ausstellung von CV-Zertifikaten dieser Kartentypen in allen Ausprägungsformen kann durch eine einzige CVC-CA mit kombinierten Zugriffsprofilen (veroderte Flaglist) erfolgen.

GS-A_5213 - CA-Flaglist für CVC-CA eines Profiltyps

Die CVC-Root-CA MUSS bei der Generierung eines CA-Zertifikates
(a) für eine CVC-CA, welche ausschließlich zur Ausstellung von EE-Zertifikaten eines bestimmten Zugriffsprofils (oder eines spezifischen Tupels aus Geräte- und Rollen-Zugriffsprofilen) aus Tab_PKI_919, genau die zugeordnete Flaglist aus der Spalte Sub-CA in das CA-Zertifikat einbringen.
(b) Für eine CVC-CA mit kombinierten Zugriffsprofilen ist die Veroderung der zugehörigen Flaglisten aus Tab_PKI_919 zulässig für die Zugriffsprofile
(b.1) aller HBA- und SMC-B sowie
(b.2) aller gSMC-K und gSMC-KT.

[<=]

6.4.2 Aufbau und Bestandteile der CV-Zertifikate der Generation 2

Obwohl die Struktur selbstbeschreibend ist, enthalten die CV-Zertifikate einen Certificate Profile Identifier, der angibt, welche Datenelemente in welcher Reihenfolge in das CV-Zertifikat einzustellen sind. Im Einzelnen sind das:

1. Certificate Profile Identifier (CPI) gemäß 6.4.3.1
2. Certification Authority Reference (CAR) gemäß 6.4.3.2
3. Öffentlicher Schlüssel: Das Datenobjekt zum öffentlichen Schlüssel enthält neben einer OID, welche den Verwendungszweck des öffentlichen Schlüssels kennzeichnet, den öffentlichen Punkt Q (siehe [EN 14890-1#Table 234]).
4. Certificate Holder Reference (CHR) gemäß 6.4.3.4
5. Certificate Holder Authorization Template (CHAT):   Eine Flagliste beschreibt  gemäß [EN 14890-1#14.9.3.6] die Rechte, die einem Zertifikatsinhaber nach einer erfolgreichen Authentisierung eingeräumt werden.
6. Certificate Effective Date (CED): Dieses Datenobjekt enthält das Datum des Inkrafttretens des Zertifikates.
7. Certificate Expiration Date (CXD): Dieses Datenobjekt enthält das Datum mit dem Gültigkeitsende des Zertifikates.

Berechtigungssteuerung über die Flagliste im Feld CHAT

Die Zugriffsberechtigung einer Karte auf die Inhalte einer anderen Karte (Bsp. HBA auf eGK) kann sehr differenziert über einzelne Bits der sog. Flagliste im Feld CHAT gesteuert werden.

• Im CVC-CA-Zertifikat (ausgestellt durch die CVC-Root-CA) steuert die Flagliste, welche CV-Berechtigungen durch diese CA ausgestellt werden können.
• Im CV-Zertifikat (ausgestellt durch eine CVC-CA) einer Karte steuert die Flagliste, über welche Berechtigung diese Karte (d. h. der Karten- und Zertifikatsinhaber) gegenüber anderen Karten der TI verfügt.

6.4.3 Zertifikatsprofil eines CV-Zertifikates für ELC-Schlüssel

Für ELC-Schlüssel ist genau ein Zertifikatsprofil zu berücksichtigen. Dieses Zertifikatsprofil gilt sowohl für CV-Zertifikate, welche den öffentlichen Schlüssel einer CA transportieren, als auch für CV-Zertifikate, welche öffentliche Schlüssel zu Authentisierungszwecken transportieren.

6.4.3.1 Certificate Profile Identifier (CPI)

Die hier folgenden Anforderungen sind konform zu Table 205 aus [EN 14890-1#14.9.2].

GS-A_4986 - Datenobjekt für das Feld Card Profile Identifier in G2

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS den Wert für den CPI in das Datenobjekt ´5F29´ einstellen.

[<=]

GS-A_4987 - Wert des Card Profile Identifier in G2

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS als Wert für den CPI ´70´ eintragen.

[<=]

6.4.3.2 Certification Authority Reference (CAR)

Die hier folgenden Anforderungen sind konform zu [EN 14890-1#14.7.2].

Tabelle 5556: Tab_PKI_266 Aufbau CAR für Karten der Generation 2 

	CA Name	Service-Indikator	CA-spezifische Information	Algorithmen-referenz	Datum
Länge	5 Byte	1 BCD	1 BCD	2 BCD	2 BCD
zugelassene Werte	Anbieterkennung gemäß Registrierung bei Fraunhofer SIT	Verwendungszweck des PrK: ’8’ für die Ausstellung von CA-Zertifikaten ’1’ für die Ausstellung von EE-Zertifikate	zur freien Verwendung durch den Anbieter; dient der Unterscheidung verschiedener CA-Schlüsselpaare	’02’ für ELC/ECC	letzte 2 Ziffern des Jahres der CA-Schlüssel-erzeugung

Hinweis: Die Anbieterkennung - bestehend aus 5 Buchstaben - wird hier gemäß [EN 14890-1] auch "CA Name" genannt. Es handelt sich dabei aber nicht um den Namen der CA als technische Instanz, sondern um den Namen des TSP (TSP-CVC oder CVC-Root). Nur die vollständige CAR benennt und referenziert den öffentlichen Schlüssel einer CVC-CA eindeutig.

GS-A_4988 - Datenobjekt für das Feld Certificate Authority Reference in G2

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS den Wert für die CAR in das Datenobjekt ´42´ einstellen

[<=]

GS-A_4989 - Länge der Certificate Authority Reference in G2

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS für die CAR ein acht Oktett langes Wertfeld verwenden.

[<=]

GS-A_4990 - Verwendung des Feldes Certificate Authority Reference in G2

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS das Feld CAR weiter unterteilen in die Konkatenation der Datenelemente CA Name, Service-Indikator, CA-spezifische Information, Algorithmenreferenz und Datum sowie dabei die Festlegungen bzgl. Länge und zugelassener Werte gemäß Tab_PKI_266 berücksichtigen.

[<=]

GS-A_4991 - Zuordnung von CAR zu Schlüsselpaar des Herausgebers für G2

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS sicherstellen, dass die Zuordnung zwischen Certificate Authority Reference (CAR) und Schlüsselpaar eindeutig ist.

[<=]

6.4.3.3 Öffentlicher Schlüssel

Für den Aufbau des öffentlichen Schlüssels gelten die folgenden Anforderungen, konform zu [BSI-TR-03110#D.3]:

GS-A_4992 - Datenobjekt für den öffentlichen Schlüssel

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS den öffentlichen Schlüssel in das Datenobjekt ´7F49´ einstellen.

[<=]

GS-A_4993 - Aufbau eines öffentlichen Schlüssel

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS in das Wertfeld des Datenobjekt ´7F49´ des öffentlichen Schlüssels genau zwei Datenobjekte eintragen. Dabei MÜSSEN das erste Datenobjekt ein Objektidentifier OIDPuK gemäß Tabelle Tab_PKI_901 und das zweite Datenobjekt ein Datenobjekt DO´86´ mit dem öffentlichen Punkt Q, dessen Wertfeld sich aus Tabelle Tab_PKI_902 ergibt, sein.

[<=]

Tabelle 5657: Tab_PKI_901 Objektidentifier des öffentlichen Schlüssels eines CV-Zertifikats der Generation 2 

Verwendungszweck des CV-Zertifikats	Domain-parameter	Objektidentifier
Transport des öffentlichen Signaturprüfschlüssels einer CA	brainpoolP256r1	OIDPuK = ´06-L06-ecdsa-with-SHA256´ OIDHex    = ´06 08 2A8648CE3D040302´ OIDDez = ´1.2.840.10045.4.3.2´
	brainpoolP384r1	OIDPuK = ´06-L06-ecdsa-with-SHA384´ OIDHex = ´06 08 2A8648CE3D040303´ OIDDez = ´1.2.840.10045.4.3.3´
	brainpoolP512r1	OIDPuK = ´06-L06-ecdsa-with-SHA512´ OIDHex = ´06 08 2A8648CE3D040304´ OIDDez = ´1.2.840.10045.4.3.4´
Transport eines öffentlichen Authentisierungsschlüssels	brainpoolP256r1	OIDPuK    = ´06-L06-authS_gemSpec-COS-G2_ecc-with-sha256´ OIDHex = ´06 06 2B2403050301´ OIDDez = ´1.3.36.3.5.3.1´
	brainpoolP384r1	OIDPuK    = ´06-L06-authS_gemSpec-COS-G2_ecc-with-sha384´ OIDHex = ´06 06 2B2403050302´ OIDDez = ´1.3.36.3.5.3.2´
	brainpoolP512r1	OIDPuK    = ´06-L06-authS_gemSpec-COS-G2_ecc-with-sha512´ OIDHex = ´06 06 2B2403050303´ OIDDez = ´1.3.36.3.5.3.3´

Tabelle 5758: Tab_PKI_902 Punkt Q des öffentlichen Schlüssels eines CV-Zertifikats der Generation 2 

Domainparameter	Codierung eines öffentlichen Punktes Q in DO´86´
brainpoolP256r1	DO´86´= ´86 – 41 – P2OS(Q)´
brainpoolP384r1	DO´86´= ´86 – 61 – P2OS(Q)´
brainpoolP512r1	DO´86´= ´86 – 8181 – P2OS(Q)´

Hinweis: In Tab_PKI_902 beschreibt P2OS(Q) die Konvertierung eines Punktes Q in einen Oktettstring gemäß „Uncompressed Encoding“ aus [BSI-TR-03111#3.2.1].

6.4.3.4 Certificate Holder Reference (CHR)

Die hier folgenden Anforderungen weichen bezüglich der Längenvorgaben von [EN-14890#14.7.3] ab.

GS-A_4994 - Datenobjekt für die Certificate Holder Reference

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS die Certificate Holder Reference in das Datenobjekt ´5F20´ einstellen.

[<=]

GS-A_4995 - Wertfeld der Certificate Holder Reference

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS in das Wertfeld der Certificate Holder Reference eine Schlüsselreferenz zum öffentlichen Schlüssel gemäß [GS-A_4629], bei Ausgabe des CV-Zertifikats durch die CVC-Root-CA, bzw. gemäß [GS-A_4630], bei Ausgabe des CV-Zertifikats durch die CVC- CA, in das CV-Zertifikat der Generation 2 einstellen.

[<=]

GS-A_4629 - CHR des CV-Zertifikats einer CVC-CA

Die CVC-Root-CA MUSS als Wert für die CHR gemäß Tab_PKI_258 die CAR der CVC-CA zu dem Schlüsselpaar eintragen, für den das CV-Zertifikat erzeugt wird.

[<=]

GS-A_4630 - CHR des CV-Zertifikats einer Chipkarte

Der TSP-CVC MUSS als Wert für die CHR gemäß Tab_PKI_258 ein Datum eintragen, das aus der Konkatenation einer zwei Byte langen, innerhalb der Chipkarte eindeutigen Schlüsselidentifikation und der 10 Byte langen ICCSN als weltweit eindeutigen Identifier der Chipkarte besteht.
[<=]

Bei dem Aufbau und der Belegung des Feldes CHR wird unterschieden zwischen einem CV-Zertifikat für eine CVC-CA und einem CV-Zertifikat für eine Chipkarte:

Tabelle 5859: Tab_PKI_258 Aufbau CHR

TODO:

@QS: Die beiden leeren Zeilen entfernen! 

CV-Zertifikat für		Länge CHR		Inhalt
CVC-CA		8 Bytes siehe Kap. 6.4.3.2		CAR zu dem Schlüsselpaar siehe Kap. 6.4.3.2
Chipkarte		12 Bytes		'xx xx' || ICCSN der Chipkarte
		Zertifikat		CHR		Anforderung für CHR
eGK		C.eGK.AUT_CVC.E256		’00 09‘ || ICCSN		Card-G2-A_2363
HBA
HBA		C.HPC.AUTR_CVC.E256		’00 06‘ || ICCSN		Card-G2-A_3386
		C.HPC.AUTD_SUK_CVC.E256		’00 09‘ || ICCSN		Card-G2-A_3387
SMC-B
SMC-B		C.SMC.AUTR_CVC.E256		’00 06‘ || ICCSN		Card-G2-A_3389
		C.SMC.AUTD__RPE_CVC.E256		’00 09‘ || ICCSN		Card-G2-A_3390
gSMC-K		C.SMC.AUT_CVC.E256		’00 05‘ || ICCSN		Card-G2-A_3328
		C.SMC.AUT_CVC.E384		’00 06‘ || ICCSN		Card-G2-A_3331
		C.SAK.AUTD_CVC.E256		’00 0A‘ || ICCSN		Card-G2-A_2638
		C.SAK.AUTD_CVC.E384		’00 0F‘ || ICCSN		Card-G2-A_2640
gSMC-KT		C.SMC.AUTD_RPS_CVC.E256		’00 0A‘ || ICCSN		Card-G2-A_2500
		C:SMS.AUTD_RPS_CVC.E384		’00 0F‘ || ICCSN		Card-G2-A_2502
KTR-AdV		C.KTRADV.AUTR_CVC.E256		’00 05‘ || ICCSN		-

Anmerkung: Die ICCSN der KTR-AdV entspricht der ICCSN der verwendeten SM-B KTR-AdV.

Eine Chipkarte kann auch mehrere Schlüsselpaare für eine C2C-Authentisierung (und damit auch mehrere CV-Zertifikate) enthalten. Über die konkrete Belegung von 'xx xx' wird sichergestellt, dass die Zuordnung von CV-Zertifikat zu einem Schlüsselpaar der Chipkarte eindeutig ist. Das genaue Vorgehen hierbei wird durch die einzelnen Spezifikationen der konkreten Chipkarten der TI festgelegt.

6.4.3.5 Certificate Holder Authorization Template (CHAT)

Die hier folgenden Anforderungen sind konform zu [EN 14890-1#14.9.3.6].

GS-A_4996 - Wertfeld des Certificate Holder Authorization Templates

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS das Certificate Holder Authorization Template in das Datenobjekt ´7F4C´ einstellen.

[<=]

GS-A_4997 - Aufbau der Certificate Holder Authorization Templates

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS in das Wertfeld des Datenobjekt ´7F4C´ genau zwei Datenobjekte eintragen. Dabei MUSS das zweite Datenobjekt ein Datenobjekt DO´53´ gemäß Tabelle Tab_PKI_910 (bei Anwendung von oid_cvc_fl_ti) oder Tab_PKI_911 (bei Anwendung von oid_cvc_fl_cms) sein und das erste Datenobjekt einen Objektidentifier OIDflags gemäß Tabelle Tab_PKI_904 enthalten, der angibt, wie die Flags im zweiten Datenobjekt zu interpretieren sind. Die Umsetzung eines bestimmten Berechtigungsprofils MUSS durch die Kombination der Einzelflags gemäß TAB_PKI_918 erfolgen.

[<=]

Tabelle 5960: Tab_PKI_904 Mögliche Objektidentifier OIDflags in Certificate Holder Authorization Templates 

OIDflags

OIDflags = ´06-L06-oid_cvc_fl_ti

OIDflags = ´06-L06- oid_cvc_fl_cms

Hinweis: Die Festlegung der OID erfolgt in der Spezifikation Festlegung von OIDs [gemSpec_OID#Tab_PKI_408].

6.4.3.6 Certificate Effective Date (CED)

Die hier folgenden Angaben sind konform zu [BSI-TR-03110-3#D.2.1.3].

GS-A_4998 - Datenobjekt des Certificate Effective Date

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS das Certificate Effective Date in das Datenobjekt ´5F25´ einstellen.

[<=]

GS-A_4999 - Länge des Certificate Effective Date

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS für das Certificate Effective Date ein Wertfeld der Länge sechs Oktett einstellen.

[<=]

GS-A_5000 - Format des Certificate Effective Date

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS ein Datum in der Form YYMMDD in unkomprimierter BCD Form in das Wertfeld des Certificate Effective Date eintragen.

[<=]

6.4.3.7 Certificate Expiration Date (CXD)

Die hier folgenden Angaben sind konform zu [BSI-TR-03110-3#D.2.1.3].

GS-A_5001 - Datenobjekt des Certificate Expiration Date

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS das Certificate Expiration Date in das Datenobjekt ´5F24´ einstellen.

[<=]

GS-A_5002 - Länge des Certificate Expiration Date

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS für das Certificate Expiration Date ein Wertfeld der Länge sechs Oktett einstellen.

[<=]

GS-A_5003 - Format des Certificate Expiration Date

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS ein Datum in der Form YYMMDD in unkomprimierter BCD Form in das Wertfeld des Certificate Expiration Date eintragen.

[<=]

6.4.3.8 Zu signierende Nachricht M eines CV-Zertifikates der Generation 2

GS-A_5004 - Tag der zu signierenden Nachricht M eines CV-Zertifikates

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS die zu signierende Nachricht des CV-Zertifikats in das Datenobjekt ´7F4E´ einstellen.

[<=]

GS-A_5005 - Datenstruktur der zu signierenden Nachricht M eines CV-Zertifikates

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS die zu signierende Nachricht M des CV-Zertifikats gemäß Tabelle Tab_PKI_905 bilden.

[<=]

Tabelle 6061: Tab_PKI_905 Zu signierende Nachricht M eines CV-Zertifikates 

M         =     DO´7F4E´

DO´7F4E´     =     ´7F4E´-L7F4E-(                      DO´5F29´     ||    DO´42´     ||                      DO´7F49´     ||    DO´5F20´     ||                      DO´7F4C´     ||    DO´5F25´     ||                      DO´5F24´              )

6.4.4 Struktur und Inhalt eines CV-Zertifikates für ELC-Schlüssel der Generation 2

GS-A_5006 - Signatur des Zertifikatsdatenobjekts

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS die Signatur der Nachricht M des CV-Zertifikates in Abhängigkeit vom Domainparameter des privaten Signaturschlüssels PrK des Herausgebers gemäß Tabelle Tab_PKI_906 erzeugen.

[<=]

Tabelle 6162: Tab_PKI_906 Signatur der Nachricht M eines CV-Zertifikats 

Domainparameter des privaten Schlüssels PrK	Signaturformat
brainpoolP256r1	( R, S ) = ECDSA( PrK, SHA_256( M ) ) im Format ecdsa-plain-SHA256 gemäß BSI-TR-03111#5.2.1.1
brainpoolP384r1	( R, S ) = ECDSA( PrK, SHA_384( M ) ) im Format ecdsa-plain-SHA384 gemäß BSI-TR-03111#5.2.1.1
brainpoolP512r1	( R, S ) = ECDSA( PrK, SHA_512( M ) ) im Format ecdsa-plain-SHA512 gemäß BSI-TR-03111#5.2.1.1

GS-A_5007 - Tag eines Zertifikatsdatenobjekts

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS die Inhalte des Zertifikatsdatenobjekts in das Datenobjekt ´7F21´ einstellen.

[<=]

GS-A_5008 - Aufbau eines Zertifikatsdatenobjekts

Der Herausgeber eines CV-Zertifikats der Generation 2 (TSP-CVC oder CVC-Root-CA) MUSS das CV-Zertifikat als zusammengesetztes Datenobjekt gemäß Tabelle Tab_PKI_907 erzeugen. Er MUSS dabei sicherstellen, dass das zusammengesetzte Datenelement genau die beiden primitiven Datenobjekte in der dargestellten Reihenfolge enthält.

[<=]

Tabelle 6263: Tab_PKI_907 Struktur und Inhalt eines CV-Zertifikat 

Tag	L	Wert
´7F21´	L7F21	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	L7F4E	Nachricht M (gemäß Tabelle 60: Tab_PKI_905 Zu signierende Nachricht M eines CV-Zertifikates) ohne Tag und Längenangabe
		´5F37´	L5F37	Signatur = R || S (gemäß Tabelle 61: Tab_PKI_906 Signatur der Nachricht M eines CV-Zertifikats)

6.4.5 Struktur und Inhalt eines CV-Zertifikates für ELC-Schlüssel der Generation 2

Die nachfolgenden Strukturdiagramme fassen die zuvor beschriebenen Definitionen und Festlegungen zu den einzelnen Feldern der CV-Zertifikate übersichtlich zusammen, normativ sind jedoch nur die in den Anforderungen ausgewiesenen Definitionen.

6.4.5.1 Struktur und Inhalt von CA CV-Zertifikaten für ELC-Schlüssel

Tabelle 6364: Tab_PKI_912 CA CV-Zertifikate für 256 bit ELC-Schlüssel, insgesamt 220 Oktett 

Tag	L	Wert
´7F21´	´81D8´	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	´8191´	Nachricht M
				Tag	L	Wert
				´5F29´	´01´	CPI = ´70´
				´42´	´08´	CAR
				´7F49´	´4D´	öffentlicher Schlüssel
						Tag	L	Wert
						´06	´08´	´2A8648CE3D040302´
						´86´	´41´	P2OS(Q, 32)
				´5F20´	´08´	CHR
				´7F4C´	´13´	CHAT
						Tag	L	Wert
						´06´	´08´	OID aus {oid_cvc_fl_ti, oid_cvc_fl_cms}
						´53´	´07´	´XX...XX´, Flagliste
				´5F25´	´06´	CED
				´5F24´	´06´	CXD
		´5F37´	´40´	Signatur = R || S

Tabelle 6465: Tab_PKI_913 CA CV-Zertifikate für 384 bit ELC-Schlüssel, insgesamt 285 Oktett 

Tag	L	Wert
´7F21´	´820118´	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	´81B1´	Nachricht M
				Tag	L	Wert
				´5F29´	´01´	CPI = ´70´
				´42´	´08´	CAR
				´7F49´	´6D´	öffentlicher Schlüssel
						Tag	L	Wert
						´06	´08´	´2A8648CE3D040303´
						´86´	´61´	P2OS(Q, 48)
				´5F20´	´08´	CHR
				´7F4C´	´13´	CHAT
						Tag	L	Wert
						´06´	´08´	OID aus {oid_cvc_fl_ti, oid_cvc_fl_cms}
						´53´	´07´	´XX...XX´, Flagliste
				´5F25´	´06´	CED
				´5F24´	´06´	CXD
		´5F37´	´60´	Signatur = R || S

Tabelle 6566: Tab_PKI_914 CA CV-Zertifikate für 512 bit ELC-Schlüssel, insgesamt 352 Oktett 

Tag	L	Wert
´7F21´	´82015B´	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	´81D3´	Nachricht M
				Tag	L	Wert
				´5F29´	´01´	CPI = ´70´
				´42´	´08´	CAR
				´7F49´	´818E´	öffentlicher Schlüssel
						Tag	L	Wert
						´06	´08´	´2A8648CE3D040304´
						´86´	´8181´	P2OS(Q, 64)
				´5F20´	´08´	CHR
				´7F4C´	´13´	CHAT
						Tag	L	Wert
						´06´	´08´	OID aus {oid_cvc_fl_ti, oid_cvc_fl_cms}
						´53´	´07´	´XX...XX´, Flagliste
				´5F25´	´06´	CED
				´5F24´	´06´	CXD
		´5F37´	´8180´	Signatur = R || S

6.4.5.2 Struktur und Inhalt von Cross-CV-Zertifikaten für ELC-Schlüssel

Ein Cross-CV-Zertifikat ist ein CV-Zertifikat, welches verschiedene Vertrauensräume verbindet. Eine CVC-Root-CA bestätigt den öffentlichen Schlüssel einer anderen CVC-Root-CA.

Tabelle 6667: Tab_PKI_937 Cross-CV-Zertifikat für ELC-Schlüssel 

Tag	L	Wert
´7F21´	*	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	*	Nachricht M
				Tag	L	Wert
				´5F29´	´01´	CPI = ´70´
				´42´	´08´	CAR
				´7F49´	*	öffentlicher Schlüssel
						Tag	L	Wert
						´06	´08´	*
						´86´	*	*
				´5F20´	´08´	CHR
				´7F4C´	´13´	CHAT
						Tag	L	Wert
						´06´	´08´	OID = oid_cvc_fl_ti
						´53´	´07´	´FF FFFF FFFF FFFF´
				´5F25´	´06´	CED
				´5F24´	´06´	CXD
		´5F37´	*	Signatur = R || S

Anmerkung: Die mit * gefüllten Feldinhalte müssen anhand der in 6.4.5.1 spezifizierten Zertifikatsprofile für 256/384/512 bit ELC-Schlüssel ermittelt bzw. berechnet werden.

6.4.5.3 Struktur und Inhalt von Endnutzer-CV-Zertifikaten für ELC-Schlüssel

Tabelle 6768: Tab_PKI_915 Endnutzer-CV-Zertifikate für 256 bit ELC-Schlüssel, insgesamt 222 Oktett 

Tag	L	Wert
´7F21´	´81DA´	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	´8193´	Nachricht M
				Tag	L	Wert
				´5F29´	´01´	CPI = ´70´
				´42´	´08´	CAR
				´7F49´	´4B´	öffentlicher Schlüssel
						Tag	L	Wert
						´06	´06´	´2B2403050301´
						´86´	´41´	P2OS(Q, 32)
				´5F20´	´0C´	CHR
				´7F4C´	´13´	CHAT
						Tag	L	Wert
						´06´	´08´	OID aus {oid_cvc_fl_ti, oid_cvc_fl_cms}
						´53´	´07´	´XX...XX´, Flagliste
				´5F25´	´06´	CED
				´5F24´	´06´	CXD
		´5F37´	´40´	Signatur = R || S

 

Tabelle 6869: Tab_PKI_916 Endnutzer-CV-Zertifikate für 384 bit ELC-Schlüssel, insgesamt 287 Oktett 

Tag	L	Wert
´7F21´	´82011A´	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	´81B3´	Nachricht M
				Tag	L	Wert
				´5F29´	´01´	CPI = ´70´
				´42´	´08´	CAR
				´7F49´	´6B´	öffentlicher Schlüssel
						Tag	L	Wert
						´06	´06´	´2B2403050302´
						´86´	´61´	P2OS(Q, 48)
				´5F20´	´0C´	CHR
				´7F4C´	´13´	CHAT
						Tag	L	Wert
						´06´	´08´	OID aus {oid_cvc_fl_ti, oid_cvc_fl_cms}
						´53´	´07´	´XX...XX´, Flagliste
				´5F25´	´06´	CED
				´5F24´	´06´	CXD
		´5F37´	´60´	Signatur = R || S

 

Tabelle 6970: Tab_PKI_917 Endnutzer-CV-Zertifikate für 512 bit ELC-Schlüssel, insgesamt 354 Oktett 

Tag	L	Wert
´7F21´	´82015D´	CV–Zertifikat
		Tag	L	Wert
		´7F4E´	´81D5´	Nachricht M
				Tag	L	Wert
				´5F29´	´01´	CPI = ´70´
				´42´	´08´	CAR
				´7F49´	´818C´	öffentlicher Schlüssel
						Tag	L	Wert
						´06	´06´	´2B2403050303´
						´86´	´8181´	P2OS(Q, 64)
				´5F20´	´0C´	CHR
				´7F4C´	´13´	CHAT
						Tag	L	Wert
						´06´	´08´	OID aus {oid_cvc_fl_ti, oid_cvc_fl_cms}
						´53´	´07´	´XX...XX´, Flagliste
				´5F25´	´06´	CED
				´5F24´	´06´	CXD
		´5F37´	´8180´	Signatur = R || S

Der Wert für OIDPuK ergibt sich dabei entsprechend Tabelle 57: Tab_PKI_901 Objektidentifier des öffentlichen Schlüssels eines CV-Zertifikats der Generation 2. 

6.4.6 Flagliste mit Berechtigungen in CV-Zertifikaten für ELC-Schlüssel

Die Flagliste flagList im DO´53´ innerhalb von CHAT eines CV-Zertifikates erfüllt zwei Aufgaben: Zum einen zeigt sie in den oberen beiden Bits an, welche Rolle das CV-Zertifikat in der PKI-Struktur spielt. Die übrigen Bits zeigen an, welche Aktionen nach einer erfolgreichen Authentisierung freigeschaltet werden. Die Festlegungen zur Rolle sind konform zu [BSI-TR-03110-3#C.4]. Anders als in [BSI-TR-03110-3#C.4] wird im Folgenden dem höchstwertigen Bit der Flagliste die Nummer null zugeordnet. In den Bits b2 bis b55 zeigt ein gesetztes Bit an, dass durch eine erfolgreiche Authentisierung das Recht erworben wird die zugehörige Aktion durchzuführen. In den Bits b2 bis b55 zeigt ein gelöschtes Bit an, dass auch nach einer erfolgreichen Authentisierung die zugehörige Aktion nicht freigeschaltet ist. 

Tabelle 7071: Tab_PKI_910 TI-PKI, Bedeutung der Bits innerhalb der Flagliste eines CHAT 

Bitnummer	Bedeutung
Rollenkennzeichnung in den Bits b0 und b1
b0 b1 = 112	Rolle = Root-CA-Schlüssel (in [BSI-TR-03110-3] als CVCA bezeichnet)
b0 b1 = 102	Rolle = CA unterhalb der Root-CA
b0 b1 = 002	Rolle = CVC enthält öffentlichen Authentisierungsschlüssel
Flaglist mit Funktionen, die nach einer erfolgreichen Authentisierung freigeschaltet werden
b02	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b03	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b04	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b05	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b06	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b07	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b08	eGK: Verwendung der ESIGN-AUTN-Funktionalität mit PIN.CH
b09	eGK: Verwendung der ESIGN-AUTN Funktionalität ohne PIN
b10	eGK: Verwendung der ESIGN-ENCV Funktionalität mit PIN.CH
b11	eGK: Verwendung der ESIGN-ENCV Funktionalität ohne PIN
b12	eGK: Verwendung der ESIGN-AUT Funktionalität
b13	eGK: Verwendung der ESIGN-ENC Funktionalität
b14	eGK: Notfalldatensatz verbergen und sichtbar machen
b15	eGK: Notfalldatensatz schreiben, löschen (hier „erase“, nicht „delete“) mit PIN.NFD
b16	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b17	eGK: Notfalldatensatz lesen mit MRPIN.NFD
b18	eGK: Notfalldatensatz lesen ohne PIN
b19	eGK: Persönliche Erklärungen (DPE) verbergen und sichtbar machen
b20	eGK: DPE schreiben, löschen (hier „erase“, nicht „delete“) mit MRPIN.DPE
b21	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b22	eGK: DPE lesen mit MRPIN.DPE_READ
b23	eGK: DPE lesen ohne PIN
b24	eGK: Einwilligungen und Verweise im DF.HCA verbergen und sichtbar machen
b25	eGK: Einwilligungen im DF.HCA lesen und löschen (hier „erase“, nicht „delete“)
b26	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b27	eGK: Einwilligungen im DF.HCA schreiben
b28	eGK: Verweise im DF.HCA lesen und schreiben
b29	eGK: Geschützte Versichertendaten lesen mit PIN.CH
b30	eGK: Geschützte Versichertendaten lesen ohne PIN
b31	eGK: Loggingdaten schreiben mit PIN.CH
b32	eGK: Loggingdaten schreiben ohne PIN
b33	eGK: Zugriff in den AdV-Umgebungen (vormals: Loggingdaten lesen)
b34	eGK: Prüfungsnachweis lesen und schreiben
b35	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b36	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b37	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b38	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b39	eGK: Gesundheitsdatendienste verbergen und sichtbar machen
b40	eGK: Gesundheitsdatendienste lesen, schreiben und löschen (hier „erase“)
b41	eGK: Organspendedatensatz lesen mit MRPIN.OSE
b42	eGK: Organspendedatensatz lesen ohne PIN
b43	eGK: Organspendedatensatz schreiben, löschen (hier „erase“, nicht „delete“) mit MRPIN.OSE
b44	eGK: Organspendedatensatz aktivieren/deaktivieren mit MRPIN.OSE
b45	eGK: AMTS-Datensatz verbergen und sichtbar machen
b46	eGK: AMTS-Datensatz lesen
b47	eGK: AMTS-Datensatz schreiben, löschen (hier „erase“, nicht „delete“)
b48	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b49	Fingerprint des COS erstellen
b50	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b51	Auslöser Komfortsignatur
b52	Sichere Signaturerstellungseinheit (SSEE)
b53	Remote-PIN Empfänger
b54	Remote-PIN Sender
b55	SAK für Stapel- oder Komfortsignatur

Hinweis: Die Rechtedifferenzierung zwischen den Rollen Ärztin/Arzt und Zahnärztin/Zahnarzt ist in die Tabelle Tab_PKI_918 aufgenommen worden: für die beiden Berufsgruppen gibt es unterschiedliche CHAT-Werte gemäß den Zuordnungen der Rechte, die gleichlautend gelten für die entsprechenden Institutionskarten SMC-B der Arztpraxen/Krankenhäuser (CHAT-Wert wie für Ärztin/Arzt) bzw. der Zahnarztpraxen (CHAT-Wert wie für Zahnärztin/Zahnarzt)

Tabelle 7172: Tab_PKI_918 Abbildung von Rollenberechtigungen Zugriffsprofilen auf äquivalente Flaglisten 

Zugriffsprofil		CHAT-Wert / Flagliste (G2)
Rolle (AUTR _CVC )	CHAT.0	´00 0000 0000 0000´
	CHAT.1	´00 AE1A CDC1 DC00´
	CHAT.2A Ärztin/Arzt Fachliche Institution des Arztes Krankenhaus	´00 5D29 DAA0 BB00´
	CHAT.2ZA Zahnärztin/Zahnarzt Fachliche Institution des Zahnarztes	´00 5D20 DAA0 8300´
	CHAT.3	´00 5C40 DAA0 8300´
	CHAT.4	´00 4C40 DAA0 8200´
	CHAT.5	´00 5C00 02A0 0000´
	CHAT.6	wird nicht verwendet
	CHAT.7	´00 0020 0480 0000´
	CHAT.8	´00 4000 02A0 0000´
	CHAT.9	´00 6800 0AA0 0000´
Gerät (AUTD _CVC)	CHAT.51	´00 0000 0000 0001´
	CHAT.53	´00 0000 0000 000C´
	CHAT.54	´00 0000 0000 0002´
	CHAT.55	´00 0000 0000 0004´
Adminis- tration (AUT _CVC)	CHAT.0	´00 0000 0000 0000´

Anmerkung: Zur Berechnung der Sub-CA-Flagliste einer bestimmten Karte muss das Zugriffsprofil der zugehörigen Rolle mit denen des Geräts kombiniert werden (siehe Tab_PKI_919).    
    
Beispiel: Ein TSP-CVC ist nur für die Ausgabe von CV-Zertifikaten für Zahnärzte-HBAs zugelassen.

Die Flagliste für das Profil CHAT.2ZA des Rollen-Zertifikates lautet    ´00 5D20 DAA0 8300´.
Die Flagliste für das Profil CHAT.53 des Geräte-Zertifikates lautet    ´00 0000 0000 000C´.
Die Kombination, bzw. Veroderung der beiden Flaglisten ergibt    ´00 5D20 DAA0 830C´.
Die Flagliste einer Sub-CA beginnt mit der Bit-Folge ´10´ (vgl. Tab_PKI_910). Der Wert für die Flagliste des CA-Zertifikates des TSP-CVC in Tab_PKI_919 lautet    ´80 5D20 DAA0 830C´.

Tabelle 7273: Tab_PKI_919 Sub-CA-Flaglisten nach Kartentyp (G2) und Zugriffsprofilen 

Kartentyp / Geräte-Zugriffsprofil	Rollen-Zugriffsprofil	Sub-CA
CHAT-Wert / Flagliste für ein bestimmtes Zugriffsprofil
eGK	CHAT.0	´80000000000000´
KTR-AdV	CHAT.1 & CHAT.0	´80AE1ACDC1DC04´
gSMC-K / CHAT.51	-	´80000000000001´
gSMC-KT / CHAT.54	-	´80000000000002´
HBA  / CHAT.53	CHAT.2A	´805D29DAA0BB0C´
HBA  / CHAT.53	CHAT.2ZA	´805D20DAA0830C´
HBA  / CHAT.53	CHAT.3	´805C40DAA0830C´
HBA  / CHAT.53	CHAT.4	´804C40DAA0820C´
HBA  / CHAT.53	CHAT.5	´805C0002A0000C´
HBA  / CHAT.53	CHAT.7	´8000200480000C´
SMC-B  / CHAT.55	CHAT.1	´80AE1ACDC1DC04´
SMC-B  / CHAT.55	CHAT.2A	´805D29DAA0BB04´
SMC-B  / CHAT.55	CHAT.2ZA	´805D20DAA08304´
SMC-B  / CHAT.55	CHAT.3	´805C40DAA08304´
SMC-B  / CHAT.55	CHAT.4	´804C40DAA08204´
SMC-B  / CHAT.55	CHAT.8	´80400002A00004´
SMC-B  / CHAT.55	CHAT.9	´8068000AA00004´
CHAT-Wert / Flagliste für kombinierte Zugriffsprofile
eGK	CHAT.0	-
gSMC-K und gSMC-KT / CHAT.51 & 54	-	´80000000000003´
HBA und SMC-B / CHAT.53 & 55	CHAT.1 - 5 & 7- 9	´80FF7BDFE1FF0C´

Tabelle 7374: Tab_PKI_911 CMS-PKI, Bedeutung der Bits innerhalb der Flagliste eines CHAT 

Bitnummer	Bedeutung
Rollenkennzeichnung in den Bits b0 und b1
b0 b1 = 112	Rolle = Root-CA-Schlüssel (in [BSI-TR-03110-3] als CVCA bezeichnet)
b0 b1 = 102	Rolle = CA unterhalb der Root-CA
b0 b1 = 002	Rolle = CVC enthält öffentlichen Authentisierungsschlüssel
Flagliste mit Funktionen, die nach einer erfolgreichen Authentisierung freigeschaltet werden
b02 … b07	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen
b08	Administrative Tätigkeiten CMS
b09	Administrative Tätigkeiten VSD
b10	Administrative Tätigkeiten zum Schreiben von CV-Zertifikaten
b11	Administrative Tätigkeiten eines TSP zur Laufzeitverlängerung der QES-Anwendung
b12 … b55	RFU, im Rahmen dieser Dokumentenversion auf 0 zu setzen

7 Festlegung von OIDs

In der vorliegenden Spezifikation wird die Verwendung von OIDs in den Zertifikatsprofilen der TI-PKI über die Verwendung der OID-Referenznamen geregelt. Die Zuordnung dieser OID-Referenzen zu den konkreten OID-Werten sowie deren Verwaltung der OIDs werden im Dokument [gemSpec_OID] normativ beschrieben.

8 Prüfung von Zertifikaten

Für die Nutzung und Statusprüfung von Zertifikaten in der TI gilt:

• Das TSL-Signer-CA-Zertifikat (RSA oder ECDSA) bildet den Vertrauensanker für die TI.
• Das TSL-Signer-CA-Zertifikat (RSA) und das TSL-Signer-CA-Zertifikat (ECDSA) sind jeweils über Cross-Zertifikate verknüpft.
• Jedes Produkt kann immer nur einen der beiden Vertrauensanker aktiv haben. Ein Wechsel der Vertrauensräume ist über die Cross-Zertifikate möglich.
• Eine TSL stellt (i. S. einer Whitelist) den Vertrauensraum für die in der TI zugelassenen Aussteller-CA dar.
• Dabei stellt die TSL(RSA) den Vertrauensraum (RSA) und die TSL(ECC-RSA) den Vertrauensraum (ECC-RSA) dar. (Hinweis: siehe bzgl. TSL- und Vertrauensraum-Begrifflichkeiten das Kapitel 8.1.1)
• nonQES-Aussteller-CA-Zertifikate werden ausschließlich gegen die TSL geprüft
• QES-Aussteller-CA-Zertifikate werden
  hinsichtlich ihres VDA-Qualifikationsstatus gemäß [eIDAS] gegen die BNetzA-VL
  geprüft.(Vgl. §9 [VDG].)
• Als Vertrauensanker für die BNetzA-VL fungieren jeweils die aktuell publizierten BNetzA-VL-Signer-Zertifikate. Diese werden mittels TSL in die QES-prüfenden Systeme (Konnektoren) eingebracht und aktualisiert.
• End-Entity-Zertifikate werden gegen den OCSP-Dienst der Aussteller-CA geprüft, außer die Statusprüfung für einen bestimmten Zertifikatstyp ist explizit optional oder nicht vorgesehen.

 

Abbildung 5: Use Case Diagramm „Prozesse zur Nutzung des TI-Vertrauensraums“ 

Die Funktionalitäten der zertifikatsprüfenden Komponenten werden nachfolgend in „Technischen Use Cases“ (TUCs) beschrieben und spezifiziert. Dabei können in jedem der beschriebenen Schritte eines TUC Fehler auftreten. Übergreifend gilt dazu:

GS-A_4637 - TUCs, Durchführung Fehlerüberprüfung

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN bei der Ausführung eines TUC auf Verarbeitungsfehler prüfen und eine definierte Fehlerbehandlung einleiten.

[<=]

GS-A_4829 - TUCs, Fehlerbehandlung

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN bei der Fehlerbehandlung von TUCs Systemmeldungen ausgeben und der Prozess muss beendet werden, sofern der TUC keine spezifische Fehlerbehandlung beschreibt.

[<=]

Bei der Beschreibung der TUCs sind folgende Punkte zu beachten:

• Die unter „Vorbedingungen“ beschriebenen Bedingungen sind nicht Bestandteil des TUC und werden im Ablauf des TUC nicht explizit geprüft. Stattdessen muss der Kontext aus dem heraus der TUC aufgerufen wird sicherstellen, dass bei einer verletzten Vorbedingung, in keinem Fall das Ergebnis eines TUC als positiv bewertet wird, z. B. eine Prüfung als erfolgreich eingestuft wird.
  In welcher Form die Umsetzung von Vorbedingungen erfolgt (z. B. durch explizite Prüfung, Teilausführung des TUC oder durch Wechsel eines Systemzustands) ist nicht Gegenstand der TUC-Spezifikation. Ein TUC muss nicht stets Vorbedingungen haben.
• Wird im Ablauf des TUC ein anderer TUC aufgerufen und dieser endet mit einer Fehlermeldung, so wird auch der aufrufende TUC mit dieser Fehlermeldung beendet, sofern nichts anderes festgelegt ist. Daher setzen sich die möglichen Fehlermeldungen eines TUC aus den Fehlerfällen im TUC-Ablauf und allen Fehlermeldungen der aufgerufenen TUCs zusammen.

Zur Zertifkatsprüfung werden die Vorgaben aus [gemKPT_PKI_TIP] Kap. 6.5 „Zertifikatsprüfung nonQES“ berücksichtigt.

Die Zertifikatsprüfung erfolgt gemäß [RFC5280] und gemäß [COMMON-PKI].

• Der TI-Vertrauensraum wird im Internet durch die Bereitstellung von OCSP-Statusauskünften zu allen in der TSL enthaltenen CAs abgebildet.
• Mangels einer der TSL entsprechenden Whitelist für zugelassene CAs im Internet müssen sämtliche nonQES CA- und EE-X.509-Zertifikate der TI im Feld authorityInfoAccess die URL des zugehörigen und im Internet erreichbaren OCSP-Responders enthalten.
• Im Internet erfolgt die Prüfung der nonQES CA- und EE-Zertifikaten (HBA, SMC-B) entlang des Zertifizierungspfades bis hin zur gematik Root-CA.
• Die nonQES-X.509-Zertifikate der temporär zu unterstützenden HBA-Vorläuferkarten werden auf Basis der dafür etablierten Statusauskunftsdienste geprüft.

GS-A_5043 - Auflösung von OCSP-Adressen im Internet

TSP-X.509 QES und TSP-X.509 nonQES MÜSSEN für Zertifikatstypen, die zusätzlich zur TI auch im Internet statusgeprüft werden, sicherstellen, dass die im Zertifikat eingetragene OCSP-Responderadresse im Internet aufgelöst und eine Statusabfrage erfolgreich durchgeführt werden kann.

[<=]

Der TI-Vertrauensraum für QES-Zertifikate wird im Internet nicht gesondert abgebildet. Die Zertifikate werden gemäß der für QES üblichen Verfahren validiert und statusgeprüft.

Über die Bereitstellung von nonQES-CA- und EE-Zertifikatsinformationen im Internet hinaus werden durch die Spezifikationen der TI keine Aussagen getroffen über Art und Umfang von durchzuführenden Schritten im Kontext der Zertifikatsprüfung durch die Anwendungen im Internet.

8.1 Vertrauensraum der TI

Grundlage jeder zertifikatsbasierten Prüfung auf Vertrauenswürdigkeit in der TI ist die gesicherte Information über den aktuell gültigen TI-Vertrauensraum, gegen den eine solche Prüfung erfolgt.

Der Vertrauensraum der TI besteht also aus der Menge der CAs (bzw. deren Zertifikate), die in der TI zugelassen, also als vertrauenswürdig anerkannt sind. Außerdem enthält er die Einsatzzwecke, für welche die CAs End-Entity-Zertifikate ausgeben dürfen. Dieser TI-Vertrauensraum wird in der TSL abgebildet.

Die TSL enthält Informationen gemäß [ETSI_TS_102_231#5]. Sie beinhalten neben den CA-Zertifikaten im TI-Vertrauensraum zusätzliche Angaben, wie z. B. die Sequenznummer oder die Adressen und Zertifikate der zuständigen OCSP-Responder.

Die TSL spielt also in zertifikatsprüfenden Komponenten die zentrale Rolle.

Konkret bereitgestellt wird die TSL als TSL-Datei in Form einer signierten XML-Datei gemäß [ETSI_TS_102_231#B].

 

Abbildung 6 : Aufbau der TSL 

Hinweis: Die TSL-Informationen müssen also nicht zwingend in Form der XML-Syntax der TSL-Datei vorgehalten werden. Sie können auch ganz oder teilweise in einen sicheren Speicher des Systems (Truststore) importiert werden.

Die nachfolgende Gliederung der Teilschritte einer Prüfung orientiert sich an den Vorgaben des TSL-Standards [ETSI_TS_102_231#H] – mit den Konkretisierungen für die TI sowie ergänzt um TI-spezifische Erweiterungen der TI-Vertrauensraumprüfung.

Die notwendigen Prüfschritte zur Prüfung des TI-Vertrauensraums werden in Form von Technischen Use Cases dargestellt:

• Initialisierung / Aktualisierung des TI-Vertrauensraumes
• Lokalisieren der TSL-Datei
• Download der TSL-Datei (ggf. nach vorheriger Aktualitätsprüfung mittels Hashwert-Vergleichsverfahren)
• Validierung der TSL-Datei
• Prüfung der Integrität und Authentizität der TSL-Datei durch die Prüfung ihrer Signatur

Die bereits im Internet etablierten PKIs der Vorläuferkarten (qSIG, ZOD), die im Rahmen des Bestandsschutzes zu unterstützen sind, werden in der TI insoweit berücksichtigt, dass die zugehörigen CAs in den TI-Vertrauensraum (also die TSL) aufgenommen und die Statusinformationen der zugehörigen EE-Zertifikate durch Nachnutzung des OCSP-Responder Proxy zur Verfügung gestellt werden (s. Beschreibung in [gemKPT_Arch_TIP#5.4.13].

8.1.1 TSL im Kontext der ECC-Migration

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

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#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 Vertrauensraum (RSA) auf Vertrauensraum (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 verwenden und/oder prüfen, verwenden die TSL(RSA). Alle Produkttypen, die ECC-Zertifikate nutzen oder validieren, müssen die TSL(ECC-RSA) verwenden.

Die gematik empfiehlt Anbietern sogenannter Weiterer elektronischer Anwendungen (aAdG und aAdG-NetG-TI) die Berücksichtigung der für die ECC-Migration aufgeführten Hinweise und Anforderungen. Letztere sind gekennzeichnet durch die Ergänzung „(ECC-Migration)“ im Titel der relevanten Anforderungen.

8.1.2 Initialisierung TI-Vertrauensraum

Verfügt eine zugelassene Komponente der TI noch nicht über einen aktuell gültigen TI-Vertrauensanker, muss für dieses Komponentenexemplar eine Initialisierung des TI-Vertrauensraumes ohne Vorbedingungen durchgeführt werden. Diese besteht aus den zwei Teilprozessen:

• Die sichere Einbringung des TI-Vertrauensankers in Form des aktuell gültigen TSL-Signer-CA-Zertifikates in die Komponente in einer gesicherten Umgebung des Herstellers oder Betreibers
• Einbringung einer aktuellen TSL in die Komponente durch den Hersteller oder den Vor-Ort-Administrator

Dies gilt für die Anwendungsfälle

• der Erstinbetriebnahme einer Komponente und
• der Wiederinbetriebnahme bzw. Systemwiederherstellung zu einem Zeitpunkt, zu dem die in der Komponente vorhandene TSL nicht mehr gültig und zwischenzeitlich ein Wechsel des TI-Vertrauensankers erfolgte.

Die folgenden Anforderungen gelten unter den oben genannten Rahmenbedingungen sowohl für die Initialisierung eines RSA- als auch eines im Rahmen der ECC-Migration notwendigen ECC-Vertrauensankers.

GS-A_4640 - Identifizierung/Validierung des TI-Vertrauensankers bei der initialen Einbringung

Hersteller von Produkttypen der TI, die Zertifikate prüfen, MÜSSEN bei der initialen Einbringung das aktuell gültige TSL-Signer-CA-Zertifikat eindeutig identifizieren und mittels Fingerprint validieren, bevor dieses Zertifikat als TI-Vertrauensanker in die Komponente eingebracht werden darf.

[<=]

GS-A_4641 - Initiale Einbringung TI-Vertrauensanker

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN die initiale Einbringung des aktuell gültigen TSL-Signer-CA-Zertifikat als TI-Vertrauensanker in die Komponente nachweislich sicher vor Manipulation vornehmen.

[<=]

WA-A_2111 - Initiale Einbringung TI-Vertrauensanker in andere Anwendungen

Der Anbieter einer aAdG oder aAdG-NetG-TI MUSS sicherstellen, dass die initiale Einbringung des aktuell gültigen TSL-Signer-CA-Zertifikats als TI-Vertrauensanker in Dienste der aAdG oder der aAdG-NetG-TI nachweislich sicher vor Manipulation vorgenommen wird. [<=]

GS-A_4748 - Initiale Einbringung TSL-Datei

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN die initiale Einbringung der TSL-Datei in die Komponente nachweislich sicher vor Manipulation vornehmen.

[<=]

WA-A_2112 - Initiale Einbringung TSL-Datei

Der Anbieter einer aAdG oder aAdG-NetG-TI MUSS sicherstellen, dass die initiale Einbringung der TSL-Datei in Dienste der aAdG oder der aAdG-NetG-TI nachweislich sicher vor Manipulation vorgenommen wird. [<=]

Im Abschnitt 8.1.1 werden relevante Punkte zur ECC-Migration erläutert. Daher gilt für Produkttypen, die auf ECC migriert bzw. im Vertrauensraum (ECC-RSA) betrieben werden:

A_17688 - Nutzung des ECC-RSA-Vertrauensraumes (ECC-Migration)

Die Produkttypen der TI, die ECC-Zertifikate validieren müssen, MÜSSEN das TSL-Signer-CA-Zertifikat (ECDSA) als TI-Vertrauensanker und die TSL(ECC-RSA) verwenden.

[<=]

Nutzung von Cross-Zertifikaten für die Etablierung des ECC-Vertrauensankers:

Neben den oben in 8.1.2 beschriebenen Festlegungen zum initialen Einbringen eines neuen Vertrauensankers (auch für ECC-RSA) gibt es eine weitere Möglichkeit zur Etablierung. Für die von der ECC-Migration betroffenen Produkttypen, die auf Basis eines bereits etablierten Vertrauensankers (RSA) den neuen Vertrauensanker (ECC-RSA) (entspricht TSL-Signer-CA-Zertifikat (ECDSA)) etablieren (z.B. Konnektoren), gilt folgendes:

A_17689 - Nutzung von Cross-Zertifikaten für Vertrauensraum-Wechsel nach ECC-RSA (ECC-Migration)

Die Produkttypen der TI, die einen Vertrauensanker (ECC-RSA) zur Etablierung des Vertrauensraumes (ECC-RSA) initialisieren, KÖNNEN Cross-Zertifikate verwenden, um auf Basis ihres bereits etablierten Vertrauensankers (RSA) in den Vertrauensraum (ECC-RSA) zu wechseln.

[<=]

A_17820 - Nutzung von Cross-Zertifikaten für Vertrauensraum-Wechsel nach RSA (ECC-Migration)

Die Produkttypen der TI, die einen Vertrauensanker (RSA) zur Etablierung des Vertrauensraumes (RSA) initialisieren, KÖNNEN Cross-Zertifikate verwenden, um auf Basis ihres bereits etablierten Vertrauensankers (ECC-RSA) in den Vertrauensraum (RSA) zu wechseln.
[<=]

Hinweis: Die Nutzung von Cross-Zertifikaten für den Wechsel des Vertrauensraums ist für den Konnektor besonders geregelt (s. gemSpec_Kon#A_17837 und A_17784).

A_17821 - Wechsel des Vertrauensraumes mittels Cross-Zertifikaten (ECC-Migration)

Die Produkttypen der TI, die den Vertrauensraum mittels Cross-Zertifikates wechseln (siehe A_17689 und A_17820) MÜSSEN die folgenden Schritte erfolgreich durchlaufen, um auf den Vertrauensanker des neuen Vertrauensraumes zu wechseln.
Vorbedingung: Das System besitzt zum aktuell etablierten Vertrauensraum den aktuell aktiven Vertrauensanker (der zu dem benutzten Cross-Zertifikat passend ist).

1. Falls eine TSL (aus dem aktuellen Vertrauensraum) bereits im System vorhanden ist, MUSS das Element TSLSequenceNumber aus dieser TSL ausgelesen und der Wert im persistenten (sicheren) Speicher des Systems abgelegt werden. Für jeden TSLSequenceNumber-Nummernkreis (s.u.) wird ein separater Wert geführt.
2. Es MUSS das neue Vertrauensanker-Zertifikat (TSL-Signer-CA<X>) in das System eingelesen werden (auch ggf. als Download realisierbar).
3. Es MUSS das Cross-Zertifikates (C.GEM-TSL-CA<X>-CROSS<Y>) in das System eingelesen werden (auch ggf. als Download realisierbar).
4. Es MUSS ein Vergleich des PublicKey im Cross-Zertifikat mit dem PublicKey im CA-Zertifikat des neuen Vertrauensankers (TSL-Signer-CA<X>) durchgeführt werden.
5. Es MUSS eine Signatur-Prüfung des Cross-Zertifikates gegen den alten Vertrauensanker im System (TSL-Signer-CA<Y>) durchgeführt werden analog zu TUC_PKI_004.
6. Es MUSS eine neue TSL (passend zum Vertrauensanker TSL-Signer-CA<X>) analog zu GS-A_4748 eingebracht und danach das Element TSLSequenceNumber ausgelesen werden. Falls für den TSLSequenceNumber-Nummernkreis der neu eingebrachten TSL eine TSLSequenceNumber im sicheren Speicher vorliegt, dann muss die TSLSequenceNumber der neu eingebachten TSL höher sein, als dieser Wert.

Wenn einer der Schritte fehlschlägt, MUSS der Vertrauensraum-Wechsel-Prozess abgebrochen werden und der alte Vertrauensanker (TSL-Signer-CA<Y>) im System verbleiben.
Nach erfolgreichem Durchlaufen aller Schritte, MUSS der Vertrauensanker (TSL-Signer-CA<X>) im System etabliert sein. 

Erklärungen zu den verwendeten Begriffen:

• Vertrauensanker im System vor dem Vertrauensraum-Wechsel: TSL-Signer-CA<Y>
• Vertrauensanker des neuen Vertrauensraumes: TSL-Signer-CA<X>
• Verwendetes Cross-Zertifikat: C.GEM-TSL-CA<X>-CROSS<Y>
• TSLSequenceNumber – Nummernkreis RSA: 0..9999
• TSLSequenceNumber – Nummernkreis ECC-RSA:  ab 10000

[<=]

Für die Zertifikatsprüfung bei der initialen Einbringung und Validierung der TSL gelten die Bestimmungen für Offline-Anwendungsszenarien aus Kap. 8.3.2.4, d. h. eine Statusprüfung des TSL-Signatur-Zertifikates erfolgt nicht.

Die in der TI zugelassenen Zertifikate der vertrauenswürdigen Herausgeber (TSPs) sind in der TSL enthalten. Bei der Initialisierung des TI-Vertrauensraumes wird der Truststore befüllt, d.h. die Zertifikate können aus der TSL-Datei ausgelesen und z. B. in den Truststore des Systems importiert werden. Der Status der bezeichneten Vertrauensdienste wird jeweils im Inhalt des TSL-Elementes „ServiceStatus“ mit einem URI identifiziert. Die untenstehende Tabelle zeigt die erlaubten Status und erklärt deren Bedeutung in der TI Für X.509-CA-Zertifikate gibt die Kombination des Inhaltes von „ServiceStatus“ mit dem Zeitpunkt in „StatusStartingTime“ an,

• seit wann ein Zertifikat dem aktuellen TI-X.509-Vertrauensraum angehört (mit „/inaccord“ markiert), oder
• bis wann unter dem CA-Zertifikat EE-Zertifikate ausgestellt werden durften.
  • „/revoked“: Dies entspricht einer Sperrung gemäß dem Kettenmodell für QES (s. [gemKPT_PKI_TIP#2.4.3]) oder dem Kompromissmodell für nonQES-Zertifikate für HBA und SMC-B (s. [gemKPT_PKI_TIP#2.4.2]). Diese erfolgt bei einer Einstellung des Betriebs aufgrund eines nicht-sicherheitskritischen Incidents, gegebenenfalls auch nach einem sicherheitskritischen Incident. Vgl. dazu auch [gemKPT_PKI_TIP#2.3.3.5] „Sperrung von CA-Zertifikaten in der TSL“ und [gemKPT_PKI_TIP#2.4]. „Gültigkeitsmodelle X.509-Zertifikate“.    
    Im TUC_PKI_018 "Zertifikatsprüfung in der TI", Schritt 5 wird geprüft, ob unerlaubt Zertifikate ausgegeben wurden, deren Ausstellungdatum nach dem Widerrufsdatum des CA-Zertifikats liegt.
  • „/expired“: Das CA-Zertifikat ist abgelaufen, es wird aber für die Validierung von Zertifikaten weiterhin benötigt. Der ServiceStatus wird zur Prüfung von nonQES-Signaturen nach Kompromissmodell benötigt .

Hinweis: Gemäß Schalenmodell gesperrte CA-Zertifikate werden aus der TSL entfernt, es wird deshalb kein URI zur Markierung dieser Zertifikate verwendet.

OCSP-Signer-, CRL-Signer- und CVC-CA-Zertifikate sowie der DNSSEC-Trust-Anchor sind nur in der aktuellen TSL-Datei enthalten, wenn sie auch gegenwärtig im Einsatz sind. Für diese Dienstarten ist deshalb „/inaccord“ der einzige erlaubte Status. 

Tabelle 7475: Tab_PKI_271 Erlaubte URIs als Inhalte des TSL-Elements ServiceStatus 

URI	Dienstart	Bedeutung
http://uri.etsi.org/TrstSvc/Svcstatus/inaccord	X.509-CA OCSP-Signer CRL-Signer CVC-Root-CA DNSSEC-Trust-Anchor BNetzA-VL-Signer Unspecified ServiceType	Der Dienst ist für die TI zugelassen und ist in Betrieb.
http://uri.etsi.org/TrstSvc/Svcstatus/revoked	X.509-CA	Die Zulassung des Dienstes wurde wegen eines nicht-sicherheitskritischen Incidents widerrufen und die CA stellt keine End-Entity-Zertifikate mehr aus. Bis zum Widerrufsdatum (im Element StatusStartingTime) ausgegebene End-Entity-Zertifikate müssen aber normal (also als gültig, falls nicht widerrufen) behandelt werden.
http://uri.etsi.org/TrstSvc/Svcstatus/expired	X.509-CA	Der Dienst war für die TI zugelassen und war bis zum angegebenen Datum (im Element StatusStartingTime) in Betrieb und im TI-Vertrauensraum.

Hinweis: Der TSL-Dienst darf nur die in Tab_PKI_271 angegebenen URIs für ServiceStatus verwenden.

8.1.2.1 TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“

GS-A_4642 - TUC_PKI_001: Periodische Aktualisierung TI-Vertrauensraum

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_001 zur periodischen Aktualisierung des TI-Vertrauensraums umsetzen.
[<=]

Tabelle 7576: TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“ 

Element	Beschreibung
Name	TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“
Beschreibung	Dieser Use Case beschreibt den gesamten Ablauf zur periodischen Aktualisierung des TI-Vertrauensraumes mittels einer TSL-Datei. Dabei verwendet er weitere TUCs, die im Laufe des Kapitels detailliert spezifiziert werden Ein Offline-Modus ist zu berücksichtigen für a) das Mobile-Kartenterminal b) Konnektor ohne Anbindung an die TI Beide verfügen nicht über die automatischen Online-Möglichkeiten zum Bezug von Statusinformationen oder TSL-Aktualisierungen aus der TI.
Anwendungsumfeld	System, das die TSL auswertet
Vorbedingungen	Gültige TSL im System (optional mit Hashwert)
Auslöser	Produkttypspezifischer Trigger Zeitpunkt MUSS durch Facharchitekturen vorgegeben werden. (Standardmäßig ist eine tägliche Prüfung der Aktualität vorzusehen.)
Eingangsdaten	Neu eingebrachte TSL-Datei (optional) OCSP-Graceperiod (legt bei der Verwendung von gecachten OCSP-Antworten den maximal zulässigen Zeitraum fest, den die Systemzeit der prüfenden Komponente noch nach dem Zeitpunkt der OCSP-Antwort liegen darf) Flag für Offline-Modus (Im Offline-Fall kann keine Sperrstatusprüfung des TSL-Signer-Zertifikates durchgeführt werden.)
Komponenten	System, TSL-Download-Punkt, OCSP-Responder
Ausgangsdaten	Status der Initialisierung
Referenzen	[ETSI_TS_102_231]
Standardablauf	1. [System:] System startet die Initialisierung des TI-Vertrauensraums. 2. [System:] Die TSL im System wird auf Aktualität geprüft (TUC_PKI_019 „Prüfung der Aktualität der TSL"). Diese Prüfung erfolgt gegen die neu eingebrachte TSL-Datei als Eingangsparameter oder optional bei Vorhandensein eines TSL-Hashwertes im System über einen Vergleich mit der TSL-Hashwert-Datei am Downloadpunkt. (Ansonsten wird die aktuelle TSL-Datei bei diesem Schritt heruntergeladen.) Die Prüfung ergibt, dass die im System abgelegten TSL-Informationen erneuert werden müssen. 3. [System:] Das verwendete TSL-Signer-Zertifikat wird aus der TSL-Datei extrahiert. 4. [System:] OCSP-Abfrage für das extrahierte TSL-Signer-Zertifikat durch das System (TUC_PKI_006 "OCSP-Abfrage"). Wenn der zuständige OCSP-Responder die Statusinformation des Zertifikats mit einem Wert „revoked“ oder „unknown“ gemäß GS-A_4690 zurückgibt oder die certHash-Erweiterung fehlt (CERTHASH_EXTENSION_MISSING) bzw. falsch ist (CERTHASH_MISMATCH), darf es nicht zu einer Aktualisierung des TI-Vertrauensraums kommen. (Sämtliche anderen Schritte einer Prüfung des Zertifikates und der XML-Signatur sind im TUC_PKI_019 „Prüfung der Aktualität der TSL" referenziert, vgl. im Schritt 2.) 5. [System:] Es wird ermittelt, ob in der neuen TSL ein neuer TI-Vertrauensanker vorliegt (TUC_PKI_013 „Import TI-Vertrauensanker aus TSL“). 6. [System:] Aus den CA-Zertifikaten aus der neuen TSL wird der neue TI-Vertrauensraum gebildet. Dazu werden sie aus der TSL-Datei extrahiert, z. B. in einen System-eigenen Truststore gespeichert und dem System bereitgestellt. Bei der Extraktion der Zertifikate aus der TSL darf keine inhaltliche Überprüfung der Datenfelder oder eine Signaturprüfung des Zertifikats erfolgen. Falls ein solcher Truststore nur den Vertrauensraum der TI enthält, wird er vor der Neubefüllung geleert, so dass anschließend nur die Zertifikate aus der aktuellen TSL dem System zur Verfügung stehen. Falls der Truststore auch für die sichere Speicherung von Zertifikaten benutzt wird, die nicht in der TSL stehen, muss keine komplette Leerung des Truststores erfolgen. Das System muss aber sicherstellen, dass im Truststore nur diejenigen Zertifikate der TI enthalten sind, die den aktuellen Vertrauensraum der TI aufspannen bzw. in der aktuellen TSL-Datei enthalten sind. Die Form des Truststore wird nicht näher spezifiziert, dieser muss nur den gestellten Anforderungen (z. B. bezüglich Sicherheit oder Performance) genügen. Das System muss den TI-Vertrauensraum mit den in der TSL als vertrauenswürdig bezeichneten und für den Produkttyp relevanten CA-Zertifikaten gemäß Tab_PKI_271 „Erlaubte Inhalte des TSL-Elements ServiceStatus“ befüllen. 7. [System:] Der Truststore wird für Zertifikatsprüfung (wieder) bereitgestellt. 8. [System:] Ende des Use Case
Varianten/Alternativen	Der Standardablauf stellt die Prüfungen dar, die vollzogen werden müssen. Eine Trennung in zwei Prozesse oder eine Umstrukturierung, bei der alle notwendigen Prüfungen erfolgen, ist zulässig. Im Falle einer aktuellen TSL im System endet der Ablauf nach Schritt 2: 2a. [System:] TSL aus Download ist gleich TSL im System; und TSL ist noch gültig. 2a.1 [System:] Ende des Use Case 3a. [System:] Wenn das Offline-Flag gesetzt ist (offline==true), dann wird mit Schritt 5 fortgesetzt. (Im Offline-Fall kann keine OCSP-Abfrage stattfinden.)
Fehlerfälle/Warnung	2b. [System:] Der TUC_PKI_019 wirft eine VALIDITY_WARNING_2. VALIDITY_WARNING_2 wird als Fehlermeldung ausgegeben. Die weitere Fehlerbehandlung erfolgt unter Beachtung von [GS-A_5336]. 3b. [System:] Das TSL-Signer-Zertifikat lässt sich nicht aus der TSL-Datei extrahieren (TSL_CERT_EXTRACTION_ERROR). Weitere Fehlerfälle sind in den jeweiligen referenzierten TUCs beschrieben.
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Die Angaben zur Prüfung einer neuen TSL-Datei müssen als vertrauenswürdige Informationen im System schon vorhanden sein. Deshalb muss die OCSP-Adresse zur Prüfung des Signers der neuen TSL-Datei aus der TSL im System ausgelesen werden. Für die Prüfung der ersten TSL-Datei nach einem Vertrauensankerwechsel (entsprechend TUC_PKI_013 „Import TI-Vertrauensanker aus TSL“ und angekündigt mit ServiceTypeIdentifier „http://uri.etsi.org/TrstSvc/Svctype/TSLServiceCertChange“) bedeutet dies, dass die OCSP-Adresse aus dem „TSLServiceCertChange“ Eintrag aus der TSL im System genommen werden muss. Bei der OCSP-Abfrage für das extrahierte TSL-Signer-Zertifikat gemäß TUC_PKI_006 "OCSP-Abfrage" ist es nicht zulässig, im Schritt „Ermittlung der OCSP-Adresse“ (TUC_PKI_005 "Adresse für Status- und Sperrprüfung ermitteln") bereits Daten aus der zu importierenden TSL zu verwenden. Hinweis zur Robustheit der TSL-Verarbeitung: Nach erfolgreichen Schema- und Signatur-Prüfungen darf es bei der Verarbeitung der TSL-Elemente nicht mehr zum Abbruch des TUC kommen.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_001 "Periodische Aktualisierung TI-Vertrauensraum". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

 

Abbildung 7: Aktivitätsdiagramm TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“ 

 

8.1.3 Geplanter Wechsel TI-Vertrauensanker

Im Folgenden werden der Prozess und die Vorgaben zum TI-Vertrauensankerwechsel beschrieben, die sich beim Wechsel innerhalb einer Schlüsselgeneration (RSA bzw. ECDSA) ergeben.

Wird ein Vertrauensankerwechsel im Rahmen der ECC-Migration vorgenommen, so gelten die Hinweise zur ECC-Migration in Kapitel 8.1.

8.1.3.1 TUC_PKI_013 „Import TI-Vertrauensanker aus TSL“

GS-A_4643 - TUC_PKI_013: Import TI-Vertrauensanker aus TSL

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_013 zum Import neuer TI-Vertrauensanker umsetzen.
[<=]

Tabelle 7677: TUC_PKI_013 „Import neuer TI-Vertrauensanker“ 

Element	Beschreibung
Name	TUC_PKI_013 „Import neuer TI-Vertrauensanker“
Beschreibung	Als TI-Vertrauensanker gilt das aktuell gültige TSL-Signer-CA-Zertifikat. Das neue TSL-Signer-CA-Zertifikat wird rechtzeitig vor dem geplanten Aktivierungsdatum in die TSL integriert und als zukünftiger TI-Vertrauensanker markiert. Über diesen Weg wird es an Komponenten und Systeme ausgeliefert. Die Integrität des neuen Schlüssels wird somit durch den gültigen alten gesichert.
Anwendungsumfeld	System, das die TSL verwendet
Vorbedingungen	TSL mit gültiger Signatur
Auslöser	TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“
Eingangsdaten	Neue TSL-Datei (TSL aus dem Download oder manuellen Import)
Komponenten	System
Ausgangsdaten	Status des Prozesses, im Erfolgsfall eine Erweiterung des sicheren Speichers des Systems um den neuen TI-Vertrauensanker und dessen Aktivierungsdatum.
Referenzen	[ETSI_TS_102_231]
Standardablauf	1. [System:] Das System sucht in der TSL nach den Einträgen für den neuen TI-Vertrauensanker. Die Identifikation erfolgt über den in GS-A_4644 bezeichneten ServiceTypeIdentifier-URI. Zusätzlich kann auch der in GS-A_4644 angegebene OID in der ServiceInformationExtension auf korrekte Belegung geprüft werden. Siehe Kapitel 8.1.3.2. Es wird immer das CA-Zertifikat bereitgestellt. Alle anderen Zustände (z. B. wenn nur der unzertifizierte Schlüssel bereitgestellt wird) müssen als Fehler behandelt werden. Parameter: heruntergeladene TSL 2. [System:] Aus dem gefundenen Eintrag wird das Zertifikat extrahiert. Ergebnis: zukünftiges TSL-Signer-CA-Zertifikat 3. [System:] Aus dem Eintrag des zukünftigen TSL-Signer-CA-Zertifikats wird die „StatusStartingTime“ extrahiert. Ergebnis: StatusStartingTime 4. [System:] Für das zukünftige TSL-Signer-CA-Zertifikat wird TUC_PKI_002 "Gültigkeitsprüfung des Zertifikats" durchlaufen. Parameter: zukünftiges TSL-CA-Zertifikat, StatusStartingTime. 5. [System:] Der zukünftige TI-Vertrauensanker wird parallel zum aktiven TI-Vertrauensanker abgelegt. Parameter: zukünftiges TSL-Signer-CA-Zertifikat 6. [System:] Der zukünftige TI-Vertrauensanker darf nicht vor dem Zeitpunkt „StatusStartingTime“ aktiviert werden. Der zukünftige TI-Vertrauensanker muss spätestens dann aktiviert werden, wenn nach Erreichen der „StatusStartingTime“ ein Update der TSL durchgeführt wird. Bei Aktivierung des zukünftigen TI-Vertrauensankers wird der alte TI-Vertrauensanker deaktiviert. Parameter: StatusStartingTime
Varianten/Alternativen	1a. [System:] Es wird kein als neuer TI-Vertrauensanker markiertes CA-Zertifikat gefunden und der Use Case wird beendet.
Fehlerfälle	Ein Abbruch des TUC führt nur dazu, dass kein neuer TI-Vertrauensanker abgelegt wird. Er hat keinen Einfluss auf die Gültigkeit des bestehenden TI-Vertrauensankers oder auf die anderen Schritte der TSL-Aktualisierung. Das System muss dies jedoch protokollieren. 1b. [System:] Es wird mehr als ein markiertes CA-Zertifikat gefunden. (MULTIPLE_TRUST_ANCHOR) 2b. [System:] Das TSL-Signer-CA-Zertifikat lässt sich nicht aus der TSL extrahieren. (TSL_SIG_CERT_EXTRACTION_ERROR)
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Der Prozess wird unhabhängig davon durchlaufen, ob schon ein zukünftiger TI-Vertrauensanker vorliegt oder nicht. Es ist immer nur der zuletzt angekündigte zukünftige TI-Vertrauensanker gültig. Ältere Ankündigungen müssen überschrieben werden. Die Gestaltung des sicheren Speichers des Systems ist durch den Betreiber/Implementierer des Systems zu definieren.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_013 "Import neuer TI-Vertrauensanker". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

 

Abbildung 8: Aktivitätsdiagramm TUC_PKI_013 „Import neuer TI-Vertrauensanker“ 

8.1.3.2 TSL-Einträge für die Bereitstellung neuer TI-Vertrauensanker

Für den Wechsel auf ein neues TSL-Signer-CA-Zertifikat wird dieses in der TSL aufgenommen unter Berücksichtigung folgender Rahmenbedingungen:

Die Aufnahme des Zertifikates erfolgt rechtzeitig, also erstmals zu einem Datum, welches eine definierte Zeitspanne vor dem geplanten Aktivierungsdatum liegt. Diese Aufnahme erfolgt in Abstimmung mit der gematik und unter Einhaltung der üblichen Prozesse der Eintragsverwaltung für Zertifikate in der TSL (s. auch [gemSpec_TSL#6.1.2]). Ab diesem Datum wird das Zertifikat auch in den folgenden TSL-Dateien bis zum Erreichen des Aktivierungszeitpunkts als nächster TI-Vertrauensanker geführt.

Dies wird so gehandhabt, um temporär offline befindliche Komponenten eine als zumutbar angenommene Zeitspanne zur Migration zu gewähren.

Die Integrität des neuen Schlüssels wird durch den alten gesichert. Dazu erzeugt der gematik TSL-Dienst einen TSP-Dienst-Eintrag in der TSL-Datei mit folgenden Eigenschaften (Update-Parameter):

• Service Type Identifier     (http://uri.etsi.org/TrstSvc/Svctype/TSLServiceCertChange)
  signalisiert den Verwendungszweck des Eintrags,    
  <xsd:element name="ServiceTypeIdentifier" type="tsl:NonEmptyURIType"/>
• das neue TSL-Signer-CA-Zertifikat (ServiceDigitalIdentity),    
  <xsd:element name="X509Certificate" type="xsd:base64Binary"/>
• der Aktivierungszeitpunkt des neuen TSL-Signer-CA-Zertifikats     (StatusStartingTime)
  <xsd:element name="StatusStartingTime" type="xsd:dateTime"/>
• die Extension für den TI-Vertrauensanker-Wechsel gemäß [gemSpec_OID#3.6]     (in ServiceInformationExtension).    
  <xsd:element name="ServiceInformationExtensions"     type="tsl:ExtensionsListType" minOccurs="0"/>

Ergänzend dazu gelten die allgemeinen Vorgaben für das Element TSPService wie in [gemSpec_TSL#7.3.2] beschrieben, siehe z. B. TIP1-A_4104 hinsichtlich Eintrag des X.509-Zertifikats oder TIP1-A_4106 bezüglich der Adresse der OCSP-Responder-Adresse.

Als TI-Vertrauensanker wird das TSL-Signer-CA-Zertifikat angesehen. Bei jedem Wechsel wird der vollständige TI-Vertrauensanker in der TSL veröffentlicht.

GS-A_4644 - TSL-Vertrauensankerwechsel

Der TSL-Dienst MUSS für einen TI-Vertrauensankerwechsel die folgenden Einträge aufnehmen:
(a) Innerhalb Element ServiceTypeIdentifier:     
URI http://uri.etsi.org/TrstSvc/Svctype/TSLServiceCertChange
(b) das Zertifikat des neuen TI-Vertrauensankers in ServiceDigitalIdentity    
(c) Einen durch die gematik vorgegebenen Aktivierungszeitpunkt im Element StatusStartingTime    
(d) Adresse des OCSP-Responders zur Prüfung von ausgestellten Zertifikaten (TSL-Signer)    in ServiceSupplyPoint(s)    (e) die Extension für den TI-Vertrauensankerwechsel {oid_tsl_cca_cert} gemäß [gemSpec_OID#GS-A_4447] (in ServiceInformationExtension)

[<=]

Hinweis: Der TSL-Dienst führt das Zertifikat des nächsten TI-Vertrauensankers ab dem erstmaligen Eintrag zusammen mit den anderen Einträgen (a) – (e) in allen folgenden TSL-Dateien bis zu seiner Aktivierung.

Das vorliegende Dokument trifft keine Festlegungen zu den konkret einzutragenden OID-Werten, sondern verwendet stattdessen eine OID-Referenz, die in der Spalte "Inhalt" der Tabelle 82 genannt ist. Die normative Festlegung der OIDs trifft das Dokument [gemSpec_OID], dort ist die Zuordnung zur OID-Referenz ersichtlich.

Tabelle 7778: Gültige Werte für den TI-Vertrauensankerwechsel 

Beschreibung	Ort	Bezeichnung	Format	Inhalt
Eintragsdaten für den Wechsel des TSL-Signer-CA-Zertifikats des TSL-Vertrauensankers	TSL	Change of TSL Signer-CA Certificate	OID	oid_tsl_cca_cert

In der folgenden Tabelle wird ein (nicht-normatives) Beispiel zu den TSL-Einträgen dargestellt, die den Wechsel des TI-Vertrauensraumes bewirken.

Tabelle 7879: Beispiel für den TSL-Eintrag zum Wechsel des TSL-Signer-CA-Zertifikats 

<TSPService>     <ServiceInformation>     <ServiceTypeIdentifier> http://uri.etsi.org/TrstSvc/Svctype/TSLServiceCertChange </ ServiceTypeIdentifier> <ServiceName>         <Name xml:lang="DE">{Name des neuen TSL-Vertrauensankers}</Name> </ServiceName>     <ServiceDigitalIdentity>         <DigitalId>     <X509Certificate>{Base64-codiertes X.509-Zertifikat}</X509Certificate>         </DigitalId>     </ServiceDigitalIdentity>     <ServiceStatus>http://uri.etsi.org/TrstSvc/Svcstatus/inaccord </ServiceStatus>     <StatusStartingTime>2008-04-01T09:30:47Z</StatusStartingTime>     <ServiceSupplyPoints>     <ServiceSupplyPoint>http://pki01ocsp02.gematik.net </ServiceSupplyPoint>     </ServiceSupplyPoints>     <ServiceInformationExtensions>         <Extension Critical="false">             <ExtensionOID>{oid_tsl_cca_cert}</ExtensionOID>             <ExtensionValue>oid_tsl_cca_cert</ExtensionValue>         </Extension>     </ServiceInformationExtensions>     </ServiceInformation> </TSPService>

Hinweis: Die Authentizität der TSL-Datei ist durch deren Signatur gegeben, die. Die Authentizität des TSL-Download-Punktes wird durch DNSSECdas TLS-Protokoll gesichert. Der Download erfolgt deshalb über einfaches HTTP, nicht sowohl in der TI als auch im Internet über HTTPS.

8.1.3.3 Prüfung der TSL nach Wechsel des TI-Vertrauensanker

Ein neuer TI-Vertrauensanker wird mit einem TSL-Eintrag (s. o.) angekündigt.

Sobald der Zeitpunkt für die Aktivierung des neuen TI-Vertrauensankers erreicht ist, wird der neue TI-Vertrauensanker aktiviert. Zur Ermittlung des Zeitpunktes soll die in der TI verbindlich geltende Zeitquelle verwendet werden.

GS-A_4645 - TSL-Signatur ab Aktivierungsdatum neuer TI-Vertrauensanker

Der TSL-Dienst MUSS ab dem Aktivierungsdatum eines über die TSL publizierten TI-Vertrauensankers (TSL-Signer-CA-Zertifikat) die TSL mit einem TSL-Signer-Zertifikat signieren, das von dieser TSL-Signer-CA ausgestellt wurde.

[<=]

8.1.4 Ungeplanter Wechsel des TI-Vertrauensanker

Ein ungeplanter Wechsel des TI-Vertrauensankers kann dann erforderlich werden, wenn die TSL-Signer-CA korrumpiert wurde. (Nur in Verbindung mit dem missbräuchlichen Zugang zu den TSL-Download-Punkten kann hieraus ein konkreter Schaden durch gefälschte TSL-Einträge, die von den auswertenden Komponenten und Systemen nicht mehr als solche erkennbar sind, für die TI resultieren.)

8.2 TSL-Prüfung

8.2.1 Erreichbarkeit und Download der TSL

Der TSL-Dienst stellt die jeweils aktuelle TSL an definierten Download-Punkten in der TI und im Internet bereit. Diese Download-Punkte sind so gewählt, dass sie von allen Diensten, Systemen und Komponenten in der TI netzwerktechnisch erreicht werden können.

Die Adressen der TSL-Download-Punkte sind in Form von URI definiert und Bestandteil jeder TSL.

Die TSL verweist auf die Download-Punkte, wo die jeweils aktuellste Version der TSL heruntergeladen werden kann (siehe Kap. 8.2.1.1).

Die Lokalisierung der Adresse ist in Abschnitt 8.2.1.1 detailliert beschrieben.

8.2.1.1 TUC_PKI_017 „Lokalisierung TSL Download-Adressen“

GS-A_4646 - TUC_PKI_017: Lokalisierung TSL Download-Adressen

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_017 zur Lokalisierung der Download-Adressen der TSL umsetzen.
[<=]

Tabelle 7980: TUC_PKI_017 „Lokalisierung Download-Adressen“ 

Element	Beschreibung
Name	TUC_PKI_017 „Lokalisierung Download-Adressen“
Beschreibung	Die TSL enthält im Element „PointersToOtherTSL“ die Zugriffsadresse für die jeweilige Liste. Zusätzlich ist ein Eintrag für eine Backup-Zugriffsadresse vorhanden. Dieser Use Case beschreibt, wie diese Adressen lokalisiert werden.
Anwendungsumfeld	System, das die TSL verwendet
Vorbedingungen	TSL mit gültiger Signatur
Auslöser	TUC_PKI_016 „Download der TSL”
Eingangsdaten	TSL
Komponenten	System
Ausgangsdaten	PointersToOtherTSL[Primär-Zugriffsadresse, Backup-Zugriffsadresse]
Referenzen	[ETSI_TS_102_231] Annex H und B.2.13
Standardablauf	1. [System:] System startet die Lokalisierung der Adressen 2. [System:] Das Element „PointersToOtherTSL“ wird ausgewählt. 3. [System:] Übergabe des Elements 4. [System:] Ende des Use Cases mit Rückgabe des Adressen-Elements
Fehlerfälle	2a. [System:] Das Element ist nicht vorhanden und der Vorgang wird mit Fehlermeldung abgebrochen. (TSL_DOWNLOAD_ADDRESS_ERROR)
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Die Kennzeichnung der Adressen in der TSL als primär oder als Backup erfolgt gemäß Tab_PKI_272
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_017 "Lokalisierung Download-Adresse". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

 

Abbildung 9: Aktivitätsdiagramm TUC_PKI_017 „Lokalisierung Download-Adresse“ 

Tabelle 8081: Tab_PKI_272 Gültige Werte zur Download-Adresse 

Beschreibung	Ort	Bezeichnung	Format	Inhalt
Bezeichner der Eintragsdaten für die Primär-Adresse der TSL	TSL	Primär-Adresse	OID	oid_tsl_p_loc
Bezeichner der Eintragsdaten für die Backup-Adresse der TSL	TSL	Backup-Adresse	OID	oid_tsl_b_loc

Die normative Festlegung der OIDs ist in [gemSpec_OID#3.6] festgelegt.

Die TSL-Dateien und deren Hash-Werte werden vom Anbieter des TSL-Dienstes in der TI und im Internet zum Download bereitgestellt. Die festgelegten Downloadpunkte sind in [gemSpec_TSL#A_17680] zu finden.

8.2.1.2 TUC_PKI_016 „Download der TSL-Datei“

GS-A_4647 - TUC_PKI_016: Download der TSL-Datei

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_016 zum Download der TSL-Datei umsetzen.
[<=]

Tabelle 8182: TUC_PKI_016 „Download der TSL-Datei“ 

Element	Beschreibung
Name	TUC_PKI_016 „Download der TSL-Datei"
Beschreibung	Es wird der Download-Prozess der TSL-Datei und das Verhalten des Systems bei Fehlerfällen, wie nicht erfolgreicher Download bzw. Netzwerkproblemen beschrieben.
Anwendungsumfeld	System, das die TSL verwendet
Vorbedingungen	Lokalisierung der Download-Adresse
Auslöser	TUC_PKI_019 „Prüfung der Aktualität der TSL"
Eingangsdaten	TSL
Komponenten	System, TSL-Download-Punkt
Ausgangsdaten	Status des Prozesses
Referenzen	[ETSI_TS_102_231]
Standardablauf	1. [System:] Das System startet den Prozess zum Download der TSL-Datei. 2. [System:] Lokalisierung der Download-Adresse (TUC_PKI_017 „Lokalisierung TSL Download-Adressen“) 3. [System:] Auswahl der Primär-Adresse gemäß Tab_PKI_272 aus dem Element „PointersToOtherTSL" und Download der TSL-Datei.Ist der TSL-Download anhand der Primär-Adresse nicht erfolgreich, wird die Backup-Adresse für den Download verwendet. 4. [System:] Ende des Use Case mit entsprechender Rückmeldung.
Varianten/Alternativen	3a. [System:] Bei Fehlern wird ein einfaches Fehlerhandling angestoßen: Der TSL-Download anhand der Primär-Adresse wird dreimal wiederholt. Bei Wiederholung des TSL-Downloads anhand der Backup-Adresse ist analog zu verfahren.
Fehlerfälle	4a. [System:] Sollte der wiederholte Download über keine der Download-Adressen erfolgreich sein, meldet das System einen Fehler und es werden für den Moment keine weiteren Download-Versuche mehr unternommen. (TSL_DOWNLOAD_ERROR)
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_016 "Download der TSL-Datei". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

 

Abbildung 10: Aktivitätsdiagramm TUC_PKI_016 „Download der TSL-Datei“ 

8.2.2 Vertrauensstatus und Authentifizieren der TSL

8.2.2.1 TUC_PKI_019 „Prüfung der Aktualität der TSL“

Eine TSL-prüfende Komponente oder Anwendung kann den übergreifend festgelegten maximalen Wert der TSL-Graceperiod (30 Tage) mit dem Eingangsparameter TSL-Grace-Period überschreiben. Je nach Kritikalität der prüfenden Anwendung kann die TSL-Grace-Period damit zwischen 0 .. 30 Tagen gewählt werden.

Wird der TUC mit dem Wert „0“ aufgerufen, kann die Bedingung für Validity-Warning-1 nicht erfüllt werden, so dass die TSL mit Überschreitung des „nextUpdate“ auf jeden Fall als „ungültig“ mit der Rückmeldung „VALIDITY_WARNING_2“ reklamiert wird. Damit gilt: 

1. OK:    nextUpdate > aktuelles Datum
2. VALIDITY_WARNING_1: nextUpdate < aktuelles Datum < (nextUpdate + TSL-Grace-Period)
3. VALIDITY_WARNING_2: nextUpdate < aktuelles Datum > (nextUpdate + TSL-Grace-Period)

Wird VALIDITY_WARNING_2 geworfen, ist der gültige Vertrauensraum der TI nicht verfügbar, d. h. die TSL-Informationen im System sind nicht mehr vertrauenswürdig. 

Der Vertrauensraum muss deaktiviert werden und bis zu dessen Re-Etablierung (Import einer gültigen TSL-Datei) darf keine Zertifikatsprüfung „gültig“ ergeben.

Dies kann z. B. durch Leeren des Truststores (Löschen der Zertifikate) erfolgen.

GS-A_5336 - Zertifikatsprüfung nach Ablauf TSL-Graceperiod

Die Produkttypen der TI-Plattform, die Zertifikate prüfen, MÜSSEN nach zeitlichem Ablauf der TSL-Graceperiod oder spätestens ab dem Zeitpunkt der darauf folgenden Prüfung der Aktualität der TSL (TUC_PKI_019) die TSL selbst als nicht mehr gültig bewerten (das TSL-Update-Prüfintervall wird in Tab_PKI_294 festgelegt).
Es steht somit keine valide Basis zur Prüfung von Zertifikaten zur Verfügung.
Die Produkttypen der TI-Plattform, die Zertifikate prüfen, MÜSSEN sicherstellen, dass nach zeitlichem Ablauf der TSL-Graceperiod die Zertifikatsprüfung in der TI (TUC_PKI_018) nicht als positiv bewertet wird. Dies gilt unabhängig vom letzten bekannten Status des (ausstellenden) CA-Zertifikats.

[<=]

Um den regelmäßigen Download der TSL effizient zu gestalten, wird neben der eigentlichen Bereitstellung der TSL-Datei auch jeweils ein SHA256-Hash der TSL-Datei bereitgestellt. Damit kann von TSL-auswertenden Komponenten auf den täglichen Download der TSL verzichtet werden, wenn anhand des zuvor geprüften Hashes festgestellt wird, dass die am Download-Punkt verfügbare TSL identisch mit der zuvor schon eingelesenen und verwendeten TSL ist.

A_17690 - Nutzung der Hash-Datei für TSL (ECC-Migration)

Die Produkttypen der TI, die Zertifikate validieren, und dafür die TSL verwenden, KÖNNEN vorab die Hash-Datei der TSL herunterladen, um zu prüfen, ob die am TSL-Downloadpunkt verfügbare TSL eine andere ist, als die schon zuvor heruntergeladene und bereits ausgewertete TSL. Entspricht der Hash-Wert am Download-Punkt (vgl. [gemSpec_TSL]#6.3.1.2) der bereits heruntergeladenen und ausgewerteten TSL, KANN auf den Download verzichtet werden.

[<=]

GS-A_4648 - TUC_PKI_019: Prüfung der Aktualität der TSL

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_019 zur Prüfung der Aktualität der TSL umsetzen.
[<=]

Tabelle 8283: TUC_PKI_019 „Prüfung der Aktualität der TSL“ 

Element	Beschreibung
Name	TUC_PKI_019 „Prüfung der Aktualität der TSL“
Beschreibung	Das System überprüft (standardmäßig täglich) die Aktualität der TSL. Dies geschieht bei Vorhandensein eines TSL-Hashwertes zunächst anhand eines Vergleichs der TSL-Hashwerte im System und auf dem TSL-Downloadpunkt. Nachfolgend erfolgt ein  Vergleich der TSL aus dem System und der TSL aus dem Download: Die jeweilige ID und die jeweilige Sequenznummer der beiden TSL werden dabei verglichen.
Anwendungsumfeld	System, das die TSL auswertet
Vorbedingungen	Eine geprüfte TSL im System
Auslöser	TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“
Eingangsdaten	TSL im System, Hashwert-Datei der TSL im System (optional), neue (nicht über TSL-Download) eingebrachte TSL-Datei (optional), TSL-Grace-Period
Komponenten	System
Ausgangsdaten	Status der Prüfung
Referenzen	[ETSI_TS_102_231]
Standardablauf	1. [System:] System lädt die aktuelle TSL-Datei herunter (TUC_PKI_016 "Download der TSL-Datei"). Im Folgenden wird diese als neue TSL-Datei bezeichnet. 2. [System:] Neue TSL-Datei wird validiert (TUC_PKI_020 „XML-Dokument validieren“) Das entsprechende von der gematik benannte Schema muss verwendet werden. 3. [System:] Das TSL-Signer-Zertifikat der neuen TSL-Datei wird geprüft. (TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“). 4. [System:] Die Signatur der neuen TSL-Datei muss geprüft werden (TUC_PKI_012 „XML-Signatur-Prüfung“) 5. [System:] Aus der TSL im System und der neuen TSL-Datei werden die jeweilige ID und das jeweilige TSLSequenceNumber-Element selektiert. 6. [System:] System prüft die ID-Attribute und das TSLSequenceNumber-Element aus Schritt 5 auf Gleichheit. Sind sie identisch, muss keine Aktualisierung erfolgen. 7. [System:] Prüfung, ob die TSL im System noch aktuell ist. Dies geschieht anhand des aktuellen Datums und des Elements „NextUpdate“ aus der TSL. Eine TSL wird als aktuell bezeichnet, wenn ihr NextUpdate in der Zukunft liegt. 8. [System:] TSL im System ist gültig. Ende des Use Case mit entsprechender Rückmeldung
Varianten/Alternativen	1a. [System:] Wenn eine TSL-Datei als Eingangsparameter eingebracht wurde, dann wird diese TSL-Datei verwendet, und es erfolgt kein Download. Im Folgenden wird diese neu eingebrachte TSL als neue TSL-Datei bezeichnet. 1b. [System:] Wenn ein TSL-Hashwert als Eingangsparameter im System vorhanden ist, wird die aktuelle Hashwert-Datei der TSL vom TSL Downloadpunkt heruntergeladen. Dazu wird der TSL-Downloadpunkt ermittelt (TUC_PKI_017 „Lokalisierung TSL Download-Adressen“) und von der emittelten URI statt der Datei mit Endung „*.xml“ die Datei mit Endung „*.sha2“ heruntergeladen. 1b1. [System:] Ist der heruntergeladene TSL-Hashwert mit dem Hashwert der aktuell im System gespeicherten TSL identisch, dann wird die im System vorhandene TSL–Datei weiter verwendet und es erfolgt kein TSL-Download. Es wird mit Schritt 7 fortgefahren. 1b2. [System:] Falls die Hashwerte verschieden sind oder im System noch kein TSL-Hashwert vorhanden ist, muss eine neue TSL-Datei heruntergeladen werden. Es wird die neue TSL-Hashwert-Datei im System gespeichert und  mit Schritt 1 fortgefahren. Variante 1a kann hier nicht wiederholt werden. 6a. [System:] Die ID-Attribute aus Schritt 5 sind nicht gleich und das TSLSequenceNumber-Element der TSL im System ist kleiner als die der neuen TSL. Somit ist die TSL im System älter als die die neue TSL. 6a1. [System:] Rückmeldung an den aufrufenden Use Case (TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“)
Fehlerfälle	6b. [System:] Keine der beschriebenen Varianten des Vergleichs der ID und SequenceNumber tritt ein. Ende des Use Case mit Fehlermeldung (TSL_ID_INCORRECT) 7a. [System:] Die Aktualitäts-Prüfung ergibt, dass die TSL im System abgelaufen ist (nextUpdate < aktuelles Datum). Das aktuelle Datum liegt aber innerhalb der TSL-Grace-Period (aktuelles Datum < nextUpdate + TSL-Grace-Period). Warnung (VALIDITY_WARNING_1) mit der entsprechenden Meldung. (Die TSL ist nicht mehr aktuell.) Rückmeldung des Warnhinweises. 7a1. [System:] Die Aktualitäts-Prüfung ergibt, dass die TSL-Grace-Period überschritten ist (aktuelles Datum > nextUpdate + TSL-Grace-Period). Warnung (VALIDITY_WARNING_2) mit der entsprechenden Meldung, (Ablauf der TSL-Grace-Period, die TSL im System ist nicht mehr vertrauenswürdig und darf nicht als valide Prüfbasis verwendet werden, s. [GS-A_5336]). Rückmeldung des Warnhinweises. Weitere Fehlerfälle sind in den referenzierten Use Cases beschrieben.
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Die ID der TSL-Datei befindet sich als Attribut im Root-Tag des XML-Dokuments. <xsd:attribute name="Id" type="xsd:ID" use="optional"/> Das Attribut Id wird vom TSL-Service-Provider immer gefüllt. Das Element TSLSequenceNumber beschreibt die Folgenummer der TSL. Sein erstmaliger Inhalt der TSL(RSA) ist gleich 1 und wird jeweils um 1 hoch gezählt. Der erstmalige Wert der TSL(ECC-RSA) ist 10000.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_019 "Prüfung der Aktualität der TSL". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

 

Abbildung 11: Aktivitätsdiagramm TUC_PKI_019 „Prüfung der Aktualität der TSL“ 

8.2.2.2 TUC_PKI_020 „XML-Dokument validieren“

GS-A_4649 - TUC_PKI_020: XML-Dokument validieren

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_020 zur Validierung eines XML-Dokumentes umsetzen.
[<=]

Tabelle 8384: TUC_PKI_020 „XML-Dokument validieren“ 

Element	Beschreibung
Name	TUC_PKI_020 „XML-Dokument validieren“
Beschreibung	Ein XML-Dokument wird gegen ein XML-Schema validiert.
Anwendungsumfeld	Dieser Use Case wird verwendet, um XML-Dokumente zu validieren. In diesem Dokument betrifft das die Validierung der TSL.
Vorbedingungen	Eine vollständig vorliegende TSL-Datei im XML-Format
Auslöser	TUC_PKI_019 „Prüfung der Aktualität der TSL"
Eingangsdaten	TSL-Datei und TSL-XML-Schema (und alle in ihm referenzierten Schemata). Das System muss sicherstellen, dass zur Validierung nur das von der gematik spezifizierte bzw. benannte Schema benutzt wird.
Komponenten	System
Ausgangsdaten	Entsprechendes Ergebnis der Validierung (Erfolg | Misserfolg)
Referenzen	[XML]
Standardablauf	Das System prüft die Wohlgeformtheit des Dokumentes und validiert es gegen das Schema. 1. [System:] System startet Prüfung der TSL-Datei. 2. [System:] System prüft Wohlgeformtheit der TSL-Datei. 3. [System:] System validiert die TSL-Datei gegen die Schemata. 4. [System:] Ende des Use Case mit positivem Ergebnis
Fehlerfälle	Die übergebenen Schemata könnten selbst invalide oder unvollständig sein. 2a. [System:] Ende des Use Case mit Fehlermeldung (TSL_NOT_WELLFORMED) 3a. [System:] Ende des Use Case mit Fehlermeldung (TSL_SCHEMA_NOT_VALID)

8.2.2.3 TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“

GS-A_4650 - TUC_PKI_011: Prüfung des TSL-Signer-Zertifikates

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_011 zur Prüfung des TSL-Signer-Zertifikats umsetzen.
[<=]

Tabelle 8485: TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“ 

Element	Beschreibung
Name	TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates"
Beschreibung	Es wird der Prozess zur Prüfung des TSL-Signer-Zertifikates gegen ein sicher verwahrtes TSL-Signer-CA-Zertifikat spezifiziert. Der Prozess verläuft analog demjenigen für Zertifikatsprüfung im Allgemeinen (TUC_PKI_018 "Zertifikatsprüfung in der TI "), berücksichtigt aber die Besonderheiten des TSL-Signer-Zertifikates. Außerdem erfolgt hier keine Statusprüfung des TSL-Signer-Zertifikates. (Der Aufruf von TUC_PKI_006 „OCSP-Abfrage“ erfolgt in TUC_PKI_001 „Periodische Aktualisierung TI-Vertrauensraum“.)
Anwendungsumfeld	System, das die TSL verwendet
Vorbedingungen	TSL-Signer-CA-Zertifikat in einem sicheren Speicher des Systems
Auslöser	TUC_PKI_019 „Prüfung der Aktualität der TSL"
Eingangsdaten	TSL-Datei Referenzzeitpunkt ( Datum optional; bei Nichtangabe Verwendung der aktuellen Systemzeit)
Komponenten	System
Ausgangsdaten	Status der Prüfung
Referenzen	[ETSI_TS_102_231], [XMLSig]
Standardablauf	1. [System:] Das verwendete TSL-Signer-Zertifikat wird aus der TSL-Datei extrahiert. 2. [System] Der Use Case TUC_PKI_002 "Gültigkeitsprüfung des Zertifikats" wird durchlaufen. 3. [System:] Prüfung der Extension KeyUsage auf vorhanden sein. Zudem wird die KeyUsage auf die richtige Belegung (nonRepudiation) geprüft. Weiter wird die ExtendedKeyUsage auf die richtige Belegung mit {id-tsl-kp-tslSigning} geprüft (vgl. Kap. 5.13.1 TSL-Signer-Zertifikat). 4. [System:] Das TSL-Signer-CA-Zertifikat aus dem sicheren Speicher des Systems wird geladen. 5. [System:] Anhand dieses CA-Zertifikates wird die mathematische Prüfung der Signatur des TSL-Signer-Zertifikats durchgeführt (TUC_PKI_004 "Mathematische Prüfung der Zertifikatssignatur"). (Jedes System muss Initial dieses CA-Zertifikat als TI-Vertrauensanker auf sicherem Wege integrieren.) 6. [System:] Ende des Use Case mit Status Rückmeldung
Varianten/Alternativen
Fehlerfälle	1a. [System:] Das TSL-Signer-Zertifikat lässt sich nicht aus der TSL-Datei extrahieren (TSL_CERT_EXTRACTION_ERROR). 3a. [System:] KeyUsage ist nicht vorhanden bzw. entspricht nicht der vorgesehenen KeyUsage (WRONG_KEYUSAGE). 3a1. [System:] ExtendedKeyUsage entspricht nicht der vorgesehenen ExtendedKeyUsage (WRONG_EXTENDEDKEYUSAGE). 4a. [System:] Das TSL-Signer-CA-Zertifikat kann nicht aus dem sicheren Speicher des Systems geladen werden (TSL_CA_NOT_LOADED). Fehlerfälle sind in den referenzierten Use Cases beschrieben.
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Die Gestaltung des sicheren Speichers des Systems ist durch den Betreiber des Systems auszuarbeiten. TUC_PKI_018 "Zertifikatsprüfung in der TI "fordert zusätzlich die Ermittlung von Autorisierungsinformationen. Dies wird im vorliegenden Use Case nicht benötigt und kann entfallen. Der Aufruf von TUC_PKI_006 "OCSP-Abfrage erfolgt nicht hier, sondern in TUC_PKI_001 "Periodische Aktualisierung TI-Vertrauensraum".
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_011 "Prüfung des TSL-Signer-Zertifikates". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

 

 

Abbildung 12: Aktivitätsdiagramm TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“ 

8.2.2.4 TUC_PKI_012 „XML-Signatur-Prüfung“

GS-A_4651 - TUC_PKI_012: XML-Signatur-Prüfung

Die Produkttypen der TI, die Zertifikate prüfen MÜSSEN TUC_PKI_012 zur Prüfung der Signatur einer XML-Datei umsetzen.
[<=]

Tabelle 8586: TUC_PKI_012 „XML-Signatur- Prüfung“ 

Element	Beschreibung
Name	TUC_PKI_012 „XML-Signatur-Prüfung“
Beschreibung	In diesem Use Case wird die Prüfung der XML-Signatur der TSL beschrieben. Die Prüfung wird nicht näher spezifiziert, sondern richtet sich nach den Vorgaben und Standards von W3C.
Anwendungsumfeld	Dieser Use Case umfasst die Prüfung der XML-Signatur und wird durch jedes System verwendet, das eine XML-Signatur prüfen muss.
Vorbedingungen	(Valide) TSL-Datei mit Signatur: Die TSL-Datei wurde Schema-validiert (TUC_PKI_020) Das Signaturzertifikat dieser TSL-Datei muss erfolgreich geprüft worden sein. (TUC_PKI_011).
Auslöser	TUC_PKI_019 „Prüfung der Aktualität der TSL"
Eingangsdaten	signierte XML-Datei und Signaturzertifikat
Komponenten	System
Ausgangsdaten	Status der Prüfung
Referenzen	[XMLSig]
Standardablauf	Der Ablauf richtet sich nach den Vorgaben von W3C.
Fehlerfälle	[System:] Die Signatur ist nicht gültig. Ende des Use Case. Abbruch mit Fehlermeldung (XML_SIGNATURE_ERROR)
Anmerkungen	Vorgaben für die verwendeten Algorithmen und Schlüssellängen der Signatur werden hier nicht getroffen. Siehe dazu [gemSpec_Krypt#GS-A_4371].

8.2.3 TSL-Sicherheitsaspekte

Für den TI-Vertrauensanker, das TSL-Signer-CA-Zertifikat, und für die TSL (die enthaltenen Zertifikate und auch die eigentliche TSL-Datei im XML-Format) gilt ein hoher Schutzbedarf. Dieser wird dadurch gewährleistet, dass TI-Vertrauensanker und TSL-Datei initial auf (organisatorisch) abgesichertem Weg in die Komponente, bzw. deren sicheren Speicher, eingebracht werden. Vor einem Wechsel der TSL (oder des TI-Vertrauensankers via TSL) müssen immer zwingend Zertifikats- und Signaturprüfungen durchgeführt werden. Dies garantiert die Authentizität und Integrität der Informationen.

8.2.4 TSL-Zeitparameter

GS-A_4897 - Gültigkeitsdauer einer TSL

Der TSL-Dienst MUSS die Gültigkeitsdauer der TSL gemäß Tab_PKI_294 umsetzen.
Der TSL-Dienst MUSS den Zeitpunkt des resultierenden Gültigkeitsendes der TSL innerhalb des Elementes NextUpdate in der TSL-Datei eintragen.

[<=]

GS-A_4898 - TSL-Grace-Period einer TSL

Produkttypen der TI, die die TSL zur Validierung des TI-Vertrauensraums einsetzen, MÜSSEN die TSL-Grace-Period gemäß Tab_PKI_294 umsetzen.

[<=]

GS-A_4899 - TSL Update-Prüfintervall

Produkttypen der TI, die die TSL zur Validierung des TI-Vertrauensraums einsetzen, MÜSSEN gemäß den in Tab_PKI_294 festgelegten TSL-Update Intervall prüfen, ob eine aktuellere als die vom System verwendete TSL bereitgestellt wurde.

[<=]

GS-A_5214 - TSL Neuausstellung

Der TSL-Dienst MUSS mindestens 7 Tage vor Ablauf der Gültigkeit der TSL eine neue Version der TSL erstellen.

[<=]

Tabelle 8687: Tab_PKI_294 TSL Zeitparameter 

Beschreibung	Zeitparameter
Gültigkeitsdauer einer TSL	Ausstellungsdatum + 30 Tage
TSL-Grace-Period für zentrale Dienste und fachanwendungsspezifische Dienste mit Anschluss an das zentrale Netz	0 Tage
TSL-Grace-Period für sonstige Dienste und Komponenten	0-30 Tage
TSL Update-Prüfintervall	24 Stunden

8.2.5 ServiceTypeIdentifier "unspecified"

Die Auswertung der TSL in der TI basiert auf [ETSI_TS_102_231_v3.1.2]. Dort wird der ServiceTypeIdentifier " http://uri.etsi.org/TrstSvc/Svctype/unspecified" definiert. Eine Komponente oder ein Dienst der TI muss also mit solch einem Identifier umgehen können. Um diesen Punkt jedoch noch deutlicher sichtbar zu machen wird er mit einer Anforderung in den Vordergrund gestellt. 

A_17700 - TSL-Auswertung ServiceTypeIdentifier "unspecified"

Alle Produkttypen der TI, die die TSL auswerten, MÜSSEN TSPService-Einträge verarbeiten können mit dem ServiceTypeIdentifier "http://uri.etsi.org/TrstSvc/Svctype/unspecified". Die Auswertung der TSL darf also nicht fehlschlagen wenn ein solcher ServiceTypeIdentifier in der TI vorgefunden wird.


[<=]

8.3 Zertifikatsprüfung X.509 nonQES

Für die Prüfung der X.509-Zertifikate gelten folgende Vorbedingungen (s. Kapitel 8.1 und 8.2):

• aktuelle TSL liegt vor
• TSL-Datei wurde geprüft
• Der TI-Vertrauensraum wurde initialisiert, der Truststore kann benutzt werden.

Die folgende Use Case Übersicht verdeutlicht die Aktionen des Systems.

 

Abbildung 13: Use Case Diagramm „Zertifikatsprüfung“ 

Die folgenden Schritte sind für eine nonQES-Zertifikatsprüfung durchzuführen:

• Prüfung der Gültigkeit (TUC_PKI_002)
• Prüfung der Identität des Zertifikatsherausgebers (TUC_PKI_003)
• Prüfung der mathematischen Korrektheit des Zertifikats (Signaturprüfung) (TUC_PKI_004)
• Abfrage des Sperrstatus des zu prüfenden Zertifikats gegen den im „ServiceSupplyPoint“ der TSL eingetragenen OCSP-Responder (TUC_PKI_006) und Prüfung der OCSP-Antwort (Responder-Zertifikat, Sperrstatus)
• Rollenermittlung (TUC_PKI_009)
• Prüfung Zertifikatstyp (TUC_PKI_007)

Bei jeder dieser Prüfungen muss nicht nur die mathematisch-kryptographische Korrektheit der jeweiligen Mechanismen, sondern auch deren Zulässigkeit mit in die Prüfung einbezogen werden. Zum Beispiel darf ein Zertifikat, welches nicht mit einem zugelassenen Hash-Algorithmus signiert ist, nie als gültig eingestuft werden. Für die TI gültige Hash-Algorithmen siehe [gemSpec_Krypt].

Die Verwendung von Informationen aus Zertifikaten kann nur dann erfolgen, wenn das zugehörige Zertifikat validiert wurde. Somit MUSS eine Zertifikatsprüfung der Ermittlung bestätigter Zertifikatsinformationen vorangehen.

In dem Dokument wird der Begriff „gültiger Zeitraum“ verwendet. Dieser bedeutet, dass sich der aktuelle Zeitpunkt innerhalb des Gültigkeitszeitraums des Objektes befindet.

Die Fachdokumente müssen die entsprechenden Eingangsparameter der Use Cases berücksichtigen. Die Festlegungen aus den Standards  [RFC6960],  [RFC5280], [RFC5019] und [RFC3370/5754] sowie TI-spezifische Vorgaben der gematik sind für die Zertifikatsprüfung verbindlich.

8.3.1 Zertifikatsprüfung in der TI

8.3.1.1 TUC_PKI_018 „Zertifikatsprüfung in der TI“

GS-A_4652-01 - TUC_PKI_018: Zertifikatsprüfung in der TI

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_018 zur Zertifikatsprüfung umsetzen

Tabelle 8788: TUC_PKI_018 „Zertifikatsprüfung in der TI“ 

Element	Beschreibung
Name	TUC_PKI_018 „Zertifikatsprüfung“
Beschreibung	Dieser Use Case beschreibt die Prüfung nicht-qualifizierter Zertifikate und umfasst die Offline- wie Online-Prüfung.
Anwendungsumfeld	System, das Zertifikate verwendet
Vorbedingungen	Eine zeitlich nicht abgelaufene TSL (innerhalb der TSL-Graceperiod) steht als valide Basis zur Prüfung von Zertifikaten zur Verfügung
Auslöser	Zertifikats-Check
Eingangsdaten	Das zu prüfende Zertifikat Referenzzeitpunkt: Zeitpunkt, für den das Zertifikat geprüft werden soll (optional; bei Nichtangabe Verwendung der aktuellen Systemzeit): Zeitpunkt, für den das Zertifikat geprüft werden soll, s. a. Glossar aus Kap. 11.2 PolicyList Liste der im aktuellen Aufruf zulässigen Zertifikatstyp-OIDs. Die Liste muss mindestens eine OID enthalten. Vorgesehene KeyUsage (intendedKeyUsage, mehrere Werte möglich) Vorgesehene ExtendedKeyUsage (intendedExtendedKeyUsage, mehrere Werte möglich) OCSP-Graceperiod (legt bei der Verwendung von (gecachten) OCSP-Antworten den maximal zulässige Zeitraum fest, den die Systemzeit der prüfenden Komponente noch nach dem Zeitpunkt der OCSP- Antwort liegen darf (Default: 10 min) Offline-Modus (ja/nein) Beigefügte OCSP-Response zum angefragten Zertifikat (optional; z. B. in der Signatur eingebettet) Timeout-Parameter (Default: 10s) TOLERATE_OCSP_FAILURE (true/false, Default: false) - Der Parameter definiert das Verhalten für den Fall, dass die OCSP-Prüfung nicht durchgeführt werden konnte, weil der OCSP-Responder beispielsweise technisch nicht erreichbar ist. Prüfmodus (OCSP, CRL)
Komponenten	System, OCSP-Responder
Ausgangsdaten	Status der Prüfung, OCSP-Response, im Zertifikat enthaltene Rollen-OIDs
Referenzen	[RFC5280] Kap. 6.1, [X.509] Referenzierte Standards in den aufzurufenden TUCs
Standardablauf	Die Zertifikatsprüfung setzt sich aus folgenden Schritten zusammen: 1. [System] Die Gültigkeit des Zertifikats wird geprüft (TUC_PKI_002 "Gültigkeitsprüfung des Zertifikats") . 2. [System] Prüfung der Extension KeyUsage auf Vorhandensein. Zudem wird die KeyUsage und ExtendedKeyUsage (falls vorhanden) auf die richtige Belegung entsprechend der vorgesehenen (intendedKeyUsage bzw. intendedExtendedKeyUsage) KeyUsage geprüft. Die intendedKeyUsage sowie die intendedExtendedKeyUsage können aus einer Liste mehrerer erlaubter Werte bestehen. Es wird geprüft, dass die im Parameter intendedKeyUsage bzw. intendedExtendedKeyUsage übergebenen Werte eine Teilmenge der Werte in der jeweiligen Extension KeyUsage bzw. ExtendedKeyUsage des Zertifikats sind. Da die übergebenen Parameter die Verwendung des Zertifikats im Aufrufkontext widerspiegeln, ist es dabei nicht notwendig, dass diese zu den Werten in der Zertifikatsextension komplett identisch sind. Enthält ein übergebener Parameter keine Werte, so bedeutet dies, dass der Inhalt der Zertifikatsextension nicht relevant ist.  3. [System] Das passende CA-Zertifikat wird in den TSL-Informationen gesucht (TUC_PKI_003 "CA-Zertifikat in TSL-Informationen finden") 4. [System] Mathematische Prüfung der Signatur des Zertifikats (TUC_PKI_004 "Mathematische Prüfung der Zertifikatssignatur"). 5. [System] Der ServiceStatus (vgl. Tab_PKI_271) des CA-Zertifikats wird geprüft. Im Fall von „revoked“ wird der Zeitpunkt des Gültigkeitsbeginns (Feld "notBefore" gemäß [RFC5280]#4.1.2.5) des End-Entity-Zertifikats mit dem Datum des Statuswechsels (StatusStartingTime) verglichen. Der Zeitpunkt des Gültigkeitsbeginns des End-Entity-Zertifikats liegt vor dem Zeitpunkt des Statuswechsels. 6. [System, Prüfmodus Offline] Falls JA, weiter mit Schritt 8, sonst mit 7. 7. [System, Prüfmodus OCSP] Statusinformation zum Zertifikat durch Abfrage des zugeordneten OCSP-Dienstes ermitteln (TUC_PKI_006 "OCSP-Abfrage"). TUC_PKI_006 wird für TLS-Zertifikate der Störungsampel (C.ZD.TLS-S mit technischer Rolle oid_stamp) und nonQES-Zertifikate einer eGK mit dem Parameter ENFORCE_CERTHASH_CHECK=false aufgerufen. Für alle anderen Zertifikate wird TUC_PKI_006 mit dem Defaultwert ENFORCE_CERTHASH_CHECK=true aufgerufen. Wenn der zuständige OCSP-Responder die Statusinformation des Zertifikats mit einem Wert „revoked“ oder „unknown“ gemäß GS-A_4690 zurückgibt – Meldungskürzel (CERT_REVOKED) bzw. (CERT_UNKNOWN) gemäß Tab_PKI_274 oder eine wegen ENFORCE_CERTHASH_CHECK=true erforderliche certHash-Erweiterung fehlt (CERTHASH_EXTENSION_MISSING) bzw. falsch ist (CERTHASH_MISMATCH), darf das Zertifikat nicht als gültig bewertet werden. 8. [System:] Ermittlung (TUC_PKI_009 "Rollenermittlung") der Rolle 9. [System:] Prüfung, ob eine der übergebenen Zertifikatstyp-OIDs (aus der Parameter PolicyList) im Zertifikat enthalten ist (TUC_PKI_007 "Prüfung Zertifikatstyp"). Zur Prüfung muss die Liste (PolicyList s.o.) mindestens eine OID enthalten. 10. [System:] Ende des Use Cases mit Rückgabe des/der im Zertifikat enthaltenen Rollen-OID(s).
Varianten/Alternativen	6a. [System:] Der Offline-Modus ist aktiviert. Es werden keine Statusinformationen zum Zertifikat eingeholt. 7a. [System, Prüfmodus CRL] Prüfung der Sperrinformation des Zertifikates mittels CRL (TUC_PKI_021 "CRL-Prüfung"). Wenn das Zertifikat in der Sperrliste (CRL) enthalten ist – Meldungskürzel (CERT_REVOKED) gemäß Tab_PKI_274, darf das Zertifikat nicht als gültig bewertet werden. 7b [System] Eine OCSP-Response zu dem zu prüfenden Zertifikat wurde im Aufruf mit übergeben. Falls diese zum Referenzzeitpunkt gültig ist, wird nicht der TUC_PKI_006 aufgerufen, sondern die beigefügte OCSP-Response zur weiteren Prüfung verwendet.
Fehlerfälle	2a. [System:] KeyUsage ist nicht vorhanden bzw. nicht alle Werte der intendedKeyUsage in der KeyUsage enthalten (WRONG_KEYUSAGE). 2a1. [System:]   intendedExtendedKeyUsage enthält Werte und nicht alle davon sind in der ExtendedKeyUsage enthalten (WRONG_EXTENDEDKEYUSAGE). 5a. [System:] Das Ausgabedatum des End-Entity-Zertifikats liegt nach dem Datum des Statuswechsels. Abbruch mit Fehlermeldung (CA_CERTIFICATE_REVOKED_IN_TSL) 7c. [System] Eine OCSP-Response zu dem zu prüfenden Zertifikat wurde im Aufruf mit übergeben, ergab bei den weiteren Prüfschritten jedoch kein gültiges Ergebnis (Überprüfung und Auswertung der Gültigkeit der OCSP-Response in TUC_PKI_006 schlägt fehl). Eine erneute Prüfung wird in diesem Fall durch Aufruf des TUC_PKI_006 durchgeführt, als wäre keine OCSP-Response beigefügt. In den Rückgabewerten dieses TUC wird die Warnmeldung (PROVIDED_OCSP_RESPONSE_NOT_VALID) an die aufrufende Funktion übergeben.
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Gültige Status zu Schritt 5 sind gemäß Tab_PKI_271 inaccord, revoked und expired.  Schritt 5 stellt eine Sperrprüfung des CA-Zertifikats (für nonQES-HBA- und SMC-B-Zertifikate) gemäß Ketten- bzw. Kompromissmodell dar. Vgl. Kap. 8.1.1 Initialisierung TI-Vertrauensraum. Eine Zertifikatsprüfung in der TI gemäß TUC_PKI_018 darf nach Ablauf der TSL-Graceperiod nicht positiv ausfallen (vgl. GS-A_5336).
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_018 "Zertifikatsprüfung". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

[<=]

 

Abbildung 14: Aktivitätsdiagramm TUC_PKI_018 „Zertifikatsprüfung“ 

8.3.1.2 TUC_PKI_002 „Gültigkeitsprüfung des Zertifikats“

GS-A_4653-01 - TUC_PKI_002: Gültigkeitsprüfung des Zertifikats

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_002 zur Gültigkeitsprüfung des Zertifikates umsetzen

Tabelle 8889: TUC_PKI_002 „Gültigkeitsprüfung des Zertifikats“ 

Element	Beschreibung
Name	TUC_PKI_002 „Gültigkeitsprüfung des Zertifikats“
Beschreibung	Dieser Use Case beschreibt die Prüfung des Zertifikats auf seine aktuelle zeitliche Gültigkeit. Damit ist der Zeitraum gemeint, der im Feld validity steht. Die Prüfung richtet sich nach referenzierten Standards.
Anwendungsumfeld	System, das Zertifikate verwendet
Vorbedingungen	Zertifikat vorhanden
Auslöser	Zertifikatsprüfung in der TI, TUC_PKI_013 „Import TI-Vertrauensanker aus TSL“,  TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“,  TUC_PKI_018 "Zertifikatsprüfung in der TI " TUC_PKI_030 "QES-Zertifikatsprüfung"
Eingangsdaten	Das zu prüfende Zertifikat Referenzzeitpunkt (optional; bei Nichtangabe Verwendung der aktuellen Systemzeit): Zeitpunkt, für den das Zertifikat geprüft werden soll, s. a. Glossar aus Kap. 11.2
Komponenten	System
Ausgangsdaten	Status der Prüfung
Referenzen	[eIDAS], [ETSI EN 319 412-5], [RFC5280]
Standardablauf	1. [System:] Zertifikat lesen 2. [System:] Aus dem Zertifikat das Feld Validity ermitteln und auslesen. 3. [System:] Anhand der ermittelten Daten wird die Gültigkeit geprüft. Dabei kommt folgender Algorithmus zu tragen: notBefore =< Referenzzeitpunkt && notAfter >= Referenzzeitpunkt entspricht einem zeitlich gültigen Zertifikat. Details siehe [RFC5280] Kap. 4.1.2.5 und 6.1.3 4. [System:] Rückmeldung des Status
Fehlerfälle	1a. [System:] Zertifikat ist nicht lesbar (CERT_READ_ERROR). 3a. [System:] Prüfzeitpunkt nicht innerhalb der Gültigkeitsdauer des Zertifikats (CERTIFICATE_NOT_VALID_TIME).
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Der Aufbau der Gültigkeit: wird nicht näher spezifiziert, sondern richtet sich nach referenzierten Standards. Die (zeitliche) Gültigkeitsprüfung ist nach [eIDAS] Artikel 28 Satz (1) auch für die QES-Zertifikatsprüfung gemäß TUC_PKI_030 verpflichtend.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_002 Gültigkeitsprüfung des Zertifikats. Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

[<=]

Abbildung 15: Aktivitätsdiagramm TUC_PKI_002 Gültigkeitsprüfung des Zertifikats 

8.3.1.3 TUC_PKI_003 „CA-Zertifikat in TSL-Informationen finden“

GS-A_4654-01 - TUC_PKI_003: CA-Zertifikat finden

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_003 zur Ermittlung des CA-Zertifikats aus den TSL-Informationen umsetzen

Tabelle 8990: TUC_PKI_003 „CA-Zertifikat in TSL-Informationen finden“ 

Element	Beschreibung
Name	TUC_PKI_003 „CA-Zertifikat in TSL-Informationen finden“
Beschreibung	Anhand der Daten aus dem Zertifikat wird versucht das CA-Zertifikat in der TSL zu finden.
Anwendungsumfeld	System, das Zertifikate verwendet
Vorbedingungen	Zertifikat innerhalb des definierten Gültigkeitszeitraums Eine TSL mit gültiger Signatur
Auslöser	TUC_PKI_005 "Adresse für Status- und Sperrprüfung ermitteln", TUC_PKI_018 "Zertifikatsprüfung in der TI "
Eingangsdaten	End-Entity-Zertifikatsdaten, TSL-Informationen
Komponenten	System
Ausgangsdaten	Status der Prüfung, (Referenz auf) CA-Zertifikat
Referenzen	[ETSI TS 102 231]
Standardablauf	1. [System:] Anhand der End-Entity-Zertifikatsdaten werden die TSL-Informationen durchsucht, um das passende CA-Zertifikat zu finden. Details siehe [ETSI TS 102 231] Kap. 5.5.1 und D.2. 2. [System:] Vergleich 1: IssuerDN des End-Entity-Zertifikats mit dem subjectDN des CA-Zertifikats 3. [System:] Vergleich 2: AuthorityKeyIdentifier des End-Entity-Zertifikats mit SubjectKeyIdentifier des CA-Zertifikats 4. [System:] Selektion (Referenz auf) CA-Zertifikat und Rückgabe
Varianten/Alternativen	2a. [System:] Keine Übereinstimmung. Der Vorgang wird mit einem anderen CA-Zertifikat wiederholt (Iteration)
Fehlerfälle	2b. [System:] Ende der Liste erreicht UND keine Übereinstimmung im DN gefunden. Abbruch des TUC mit Fehlermeldung (CA_CERT_MISSING) 3a. [System:] CA mit passendem DN gefunden, aber Ausstellerschlüssel (SubjectKeyIdentifier) und die Referenz (AuthorityKeyIdentifier) stimmen nicht überein. Abbruch des TUC mit Fehlermeldung (AUTHORITYKEYID_DIFFERENT)
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_003 CA-Zertifikat in TSL-Informationen finden. Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

[<=]

 

Abbildung 16: Aktivitätsdiagramm TUC_PKI_003 CA-Zertifikat in TSL-Informationen finden 

8.3.1.4 TUC_PKI_004 „Mathematische Prüfung der Zertifikatssignatur“

GS-A_4655-01 - TUC_PKI_004: Mathematische Prüfung der Zertifikatssignatur

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_004 zur mathematischen Prüfung der Zertifikatssignatur umsetzen

Tabelle 9091: TUC_PKI_004 „Mathematische Prüfung der Zertifikatssignatur“ 

Element	Beschreibung
Name	TUC_PKI_004 „Mathematische Prüfung der Zertifikatssignatur“
Beschreibung	Dieser Use Case beschreibt die mathematische Prüfung der Signatur des End-Entity-Zertifikats mit Hilfe des CA-Zertifikats.
Anwendungsumfeld	System, das Zertifikate verwendet
Vorbedingungen	Gültiges CA-Zertifikat und passendes End-Entity-Zertifikat innerhalb des definierten Gültigkeitszeitraums
Auslöser	TUC_PKI_011 „Prüfung des TSL-Signer-Zertifikates“, TUC_PKI_013 „Import TI-Vertrauensanker aus TSL“, TUC_PKI_018 "Zertifikatsprüfung in der TI "
Eingangsdaten	End-Entity-Zertifikat, CA-Zertifikat
Komponenten	System
Ausgangsdaten	Status der Prüfung
Referenzen	[RFC5280]
Standardablauf	1. [System:] Auswahl des öffentlichen Schlüssels des CA-Zertifikats 2. [System:] Die Signatur und der verwendete Algorithmus werden aus dem End-Entity-Zertifikat ausgelesen 3. [System:] Verifikation der Signatur und Hashwert-Vergleich (Verfahren siehe [RFC5280] Kap. 6.1) 4. [System:] Rückmeldung an das System
Fehlerfälle	3a. [System:] Die Zertifikats-Signatur ist nicht gültig. Ende des Use Case. Abbruch mit Fehlermeldung (CERTIFICATE_NOT_VALID_MATH)
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	signatureAlgorithm AlgorithmIdentifier: Stellt den verwendeten Signatur-Algorithmus dar, den die CA benutzt hat, um das Zertifikat zu signieren. signature BIT STRING: Die Signatur des Zertifikats.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_004 Mathematische Prüfung der Zertifikatssignatur. Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

[<=]

Abbildung 17: Aktivitätsdiagramm TUC_PKI_004 Mathematische Prüfung der Zertifikatssignatur 

8.3.2 Statusprüfung

8.3.2.1 TUC_PKI_005 „Adresse für Status- und Sperrprüfung ermitteln“

GS-A_4656 - TUC_PKI_005: Adresse für Status- und Sperrprüfung ermitteln

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_005 zur Ermittlung der Adresse für Status- und Sperrprüfung umsetzen.
[<=]

Tabelle 9192: TUC_PKI_005 „Adresse für Status- und Sperrprüfung ermitteln“ 

Element	Beschreibung
Name	TUC_PKI_005 „Adresse für Status- und Sperrprüfung ermitteln“
Beschreibung	In diesem Use Case wird die Ermittlung der Adresse für Status- und Sperrprüfung beschrieben. Default-mäßig handelt es sich dabei um die Adresse des OCSP-Responders, alternativ um diejenige des CRL-Downloadpunktes. Hierbei wird auf die TSL-Informationen zurückgegriffen. Die Adresse ist im CA-Eintrag der TSL hinterlegt. Für das Verhalten in spezifizierten Offline-Szenarien gilt [GS-A_4658].
Anwendungsumfeld	System, das Zertifikate verwendet
Vorbedingungen	Eine TSL mit gültiger Signatur
Auslöser	TUC_PKI_006 "OCSP-Abfrage" oder TUC_PKI_021 "CRL-Prüfung"
Eingangsdaten	End-Entity-Zertifikatsdaten TSL-Informationen
Komponenten	System
Ausgangsdaten	OCSP-Adresse oder Adresse des CRL-Downloadpunktes
Standardablauf	1. [System:] (Referenz auf) CA-Zertifikat in TSL-Informationen finden (TUC_PKI_003 "CA-Zertifikat in TSL-Informationen finden") 2. [System:] Das Element "ServiceSupplyPoint" (bzw. via referenziertes CA-Zertifikat die Referenz auf den bezeichneten Statusprüfdienst- oder CRL Downloadpunkt) auswählen und URI selektieren. 3. [System:] Adresse zurückmelden
Fehlerfälle	1a. [System:] CA kann nicht in den TSL-Informationen ermittelt werden (CA_CERT_MISSING). 2a. [System:] Das Element „ServiceSupplyPoint" konnte nicht gefunden werden (SERVICESUPPLYPOINT_MISSING). Weitere Fehlerfälle werden in den jeweiligen referenzierten TUCs beschrieben.
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Die Adresse des Statusprüfdienstes oder des CRL-Downloadpunktes muss nicht zwingend in der TSL-Datei vorgehalten werden, sondern kann z. B. im Truststore des Systems gespeichert und aufgerufen werden.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_005 "Adresse für Status- und Sperrprüfung ermitteln ". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

 

Abbildung 18: Aktivitätsdiagramm TUC_PKI_005 „Adresse für Status- und Sperrprüfung ermitteln“ 

8.3.2.2 TUC_PKI_006 „OCSP-Abfrage“

GS-A_4657-03 - TUC_PKI_006: OCSP-Abfrage

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_006 zur OCSP-Abfrage umsetzen.

Tabelle 9293: TUC_PKI_006 „OCSP-Abfrage“ 

Element	Beschreibung
Name	TUC_PKI_006 „OCSP-Abfrage"
Beschreibung	Dieser Use Case beschreibt den Prozess zur OCSP-Prüfung eines Zertifikats. Für das Verhalten in spezifizierten Offline-Szenarien gilt [GS-A_4658]. Der Use Case richtet sich nach den Anforderungen aus den referenzierten Standards und den spezifischen Eigenschaften der TI.
Anwendungsumfeld	System, das Zertifikate verwendet
Vorbedingungen	Zeitlich gültiges End-Entity- und CA-Zertifikat. TSL-Informationen sind vorhanden.
Auslöser	Zertifikats-Check
Eingangsdaten	End-Entity-Zertifikatsdaten CA-Zertifikatsdaten TSL-Informationen Referenzzeitpunkt (optional; bei Nichtangabe Verwendung der aktuellen Systemzeit, vgl. Glossar aus Kapitel 11.2): Zeitpunkt, für den das Zertifikat geprüft werden soll OCSP-Graceperiod (Default: 10min) Timeout-Parameter (Default: 10s) TOLERATE_OCSP_FAILURE (true/false, Default: false)  ENFORCE_CERTHASH_CHECK (true/false, Default: f true)
Komponenten	System, OCSP-Responder
Ausgangsdaten	Status der Prüfung OCSP-Response
Referenzen	[RFC6960], [RFC5019],[RFC3370], [RFC5754]
Standardablauf	1. [System:] Prüfung, ob (zum Referenzzeitpunkt unter Berücksichtigung der OCSP-Graceperiod) gültige Statusinformationen bereits vorliegen (z. B. im lokalen Cache bereitgestellt). 2. [System:] Ermittlung der OCSP-Adresse (TUC_PKI_005 "Adresse für Status- und Sperrprüfung ermitteln") 3. [System:] Aufbau des OCSP-Request anhand der passenden Zertifikatsdaten 4. [System:] Absenden des Request an die ermittelte Adresse Der Timeout-Parameter definiert hier, zu welchem Zeitpunkt das System ein Timeout bei Nichterreichbarkeit des Dienstes meldet. 5. [System, OCSP-Responder:] Überprüfung der OCSP-Response (Signatur) auf Integrität. Das dazu benötigte OCSP-Responder-Zertifikat in den TSL-Informationen ermitteln. Die OCSP-Responder-Zertifikate sind alle in den TSL-Informationen enthalten. Somit kann direkt nach dem Zertifikat gesucht werden. (OCSP-Responder sind in der TSL-Datei mit dem „ServiceTypeIdentifier“ "http://uri.etsi.org/TrstSvc/Svctype/Certstatus/OCSP" markiert.) 6. [System:] Auswertung der OCSP-Response.  Dies umfasst die Prüfung von Statuscode („OCSPResponseStatus“) auf Belegung mit  ‚0‘ (für „successful“), Zertifikatsidentifizierungs-Informationen („CertID“) auf Identiät mit derjenigen aus dem Request und Konformität/Plausibilität der Zeitangaben („producedAt“,  „thisUpdate“ und (sofern vorhanden) „nextUpdate“). Details siehe [RFC2560]/[RFC6960] Kap. 4.1, 4.2 und 4.4 [RFC5019], Kap. 4, [gemSpec_PKI] Kap. 9.1.2 (insb. [GS-A_5215]).  7. [System:] Wenn ENFORCE_CERTHASH_CHECK auf ´true´ gesetzt ist, wird das End-Entity-Zertifikat mit dem in der certHash-Erweiterung bezeichneten Algorithmus gehasht (vgl. [gemSpec_Krypt#GS-A_4393]). Das Resultat stimmt mit dem gelieferten certificateHash überein. 8. [System:] Überprüfung der Gültigkeit anhand des Referenzzeitpunkts. Der CertStatus "good“ wird gemeldet. 9. [System:] Rückmeldung, dass das Zertifikat gültig ist und Rückgabe der OCSP-Response. 10. [System:] Ende des UseCase
Varianten/Alternativen	1a. [System:] Prüfung der Gültigkeit des Zertifikats gegen vorliegende Informationen. 1a1. [System:] Zertifikat ist gesperrt. Weiter mit Schritt 5, falls die entsprechenden Prüfungen nicht bereits erfolgt sind. Ansonsten Rückmeldung analog 8. 1a2. Die Statusinformationen sind zu alt (Zertifikat nicht gesperrt && (Referenzzeit - Statusinfo.producedAt) > OCSP-Graceperiod)). Neue Informationen müssen eingeholt werden. Es geht weiter mit Schritt 2 (Standardablauf).  1a3. [System:] Zertifikat ist nicht gesperrt und Statusinformationen sind noch gültig Referenzzeit - Statusinfo.producedAt) <= OCSP-Graceperiod. Rückmeldung: Zertifikat ist gültig.  7a. [System:] ENFORCE_CERTHASH_CHECK ist auf ´false´ gesetzt. Weiter mit nächstem Schritt. Damit wird eine etwaig vorhandene Erweiterung ‚certHash‘ ignoriert.  8a. [System:] Das Zertifikat ist für den Referenzzeitpunkt gültig, obwohl der CertStatus "revoked“ gemeldet wird, da "revocationTime“ > Referenzzeitpunkt. Rückmeldung Zertifikat ist für den Referenzzeitpunkt gültig und Rückgabe der OCSP-Response. 8b. [System:] Zertifikat ist gesperrt und die Referenzzeit liegt nach dem Sperrzeitpunkt (CertStatus revoked UND revocationTime <= des Referenzzeitpunkts). Rückmeldung Zertifikat ist gesperrt und Rückgabe der OCSP-Response. (CERT_REVOKED) 8c. [System:] Zertifikat ist unbekannt (Status unknown) Rückmeldung, dass das Zertifikat ungültig ist und Rückgabe der OCSP-Response. (CERT_UNKNOWN)
Fehlerfälle/Warnungen	4a. [System:] Die OCSP-Prüfung konnte nicht durchgeführt werden: Im Falle von TOLERATE_OCSP_FAILURE=true wird als Ergebnis eine Warnung generiert (OCSP_CHECK_REVOCATION_FAILED). 4b. [System:] Die OCSP-Prüfung konnte nicht durchgeführt werden: Im Falle von TOLERATE_OCSP_FAILURE=false wird mit einer Fehlermeldung abgebrochen. (OCSP_CHECK_REVOCATION_ERROR) 4c. [System:] Der OCSP-Responder ist (unabhängig v. TOLERATE_OCSP_FAILURE) nicht verfügbar. (OCSP_NOT_AVAILABLE) 5a. [System:] OCSP-Zertifikat nicht in TSL-Informationen enthalten. Abbruch mit Fehlermeldung. (OCSP_CERT_MISSING) 5a1. [System:] Signatur der Response ist nicht gültig. Abbruch mit Fehlermeldung (OCSP_SIGNATURE_ERROR) 6a. [System:] Die Response enthält einen Statuscode („OCSPResponseStatus“), der ungleich 0 (für „successful“) ist. (Damit zeigt der OCSP-Responder eine Exception an. Z. B. kann der Wert für den Status auf 3 für „tryLater“ gesetzt sein.) Abbruch mit Fehlermeldung (OCSP_STATUS_ERROR) 6b. [System:] Die Response enthält einen Statuscode („OCSPResponseStatus“), der gleich 0 („successful“) ist. Die ausgewertete OCSP-Response passt aber nicht zum OCSP-Request (z.B. CertID in OCSP-Request und -Response stimmt nicht überein). Abbruch mit Fehlermeldung (OCSP_CHECK_REVOCATION_ERROR) 7b. ENFORCE_CERTHASH_CHECK ist auf ´true´ gesetzt und die OCSP-Response enthält keine certHash-Erweiterung. (CERTHASH_EXTENSION_MISSING) 7c. Der errechnete Zertifikats-Hash stimmt nicht mit demjenigen aus der in der Erweiterung certHash überein. (CERTHASH_MISMATCH)
Sicherheitsanforderungen	Es gelten die allgemeinen Sicherheitsanforderungen an den Produkttypen.
Anmerkungen	Der genaue Aufbau des OCSP-Requests und der OCSP-Response ist in Kapitel 9 spezifiziert. Zur Abfrage beim OCSP-Responder MUSS ein Timeout-Parameter konfiguriert werden können. Dieser definiert, zu welchem Zeitpunkt das System ein Timeout bei Nichterreichbarkeit des Dienstes meldet. Die OCSP-Graceperiod dient der Performance-Steigerung. Die OCSP-Graceperiod legt bei der Verwendung von OCSP-Antworten (im Cache) deren maximal zulässiges Alter fest (gemessen an der Systemzeit). Ein Zwang, OCSP-Responses über die gesamte Dauer der OCSP-Graceperiod zu cachen, existiert nicht. Anmerkung zu 6b: Die OCSP-Response muss gemäß [RFC6960] Kap. 4.2 verarbeitet werden, unabhängig davon, ob das Feld "parameters" der Sequenz AlgorithmIdentifier innerhalb der CertID mit NULL belegt oder nicht gesetzt ist, Details siehe Tab_PKI_290. Der in [RFC5754] Kap. 2 empfohlene SHA2 als Hash-Algorithmus für die Bildung von certID wird nicht von allen OCSP-Responder-Produkten unterstützt. Hinweis zum Referenzzeitpunkt (s. auch Glossar aus Kapitel 11.2): Bei der Prüfung von nonQES-Zertifikaten handelt es sich beim jeweiligen Referenzzeitpunkt um die aktuelle Systemzeit. Dadurch vereinfacht sich der Ablauf des TUC: Die Variante 8a ist unter diesen Umständen nicht möglich, sie muss also nicht berücksichtigt werden.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_006 "OCSP-Abfrage". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

[<=]

Abbildung 19: Aktivitätsdiagramm TUC_PKI_006 „OCSP-Abfrage“ 

8.3.2.3 TUC_PKI_021 „CRL-Prüfung“

GS-A_4900-01 - TUC_PKI_021 “CRL-Prüfung”

Der Konnektor MUSS den TUC_PKI_021 zur Prüfung der Widerrufsinformationen (Statusprüfung) mittels Zertifikatssperrliste (CRL) umsetzen

Tabelle 9394: TUC_PKI_021 „CRL-Prüfung“ 

Element	Beschreibung
Name	TUC_PKI_021 „CRL-Prüfung“
Beschreibung	Dieser Use Case beschreibt den Prozess zur Validierung einer CRL (Certificate Revocation List) sowie den Prozess zur Ermittlung der Sperrinformationen zu einem End-Entity-Zertifikat mittels einer CRL. Die Festlegungen aus [RFC5280], [X.509] und den spezifischen Eigenschaften der TI sind verbindlich.
Anwendungsumfeld	Use Case für den Anwendungsfall zur Prüfung der Sperrinformationen eines End-Entity-Zertifikats.
Vorbedingungen	Ein End-Entity-Zertifikat (mathematisch und zeitlich gültig) Eine CRL ist vorhanden oder kann heruntergeladen werden.
Auslöser	TUC_PKI_018 "Zertifikatsprüfung in der TI "
Eingangsdaten	CRL End-Entity-Zertifikatsdaten (Zertifikats-Seriennummer, CertificateIssuer) Timeout-Parameter (alternativ zu CRL) CRL-Downloadpunkt-Adresse (optional, alternativ zu CRL)
Komponenten	System (nur Konnektor)
Ausgangsdaten	Status der Prüfung
Referenzen	[[RFC5280]                                                              [X.509]
Standardablauf	1. [System:] Selektion der CRL 2. [System:] Prüfen der zeitlichen Gültigkeit der CRL (Systemzeit < crl.NextUpdate), s. [RFC5280] Kap. 5.1.2.5. 3. [System:] Auswertung der Art der CRL. Es wird anhand der IssuingDistributionPoint-Erweiterung in der Sperrliste (CRL) geprüft, ob es sich um eine indirekte CRL handelt (indirectCRL-bit), s. [RFC5280] Kap. 5.2.5, [X.509] Kap. 7.12..  4. [System:] Das zugehörige CRL-Signer-Zertifikat wird in den TSL-Informationen ermittelt. In der TSL-Datei ist der CRL-Signer mit „http://uri.etsi.org/TrstSvc/Svctype/Certstatus/CRL“ im Element ServiceTypeIdentifier gekennzeichnet, s. [ETSI_TS_102_231_V3.1.2] D.2 ETSI Common Domain URIs.  5.  [System:] Prüfung der Signatur der CRL, s. [RFC5280] Kap. 6.3.3. 6.  [System:] Auswertung der CRL-Einträge. Es wird nach der Zertifikatsseriennummer des zu überprüfenden End-Entity-Zertifikats in der CRL gesucht, s. [RFC5280] Kap. 6.3.3. 7.  [System:] Falls einer oder mehrere Einträge gefunden wurden, wird die CRL-Entry-Erweiterung „CertificateIssuer“ ausgelesen und deren Inhalt mit dem Issuer-DistinguishedName des End-Entity-Zertifikats verglichen. Nur wenn der Inhalt der CertificateIssuer-Erweiterung mit diesem DistinguishedName übereinstimmt, ist das Zertifikat gesperrt, s. [RFC5280] Kap. 6.3.3. 8.  [System:] Rückmeldung, dass das Zertifikat nicht in der Sperrliste enthalten ist. 9.  [System:] Ende des Use Case
Varianten/Alternativen	1a. Die CRL ist nicht im System vorhanden und der CRL-Downloadpunkt unbekannt. 1a1. [System:] Ermittlung des TSL-Eintrags der CA, welche das End-Entity-Zertifikat herausgegeben hat. (TUC_PKI_003 „CA Zertifikat in TSL finden“) 1a2. [System:] Ermittlung des CRL-Downloadpunktes aus dem „Service-SupplyPoint“ des TSL-Service Eintrags (TUC_PKI_005 "Adresse für Status- und Sperrprüfung ermitteln"). 1a3. [System:] Herunterladen der CRL aus der ermittelten Adresse. Der Timeout-Parameter definiert hier, zu welchem Zeitpunkt das System ein Timeout bei Nichterreichbarkeit des Dienstes meldet. 1b. Die CRL ist nicht im System vorhanden, der CRL-Downloadpunkt ist aber schon bekannt. 1b1. [System:] Weiter mit 1a3.  7a.  [System:] Zertifikat ist gesperrt. Rückmeldung an das System. (CERT_REVOKED)
Fehlerfälle	1a3a. [System:] Die CRL kann nicht heruntergeladen werden. (CRL_DOWNLOAD_ERROR) 2a. [System:] Die Prüfung der zeitlichen Gültigkeit der CRL ergibt, dass die CRL abgelaufen ist (Systemzeit > crl.NextUpdate) (CRL_OUTDATED_ERROR) 3 b.  [System:] CRL-Signer-Zertifikat nicht in TSL-Informationen enthalten. Abbruch mit Fehlermeldung. (CRL_SIGNER_CERT_MISSING) 4a.  [System:] Signatur der CRL ist nicht gültig. (CRL_SIGNATURE_ERROR) 5a.  [System:] Die CRL ist fehlerhaft aufgebaut und kann nicht geprüft werden. (CRL_CHECK_ERROR)  6a.  [System:] Die CRL ist fehlerhaft aufgebaut und ihre Einträge können nicht ausgewertet werden. (CRL_CHECK_ERROR)  7b.  [System:] Die CRL-Einträge sind fehlerhaft aufgebaut und können nicht weiter geprüft werden. (CRL_CHECK_ERROR)
Anmerkungen, Bemerkungen	Dieser TUC kommt z.B. bei der Konzentrator-Zertifikatsprüfung zur Anwendung. Der Downloadpunkt der CRL ist aus dem Internet erreichbar. Als Übertragungsprotokoll für den allfälligen Download ist „HTTP“ zu verwenden. Die Schritte 1-5 beinhalten die Validierung der CRL. Diese können vorgängig durchgeführt werden und müssen also nicht bei jeder einzelnen CRL-Prüfung eines End-Entity-Zertifikats durchlaufen werden, solange gewährleistet ist, dass die CRL zeitlich gültig ist. Die Zertifikats-Extension crlDistributionPoint wird bei der Zertifikatsprüfung von TI-Zertifikaten gemäß TUC_PKI_018/TUC_PKI_021 nicht ausgewertet (vgl. Tab_PKI_245/Tab_PKI_265).
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_021 "CRL-Prüfung". Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

[<=]

Abbildung 20: Aktivitätsdiagramm TUC_PKI_021 „CRL-Prüfung“ 

8.3.2.4 Szenarien für Offline und Timeout von OCSP

Komponenten und Systeme der Gesundheitstelematik, die ihre Funktion zeitweise oder ständig ohne Online-Zugang zur TI bereitstellen müssen, können im Offline-Fall keine Statusauskünfte für Zertifikate von OCSP-Respondern aus der TI erhalten und müssen somit die Zertifikatsprüfung auf die mathematische Prüfung gegen das Aussteller-CA-Zertifikat aus der lokal vorliegenden TSL beschränken.

GS-A_4658 - Zertifikatsprüfung in spezifizierten Offline-Szenarien

Die Produkttypen der TI, die Zertifikate prüfen und per Spezifikation ihre Funktionen zeitweise oder ständig offline von der TI erbringen, MÜSSEN für die explizit spezifizierten Offline-Szenarien bei der Zertifikatsprüfung die TUCs TUC_PKI_005 OCSP-Adresse ermitteln und TUC_PKI_006 OCSP-Abfrage auslassen.

[<=]

8.3.2.5 Statusprüfung von eGK-Zertifikaten

Bei eGK-Zertifikaten ist es nicht ausgeschlossen, dass diese suspendiert, also nur vorübergehend gesperrt werden. Die OCSP-Statusinformationen für eGK-Zertifikate müssen deshalb in jedem Fall aktuell sein. (Bei Zertifikaten, die dauerhaft gesperrt werden, können sich Applikation hingegen auf OCSP-Responses, die den Status „revoked“ enthalten, verlassen, auch wenn diese älter sind. Vgl. TUC_PKI_006 „OCSP-Abfrage“)

GS-A_4943 - Alter der OCSP-Responses für eGK-Zertifikate

Die Produkttypen der TI, die Zertifikate der elektronischen Gesundheitskarte (eGK) prüfen, DÜRFEN NICHT OCSP-Responses für die Statusprüfung verwenden, deren Alter die OCSP-Graceperiod (maximale Caching-Dauer) übersteigt. Dies beinhaltet auch OCSP-Responses, die den Status „revoked“ enthalten.
[<=]

8.3.3 Ermittlung von Autorisierungsinformationen

8.3.3.1 Bestätigte Zertifikatsinformationen

Das vorliegende Kapitel beschreibt die Ermittlung der folgenden Informationen aus einem X.509-Zertifikat der Telematikinfrastruktur. Dabei geht es um:

• Zertifikatstypen
• Die Rolle der Zertifikatsidentität

Die in diesem Kapitel beschriebenen Use Cases können durch weitere gematik Dokumente referenziert werden.

8.3.3.2 TUC_PKI_009 „Rollenermittlung“

GS-A_4660-0102 - TUC_PKI_009: Rollenermittlung

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_009 zur Ermittlung der Rolle der Identität umsetzen

Tabelle 9495: TUC_PKI_009-01 „Rollenermittlung“ 

Element	Beschreibung
Name	TUC_PKI_009 „Rollenermittlung“
Beschreibung	Die Rolle einer Identität steht im jeweiligen Zertifikat. Dieser Use Case beschreibt die Ermittlung dieser Rolle aus dem Zertifikat. Jede Rolle wird in der Struktur professionInfo als OID gespeichert (siehe Kap 4.4, 4.5, 4.6). In allen Zertifikaten, die eine Rolle besitzen, steht diese in der Extension Admission, aus welcher der OID ausgelesen wird.
Anwendungsumfeld	System, das spezifische Inhalte von Zertifikaten verwendet
Vorbedingungen	Gültiges End-Entity-Zertifikat
Auslöser	Zertifikatsprüfung in der TI, TUC_PKI_018 "Zertifikatsprüfung in der TI ", TUC_PKI_030 "QES-Zertifikatsprüfung"
Eingangsdaten	End-Entity-Zertifikatsdaten
Komponenten	System
Ausgangsdaten	OID der Rolle
Referenzen	[Common-PKI#Part1#3.1]
Standardablauf	1. [System:] Prozess zur Ermittlung der Rolle beginnt 2. [System:] Extension Admission aus dem Zertifikat auslesen. 3. [System] Admission ist vorhanden und die Rolle aus dem Feld professionOIDs ermittelt. Sind weitere Einträge professionInfo enthalten, wird dieser Schritt so oft durchlaufen, bis alle professionOIDs ermittelt sind. 4. [System:] Mindestens eine OID ist vorhanden und wird zurück geliefert. Bei mehreren OID wird die Liste der OID als Rückgabewert geliefert. Ende des Use Case mit vorhandener Rolle
Varianten/Alternativen	3a. [System:] Extension Admission ist nicht vorhanden. 3a1. [System:] Meldung des Systems, dass keine Rolle vorhanden ist. 3a2. [System:] Ende des Use Case ohne Rolle 4a. [System:] OID nicht vorhanden 4a1. [System:] Meldung des Systems, dass keine Rolle vorhanden ist. 4a2. [System:] Ende des Use Case ohne Rolle
Fehlerfälle	Es werden keine spezifischen Fehlerfälle beschrieben.
Anmerkungen	Die Rolle in der Extension Admission befindet sich im Feld professionOIDs und ist als OID abgelegt. Die genaue Festlegung der OID wird im Dokument [gemSpec_OID] spezifiziert. Syntax der Extension Admission siehe IT-spezifische Festlegungen, insbesondere Tab_PKI_226-01. Die Auswertung der Rolle und wie im Fehlerfall zu verfahren ist, wird in der jeweiligen Produktspezifikation beschrieben.
Zugehörige Diagramme	Aktivitätsdiagramm TUC_PKI_009 „Rollenermittlung“. Das Diagramm dient nur der Veranschaulichung und ist nicht normativ. Gegebenenfalls enthält es nicht alle Prüfschritte und Meldungen im Detail.

[<=]

 

Abbildung 21: Aktivitätsdiagramm TUC_PKI_009 „Rollenermittlung“ 

8.3.3.3 TUC_PKI_007 „Prüfung Zertifikatstyp“

GS-A_4749-01 - TUC_PKI_007: Prüfung Zertifikatstyp

Die Produkttypen der TI, die Zertifikate prüfen, MÜSSEN TUC_PKI_007 zur Prüfung des Zertifikatstyps umsetzen. 

Tabelle 9596 : TUC_PKI_007 „Prüfung Zertifikatstyp“