Verzeichnisdienstkonzept

Transkript

1 Einführung der Gesundheitskarte Verzeichnisdienstkonzept der gematik- Version: Revision: main/rel_main/24 Stand: Status: freigegeben gematik_pki_verzeichnisdienstkonzept.doc Seite 1 von 44

2 Dokumentinformationen Änderungen zur Vorversion Es wurden die Kommentare des Kostenträgerreviewboard eingearbeitet, insbesondere die zusätzlichen Informationen zum Anhang A und zur Dauer der Speicherung der Prüfinformation gesperrter oder abgelaufener Zertifikate. Bezüglich der unterschiedlichen Gültigkeitsmodelle wurde ein klärender Hinweis eingearbeitet und der Link zur Seite der BAEK ergänzt. Festlegungen, die an anderer Stelle der Dokumente zur Einführung der Gesundheitskarte getroffen werden, werden nicht mehr wiederholt sondern lediglich referenziert (siehe Abschnitt 4.3 zum OCSP-Responder). Redaktionell wurde der ehemalige Anhang B jetzt als Anhang A eingeordnet. Inhaltliche Änderungen gegenüber der letzten freigegebenen Version sind gelb markiert. Sofern ganze Kapitel eingefügt oder umfassend geändert wurden, wurde zur besseren Lesbarkeit lediglich die Überschrift durch gelbe Markierung hervorgehoben. Referenzierung des Dokumentes: Die Referenzierung in weiteren Dokumenten der gematik erfolgt unter: [gempki_verzd] gematik: Einführung der Gesundheitskarte Verzeichnisdienstkonzept der gematik-, Dokumentenhistorie Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Erstellung gematik, AG Grundlegende Überarbeitung gematik, AG Ergänzung Kapitel 4 gematik, AG Ergänzung der OCSP Definitionen gematik, AG OCSP Prüfung überarbeitet gematik, AG Begrifflichkeiten angepasst gematik, AG Editorische Überarbeitung gematik, AG Abstimmung in der AG Ergänzung Anhang B zu Performanz gematik, AG Einarbeitung der Ergebnisse interne QS gematik, AG3 gematik_pki_verzeichnisdienstkonzept.doc Seite 2 von 44

3 Version Stand Kap./ Seite Grund der Änderung, besondere Hinweise Bearbeitung Abgleich zu Dokument bezüglich Zulassung des Konnektors gematik, AG Freigegeben zur Vorkommentierung gematik Einarbeitung der Ergebnisse der Vorkommentierung gematik, AG Editorische Überarbeitung gematik, AG Einfügen einer Tabelle zu OCSP-Abfragen gematik, AG freigegeben gematik , 5.4 Anh. B Einschränkung auf eine Zertifikatsabfrage pro OCSP-Request aufgrund verteilter Responder Klarstellung, dass Anh. B informativen Charakter hat AG freigegeben gematik Kap 2.4 Bezug zu den neuen Dokumenten der Komponentenzertifikate hergestellt. Kommentare des Kostenträgerreviewboard eingearbeitet Editorische Änderungen, ISIS-MTT angepasst Verweis auf CRL bei Konzentratoren und Caching zu offenen Punkten eingefügt Präzisierung der Anforderung in Bezug auf die Zukunft Kap. 3 Präzisierung der Anforderung an OCSP- Response SPE/ZD SPE/ZD SPE/ZD SPE/ZD SPE/ZD freigegeben gematik gematik_pki_verzeichnisdienstkonzept.doc Seite 3 von 44

4 Inhaltsverzeichnis Dokumentinformationen...2 Inhaltsverzeichnis Zusammenfassung Einführung Zielsetzung und Einordnung des Dokumentes Zielgruppe Geltungsbereich Arbeitsgrundlagen Abgrenzung des Dokumentes Verwendung von Schüsselworten Technische Grundlagen Online Certificate Status Protocol Kodierung des OCSP Request Response Zertifikatsstatus Zeiten in einer OCSP-Response Strukturen der Dienste Zuordnung der Dienste Technische Festlegungen zu den OCSP-Diensten Statusabfrageüberprüfung für Zertifikate Gültigkeitsmodell Festlegungen zu den OCSP-Zertifikatsprüfungen Funktionale Anforderungen an OCSP Responder Grundsätze Struktur des öffentlichen Verzeichnisdienstes Verfügbarkeit des OCSP-Responders Syntax von OCSP gemäß COMMON-PKI Part gematik_pki_verzeichnisdienstkonzept.doc Seite 4 von 44

5 6 Namensregeln und formate Organisatorische Verantwortlichkeiten der Namensvergabe Generelle Vorgaben und Empfehlungen Eindeutigkeit von Distinguished Names Umlaute Subject Distinguished Names (DNs) Grundsätzliche Regeln für Subject DNs Subject-DNs für natürliche und juristische Personen Subject-DNs für die Domäne der Komponenten Namen in Directories...36 Anhang A: Performanz von OCSP-Services (informativ)...37 A1 OCSP für qualifizierte Zertifikate...37 A2 Optimierungsmöglichkeiten bezüglich Performance...37 A3 Klassisches OCSP-Verfahren...38 A4 Vorschlag für optimiertes Verfahren...38 A5 Voraussetzungen für optimiertes Verfahren...39 Anhang B...40 B1 Abkürzungen...40 B2 - Glossar...41 B3 Tabellenverzeichnis...41 B4 Abbildungsverzeichnis...41 B5 - Referenzierte Dokumente...41 B6 - Klärungsbedarf...44 gematik_pki_verzeichnisdienstkonzept.doc Seite 5 von 44

