Trustcenter für medizinische Kompetenznetze

Transkript

1 Trustcenter für medizinische Kompetenznetze Policy Version 0.1.6

2 Inhaltsverzeichnis 1 Einleitung Rechtliche Bedeutung Zuständigkeitsbereich Zertifizierungsinfrastruktur Sicherheitsanforderungen Sicherheitsanforderungen an Zertifizierungsstellen Sicherheitsanforderungen an Teilnehmer Zertifikate Zertifikatstypen Schlüssellängen Verwendungszweck Gültigkeitsmodell Zertifikatsprofile Zertifizierungsregeln Regeln für die Zertifizierung von CAs Regeln für die Registrierung des Teilnehmerservice Regeln für die Registrierung des zentralen Teilnehmerservice Regeln für die Registrierung des dezentralen Teilnehmerservice Regeln für die Registrierung von Teilnehmern Regeln für Ausstellung von Serverzertifikaten Management von Zertifikaten Widerruf von Zertifikaten und Sperrlisten-Management Regeln für die Namensgebung Namenskonvention für CAs Namenskonvention für Teilnehmer Prüfung der Angaben im Zertifikat Gültigkeit dieses Dokuments Referenzen Anhang A Rootzertifikat Titel des Dokuments GB-nn Seite 2 von 34

3 Anhang B Teilnehmerzertifikat Anhang C Serverzertifikat Anhang D Antrag für zentrale Teilnehmerdienste Anhang E Antrag für dezentrale Teilnehmerdienste Anhang F Zertifizierungsantrag Endanwender Anhang G Zertifizierungsantrag Serverzertifikat Titel des Dokuments GB-nn Seite 3 von 34

4 Abkürzungsverzeichnis BSI C CA CCI GmbH CN DN L O OU PEM PIN PKI RA RFC RSA Bundesamt für Sicherheit in der Informationstechnik Country Certification Authority Competence Center Informatik GmbH Common Name Distinguished Name Locality Organization Organizational Unit Privacy Enhancement for Internet Electronic Mail Personal Identification Number Public Key Infrastruktur Registration Authority Request for Comment Von Rivest, Shamir und Adleman entwickelter Kryptoalgorithmus Titel des Dokuments GB-nn Seite 4 von 34

5 1 Einleitung Dies Dokument enthält die Zertifizierungsrichtlinie (Policy) des von der SchlumbergerSema CCI GmbH betriebenen Trustcenters für medizinische Kompetenznetze. Die hier getroffenen Aussagen sind für die Arbeit der Wurzelzertifizierungsinstanz (Root) und aller von ihr zertifizierten Certification Authorities (CAs) bindend, soweit sie nicht gesetzlichen Regelungen widersprechen. In den ersten Kapiteln wird die Gültigkeit und die rechtliche Bedeutung der Policy beschrieben, danach erfolgt eine Abgrenzung des Zuständigkeitsbereichs. Es werden dann die vom Trustcenter betriebene Zertifizierungsinfrastruktur und die Sicherheitsanforderungen an die beteiligten Instanzen erläutert. Im Anschluss erfolgt die Darstellung der vom Trustcenter erstellten Zertifikate. Im anschließenden Abschnitt des Dokuments werden die Regeln beschrieben, nach denen Zertifikate auszustellen sind. Es werden hierbei die Schritte dargelegt, die zur Erstellung eines Zertifikats erfolgen müssen. Hierzu gehören u.a. die Generierung des Schlüsselpaares, die Beantragung eines Zertifikats, die Identifizierung und Registrierung und schließlich der Zertifizierungsvorgang. Im Anschluss daran werden noch das Management und die Sperrung von Zertifikaten und abschließend die Regeln für die Namensgebung beschrieben. 2 Rechtliche Bedeutung Das Trustcenter für medizinische Kompetenznetze ist keine genehmigte Zertifizierungsstelle im Sinne des 4 Signaturgesetz. Das Trustcenter prüft die Korrektheit der in Zertifikaten angegebenen Identität auf die weiter unten beschriebene Weise. Es werden keinerlei Prüfungen über Liquidität, Kreditwürdigkeit oder dergleichen der angegebenen Identität durchgeführt. Zertifikate schaffen Vertrauen darin, dass der Zertifikatsinhaber tatsächlich derjenige ist, der er vorgibt zu sein. Sie geben keinerlei Hinweise auf die Vertrauenswürdigkeit des Zertifikatinhabers selbst. Das Trustcenter überprüft die im Zertifikatsantrag angegebenen Daten nur bei der Zertifikatsausstellung. Änderungen in den Antragsdaten oder anderer Ereignisse, die die Gültigkeit eines Zertifikats betreffen 1 sind dem Trustcenter unverzüglich nach bekannt werden mitzuteilen. Eine Zusicherung der Aktualität dieser Daten wird vom Trustcenter im Rahmen dieser Meldeverpflichtung der Teilnehmerdienste und des Teilnehmers selbst gegeben. Das Trustcenter weist ausdrücklich auf die Informationspflicht jedes Teilnehmers am Zertifizierungsservice hin. In diesem Zusammenhang ist es unerlässlich, sich vor der Antragstellung oder Teilnahme am Zertifizierungsservice Grundkenntnisse über Public Key Verfahren anzueignen. Der Zertifikatsinhaber muss zur Sicherheit der Verfahren beitragen. Dazu muss er die Sorgfalts- und Mitwirkungspflichten des Zertifikatinhabers im Abschnitt 5 Sicherheitsanforderungen beachten. Aufgrund der sich stetig ändernden Marktanforderungen ist es unerlässlich, dass die Dienste der Zertifizierungsstelle den konkreten Bedürfnissen der Kunden angepasst werden. Die AGB [CCI-AGB] und die Zertifizierungsrichtlinien werden dementsprechend regelmäßig überarbeitet. 1 Dies können sein: Ausscheiden des Teilnehmers aus der Organisation, Verdacht auf Schlüsselkompromittierung, Verlust der Chipkarte. Titel des Dokuments GB-nn Seite 5 von 34

6 3 Zuständigkeitsbereich Der Zuständigkeitsbereich dieser Policy umfasst alle vertraglich zertifizierten Certification Authorities (CAs), die untergeordneten zentralen und dezentralen Teilnehmerservices, im folgenden Registration Authorities (RAs) genannt und die Nutzer medizinischer Kompetenznetze. Ziel ist es, den Vertragspartnern eine Public-Key-Zertifizierungs-Infrastruktur zur Verfügung zu stellen, die die Voraussetzung für eine vertrauenswürdige und vertrauliche Kommunikation ist. 4 Zertifizierungsinfrastruktur Die Zertifizierungsinfrastruktur basiert auf dem PEM-Modell, das in RFC 1422 beschrieben ist. Zur Integration mehrerer Infrastrukturen dient eine Root. Die Root bildet die Wurzel einer zweistufigen Hierarchie. Diese Hierarchie umfasst neben der Root weitere Zertifizierungsstellen für die einzelnen Kompetenznetze. Die unterste Schicht bilden die Teilnehmer als die eigentlichen Nutzer der Zertifizierungsinfrastruktur. Abbildung 4-1: Zertifizierungshierarchie Die Aufgabe der Root ist die Zertifizierung weiterer CAs und deren vertrauenswürdige Verknüpfung. Die CAs stellen ihrerseits die Zertifikate für die Teilnehmer aus. Die Schlüssel von Root und CA werden nicht zum Signieren anderer Dokumente verwendet. Titel des Dokuments GB-nn Seite 6 von 34

7 Die Teilnehmer werden durch den jeweils zuständigen Teilnehmerservice identifiziert und registriert. Ein zentrale Teilnehmerservice für jedes Kompetenznetz übernimmt die Identifizierung und Registrierung der dezentralen Teilnehmerservices in den Institutionen. Die dezentralen Teilnehmerservices identifizieren und registrieren die Endanwender. Dem öffentlichen Schlüssel der Root kommt innerhalb der Zertifizierungsinfrastruktur eine besondere Bedeutung zu. Er dient als Ausgangspunkt für die Überprüfung aller Zertifizierungspfade und damit aller Zertifikate. Innerhalb der Zertifizierungsinfrastruktur müssen sich alle Beteiligten von der Authentizität und Integrität des öffentlichen Schlüssels der Root überzeugen können. Die Root veröffentlicht ihren Schlüssel elektronisch als Bestandteil ihres selbstsignierten Zertifikates. Dies allein reicht jedoch nicht aus, da für die Root kein Zertifikat einer Zertifizierungsstelle außerhalb der Zertifizierungsinfrastruktur besteht, mit dessen Hilfe der öffentliche Schlüssel der Root verifiziert werden könnte. Die Root veröffentlicht ihren öffentlichen Schlüssel deshalb zusätzlich auf sichere Weise als allgemein zugängliche Information, so dass sich jeder von der Authentizität des Schlüssels überzeugen kann. Die Veröffentlichung erfolgt als Anhang der jeweils aktuellen Version dieser Policy. Dem entspricht für die Teilnehmer die Obliegenheit, die Authentizität und Integrität des öffentlichen Schlüssels der Root anhand dieser Veröffentlichungen zu verifizieren. Das jeweils aktuelle Rootzertifikat wird als Anhang der aktuellen Version der Policy beigefügt. Beide sind unter folgender URL aufrufbar: Zur Entgegennahme von Zertifizierungsanträgen der Teilnehmer sowie deren Identifizierung und Belehrung über die Risiken des Verfahrens bedienen sich die CAs des zentralen und des dezentralen Teilnehmerservice als Registrierungsstellen. Die Root wird als verknüpfende Zertifizierungsstelle zwischen den einzelnen CAs für medizinischen Kompetenznetze bei SchlumbergerSema CCI betrieben. 5 Sicherheitsanforderungen Für die Teilnahme an einer Public Key Infrastruktur (PKI) bestehen für die Zertifizierungsstellen (Root und CAs) und die Teilnehmer bestimmte Minimalanforderungen hinsichtlich der Sicherheit der eingesetzten Hard- und Software einerseits sowie des verantwortungsvollen Umgangs mit kryptographischen Schlüsseln und personenbezogenen Daten andererseits. Die Anforderungen an die Zertifizierungsstellen sind dabei naturgemäß höher, da der Missbrauch ihrer Schlüssel allen untergeordneten Zertifikaten die Vertrauenswürdigkeit entziehen würde. Die Sicherheitsanforderungen dieser PKI leiten sich grundsätzlich aus dem Gefährdungspotential bei der Datenübermittlung. Eine Gefährdung der Datenübermittlung ist insbesondere dann gegeben, wenn personenbezogene Daten Unbefugten in die Hände fallen könnten oder andere vertrauliche Daten durch Unbefugten eingesehen werden können. Dies ist in sehr hohem Maße durch das kryptographische Verschlüsselungs- und Signaturverfahren ausgeschlossen. Im folgenden werden Anforderungen beschrieben, die für die gesamte Zertifizierungsinfrastruktur gelten. Jeder Beteiligte muss geeignete Sicherheitsmassnahmen zur Umsetzung der ihn betreffenden Anforderungen realisieren, bevor er am Verfahren teilnimmt. 5.1 Sicherheitsanforderungen an Zertifizierungsstellen Als Basisschutz sind die Maßnahmen des IT-Grundschutzhandbuchs des BSI umgesetzt. Titel des Dokuments GB-nn Seite 7 von 34

8 Als Schutz vor unbefugtem Zutritt ist ein System der Einbruchmelde- und Zutrittskontrolltechnik installiert. Die Außenhaut der Sicherheitsbereiche sind durch widerstandsfähige Außenwände sowie einbruchshemmende Türen und Fenster gesichert. Es ist eine Pförtnerfunktion realisiert, bei der Alarme des Systems auflaufen. Dem Schutzbedarf entsprechend sind unterschiedliche Sicherheitsbereiche eingerichtet, wobei die ldentifizierung (soweit vorgesehen), Schlüsselgenerierung und -zertifizierung sowie der Verzeichnisdienst in geeigneter Weise aufgeteilt sind. Nur der Bereich Identifizierung ist der Öffentlichkeit zugänglich. Die Schlüsselgenerierung und -zertifizierung werden innerhalb des Sicherheitsbereiches der Hochfrequenzzelle - betrieben. Die Hochfrequenzzelle (HF-Zelle) ist bis 30 GHz abstrahlsicher, mit einer durch Zahlenkombinationsschloss und einer Codeschalteinrichtung gesicherten Tresortür und einer direkt auf die Polizei geschalteten Einbruchs- und Überfallmeldeanlage gesichert. Der private Schlüssel der Zertifizierungsstelle zur Erzeugung der Zertifikate wird nur innerhalb der dafür benötigten, geschützten Hardware aufbewahrt und verwendet. Unbefugter Zugriff ist mit geeigneten Mitteln zu verhindern. Die Aufbewahrung des privaten Schlüssels der Zertifizierungsstelle darf nur in Aktenverwahrräumen bzw. Aktensicherungsräumen erfolgen. Eine Datensicherung des privaten Schlüssels der Zertifizierungsstelle findet im Regelfall nicht statt; im Verlustfall erfolgt ein Schlüsselwechsel. Sollte im Ausnahmefall eine Sicherung des privaten Schlüssels erfolgen, sind die Sicherungsmedien entsprechend den Sicherheitsanforderungen geschützt zu lagern. Der Zugang zur geschützten Hardware für Schlüsselgenerierung und Zertifizierung erfolgt grundsätzlich nur im 4-Augen-Prinzip; d. h. bei jedem Zugriff kontrollieren sich mindestens zwei Mitarbeiter der Zertifizierungsstelle gegenseitig. Alle wesentlichen Aktionen wie Schlüsselgenerierung, Zertifizierung und Sperrung von Zertifikaten werden zugriffsgeschützt dokumentiert und regelmäßig durch einen Revisor ausgewertet. Die SchlumbergerSema CCI GmbH ist ein geheimschutzbetreutes Unternehmen. Jeder Mitarbeiter der SchlumbergerSema CCI GmbH ist durch das BMWi sicherheitsüberprüft. Die Mitarbeiter des Trustcenters, die die Zertifizierung und Schlüsselgenerierung durchführen, sind mindestens mit der Stufe 2 überprüft. Das Personal ist in ausreichendem Maße eingewiesen, über die Sensitivität der Aufgabe belehrt und auf die Einhaltung der betreffenden Vorschriften verpflichtet. Um die Erreichbarkeit der Teilnehmer auch nach einem Katastrophenfall sicherstellen zu können, werden die Identifikationsparameter gesichert. Sicherungskopien werden in einem Sicherungsarchiv hinterlegt. Sofern die CA die Schlüsselgenerierung für den Benutzer vornimmt, hat sie den privaten Schlüssel des Benutzers wie ihren eigenen zu schützen. Sie hat dafür Sorge zu tragen, dass dieser während des Transports zum Benutzer vor Missbrauch durch Unbefugte geschützt ist (z. B. durch Verschlüsselung oder Verwendung eines Hardware-Tokens und PIN-Brief). Über die Schlüsselgenerierung hinaus wird der private Schlüssel des Benutzers nicht bei der CA gespeichert. Alle personenbezogenen Daten, die durch die Zertifizierungsstelle gespeichert werden müssen, sind durch ein Datenschutzkonzept geschützt. Mit dem geheimen Zertifizierungsschlüssel der Root dürfen nur Schlüssel unterschrieben werden. Asymmetrische Schlüsselpaare der Root zur Erzeugung von Signaturen haben eine Länge von mindestens 2048 Bit RSA (oder vergleichbarer Sicherheitslevel). Titel des Dokuments GB-nn Seite 8 von 34