6 1 Zusammenfassung In der Telematikinfrastruktur werden X.509-Zertifikate zum Schutz der Sicherheitsziele Vertraulichkeit, Integritätsschutz, Identitätsschutz und Nicht-Abstreitbarkeit eingesetzt. Dieses betrifft sowohl die Identitäten von Personen im Bereich des HBA und der egk, die Organisationszertifikate der SMC-B und die Zertifikate der relevanten informationsverarbeitenden Objekte, insbesondere Konnektoren (SM-K), Fachdienste, Serversysteme, Infrastrukturdienste und Netzkomponenten. Um in diesem heterogenen Umfeld einen homogenen Vertrauensraum zu schaffen, wird für die übergeordneten X.509-Zertifikate der ausstellenden Organisationen, der sog. Trust Service Provider (TSP), nicht der Ansatz einer hierarchischen Kontrolle der Zertifikatserstellung verfolgt, sondern das Konzept der zentralisierten (Online-) TSP- Zertifikatsprüfung mittels der Trust-service Status List (TSL) bzw. der Trusted Component List (TCL) umgesetzt. Erst nach erfolgter Zulassung des TSP werden dessen Herausgeber- und Prüfdienstzertifikate in die TSL bzw. TCL aufgenommen. Der Konnektor und andere zertifikatsprüfende Institutionen bzw. Komponenten können durch Verwendung dieser Listen auf technischem Wege die Zulassung des TSP überwachen und damit das erforderliche Sicherheitsniveau (siehe [gemtsl_sp_cp]) sicherstellen. Bezüglich der Zertifikate der Endnutzer, also der Versicherten, der Heilberufler, der Organisationen und Komponenten wird das Prinzip der dezentralen Online-Prüfung via Online Certificate Status Protocol (OCSP) realisiert. Jeder TSP, der Endnutzerzertifikate herausgibt, ist auch verpflichtet, mindestens über die Lebensdauer des Zertifikats einen hinreichend performanten Auskunftsdienst auf Basis von OCSP zu betreiben bzw. betreiben zu lassen. Ergänzend zu den Einträgen der OCSP-Dienste in der TSL bzw. TCL enthält jedes X.509- Zertifikat bereits die Adresse des OCSP-Responders, der die relevanten Prüfinformationen bereithält. Aus Gründen der Performanz, der Interoperabilität und der gesetzlichen Vergabekriterien sind in diesem Dokument nur Festlegungen getroffen worden, die auf internationalen Standards beruhen. Bei Abweichungen aufgrund von Vorgaben des Signaturgesetzes für akkreditierte bzw. qualifizierte Zertifizierungsdiensteanbieter wird auf die entsprechenden Dokumente der Herausgeber der gemeinsamen Policy für die Ausgabe der HPC verwiesen. ( Bzgl. der Einträge der OCSP-Responder-Adressen verhält sich die TCL für die Komponentenzertifikate analog zur TSL für die so genannten Personen- und Organisationszertifikate. Deshalb ist im weiteren Dokument an allen Stellen, in denen auf die TSL verwiesen wird, ebenso die TCL gemeint. Für die performante Prüfung von Komponentenzertifikaten wurden ergänzende Festlegungen getroffen. Die dafür relevanten Dokumente sind in Kapitel 2.4 referenziert. gematik_pki_verzeichnisdienstkonzept.doc Seite 6 von 44

7 2 Einführung 2.1 Zielsetzung und Einordnung des Dokumentes Dieses Dokument stellt eine Übersicht über die technischen Vorgaben zur X.509- Zertifikatsprüfung für Betreiber von PKI-Diensten und für alle Institutionen, welche die in der TI verwendeten X.509-Zertifikate prüfen wollen, dar. Kapitel 3 erläutert die technischen Grundlagen zur Ausgestaltung dieser Dienste. Das nachfolgende Kapitel definiert die entsprechenden Vorgaben. Kapitel 5 beschreibt die funktionalen Vorgaben die sich aus Gesamtarchitektur und Konnektorspezifikation ergeben. Erforderliche Festlegungen zu den Namensregeln und formaten erfolgen im letzten Kapitel. Der Anhang A bietet einen Vorschlag für die Performanzsteigerung der OCSP-Prüfung insbesondere bei qualifizierten Zertifikaten. Detaillierte Festlegungen zu LDAP-basierenden Verzeichnisdiensten erfolgen in dieser Version des Dokuments noch nicht, da hier noch der genaue Bedarf in Bezug auf die Gesamtarchitektur definiert werden muss. 2.2 Zielgruppe Dieses Dokument richtet sich an alle Trust Service Provider, die X.509-Zertifikate im Rahmen der Telematikinfrastruktur des deutschen Gesundheitswesens generieren und/oder deren Gültigkeitsinformationen bereitstellen. 2.3 Geltungsbereich Die in diesem Dokument enthaltenen Vorgaben sind für alle unter Abschnitt 2.2 genannten Trust Service Provider verbindlich, sofern sie X.509-Zertifikate generieren und/oder deren Gültigkeitsinformationen bereitstellen und sich bei der gematik registrieren lassen möchten. gematik_pki_verzeichnisdienstkonzept.doc Seite 7 von 44

8 2.4 Arbeitsgrundlagen Dieses Dokument hat folgende PKI-relevanten Dokumente als Grundlage, diese haben für die jeweiligen Teilbereiche normativen Charakter. Insbesondere für die Prüfung von Komponentenzertifikaten wurden einige ergänzende Festlegungen getroffen, die nun zu berücksichtigen sind gefunden. Tabelle 1: Überblick über die Basisdokumente Name Gemeinsame Zertifizierungsrichtlinie für Teilnehmer der gematik-tsl zur Herausgabe von X.509-ENC/AUTH/OSIG-Zertifikaten Festlegung einer einheitlichen X.509-Zertifikatsinfrastruktur (TSL) Festlegung zu den X.509-Zertifikaten der SMCTyp B Festlegungen zu den X.509-Komponentenzertifikaten des Konnektors Festlegungen zu den Zertifikaten der Server- und Fachdienste Verwendung von Zertifikaten in der Telematikinfrastruktur Version Dokument [gemtsl_sp_cp] [gemx.509_tsl] [gemx.509_smcb] [gemx.509_kon] [gemx.509_sd] [gemverw_zert_ti] 2.5 Abgrenzung des Dokumentes Das Dokument stellt eine Schnittmenge verschiedener Dokumente dar. Detaillierte Vorgaben für die Prüfung von Zertifikaten werden in der Konnektorspezifikation [gemspec_kon] und dem Dokument Verwendung von Zertifikaten in der Telematikinfrastruktur [gemverw_zert_ti] getroffen. Die Abläufe zur Prüfung innerhalb der Telematikinfrastruktur werden in der Gesamtarchitektur [gemgesarch] festgelegt. Die Vorgaben für CV-Zertifikate und für den Aufbau von LDAP-Verzeichnisdiensten erfolgen in gesonderten Dokumenten. Das Dokument trifft keine Vorgaben für die Prüfung qualifizierter Zertifikate, hierfür sind die spezifischen Policies der Berufsständischen Organisationen, welche HBAs herausgeben, und das Verhalten der jeweiligen OCSP-Responder der ZDA in Verbindung mit [gemverw_zert_ti] maßgeblich. Die Vorgaben für CV-Zertifikate und für den Aufbau von LDAP-Verzeichnisdiensten erfolgen in gesonderten Dokumenten. 2.6 Verwendung von Schüsselworten Für die genauere Unterscheidung zwischen normativen und informativen Inhalten werden die dem RFC 2119 [RFC2119] entsprechenden in Großbuchstaben geschriebenen, deutschen Schlüsselworte verwendet: MUSS bedeutet, dass es sich um eine absolutgültige und normative Festlegung bzw. Anforderung handelt. gematik_pki_verzeichnisdienstkonzept.doc Seite 8 von 44

9 DARF NICHT bezeichnet den absolutgültigen und normativen Ausschluss einer Eigenschaft. SOLL beschreibt eine Empfehlung. Abweichungen zu diesen Festlegungen sind in begründeten Fällen möglich. SOLL NICHT kennzeichnet die Empfehlung, eine Eigenschaft auszuschließen. Abweichungen sind in begründeten Fällen möglich. KANN bedeutet, dass die Eigenschaften fakultativ oder optional sind. Diese Festlegungen haben keinen Normierungs- und keinen allgemeingültigen Empfehlungscharakter. gematik_pki_verzeichnisdienstkonzept.doc Seite 9 von 44

10 3 Technische Grundlagen 3.1 Online Certificate Status Protocol Das Online Certificate Status Protocol (OCSP) ist ein Protokoll, welches die Statusabfrage eines Zertifikates ermöglicht. Das OCSP wurde durch die PKIX Arbeitsgruppe IETF als Standard (RFC 2560) definiert. Es stellt ein einfaches Request-Response-Protokoll dar, welches auf einem beliebigen Transportprotokoll aufsetzt. Hierbei richtet der OCSP-Client eine spezifische Anfrage an den OCSP-Responder, um zu prüfen, ob das entsprechende Zertifikat bekannt ist und nicht zwischenzeitlich gesperrt wurde. Dieser OCSP-Responder nimmt die Anfrage des Client entgegen und beschafft sich dann die Sperrinformation des spezifischen Zertifikats. Dem Client werden die Antworten "good", "revoked" oder "unknown" übermittelt. Im Unterschied zum CRL Mechanismus kann die Statusüberprüfung serverbasiert in Echtzeit vorgenommen werden. Das zeitnahe Sperren mit CRLs würde bedeuten, dass in sehr kurzen Abständen eine neue CRL erstellt und verteilt werden müsste. Dieses ist nicht praktikabel und belastet die Infrastruktur enorm. Bei der Abfrage per OCSP muss der Client keine Sperrliste herunter laden. Eine Statusauskunft (z. B. Zertifikat vorhanden und nicht gesperrt oder vorhanden und seit :42:00 Uhr gesperrt ) ist eine elektronisch signierte Nachricht. Ein OCSP-Responder kann seine Informationen über verschiedene Quellen, wie der internen CA-Datenbank, OCSP, LDAP oder CRL beziehen. 3.2 Kodierung des OCSP Zur Definition der Datenstrukturen des Protokolls OCSP wird die Abstract Syntax- Notation 1 (ASN.1) eingesetzt. ASN.1 definiert lediglich die abstrakte Darstellung von Daten und dient der plattformunabhängigen Definition von Datenstrukturen. Um diese abstrakte Darstellung von Daten tatsächlich verschicken zu können, müssen sie kodiert werden. Im Zusammenhang mit Zertifikaten wird die Kodierungsregel Distingueshed- Encoding-Rules (DER) verwendet Request Die Anfrage (Request) des OCSP-Clients soll das zu prüfende Zertifikat eindeutig identifizieren. Ein Zertifikat kann eindeutig durch die Angabe des Zertifikatsausstellers und der Seriennummer des Zertifikats gekennzeichnet werden. Die Anfrage besteht aus den Angaben selbst und einem Anfrageblock mit dem Zertifikat bzw. dessen Zertifikatsbezeichnern. Dem Zertifikat respektive der Zertifikatsanfrage können Erweiterungen angefügt werden. Zur Authentisierung des Clients kann die Anfrage signiert werden. Der OCSP-Responder MUSS auch signierte Requests nach [RFC2560] beantworten. Zur Gewährleistung der Performance KANN der OCSP-Responder signierte gematik_pki_verzeichnisdienstkonzept.doc Seite 10 von 44

11 Requests wie unsignierte Requests behandeln und die Signaturprüfung der Requests entfallen lassen. Eine Anfrage an den OCSP-Server enthält folgende Daten: Protokollversion Art des Services für den Request ein Zertifikatsbezeichner zusätzliche Erweiterungen zum Zertifikat und Erweiterungen je Anfrage (optional den technischen Namen des Anfragenden) eine optionale Signatur der Anfrage Eine Anfrage MUSS sich auf ein einzelnes Zertifikat beziehen. Zwar unterstützt das OCSP die Anfrage mehrerer Zertifikate, dies kann jedoch zu folgenden Problemen führen: Bei Anfragen mehrerer Zertifikate in einem OCSP-Request müssten lt. Protokoll bzw. Definition in [RFC2560] alle Antworten in einer einzigen OCSP-Response zusammengefasst und signiert werden. Dazu müssten dann alle Antworten von ein- und demselben OCSP-Responder kommen. Da insbesondere hinsichtlich der zu erwartenden Mengengerüste und Antwortzeiten die TSPs mit verteilten OCSP-Respondern arbeiten können (z. B. über virtuelle Responder und/oder per Loadbalancing), kann nicht sichergestellt sein, dass wirklich EIN Responder die Antworten signiert. Ein Responder antwortet wenn die Anfrage "well formed", also spezifikationskonform formuliert ist und der Responder für diesen Service konfiguriert ist. gematik_pki_verzeichnisdienstkonzept.doc Seite 11 von 44

12 Abbildung 1: Struktur der OCSP Anfrage Response Alle definitiven Antworten (responses) müssen vom OCSP-Server digital signiert werden. Im Wesentlichen besteht eine Response aus: Version der Response Syntax Name des Responders Antwort auf das Zertifikat in einem Request Algorithmusverfahren der Signatur (OID) Signatur über den Hash der Response Die Response für das Zertifikat besteht aus: eindeutige Kennzeichnung des Zertifikats, Status des Zertifikats (good, revoked, unknown), Gültigkeitsintervall der Response und optionalen Erweiterungen gematik_pki_verzeichnisdienstkonzept.doc Seite 12 von 44

13 Abbildung 2: Struktur der OCSP-Antwort 3.3 Zertifikatsstatus Die OCSP-Antwort (Response) gibt den Status eine Zertifikats mit einem der drei Werte "good", "revoked", "unknown" zurück. Insbesondere wird die durch "notbefore und "notafter" angegebene Gültigkeitsdauer eines Zertifikats von OCSP nicht überprüft. OCSP geht davon aus, dass dem Zertifikatsprüfer (Client) alle Informationen außer dem Zertifikatsstatus bereits vorliegen. Aus dem Ergebnis der Pfadvalidierung (die durch eine Komponente wie z. B. dem Konnektor unter Verwendung der TSL durchgeführt wird) ergibt sich, ob ein Zertifikat von einer zugelassenen CA ausgestellt wurde. good: Der Zustand good sagt aus, dass zum Zeitpunkt thisupdate das Zertifikat nicht gesperrt war. Good sagt aber nichts über die Gültigkeitsdauer und Existenz des Zertifikates aus. Es könnte bedeuten, dass das Zertifikat regulär abgelaufen ist und deshalb nicht auf einer CRL- oder CA-Datenbank aufgeführt ist. In diesem Fall kommt auf die Anfrage ein good zurück, auch wenn das Zertifikat nicht mehr gültig ist. Der Client überprüft jedoch dieses Ablaufdatum im Zusammenhang mit der Zertifikatsvalidierung. Über OCSP oder CRL wird lediglich der Status des Zertifikates abgefragt. Die genaue Interpretation des Zustandes ist der Tabelle 2 zu entnehmen. revoked Der Zustand revoked sagt aus, dass das Zertifikat von der zugehörigen Zertifizierungsstelle ausgestellt wurde, dem OCSP-Server bekannt ist und temporär oder endgültig gesperrt ist. Falls ein revoked-zustand vorliegt, wird der Sperrzeitpunkt im gematik_pki_verzeichnisdienstkonzept.doc Seite 13 von 44

14 Teilfeld revocationtime und optional der Sperrgrund im Teilfeld revocationreason der Struktur RevokedInfo abgelegt. unknown Diese Antwort bedeutet, dass der OCSP-Responder das nachgefragte Zertifikat nicht kennt. Entweder ist dieser von der entsprechenden CA nicht für die Beantwortung von Statusabfragen autorisiert, oder es können keine Informationen zu dem Zertifikat gefunden werden. Es kann auch sein, dass ein CRL-basierter OCSP-Responder keine gültige CRL vorfand. Falls ein unknown Zustand vorliegt, so muss im Feld certid der Struktur SingleResponse der Inhalt des certid-feld in der Struktur Request der Anfrage wiederholt werden. Exception Case Tritt kein Fehler auf, so beinhaltet das Feld Status den Wert successful. Im Falle eines Fehlers erscheinen Werte wie malformedrequest, internalerror, trylater, sigrequired oder unauthorized. In der folgenden Tabelle sind alle Ergebnisse aufgelistet. Der Exception Case sigrequired DARF NICHT vom OCSP- Responder verwendet werden. Tabelle 2: OCSP Festlegungen Ergebnis Anfrage successful malformed Request internalerror trylater unauthorized sigrequired Bedeutung Erfolgreiche Bearbeitung einer Anfrage Wegen fehlerhaftem Anfrageformat konnte keine erfolgreiche Bearbeitung der Anfrage erfolgen. Auftretung eines internen Fehlers beim OCSP-Server Nicht-Verfügbarkeit des OCSP-Servers (temporär) Der Client ist nicht berechtigt Der OCSP-Server fordert explizit, dass die Anfrage vom Client signiert werden muss 3.4 Zeiten in einer OCSP-Response Die Antwort eines OCSP-Servers kann folgende Zeiten beinhalten: thisupdate, nextupdate, producedat, revocationtime und certindirsince thisupdate: Die Komponente thisupdate enthält den Zeitpunkt, für den die gemachte Aussage gültig ist. Es zeigt sozusagen den aktuellen Zeitpunkt zu der die Sperrinformationen erstellt wurden an. Beim OCSP-Dienst stimmt dieser Zeitpunkt mit dem Zeitpunkt producedat überein. OCSP-Antworten, deren thisupdate Zeitpunkt nach der lokalen Systemzeit liegt, sollen als ungültig erachtet werden. Es liegt im Ermessen des Client, wie weit dieser Zeitpunkt zurückliegen darf. gematik_pki_verzeichnisdienstkonzept.doc Seite 14 von 44

15 nextupdate: Die Komponente nextupdate enthält einen Hinweis, wann die Information, auf der die Antwort basiert, erneuert wird. Dieses schließt nicht aus, dass schon früher aktuellere Auskünfte erteilt werden können. Spätestens nachdem der Zeitpunkt nextupdate verstrichen ist, soll eine neue Anfrage gestellt werden. Dieser Zeitpunkt ist nur für OCSP Antworten sinnvoll, die auf CRLs basieren. Beim reinen Online-Dienst stimmt dieser Zeitpunkt immer mit dem Zeitpunkt thisupdate überein. Der Zeitpunkt nextupdate kann in der Zukunft liegen, sofern die Antwort auf einer Sperrliste mit einem festgelegtem Gültigkeitszeitraum basiert. OCSP-Antworten, die keinen nextupdate Zeitpunkt enthalten, zeigen an, dass jederzeit neuere Statusinformationen zu Zertifikaten vorhanden sein können. producedat: Der Zeitpunkt der Erzeugung und Signierung einer OCSP-Response wird in producedat gesondert vermerkt. Als Kontrolle KANN überprüft werden, ob producedat vor der lokalen Systemzeit liegt. Der Zeitpunkt darf nicht DARF NICHT in der Zukunft liegen. Hierbei sind Abweichungen unterhalb einer Toleranzkonstante, die im Rahmen der betrieblichen Anforderungen noch festzulegen ist, nicht zu berücksichtigen. revocationtime: Die Komponente revocationtime gibt bei einem gesperrten Zertifikat den Zeitpunkt an, zu dem die Sperrung aktiv wurde, das heißt, dass der Sperreintrag gemacht wurde und über den OCSP-Server für die Nutzer des Gesamtsystems verfügbar war. certindirsince: Der Zeitpunkt certindirsince wurde eingeführt, um folgenden Sonderfall abzufangen: Ein Zertifikat wird in den Verzeichnisdienst eingestellt, wobei der Zeitpunkt der Einstellung in den Verzeichnisdienst nach dem Beginn des Gültigkeitszeitraumes des Zertifikates liegt. Anfragen zu einem Zertifikat vor der Einstellung in den Verzeichnisdienst würden mit ungültig beantwortet werden (Antwort Zertifikat nicht vorhanden ). Anfragen zu diesem Zertifikat nach der Einstellung würden mit Zertifikat vorhanden seit und nicht gesperrt beantwortet werden. Um diese widersprüchlichen Antworten klären zu können, wurde die spezifische Erweiterung certindirsince eingeführt, die den Zeitpunkt enthält, seit dem das Zertifikat im Verzeichnis vorhanden ist. gematik_pki_verzeichnisdienstkonzept.doc Seite 15 von 44

16 3.5 Strukturen der Dienste Public-Key-Verfahren mit X.509-Zertifikaten bilden die Basis für die vielfältigen Schutzmechanismen der Telematikinfrastruktur. Die nachfolgende Graphik verdeutlicht die Gesamtheit der verwendeten Zertifikate. Abbildung 3: Gesamtheit der Zertifikate Da in der Gesamtarchitektur [gemgesarch] verpflichtend festgelegt ist, dass der Herausgeber eines Zertifikats auch die Bereitstellung der Prüfinformation mindestens über die gesamte Zertifikatslebensdauer sicherstellen muss, lassen sich analog zu den drei Domänen von Herausgebern (Kostenträger, Leistungserbringer und gematik) auch die Verantwortlichkeiten für den Betrieb der OCSP-Responder zuordnen. Verzeichnisdienste via LDAP sind nur dann erforderlich, wenn Verschlüsselungszertifikate oder Berechtigungsattribute anhand spezifischer Identitätsmerkmale gesucht werden sollen. Hierfür existiert nach derzeitiger Festlegung nur bei den personen- und organisationsbezogenen Zertifikaten der Heilberufler und deren Organisationen Bedarf. Daher wurde in dieser Version des Dokuments auf die nähere Festlegung der LDAP- Strukturen verzichtet. Ein Dokument zu den übergreifenden Suchdiensten für Identitäten ist derzeit in Vorbereitung. gematik_pki_verzeichnisdienstkonzept.doc Seite 16 von 44

17 3.6 Zuordnung der Dienste Abbildung 4: Zuordnung der Dienste Die Graphik erläutet die Integration der Root- und CA-Zertifikate in die zentrale Trustservice Status List der gematik. Hierdurch wird die Zulassung zur Herausgabe von X.509- Zertifikaten für die Telematikinfrastruktur technisch abgebildet. Eine zentrale Infrastruktur zur Gültigkeitsprüfung von Zertifikaten via OCSP wird nach dem gleichen Schema, aber in umgekehrter Richtung, abgebildet. Die dezentral aufgestellten und in der Verantwortung der jeweiligen Zertifikatsherausgeber betriebenen OCSP-Server könnten direkt mittels der im jeweiligen Zertifikat enthaltenen OCSP- Adresse angesprochen werden. Maßgeblich für die Zertifikatsprüfungen innerhalb der Telematikinfrastruktur ist die in der TSL bzw. TCL angegebene OCSP-Adresse. gematik_pki_verzeichnisdienstkonzept.doc Seite 17 von 44

18 4 Technische Festlegungen zu den OCSP-Diensten 4.1 Statusabfrageüberprüfung für Zertifikate In der Telematikinfrastruktur MUSS jeder TSP Informationen über durch ihn signierte und widerrufene Zertifikate zur Verfügung stellen. Hierdurch wird es möglich, einzelne Zertifikate sowie alle durch einen TSP signierten Zertifikate zu sperren, sofern dies notwendig ist. Jedes Zertifikat MUSS die Adresse des zugehörigen OCSP-Responders enthalten. Innerhalb der Telematik MÜSSEN Statusabfragen für Zertifikate immer durch das Online Certificate Status Protokoll durchgeführt werden. Daher muss jeder TSP einen OCSP- Responder für die durch ihn signierten Zertifikate anbieten. Dies bietet den Vorteil, dass zwar für ein gegebenes Zertifikat der Status abgefragt werden kann, jedoch wird die Information über gesperrte Zertifikate nicht unnötig verteilt. Perspektivisch kann aus Gründen der Skalierbarkeit die Verwendung von Certificate Revocation Lists zur Verifizierung von nicht qualifizierten Signaturen vorgegeben werden. Die Adresse des zugehörigen OCSP-Responders und des optionalen CRL-Providers ist für jede CA in dem entsprechenden TSL-Eintrag enthalten. Der für OCSP maßgebliche RFC [RFC2560] schreibt vor, dass die Auskunft zum Status eines Zertifikates zum Anfragezeitpunkt durch den OCSP-Responder signiert wird. Aus Performanzgründen werden insbesondere für die OCSP-Responses qualifizierter Zertifikate in Anhang A Optimierungen empfohlen, wie z. B. OCSP Response Caching durch Requestor und Clients. Die Algorithmen und Parameter für die OCSP-Signaturzertifikate werden in dem Dokument [gemspec_krypt] festgelegt. Eine Ausnahme bilden die zentralen VPN-Konzentratoren der TI, die Gültigkeit dieser Komponentenzertifikate wird über CRL (gemäß ISIS-MTT Part 4) geprüft. 4.2 Gültigkeitsmodell Für Prüfung der Zertifikatsgültigkeit MUSS das PKIX-Modell (RFC 2459 mit RFC 2560), so wie es in der COMMON-PKI V.1.1 Core-Spec beschrieben ist, verwendet werden. Eine Ausnahme gilt für den Bereich der qualifizierten Zertifikate, hierfür sind die spezifischen Policies der berufsständischen Organisationen, welche HBAs herausgeben, und das Verhalten der jeweiligen OCSP-Responder der ZDA maßgeblich. [BÄK_GUELT] Somit ist zu berücksichtigen, dass bei der Verwendung von nicht-qualifizierten und qualifizierten X.509-Zertifikaten zwei unterschiedliche Gültigkeitsmodelle (PKIX versus Kettenmodell) zur Zertifikatsprüfung zu implementieren sind. Die Vorgaben für CV-Zertifikate und für den Aufbau von LDAP-Verzeichnisdiensten erfolgen in gesonderten Dokumenten. gematik_pki_verzeichnisdienstkonzept.doc Seite 18 von 44

19 4.3 Festlegungen zu den OCSP-Zertifikatsprüfungen Die nachfolgenden grundsätzlichen OCSP-relevanten Anforderungen sind in der Gesamtarchitektur [gemgesarch] und der Konnektorspezifikation [gemspec_kon#tab2] und [gemverw_zert_ti#9.3] umfassend definiert. und werden hier wiedergegeben. Weitergehende Festlegungen werden in den jeweiligen Fachdokumenten z. B. [gemx.509_sd#7] getroffen. OCSP [RFC2560] MUSS als primäres Verfahren zur Statusprüfung für Zertifikate unterstützt werden, auch im Falle von Zertifikaten, die nicht qualifizierte Signaturzertifikate sind (z.b. Zertifikate für Authentifizierung, Verschlüsselung oder das OSIG der Institutionskarte). Der Certificate Validation Basisdienst des Konnektors MUSS die Validierung von Zertifikaten entsprechend ISIS MTT Specification, Part 5 Certificate Path Validation [COMMON- PKI] mit den folgenden zusätzlichen Festlegungen unterstützen. Die Statusprüfung mittels OCSP ist nur auf das Nutzerzertifikat anzuwenden, nicht auf CA-Zertifikate. Für die Prüfung qualifizierter Signaturzertifikate MUSS der Certificate Validation Basisdienst das COMMON-PKI Specification Optional Profile SigG-Profile unterstützen [COMMON-PKI] P1. Dies bedeutet insbesondere für Statusabfragen, dass der Status unknown erkannt wird (am Fehlen der CertHash Extension in der OCSP-Response) und dass in diesem Falle das Zertifikat als ungültig angesehen wird. Quelle aller für den Konnektor vertrauenswürdigen Root- und CA-Zertifikate für die bei der Validierung notwendige Bildung des Zertifikatspfades ist die TSL (Trusted-Service-Status List) der gematik. Der Konnektor MUSS diese vorhalten und regelmäßig (entsprechend den Vorgaben für die TSL, siehe [gemtsl_sp_cp] und [ETSI-TSL]) aktualisieren. Aufgrund der Offline-Funktionsabschnitte MUSS es auch möglich sein, die Aktualisierung über die Managementschnittstelle des Konnektors vorzunehmen. Dabei MUSS der Konnektor sicherstellen, dass eine TSL nicht durch eine ältere Version überschrieben werden kann. Der Konnektor darf die Änderungen der TSL nur akzeptieren, nachdem er die Signatur der TSL geprüft hat. Signaturzertifikat bzw. dessen Root-Zertifikat müssen dem Konnektor als vertrauenswürdige Sicherheitsanker bekannt sein. Die Sicherheitsanker für die TSL-Prüfung (Root-Zertifikat bzw. Signaturzertifikat) MÜSSEN in die Integritätsprüfung des Konnektors einbezogen werden und so vor Manipulation geschützt werden. Die Sicherheitsanker für die TSL-Prüfung MÜSSEN im Rahmen der Software- Aktualisierung rechtzeitig vor Ablauf ihrer Gültigkeit aktualisiert werden. Die neuen Sicherheitsanker sind hierbei wie andere Software Updates durch Signaturen integritätsgeschützt, die sich mit Hilfe der noch gültigen Sicherheitsanker im Konnektor verifizieren lassen. Für OCSP-Anfragen MÜSSEN die in der TSL angegebenen Informationen über zuständige OCSP-Responder verwendet werden. Falls der ausstellende TSP nicht in der TSL enthalten ist, so ist das Zertifikat nicht als von einem von der gematik zugelassenen TSP ausgestellt zu betrachten. gematik_pki_verzeichnisdienstkonzept.doc Seite 19 von 44

20 Der Certificate Validation Basisdienst MUSS es auch ermöglichen, eine Validierungsanfrage zu bearbeiten, die nur eine Zertifikatsreferenz anstatt des Zertifikats enthält. Der Certificate Validation Basisdienst MUSS dazu die Zertifikatsreferenz auflösen. Bieten OCSP-Responder die Möglichkeit, das Zertifikat in ihrer Antwort mitzuliefern (Extension RetrieveIfAllowed in der Anfrage und Extension RequestedCertificate im Response), so MUSS der Certificate Validation Basisdienst davon Gebrauch machen, um somit einen zusätzlichen Server-Round-Trip zum Verzeichnisdienst zu vermeiden. Der Konnektor KANN das Ergebnis der Prüfung eines (nicht qualifizierten) Zertifikates bis zu einem Tag lang cachen. Liegt ein gecachtes Ergebnis vor, so liefert der Konnektor es sofort zurück, anstatt eine erneute Prüfung durchzuführen. Beim Cachen der Ergebnisse von Zertifikatsprüfungen MUSS der Konnektor seinen Online-/Offline-Status berücksichtigen. Wird ein Zertifikat im Offline-Zustand geprüft, so MUSS das gecachte Ergebnis verworfen werden, wenn der Konnektor in den Online-Zustand wechselt und der Zeitpunkt in nextupdate überschritten ist. Es liegt im Ermessen der jeweiligen Anwendung, wie dann mit dieser ggf. neuen Auskunft umzugehen ist. Die nachfolgende Tabelle stellt die Bedeutung der OCSP-Responses überblickartig im Kontext der Zertifikatsdomänen dar. Tabelle 3: Spezifische Bedeutung der OCSP-Responses Status Domäne Beschreibung good egk, SMC-B Der Zustand good sagt aus, dass zum Zeitpunkt thisupdate das Zertifikat nicht gesperrt war. Good sagt aber nichts über die Gültigkeitsdauer und Existenz des Zertifikates aus. Es kann bedeuten, dass das Zertifikat regulär abgelaufen ist und deshalb nicht auf einer CRL- oder CA- Datenbank aufgeführt ist. In diesen Fall kommt auf die Anfrage ein good zurück, auch wenn das Zertifikat nicht mehr gültig ist. Der Client überprüft jedoch dieses Ablaufdatum im Zusammenhang mit der lokalen Zertifikatsvalidierung. Über OCSP oder CRL wird lediglich der Status des Zertifikates abgefragt. revoked egk, SMC-B Der Zustand revoked sagt aus, dass das Zertifikat von der zugehörigen Zertifizierungsstelle ausgestellt wurde, dem OCSP-Server bekannt ist und temporär oder endgültig gesperrt ist. Falls ein revoked-zustand vorliegt, wird der Sperrzeitpunkt im Teilfeld revocationtime und optional der Sperrgrund im Teilfeld revocationreason der Struktur RevokedInfo abgelegt. unknown egk, SMC-B Diese Antwort bedeutet, dass der OCSP-Responder das nachgefragte Zertifikat nicht kennt. Entweder ist er von der entsprechenden CA nicht für die Beantwortung von Statusabfragen autorisiert, oder es können keine Revokationsinformationen zu dem Zertifikat gefunden werden. Es kann auch sein, dass der CRL-basierte OCSP-Responder keine gültige CRL vorfand. Falls ein unknown Zustand vorliegt, so muss im Feld certid der Struktur SingleResponse der Inhalt des certid-feld in der Struktur Request der Anfrage wiederholt werden. good SM-K Vorbedingung: Der TSP muss über die Durchführung des gematik_pki_verzeichnisdienstkonzept.doc Seite 20 von 44

21 Status Domäne Beschreibung Freischaltens bei Inbetriebnahme des Konnektors informiert werden. Dabei müssen der Inbetriebnehmende sowie das freigeschaltete Komponentenzertifikat sicher eindeutig identifiziert und authentifiziert werden. Erst danach darf eine Statusabfrage zu dem Komponentenzertifikat durch den OCSP-Responder mit dem Zertifikatstatus good beantwortet werden. Vorher muss unknown ausgegeben werden. Das Zertifikat ist vorhanden und nicht gesperrt. Als Nachweis dafür muss der OCSP-Responder den Hashwert des Public Keys des Zertifikats liefern. revoked SM-K siehe oben bei egk, SMC-B unknown SM-K good Zentrale Dienste und Fachdienste revoked Zentrale Dienste und Fachdienste unknown Zentrale Dienste und Fachdienste good Konzentrator revoked Konzentrator unknown Konzentrator good System- und revoked Service-Mgmt. System- und Service-Mgmt. unknown System- und Service-Mgmt. siehe oben bei egk, SMC-B oder nicht freigeschaltet. Vorbedingung: Der TSP muss über die Durchführung des Freischaltens durch den Dienstbetreiber informiert werden. Dabei müssen der Dienstbetreiber sowie das freigeschaltete Dienstzertifikat sicher eindeutig identifiziert und authentifiziert werden. Erst danach darf eine Statusabfrage zu dem Komponentenzertifikat durch den OCSP-Responder mit dem Zertifikatstatus good beantwortet werden. Vorher muss unknown ausgegeben werden. Das Zertifikat ist vorhanden und nicht gesperrt. Als Nachweis dafür muss der OCSP-Responder den Hashwert des Public Keys des Zertifikats liefern. siehe oben bei egk, SMC-B siehe oben bei egk, SMC-B oder nicht freigeschaltet. entfällt - hier wird die Gültigkeit über CRL geprüft entfällt - hier wird die Gültigkeit per White-List geprüft gematik_pki_verzeichnisdienstkonzept.doc Seite 21 von 44

22 5 Funktionale Anforderungen an OCSP Responder Dieses Kapitel beschreibt die funktionale Spezifikation der OCSP-Responder für die PKI der elektronischen Gesundheitskarte. Die Spezifikation muss von den für die TSL zugelassenen TSP implementiert werden, um die Zertifikate nachprüfbar und ggf. abrufbar zu halten. Die funktionalen Anforderungen in der Test- und Pilotierungsphase unterscheiden sich nicht von denen der Wirkbetriebsphase. 5.1 Grundsätze Alle Zertifikate MÜSSEN nachgeprüft werden können. Die Nachprüfbarkeit der Zertifikate wird über das OCS-Protokoll realisiert. Qualifizierte Signatur- und Attributzertifikate werden über OCSP-Responder soweit zulässig abrufbar und (stets) nachprüfbar gehalten. Der OCSP-Responder MUSS über das VPN der Telematikinfrastruktur erreichbar sein Es gibt über die verschiedenen TSP hinweg keine zentrale Datenhaltung oder zentrale OCSP-Responder für Endnutzerzertifikate. Jeder TSP betreibt seine eigenen OCSP- Responder, ggf. getrennt für qualifizierte und nicht-qualifizierte Zertifikate. Die Adresse des zuständigen OCSP-Responders für die Überprüfung eines Zertifikates ist im Zertifikat selbst (Extension AuthorityInfoAccess) und in der TSL der gematik enthalten. 5.2 Struktur des öffentlichen Verzeichnisdienstes Eine prüfende Applikation muss das Zertifikat bzw. die relevanten Teile davon haben, dessen Status es erfahren möchte. Die Information, welcher OCSP-Responder für das Zertifikat anzufragen ist, ist in der AuthorityInfoAccess -Extension im Zertifikat und in der TSL enthalten. In der Gesamtarchitektur [gemgesarch] ist festgelegt, dass die TSL hierbei die primäre Informationsquelle ist. Es ist zulässig für die Nachprüfbarkeit und ggf. Abrufbarkeit von nicht-qualifizierten Zertifikaten, ein HSM für die Signatur der OCSP-Responses zu verwenden. Die Anforderungen hierfür werden in der jeweiligen für das Zertifikat gültigen Policy definiert. [CP-HPC] [gemtsl_sp_cp]. Der TSP ist für die Sicherheit eines HSM-betriebenen OCSP-Servers verantwortlich und muss dies gegenüber der gematik erklären. Die gematik stellt die TSL als Teil einer -Architektur bereit. Diese sind auch dafür geeignet, eine Zuordnung zwischen OCSP-Responder und Issuer-Zertifikat herzustellen. Die Clientsoftware kann z. B. die aus dem erezept erhaltene Information des IssuerDN benutzen, um aus der hinterlegten TSL den zugehörigen OCSP-Responder des entsprechenden TSP zu identifizieren. Mittels der im erezept enthaltenen (Zertifikats-) Seriennummer wird sodann eine OCSP-Anfrage an den benannten Responder gestellt. Dieser liefert mit der OCSP-Response das zugehörige Zertifikat an den Client. gematik_pki_verzeichnisdienstkonzept.doc Seite 22 von 44

23 Der OCSP-Responder MUSS konform zur COMMON-PKI-Spezifikation v1.1 Core sein. Bei der Prüfung qualifizierter Zertifikate akkreditierter Zertifizierungsdiensteanbieter SOLL auch das SigG-Profil inkl. optionaler Erweiterungen berücksichtigt werden. Die Algorithmen und Parameter für die OCSP-Signaturzertifikate werden in dem Dokument [gemspec_krypt] festgelegt. 5.3 Verfügbarkeit des OCSP-Responders Der OCSP-Dienst wird für die Gültigkeitsprüfung der Authentisierungs- und Signaturzertifikate eingesetzt und unterliegt damit im Wirkbetrieb sehr hohen Verfügbarkeitsanforderungen. Die Verfügbarkeit von Computersystemen wird meist in "Dauer Downtime pro Jahr" gemessen und in Prozent angegeben. Die Harvard Research Group (HRG) teilt Hochverfügbarkeit in ihrer Availability Environment Classification (kurz: AEC) in sechs Klassen ein. [HRG] Die Details werden zwischen den Verantwortlichen des jeweiligen Sektors und dessen beauftragten Dienstleister in Service-Level-Agreements festgelegt. Stellt der Betreiber den Betrieb ein, so MÜSSEN Maßnahmen zur Sicherstellung der Verfügbarkeit der Prüfinformationen gemäß der relevanten Policies getroffen werden. Dazu gehören auch die Netzadressen, über die die Statusabfragen an den OCSP- Responder gestellt werden können. Durch die Flexibilität des TSL-Konzeptes ist es bei Betriebseinstellung auch möglich, die Prüfpfade zu OCSP-Respondern abweichend von der im Zertifikat angegebenen Adresse zu gestalten, so dass ein anderer Betreiber den Zertifikatsdienst fortführen kann. Der OCSP-Dienst MUSS die Prüfinformation für mindestens drei Jahre nach Ablauf oder Sperrung hinaus online bereitstellen. mindestens über die gesamte Zertifikatslebensdauer sicherstellen. Für qualifizierte bzw. qualifizierte Zertifikate akkreditierter Anbieter gelten die entsprechenden gesetzlichen Vorgaben. Testzertifikate sind hiervon nicht betroffen. Neben der Verfügbarkeit des Responders MUSS auch die Erreichbarkeit aus allen Bereichen der Telematikinfrastruktur (Konnektor, Broker, Audit, Fachdienst) aus sichergestellt sein. Nähere Festlegungen dazu sind in der Gesamtarchitektur [gemgesarch] getroffen. Die Details werden ebenfalls zwischen den Verantwortlichen des jeweiligen Sektors und dessen beauftragten Dienstleister in Service-Level-Agreements festgelegt. gematik_pki_verzeichnisdienstkonzept.doc Seite 23 von 44

24 5.4 Syntax von OCSP gemäß COMMON-PKI Part 4 [Verbindlich ist die aktuelle Version, jeweils unter [COMMON-PKI] zu beziehen.] Folgende Änderungen, abweichend von [COMMON-PKI] werden durch die gematik festgelegt: In den Tabellen 4 und 7 wird der Bezug entfernt, der erlaubt, dass in einem OCSP-Request mehrere Zertifikate abgefragt werden dürfen (s. Abschnitt 3.2.1) In Tabelle 5 wird MD5 und Ripe-MD ausgeschlossen und SHA-256 als SHOULD definiert. BasicOCSPResponse, that MUST be supported by all PKIX-conforming clients and responders. Tabelle 4 COMMON-PKI Syntax # ASN.1 Definition Semantics 1 OCSPRequest ::= SEQUENCE { 2 tbsrequest TBSRequest, 3 optionalsignature [0] EXPLICIT Signature OPTIONAL } 4 TBSRequest ::= SEQUENCE { The requestor MAY sign the DERencoding of this to be signed part of the data structure. Support References Gen Proc Rfc Table Not es #3 [1] The optional signature of the requestor #10 [1] 5 version [0] EXPLICIT OCSPVersion DEFAULT v1, Version number of the OCSP protocol # requestorname [1] EXPLICIT GeneralName OPTIONAL, Name of the requestor RFC P1.T8.# 2 [1] gematik_pki_verzeichnisdienstkonzept.doc Seite 24 von 44

25 # ASN.1 Definition Semantics 7 requestlist SEQUENCE OF Request, Support References Gen Proc Rfc2560 Table List of single status requests T6 [2] 8 requestextensions [2] EXPLICIT Extensions OPTIONAL } OCSPRequest extensions RFC OCSPVersion ::= INTEGER { v1(0) } 10 Signature ::= SEQUENCE { 11 signaturealgorithm AlgorithmIdentifier, 12 signature BIT STRING, 13 certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } An identifier of the signature algorithm used by the requestor to sign the request The signature of the requestor Certificates that are relevant for the verification of the signature T9, P1.T9 Not es [1] RFC P1.T [1] [1] [RFC2560]: The requestor MAY choose to sign the request message, e.g. when the responder requires an authentication of users. In this case, the requestor MUST specify its name in the requestorname field (#6) and MAY include certificates in the certs field (#13) that help the responder to verify the signature. COMMON-PKI PROFILE: If the requestor chooses to sign the request message, requestorname MUST contain a directoryname with the subject DName of the signer s certificate. Alternative names MAY additionally be inserted. So that the request can be validated, certs SHOULD contain all certificates of a certificate path, but MUST at least contain the requestor s signing certificate. Responders may choose not to verify the signature, if the OCSP service is publicly available. [2] COMMON-PKI PROFILE: the list MUST contain exactly one single request. gematik_pki_verzeichnisdienstkonzept.doc Seite 25 von 44

26 Tabelle 5: COMMON-PKI Request # ASN.1 Definition Semantics 1 Request ::= SEQUENCE { 2 reqcert CertID, 3 singlerequestextensions [0] EXPLICIT Extensions OPTIONAL } 4 CertID ::= SEQUENCE { 5 hashalgorithm AlgorithmIdentifier, 6 issuernamehash OCTET STRING, 7 issuerkeyhash OCTET STRING, 8 serialnumber CertificateSerialNumber } Uniquely identifies the certificate being requested Support References Gen Proc Rfc2560 Table (Single) Request extensions RFC2459 Uniquely identifies the certificate being requested by identifying the public key (not certificate!) of its issuer and its serial number. Hash algorithm to build hash values below Hash of issuer s DER-encoded DName, as it occurs in the certificate being requested Hash of the DER-encoded public key of the issuer of the certificate being requested. Calculated over the public key (excluding tag, length and unused bits in the BIT STRING representation). Serial number of the certificate being requested RFC RFC2459 #4 T9, P1.T9 Not es P1.T4 [1] [1] COMMON-PKI PROFILE: The hash values in certid MUST be built using SHA-1. Processing components (typically the responder) MUST support SHA-1 and SHOULD support SHA P1.T2 [2] gematik_pki_verzeichnisdienstkonzept.doc Seite 26 von 44

27 # ASN.1 Definition Semantics Support References Gen Proc Rfc2560 Table [2] RFC2560: The hash of the public key is included here, so that the issuer can be identified even in the case, when DNames of two different CAs are accidentally identical. Not es Tabelle 6 OCSP Response # ASN.1 Definition Semantics Support References Gen Proc Rfc OCSPResponse ::= SEQUENCE { #4 2 responsestatus OCSPResponseStatus, Processing status of the request 3 responsebytes [0] EXPLICIT ResponseBytes OPTIONAL } Response data is returned here, if the request be successfully processed Table #12 4 OCSPResponseStatus ::= ENUMERATED { successful (0), Response has valid confirmation malformedrequest (1), Illegal request format, not conforming to the OCSP syntax internalerror (2), The OCSP responder reached an inconsistent internal state. The query should be retried, potentially with another responder. 8 trylater (3), The OCSP responder is in operational status, but temporarily unable to return a status. Not es gematik_pki_verzeichnisdienstkonzept.doc Seite 27 von 44

28 # ASN.1 Definition Semantics 9 Value 4 is not used. 10 sigrequired (5), The server requires the client to sign the request. 11 unauthorized (6) } The client is not authorized to query the server. Support References Gen Proc Rfc ResponseBytes ::= SEQUENCE { responsetype OBJECT IDENTIFIER, indicates the type of response [1] 14 response OCTET STRING } DER-encoding of the response data [1] [1] RFC2560: In this profile, only response type BasicOCSPResponse is defined. This response type MUST be supported by all conforming clients and responders. Table Not es Tabelle 7 Basic OCSP Response # ASN.1 Definition Semantics Support References Gen Proc Rfc id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } The OID to be used in conjunction with BasicOCSPRequest BasicOCSPResponse ::= SEQUENCE { tbsresponsedata ResponseData The responder signs the DER-encoding of this to be signed part of the data structure. Table #8 Not es gematik_pki_verzeichnisdienstkonzept.doc Seite 28 von 44

29 # ASN.1 Definition Semantics 5 signaturealgorithm AlgorithmIdentifier, An identifier of the signature algorithm used by the responder to sign ResponseData 6 signature BIT STRING, The signature of the responder represented as BIT STRING Support References Gen Proc Rfc2560 RFC certs [0] EXPLICIT SEQUENCE OF Certificates that are relevant for the +- + RFC2459 Certificate verification of the signature OPTIONAL } 8 ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, Version of BasicOCSPResponse RFC responderid ResponderID, Identifier of the responder #14 Table P1.T4 Not es [1] [2] P1.T1 [3] 11 producedat GeneralizedTime, Time of signing the response [4] 12 responses SingleResponse, Single response, for the single request #18 13 responseextensions [1] EXPLICIT Extensions OPTIONAL } BasicOCSPResponse extensions RFC ResponderID ::= CHOICE { byname [1] EXPLICIT Name, DName of the responder RFC bykey [2] EXPLICIT KeyHash } Hash of responders public key (see below) P1.T2 T9, P1.T9 P1.T5 [5] #17 [5] gematik_pki_verzeichnisdienstkonzept.doc Seite 29 von 44

30 # ASN.1 Definition Semantics 17 KeyHash ::= OCTET STRING SHA-1 hash of responders public key (excluding tag, length and unused bits in the BIT STRING representation) Support References Gen Proc Rfc SingleResponse ::= SEQUENCE { A single response certid CertID, Uniquely identifies the queried certificate Table Not es [6] T6.#4 [7] 20 certstatus CertStatus, Certificate status #24 21 thisupdate GeneralizedTime, The time at which the status being indicated was known to be correct. 22 nextupdate [0] EXPLICIT GeneralizedTime OPTIONAL, The time at or before which more upto-date information will be available. [4] [8] [4] 23 singleextensions [1] EXPLICIT Extensions OPTIONAL } SingleResponse extensions RFC CertStatus ::= CHOICE { good [0] IMPLICIT NULL, indicates that the certificate IS NOT revoked. 4.1 T9, P1.T9 [8] [9] 26 revoked [1] IMPLICIT RevokedInfo, indicates that the certificate IS revoked, #28 either permanently or temporarily (on hold). 27 unknown [2] IMPLICIT UnknownInfo } indicates that the responder does not #31 know about the certificate being requested gematik_pki_verzeichnisdienstkonzept.doc Seite 30 von 44

31 # ASN.1 Definition Semantics Support References Gen Proc Rfc RevokedInfo ::= SEQUENCE { revocationtime GeneralizedTime, time of revocation 30 revocationreason [0] EXPLICIT CRLReason OPTIONAL } reason of revocation RFC UnknownInfo ::= NULL [1] RFC2560: All definitive response messages (responsestatus=successful) MUST be digitally signed. The key used to sign the response MUST belong to one of the following: the CA who issued the certificate(s) in question a Trusted Responder whose public key is trusted by the responder (and installed directly at the client), affected certificates include the OCSPNocheck extension. a CA Designated Responder (Authorized Responder) who holds a specially marked certificate issued directly by the CA, indicating in the ExtendedKeyUsage extension that the responder may issue OCSP responses for that CA. [DraftOCSPv2]: The above list is extended with the following option: a key associated with the CA (i.e. a CA's OCSP-signing key) COMMON-PKI PROFILE: As described in (d) above, the responder s certificate MAY be issued for the CA by some other trusted authority. This set-up allows clients to obtain reliable status information even if the key of the issuing CA has been compromised. This configuration is RECOMMENDED for all COMMON-PKI-compliant CAs. Clients MUST NOT rely on the authorization rules, i.e. they MUST accept responder certificates issued by any trusted authorities. [2] RFC2560: If an OCSP responder knows that a particular CA's private key has been compromised, it MAY return the revoked state for all certificates issued by that CA. COMMON-PKI PROFILE: Reliable status information can be delivered, when using the setup (d) described in [1]. In such a configuration, OCSP responders SHOULD in return the actual status, i.e. SHOULD NOT return the revoked state, unless the certificate has been explicitly revoked Table P1.T3 8 Not es gematik_pki_verzeichnisdienstkonzept.doc Seite 31 von 44