9 Asymmetrische Schlüsselpaare der CAs zur Erzeugung von Signaturen haben eine Länge von mindestens 1024 Bit RSA (oder vergleichbarer Sicherheitslevel). 5.2 Sicherheitsanforderungen an Teilnehmer Jeder Teilnehmer ist selbst dafür verantwortlich, dass seine privaten Schlüssel vor Missbrauch durch Unbefugte geschützt werden. Die Schlüssel sind hierzu auf einer Chipkarte gespeichert deren Zugriff durch eine Persönliche Identifikationsnummer (PIN) gesichert ist, die nur dem Teilnehmer bekannt sein darf. Passwörter und PINs zum Schutz der privaten Schlüssel sind geheim zu halten. Bei Preisgabe oder Verdacht der Preisgabe sind Passwort/PIN unverzüglich zu ändern. Bei begründetem Verdacht eines Teilnehmers, dass sein privater Schlüssel kompromittiert wurde, ist bei der CA oder dem zuständigen dezentralen Teilnehmerservice unverzüglich die Sperrung des Zertifikats zu veranlassen (siehe Abschnitt 9 Widerruf von Zertifikaten und Sperrlisten-Management ). Bei der Prüfung empfangener Daten mit Hilfe der Hashfunktion hat der Teilnehmer nach eigenem Ermessen festzustellen, ob der Zertifizierungspfad gültig ist. Dazu kann er die aktuelle Sperrliste verwenden. Ein Verzicht auf die Prüfung eines Zertifikats erfolgt auf eigenes Risiko. 6 Zertifikate 6.1 Zertifikatstypen Das Trustcenter für medizinische Kompetenznetze stellt zwei Arten von Zertifikaten aus: 1. personengebundene Zertifikate und 2. Serverzertifikate Zertifikate und Smartcards für Einzelpersonen werden auf Anforderung durch einen zentralen oder dezentralen Teilnehmerservice erstellt. Mit der Ausstellung eines Serverzertifikats bestätigt das Trustcenter folgende Punkte: 1. Die angegebene Organisation existiert. Dazu muss dem Trustcenter die Kopie eines Legitimationspapieres vorliegen. Werden mehrere Zertifikate beantragt, so ist die Kopie nur einmal beizubringen, sofern sich zwischenzeitlich keine wesentlichen Änderungen ergeben haben. Das Trustcenter behält sich vor, im Zweifelsfall eine neue Kopie anzufordern. 2. Zeichnungsberechtigte Personen der Organisation haben den Inhalt des Zertifikats persönlich oder über von ihnen bestimmte Dritte bestätigt. Diese Bestätigung muss handschriftlich unterschrieben sein. 3. Die Zertifikatsdaten wurden, abgesehen von persönlichen Informationen, zusätzlich soweit möglich vom Trustcenter überprüft. Beispielsweise wird bei Server-Zertifikaten die Registrierung der angegebenen Domain auf die im Zertifikatsantrag genannte Organisation überprüft. Sofern -Adressen angegeben sind kann deren Existenz überprüft werden. 6.2 Schlüssellängen Schlüssel haben eine Länge von mindestens 1024 Bit. Titel des Dokuments GB-nn Seite 9 von 34

10 6.3 Verwendungszweck Einzelpersonen erhalten drei Schlüsselpaare, die auf einer Smartcard gespeichert sind. Für die jeweiligen öffentlichen Schlüssel werden personengebundene Zertifikate ausgestellt. Jedes Zertifikat ist für genau einen Nutzungsart vorgesehen: a. digitale Signatur, b. Verschlüsselung und c. Authentisierung. Die Unter a. bezeichneten Zertifikate können für die Erstellung fortgeschrittener elektronischer Signaturen im Sinne des deutschen Signaturgesetzes [SigG] und der EU Signaturrichtlinie [EU-RL] verwendet werden. 6.4 Gültigkeitsmodell Die Gültigkeit aller Zertifikate innerhalb der Public Key Infrastruktur richtet sich nach dem in RFC 1422 beschriebenen Modell. Das Zertifikat der Root hat eine Gültigkeit von maximal 7 Jahren. Zertifikate für CAs werden für eine Gültigkeitsdauer von maximal 5 Jahren erteilt. Teilnehmerzertifikate sind mindestens 1 Jahr höchstens jedoch 3 Jahre gültig. 6.5 Zertifikatsprofile (siehe Anhang) 7 Zertifizierungsregeln Dieser Abschnitt beschreibt technische und organisatorische Richtlinien und Prozeduren, die vor einer Zertifizierung von CAs oder Teilnehmern zu beachten sind. Sowohl Zertifizierungsstellen als auch Teilnehmer werden innerhalb der Zertifizierungsinfrastruktur mit eindeutigen Namen - sog. Distinguished Name (DN) - bezeichnet. Die Konvention für die Wahl dieses eindeutigen Namens wird weiter unten beschrieben. Vor jeder Zertifizierung hat sich die CA in geeigneter Weise durch technische und organisatorische Maßnahmen von der Identität desjenigen Schlüsselinhabers zu überzeugen, welcher eine Zertifizierung wünscht, um unerlaubte Zertifizierungswünsche zu erkennen. Setzt eine CA Registrierungsinstanzen ein, kann die Verantwortung der Identitätsprüfung an die RAs delegiert werden. Diese Delegierung ist mit der Einrichtung der RA ausgesprochen und bedarf keiner Einzelfallzustimmung. Zur Identitätsprüfung sollte die CA oder RA benutzt werden, die der Aufgabe am geeignetsten nachkommen kann. Das selbstsignierte Zertifikat eines Zertifikatnehmers im Sinne dieser Policy muss mindestens den Namen des Teilnehmers sowie dessen Public Key enthalten. Wahlweise kann dieses Zertifikat auch eine Gültigkeitsdauer enthalten. Nur derartige selbstsignierte Zertifikate sind im Rahmen dieser Policy zertifizierbar. Zertifikate werden ausschließlich dann erteilt, wenn der zu zertifizierende Public Key über die festgelegten Mindestlängen verfügt und sich die zertifizierende Instanz in geeigneter Weise von der Identität des Schlüsselinhabers und dem Besitz des korrekten Schlüsselpaares überzeugt hat. Titel des Dokuments GB-nn Seite 10 von 34

11 7.1 Regeln für die Zertifizierung von CAs Jedes Kompetenz-Netz ist einer CA zugeordnet. Die CAs werden bei SchlumbergerSema CCI betrieben. Für die Einrichtung einer neuen CA für ein weiteres Kompetenz-Netz ist eine einzelvertragliche Regelung zu treffen. Das Verfahren der Zertifizierung einer CA beginnt mit der Antragstellung bei der Root. Der Antrag ist persönlich bei einem Mitarbeiter der Root abzugeben. Dabei muss die Identität des Antragstellers nachgewiesen werden. Dies kann durch Vorlage des Bundespersonalaus-weises oder Reisepasses oder auf andere geeignete Weise erfolgen. CAs, die einen Antrag auf Zertifizierung gestellt haben, müssen vor der Zertifizierung eine Vereinbarung mit der Root treffen. Diese Vereinbarung enthält eine Erklärung darüber, dass die Sicherheitsleitlinien dieser Policy akzeptiert werden und deren Einhaltung beim Betrieb der eigenen CA zugesichert wird. Die Root führt eine Datenbank aller bei ihr registrierten und zertifizierten CAs. Sie prüft auf Kollisionsfreiheit des beantragten Namens. Des weiteren wird die Einhaltung der Namenskonvention geprüft (s. Abschnitt 10 Regeln für die Namensgebung ). 7.2 Regeln für die Registrierung des Teilnehmerservice Für die Registrierung und Identifizierung der Teilnehmer werden sogenannte Teilnehmerservices eingerichtet. Für jedes Kompetenz-Netz gibt es einen zentralen Teilnehmerservice. Dieser registriert und identifiziert die dezentralen Teilnehmerservices in den Organisationen. Diese wiederum sind für die Registrierung und Identifizierung der Teilnehmer zuständig Regeln für die Registrierung des zentralen Teilnehmerservice Abbildung 7-1: Registrierung des zentralen Teilnehmerservice Titel des Dokuments GB-nn Seite 11 von 34

12 Der zentrale Service verantwortet die Gesamtstruktur der Kommunikation. Er soll personell und mit Vertretungsregelungen so besetzt werden, dass er dauerhaft und regelmäßig verfügbar ist und folgende Aufgaben übernehmen kann: Er führt die Kontakte mit dem Trustcenter in allen Verträge und Technik betreffenden Fragen. Er übernimmt die Legitimation der verantwortlichen Personen in organisatorischen Untereinheiten des KNRh, Anträge von Mitgliedern des KNRh zur Teilnahme an der PKI an das Trustcenter weiterzuleiten. Er unterstützt die dezentralen Teilnehmerservicestellen in technischen und prozeduralen Problemen. Im Prozess der Einführung der PKI und ihrer Nutzung unterstützt er auch die Teilnehmer in technischen und prozeduralen Problemen; diese Aufgabe soll später von den dezentralen Stellen übernommen werden. Die Aufgabe des Teilnehmerservice wird durch den Sprecher des jeweiligen Kompetenznetz esoder eine von ihm bevollmächtigte Person wahrgenommen. Erteilte Vollmachten sind dem Trustcenter vorzulegen. Die Personen erhalten ihre Chipkarte mit Zertifikaten aufgrund eines schriftlichen Antrags, der vom Sprecher des jeweiligen Kompetenznetz gegengezeichnet ist. Ihre schriftliche Signatur wird beim Trustcenter für Teilnahmeanträge anerkannt, und zwar sowohl für Verantwortliche der dezentralen Servicestellen, wie für Teilnehmer direkt Regeln für die Registrierung des dezentralen Teilnehmerservice Die Verwaltung von Teilnahmeanträgen soll dezentral in den organisatorischen Untereinheiten bearbeitet werden. Die Hauptaufgabe dieser Stellen ist die Prüfung, Registrierung und Weiterleitung von Teilnahmeanträgen an das Trustcenter und die Verteilung der Chipkarten an die Teilnehmer und Software-PSE für zugehörige Server. Die zweistufige Organisation unterstützt die Verteilung der Serviceaufgaben auf mehrere Personen und vermeidet, dass Stellen ausschließlich für solche Aufgaben geschaffen werden müssen. Die erweiterte Leitgruppe des jeweiligen Kompetenznetzes vereinbart die Zuordnung der Servicestellen zu den organisatorischen Untereinheiten und Einrichtungen (Studienzentralen, Kliniken, Referenzzentren, Projektgruppen); die Leiter dieser Organisationen bestimmen die verantwortlichen Personen für den dezentralen Teilnehmerservice, mindestens zwei mit Vertretungsregelungen. Die verantwortlichen Personen für den dezentralen Teilnehmerservice erhalten ihre Chipkarte mit Zertifikaten und Signaturfunktion aufgrund eines Antrags an das Trustcenter, der über den zentralen Teilnehmerservice eingereicht und von diesem unterzeichnet wird. Titel des Dokuments GB-nn Seite 12 von 34

13 Abbildung 7-2: Registrierung des dezentralen Teilnehmerservice Der Zertifizierungsvorgang verläuft in folgenden Schritten: 1. Der dezentrale Teilnehmerservice stellt einen schriftlichen Antrag beim zentralen Teilnehmerservice. 2. Der zentrale Teilnehmerservice prüft den Antrag auf Richtigkeit, zeichnet ihn gegen und sendet ihn an das Trustcenter weiter. 3. Das Trustcenter erstellt eine Chipkarte mit den entsprechenden Schlüsseln und Zertifikaten und einen Pin-Brief. Die Chipkarte wird an den zentralen Teilnehmerservice geschickt. 4. Der zentrale Teilnehmerservice gibt die Chipkarte an den antragstellenden dezentralen Teilnehmerdienst weiter. 5. Der dezentrale Teilnehmerdienst bestätigt dem Trustcenter auf einem der Chipkarte beigefügten Formblatt den Empfang der Chipkarte. 6. Nach Eingang der Empfangsbestätigung schickt das Trustcenter den zugehörigen PIN- Brief an den dezentralen Teilnehmerservice. Titel des Dokuments GB-nn Seite 13 von 34

14 7.3 Regeln für die Registrierung von Teilnehmern Abbildung 7-3: Teilnehmerregistrierung Das Verfahren der Zertifizierung von Teilnehmern beginnt mit der Antragstellung und Identifizierung beim dezentralen Teilnehmerservice. Diese können wie folgt vorgenommen werden: 1. persönlich an Hand des Bundespersonalausweises oder Reisepasses; Der Antrag muss die Angabe des eindeutigen Namens (s. Abschnitt 10 Regeln für die Namensgebung ) enthalten und muss vom Benutzer unterschrieben sein. Mit der Unterschrift bestätigt der Teilnehmer, dass er vom dezentralen Teilnehmerservice über die möglichen Risiken und die notwendigen Sicherheitsmaßnahmen belehrt worden ist (s. Abschnitt 5.2 Sicherheitsanforderungen an Teilnehmer ). Diese Erklärung wird von der CA aufbewahrt. Die CA hat den Namen auf Kollisionsfreiheit zu prüfen. Sie hat auch zu prüfen, ob der Schlüssel nicht bereits einem anderen Teilnehmer zugewiesen wurde. In diese Prüfung werden auch Schlüssel einbezogen, die nicht mehr gültig sind. Bei positivem Ergebnis aller Prüfungen generiert die CA die Schlüssel und Zertifikate für den Teilnehmer. Schlüssel und Zertifikate werden dem Teilnehmer auf einer Chipkarte durch den dezentralen Teilnehmerservice ausgehändigt. Der PIN-Brief wird dem Teilnehmer direkt zugestellt. Die Teilnehmer-Zertifikate, das Zertifikat der CA sowie das Zertifikat der Root werden im LDAP-Verzeichnis des Trustcenters veröffentlicht. Titel des Dokuments GB-nn Seite 14 von 34

15 7.4 Regeln für Ausstellung von Serverzertifikaten Serverzertifikate werden dazu verwendet, einen Server eindeutig zu identifizieren und einen Schlüsselaustausch zum Aufbau einer verschlüsselten SSL-Verbindung durchzuführen. Die benötigen kryptographischen Schlüssel werden üblicherweise lokal, dezentral beim Server erzeugt. Ein zentrales Schlüsselmanagement mit Chipkarten ist Trustcenter-seitig nicht vorgesehen. Die Wahl des Schlüsselspeichermediums bleibt dem Betreiber des Servers überlassen. Die Sicherheit des privaten Serverschlüssel ist durch geeignete Maßnahmen zu gewährleisten. Abbildung 7-4: Ausstellung von Serverzertifikaten Die Ausstellung eines Serverzertifikats hat folgenden Ablauf: 1. Der Server-Administrator erzeugt ein Schlüsselpaar und einen elektronischen Zertifizierungsantrag (Certification Request i. d. R. im PEM- oder PKCS#10-Format). Den Certification Request schickt er per oder auf Diskette an das Trustcenter (1b). Gleichzeitig stellt er einen schriftlichen Antrag bei seinem zuständigen dezentralen Teilnehmerservice (1a) und fügt diesem Kopien des BundesPersonalausweises oder Reisepasses und des IK-Nummern-Bescheides oder eines beglaubigten aktuellen Handelsregisterauszuges bei. 2. Der dezentrale Teilnehmerservice bestätigt mit seiner Unterschrift die Richtigkeit des Antrags und leitet diesen an das Trustcenter weiter. 3. Das Trustcenter erstellt das Zertifikat wenn sowohl Certification Request als auch bestätigter, schriftlicher Antrag vorliegen und sendet es per oder Diskette an den Antragsteller zurück. Titel des Dokuments GB-nn Seite 15 von 34

16 8 Management von Zertifikaten Jede CA führt für die bei ihr angeschlossenen Teilnehmer ein LDAP-Verzeichnis der von ihr erstellten Zertifikate und ist für die Bereitstellung der von ihr ausgegebenen Zertifikate und die Aufnahme von Zertifikaten aus den LDAP-Verzeichnissen anderer CAs selbst verantwortlich. Dieses LDAP-Verzeichnis enthält auch das Zertifikat der Root und der ihr untergeordnete CAs. Die Zertifikate müssen bei der zuständigen CA für die Dauer ihrer Gültigkeit aus dem LDAP- Verzeichnis abrufbar sein. Abgelaufene Zertifikate werden aus dem LDAP-Verzeichnis entfernt; die Aufbewahrung abgelaufener Zertifikate liegt in der Entscheidung der jeweiligen CA. Zertifikate werden nach Eingang der Empfangsbestätigung im Verzeichnis veröffentlicht. LDAP-Server: ldap-cci.cci.de Port: 389 Search-Root: O=<kompetenzNetzBezeichner>, c=de 9 Widerruf von Zertifikaten und Sperrlisten-Management Ein Zertifikat ist zu sperren, falls 1. der zugehörige private Schlüssel verloren oder kompromittiert wurde, 2. Angaben im Zertifikat ungültig sind (z. B. nach Wechsel der -Adresse), 3. das Zertifikat der Zertifizierungsstelle ungültig wird, 4. der Inhaber dies beantragt. Eine Sperrung kann auf mehrere Arten veranlasst werden: 1. Hat der Zertifikatsinhaber seinen privaten Schlüssel verloren oder ist der Zugriff darauf aus irgendwelchen Gründen nicht mehr möglich, so kann er sich telefonisch beim Trustcenter melden und sich durch Nennung des bei der Antragstellung vergebenen Sperrkennwortes authentisieren. 2. Der Zertifikatsinhaber kann schriftlich beim Trustcenter die Sperrung seines Zertifikats beantragen. Zur Authentisierung wird die Unterschrift des Inhabers herangezogen. 3. Jeder Dritte, der Zertifikatsinhalte bestätigt hat, muss das CCI Trustcenter schriftlich darüber informieren, sobald im Zertifikat dokumentierte Daten ungültig werden. Hat das Trustcenter Kenntnis über ungültige Zertifikatsangaben erlangt, wird das betreffende Zertifikat umgehend gesperrt. Zertifikate können nur von der ausstellenden Zertifizierungsstelle gesperrt werden. CAs haben jedoch einer Aufforderung durch die Root zur Sperrung eines Teilnehmer-Zertifikats nachzukommen. Diese Aufforderung ist zu begründen. Teilnehmer und Antragsteller sind von der Zertifizierungsstelle unverzüglich über die Sperrung und die Begründung der Sperrung (falls vorhanden) in Kenntnis zu setzen. Einmal gesperrte Zertifikate können nicht erneuert werden. Jedoch besteht stets die Möglichkeit, ein neues Zertifikat zu beantragen. Sämtliche gesperrte Zertifikate werden von der zuständigen Zertifizierungsstelle in eine Sperrliste (Certificate Revocation List, CRL) eingetragen. Es ist sicherzustellen, dass gesperrte Zertifikate nicht mehr abgerufen werden können. Sie müssen deshalb zuvor aus dem Verzeichnis und allen weiteren Informationsquellen der Root entfernt werden. In der Sperrliste werden Angaben zu Zeitpunkt und Datum der Sperrung eines Zertifikats ausgewiesen. Diese Angaben dürfen nicht auf einen Zeitpunkt vor Entfernung des Zertifikats referenzieren. Gesperrte Zertifikate dürfen nicht aus der Sperrliste entfernt werden, bevor der Bereitstellungszeitraum für die Zertifikate endet (s. Abschnitt 7 Zertifizierungsregeln ). Titel des Dokuments GB-nn Seite 16 von 34

17 Jede Zertifizierungsstelle muss unmittelbar nach ihrer Zertifizierung und danach regelmäßig, mindestens einmal monatlich, seine Sperrliste aktualisieren, auch wenn keine weiteren Zertifikate gesperrt wurden. Jede Sperrliste enthält die Information über den Ausgabetag der nächsten Sperrliste. An diesem Tage ist auf jeden Fall eine Sperrliste zu aktualisiern. Alle Sperrlisten innerhalb der Zertifizierungsinfrastruktur sollen über das in Abschnitt 8 Management von Zertifikaten beschriebene Verzeichnis veröffentlicht werden. Für die Bereitstellung der von ihr ausgegebenen Zertifikate im Verzeichnis ist jede Zertifizierungsstelle selbst verantwortlich. 10 Regeln für die Namensgebung Mit einem Zertifikat wird die eindeutige Zuordnung eines öffentlichen Schlüssels zu einem Teilnehmer bestätigt. Die eindeutige Identität jedes Teilnehmers (Distinguished Name, DN) muss sichergestellt werden. Die Syntax des Distinguished Name richtet sich nach der X.500-Struktur. Dies ermöglicht eine effiziente Speicherung und Suche von Zertifikaten innerhalb des LDAP-Verzeichnisses. Ein Distinguished Name besteht aus einer Folge von eindeutig kennzeichnenden Namensattributen, durch die alle Teilnehmer referenziert werden können Namenskonvention für CAs Der Distinguished Name einer CA hat folgender Konvention zu genügen: O=<kompetenzNetzBezeichner>, C=DE Der <kompetenznetzbezeichner> kann grundsätzlich frei gewählt werden. Die Root hat jedoch sicherzustellen, dass der Name nicht mehrfach vorkommt. Sie kann deshalb die Zertifizierung unter dem gewählten Namen ablehnen, falls dieser Name tatsächlich oder potentiell doppelt vergeben werden könnte. In diesem Fall schlägt die Root die Wahl eines anderen Namens vor Namenskonvention für Teilnehmer Jedem Zertifikatsinhaber ist ein eindeutiger Name (Distinguished Name, DN) zugeordnet, der bei der Ausstellung eines Zertifikats für einen Teilnehmer als dessen Subjektname verwendet wird. Ein DN enthält eine Folge von eindeutigen Namensattributen, durch die alle Teilnehmer einer Hierarchie identifiziert werden. Die vom CCI Trustcenter vergebenen DNs haben folgende Aufbau: Feld Bedeutung Inhalt C Country Hier wir der Domainname eingetragen, der zum Wohnort des Zertifikatempfängers gehört, z. B. DE L Locality Standort, kann weggelassen werden. O Organization Name des Kompetenznetzes OU Organizational Unit Name des Instituts CN Common Name Vorname und Nachname, z. B. Paul Müller E- Mail Hier wird die zum Zertifikat gehörende -Adresse eingesetzt, wenn gewünscht, z. B. müller@ .de Kommt ein Name unter den Teilnehmern der CA mehrfach vor, ist es die Aufgabe der CA, durch geeignete Namenszusätze Eindeutigkeit herbeizuführen. Titel des Dokuments GB-nn Seite 17 von 34

18 11 Prüfung der Angaben im Zertifikat Die vom Antragsteller gemachten Angaben werden in Abhängigkeit von der Zertifikatsstufe geprüft. Im Bereich der medizinischen Kompetenznetze kommen nur Zertifikate der Stufe 2 (siehe [CCI_POL]) zum Einsatz. Zertifikate für Einzelpersonen Bei Zertifikaten für Einzelpersonen wird die Identität (Name, Ort, Herkunftsland) mittels einer Kopie von Personalausweis oder Reisepass überprüft. Weiterhin wird überprüft, ob die angegebene -Adresse existiert und der Besitzer Zugriff darauf hat. Server-Zertifikate Bei Server-Zertifikaten wird die Existenz und Identität (Name, Ort, Herkunftsland) des Unternehmens mittels einer Kopie eines Legitimationspapieres überprüft. Zusätzlich sind diese Informationen durch zeichnungsberechtigte Mitarbeiter des Unternehmens zu bestätigen. Weiterhin wird die Existenz der angegebenen -Adresse und Domain überprüft und getestet, ob der Besitzer Zugriff auf die -Adresse hat. Die folgende Übersicht stellt die zu prüfenden Angaben tabellarisch dar. Zertifikatsfeld Stufe 2 (privat) Stufe 2 (geschäftlich) CN Ausweiskopie HRA (Kopie), Check der Domain Test Test O - Legitimationspapier (Kopie) OU - schriftliche Bestätigung C Ausweiskopie Legitimationspapier (Kopie) L Ausweiskopie Legitimationspapier (Kopie) Abbildung 11-1 Übersicht über die zu prüfenden Angaben 12 Gültigkeit dieses Dokuments Die Gültigkeit dieses Dokument beginnt am Der PolicyIdentifier der vorliegenden Version 1.0 lautet Referenzen [CCI-POL] [CCI-AGB] [EU-RL] [SigG] CCI TrustCenter Policy, Version 0.9 vom 30. Juli 2002 CCI TrustCenter Allgemeine Geschäftsbedingung vom Richtlinie 1999/93/EG des europäischen Parlaments und des Rates vom 13.Dezember 1999 über gemeinschaftliche Rahmenbedingungen für elektronische Signaturen Gesetz über Rahmenbedingungen für elektronische Signaturen und zur Änderung weiterer Vorschriften (Signaturgesetz SigG) vom 16. Mai 2001 Titel des Dokuments GB-nn Seite 18 von 34

19 Titel des Dokuments GB-nn Seite 19 von 34

20 Anhang A Rootzertifikat Feldname Inhalt Version 2 (X.509v3) Seriennummer 0 Signaturalgorithmus sha1rsa Aussteller <DN der CA des Kompetenznetzes> Gültig ab Gültig bis Antragsteller Hash MD5 Hash SHA1 <DN des Teilnehmers> SubjectAltName < -Adresse des Teilnehmers > PolicyIdentifier CRLDistributionPoint AuthorityKeyIdentifier SubjectKeyIdentifier BasicConstraints ca ja PathLengthConstraints 1 KeyUsage digitale Signatur Non repudiation key encipherment data encipherment Key agreement key cert sign CRL sign encipher only decipher only X X ExtendedKeyUsage NsCertType NsComment NsSslServerName client server objsign sslca ca objca X X Titel des Dokuments GB-nn Seite 20 von 34

21 Anhang B Teilnehmerzertifikat Feldname Version Seriennummer Signaturalgorithmus Aussteller Gültig ab Gültig bis Antragsteller Inhalt 2 (X.509v3) sha1rsa <DN der CA des Kompetenznetzes> <DN des Teilnehmers> SubjectAltName < -Adresse des Teilnehmers > PolicyIdentifier CRLDistributionPoint AuthorityKeyIdentifier SubjectKeyIdentifier BasicConstraints ca Nein PathLengthConstraints keine KeyUsage Digitale Signatur Ver-/Entschlüsselung Authentisierung digitale Signatur X Non repudiation X key encipherment X data encipherment Key agreement key cert sign CRL sign encipher only decipher only ExtendedKeyUsage Digitale Signatur Ver-/Entschlüsselung Authentisierung NsCertType Digitale Signatur Ver-/Entschlüsselung Authentisierung client X server objsign sslca ca objca X X NsComment NsSslServerName Titel des Dokuments GB-nn Seite 21 von 34

22 Anhang C Serverzertifikat Feldname Inhalt Version 2 (X.509v3) Seriennummer 0 Signaturalgorithmus sha1rsa Aussteller <DN der CA des Kompetenznetzes> Gültig ab Gültig bis Antragsteller <DN des Teilnehmers> SubjectAltName < -Adresse des Teilnehmers > PolicyIdentifier CRLDistributionPoint AuthorityKeyIdentifier SubjectKeyIdentifier BasicConstraints ca Nein PathLengthConstraints keine KeyUsage digitale Signatur X Non repudiation X key encipherment X data encipherment Key agreement key cert sign CRL sign encipher only decipher only ExtendedKeyUsage NsCertType NsComment NsSslServerName client server objsign sslca ca objca X <Web-Servername> Titel des Dokuments GB-nn Seite 22 von 34

23 Anhang D Antrag für zentrale Teilnehmerdienste 1. Angaben zur Institution Firma/Institution Straße/Postfach Telefonnummer Faxnummer Postleitzahl Ort 2. Angaben zur Person Ansprechpartner (Name, Vorname) Abteilung Anrede Akademischer Titel Vorname Nachname Telefonnummer Faxnummer Straße/Postfach Postleitzahl Ort -Adresse Titel des Dokuments GB-nn Seite 23 von 34

24 3. Identifikation Der Ansprechpartner der Registrierungsstelle wurde identifiziert und authentisiert durch persönliche Vorstellung anhand eines Personalausweises Reisepasses Nr: Hinweis: Eine Kopie des Legitimationspapiers ist dem Antrag beizufügen. 4. Unterschrift des Antragstellers Mit seiner Unterschrift bestätigt der Antragsteller die Richtigkeit der aufgeführten Angaben und erklärt, dass der zentrale Teilnehmerservice seine Verpflichtungen aus der Sicherheitspolicy der TMF und der Trustcenter-Policy erfüllen wird. Datum/Unterschrift 5. Unterschrift des Trustcenters Die Identifikation wurde von folgendem Mitarbeiter des CCI TrustCenters durchgeführt: Name, Vorname Datum/Unterschrift Anlagen: Kopie des Legitimationspapiers (Personalausweis, Reisepass) Titel des Dokuments GB-nn Seite 24 von 34

25 Anhang E Antrag für dezentrale Teilnehmerdienste 1. Angaben zur Institution Firma/Institution Straße/Postfach Telefonnummer Faxnummer Postleitzahl Ort 2. Angaben zur Person Ansprechpartner (Name, Vorname) Abteilung Anrede Akademischer Titel Vorname Nachname Telefonnummer Faxnummer Straße/Postfach Postleitzahl Ort -Adresse Titel des Dokuments GB-nn Seite 25 von 34

26 3. Identifikation Der Ansprechpartner des dezentralen Teilnehmerservice wurde identifiziert und authentisiert durch persönliche Vorstellung anhand eines Personalausweises Reisepasses Nr: Hinweis: Eine Kopie des Legitimationspapiers ist dem Antrag beizufügen. 4. Unterschrift des Antragstellers Mit seiner Unterschrift bestätigt der Antragsteller die Richtigkeit der aufgeführten Angaben und erklärt, dass der dezentrale Teilnehmerservice seine Verpflichtungen aus der Sicherheitspolicy der TMF und der Trustcenter-Policy erfüllen wird. Datum/Unterschrift 5. Unterschrift der vorgesetzten Stelle Mit seiner Unterschrift bestätigt der Vorgesetzte, dass Antragsteller beauftragt wurde, den dezentralen Teilnehmerservice für die o. a. Organisation wahrzunehmen. Datum/Unterschrift 6. Unterschrift des Leiters der Kompetenznetzes Die Identifikation wurde von folgendem Mitarbeiter des CCI TrustCenters durchgeführt: Name, Vorname Datum/Unterschrift Anlagen: Kopie des Legitimationspapiers (Personalausweis, Reisepass) Titel des Dokuments GB-nn Seite 26 von 34

27 Anhang F Zertifizierungsantrag Endanwender 1. Angaben zum Antragsteller (Endanwender, Teilnehmer) Firma/Institution Abteilung Anrede Akademischer Titel Vorname Nachname Telefonnummer Faxnummer Straße/Postfach Postleitzahl Ort -Adresse 2. Identifikation des Antragstellers Der Antragsteller wurde identifiziert und authentisiert durch persönliche Vorstellung anhand eines Personalausweises Reisepasses Dienstausweises eine hinterlegte handschriftliche Unterschrift (z.b. bei bestehender Vertragsbeziehung) Hinweis: Eine Kopie des Legitimationspapiers ist dem Antrag beizufügen. Titel des Dokuments GB-nn Seite 27 von 34

28 3. Angaben zum Zertifikat Angaben zur Schlüsselverwendung Ich beantrage Schlüssel und Zertifikat für folgende Verwendung(en) Digitale Signatur Verschlüsselung Autehtisierung Schlüsselgenerierung Die Schlüssel wurden selbst erzeugt. Mein selbstsigniertes Zertifikat liegt diesem Zertifizierungsantrag bei. Fingerprint (CertReq): Ich beantrage eine Schlüsselgenerierung durch die CA (zentral). Angaben zum Gültigkeitsbeginn (Bitte genau eine Angabe) Das Zertifikat soll gültig sein ab (Gültigkeitsbeginn) schnellstmöglich (Datum) Veröffentlichung des Zertifikats (im öffentlichen Verzeichnis) (Bitte genau eine Angabe) Ich wünsche, dass mein Zertifikat im Verzeichnis veröffentlicht wird Ich wünsche, dass mein Zertifikat nicht im Verzeichnis veröffentlicht wird Sperrkennwort Mein Sperrkennwort lautet: Sperrkontrollfrage (freiwillige Angabe) Meine Kontrollfrage lautet: Die Antwort auf meine Frage lautet (möglichst nur ein Wort) 4. Angaben zum eindeutigen Namen des Antragstellers CN=, L=, OU=, O=, C= DE Titel des Dokuments GB-nn Seite 28 von 34

29 5. Risiken und Sicherheitsmaßnahmen Jeder Teilnehmer ist selbst dafür verantwortlich, dass sein privater Schlüssel vor Missbrauch durch Unbefugte geschützt wird. Der Schlüssel kann hierzu z. B. durch ein Passwort oder eine Persönliche Identifikationsnummer (PIN) verschlüsselt gespeichert werden, die nur dem Teilnehmer bekannt sein darf. Passwörter und PINs zum Schutz des privaten Schlüssels sind geheim zu halten. Bei Preisgabe oder Verdacht der Preisgabe ist unverzüglich die Sperrung des Zertifikats zu beantragen. Bei begründetem Verdacht eines Teilnehmers, dass sein privater Schlüssel kompromittiert wurde, ist bei der CA bzw. Sub-CA unverzüglich die Sperrung des Zertifikats zu veranlassen. Bei der Prüfung der Signatur hat der Teilnehmer nach eigenem Ermessen festzustellen, ob der Zertifizierungspfad gültig ist. Dazu sollte er die aktuelle Sperrliste verwenden. Ein Verzicht auf die Prüfung eines Zertifikats erfolgt auf eigenes Risiko. Analoges gilt für den Fall der Verschlüsselung. Vor einer Verschlüsselung hat der Teilnehmer nach eigenem Ermessen festzustellen, ob das Zertifikat gültig ist. 6. Unterschrift des Antragstellers WICHTIG: Leisten Sie Ihre Unterschrift nur im Beisein Ihres zuständigen dezentralen Teilnehmerservices Mit seiner Unterschrift erklärt der Antragsteller die Richtigkeit der aufgeführten Angaben und bestätigt, dass er durch Kapitel 5 dieses Antrags auf die Risiken und die notwendigen Sicherheitsmaßnahmen belehrt wurde. Datum/Unterschrift (Antragsteller) Datenschutzerklärung durch den Antragsteller (nur zu unterschreiben, wenn das hier beantragte Zertifikat im Verzeichnis veröffentlicht werden soll) Mir ist bekannt, dass das hiermit beantragte Zertifikat personenbezogene Daten über mich enthält (u.a. meinen Namen und Angaben zur Institution). Ich erkläre mich damit einverstanden, dass das hiermit beantragte Zertifikat, welches personenbezogene Daten über mich enthält, im Verzeichnisdienst veröffentlicht wird. Datum/Unterschrift Titel des Dokuments GB-nn Seite 29 von 34

30 7. Unterschrift der Registrierungsstelle Mit ihrer Unterschrift bestätigt die Registrierungsstelle die erfolgreiche Identifizierung und Authentifizierung des Antragstellers sowie die Unterzeichnung des Antrags durch den Antragsteller im Beisein der Registrierungsstelle. Datum/Unterschrift (Registrierungsstelle) Titel des Dokuments GB-nn Seite 30 von 34

31 Anhang G Zertifizierungsantrag Serverzertifikat 1. Angaben zum Antragsteller (Serveradmin/-verantwortlicher) Firma/Institution Abteilung Anrede Akademischer Titel Vorname Nachname Telefonnummer Faxnummer Straße/Postfach Postleitzahl Ort -Adresse 2. Identifikation des Antragstellers Der Antragsteller wurde identifiziert und authentisiert anhand einer Kopie des Personalausweises Reisepasses sowie der Kopie des IK-Nummern-Bescheides oder eines beglaubigten Handelsregisterauszuges. Hinweis: Kopien der Legitimationspapiere sind dem Antrag beizufügen. Seite 31 von 37 Stand: 28. März 2003

32 3. Angaben zum Zertifikat Angaben zur Schlüsselverwendung Ich beantrage Schlüssel und Zertifikat für folgende Verwendung(en) Serverauthentisierung Schlüsselgenerierung Die Schlüssel wurden selbst erzeugt. Mein selbstsigniertes Zertifikat liegt diesem Zertifizierungsantrag bei. Fingerprint (CertReq): Ich beantrage eine Schlüsselgenerierung durch die CA (zentral). Angaben zum Gültigkeitsbeginn (Bitte genau eine Angabe) Das Zertifikat soll gültig sein ab (Gültigkeitsbeginn) schnellstmöglich (Datum) Veröffentlichung des Zertifikats (im öffentlichen Verzeichnis) (Bitte genau eine Angabe) Ich wünsche, dass mein Zertifikat im Verzeichnis veröffentlicht wird Ich wünsche, dass mein Zertifikat nicht im Verzeichnis veröffentlicht wird Sperrkennwort Mein Sperrkennwort lautet: Sperrkontrollfrage (freiwillige Angabe) Meine Kontrollfrage lautet: Die Antwort auf meine Frage lautet (möglichst nur ein Wort) 4. Angaben zum eindeutigen Namen des Antragstellers CN=, L=, OU=, O=, C= DE Seite 32 von 37 Stand: 28. März 2003

33 5. Risiken und Sicherheitsmaßnahmen Jeder Teilnehmer ist selbst dafür verantwortlich, dass sein privater Schlüssel vor Missbrauch durch Unbefugte geschützt wird. Der Schlüssel kann hierzu z. B. durch ein Passwort oder eine Persönliche Identifikationsnummer (PIN) verschlüsselt gespeichert werden, die nur dem Teilnehmer bekannt sein darf. Passwörter und PINs zum Schutz des privaten Schlüssels sind geheim zu halten. Bei Preisgabe oder Verdacht der Preisgabe ist unverzüglich die Sperrung des Zertifikats zu beantragen. Bei begründetem Verdacht eines Teilnehmers, dass sein privater Schlüssel kompromittiert wurde, ist bei der CA bzw. Sub-CA unverzüglich die Sperrung des Zertifikats zu veranlassen. Bei der Prüfung der Signatur hat der Teilnehmer nach eigenem Ermessen festzustellen, ob der Zertifizierungspfad gültig ist. Dazu sollte er die aktuelle Sperrliste verwenden. Ein Verzicht auf die Prüfung eines Zertifikats erfolgt auf eigenes Risiko. Analoges gilt für den Fall der Verschlüsselung. Vor einer Verschlüsselung hat der Teilnehmer nach eigenem Ermessen festzustellen, ob das Zertifikat gültig ist. 6. Unterschrift des Antragstellers WICHTIG: Leisten Sie Ihre Unterschrift nur im Beisein Ihres zuständigen dezentralen Teilnehmerservices Mit seiner Unterschrift erklärt der Antragsteller die Richtigkeit der aufgeführten Angaben und bestätigt, dass er durch Kapitel 5 dieses Antrags auf die Risiken und die notwendigen Sicherheitsmaßnahmen belehrt wurde. Datum/Unterschrift (Antragsteller) Datenschutzerklärung durch den Antragsteller (nur zu unterschreiben, wenn das hier beantragte Zertifikat im Verzeichnis veröffentlicht werden soll) Mir ist bekannt, dass das hiermit beantragte Zertifikat personenbezogene Daten über mich enthält (u.a. meinen Namen und Angaben zur Institution). Ich erkläre mich damit einverstanden, dass das hiermit beantragte Zertifikat, welches personenbezogene Daten über mich enthält, im Verzeichnisdienst veröffentlicht wird. Datum/Unterschrift Seite 33 von 37 Stand: 28. März 2003

34 7. Unterschrift der Registrierungsstelle Mit ihrer Unterschrift bestätigt die Registrierungsstelle die erfolgreiche Identifizierung und Authentifizierung des Antragstellers sowie die Unterzeichnung des Antrags durch den Antragsteller im Beisein der Registrierungsstelle. Datum/Unterschrift (Registrierungsstelle) Seite 34 von 37 Stand: 28. März 2003