certificate practice statement · certificate practice statement 8/10 1. einfÜhrung dieses...

Jean-Monnet-Gebäude, Rue Alcide de Gasperi, L-2920 Luxemburg. Telefon: (352)43011. Rue de la Loi 200, B-1049 Brüssel / Wetstraat 200, B-1049 Brüssel - Belgien. Telefon : (32-2)299 11 11.

EUROPÄISCHE KOMMISSION GENERALDIREKTION PERSONAL UND VERWALTUNG Direktion SPS – Dienst Protokoll und Sicherheit Datensicherheit

Europäische Kommission

CERTIFICATE PRACTICE STATEMENT

(Version 1.0 vom 25.02.2002)


2/10

Inhaltsverzeichnis

(Version 1.0 vom 25.02.2002)..................................................................................... 1

1. EINFÜHRUNG ........................................................................................................... 8

1.1. Überblick ........................................................................................................... 8

1.2. Dokumentidentifikation................................................................................... 10

1.3. Mitwirkende Stellen und Anwendungsbereich ............................................... 10

1.3.1. Zertifizierungsstelle (CA).................................................................. 10

1.3.2. Registrierungsstellen (RA)............................................................. 11

1.3.3. Repositories ....................................................................................... 12

1.3.4. Teilnehmer......................................................................................... 12

1.3.5. Vertrauende Parteien ......................................................................... 13

1.3.6. Anwendungsbereich .......................................................................... 13

1.4. Kontakt ............................................................................................................ 13

2. ALLGEMEINE BESTIMMUNGEN ........................................................................ 14

2.1. Pflichten........................................................................................................... 14

2.1.1. Pflichten der CA................................................................................ 14

2.1.2. Pflichten der RA und LRA................................................................ 15

2.1.3. Pflichten der Teilnehmer ................................................................... 16

2.1.4. Pflichten der vertrauenden Partei ...................................................... 17

2.1.5. Pflichten des Repository.................................................................... 18

2.2. Haftung [vom Juristischen Dienst zu überprüfen]........................................... 18

2.2.1. Gewährleistung und Einschränkungen der Gewährleistung ............. 18

2.2.2. Haftungsausschluss und –beschränkungen........................................ 19

2.2.3. Weitere Vereinbarungen und Bedingungen ...................................... 20

2.3. Finanzielle Verantwortung .............................................................................. 20

2.3.1. Entschädigung durch vertrauende Parteien ....................................... 20

2.3.2. Treuhänderische Beziehungen........................................................... 20

2.4. Auslegung und Durchsetzung.......................................................................... 20

2.4.1. Geltendes Recht................................................................................. 20

2.4.2. Aufteilung, Fortbestehen, Zusammenlegung, Kündigung ................ 20

2.4.3. Streitbeilegungsverfahren.................................................................. 20

2.5. Gebühren ......................................................................................................... 21

2.6. Veröffentlichung und Repository .................................................................... 21

2.6.1. Veröffentlichung von Informationen der CA.................................... 21


3/10

2.6.2. Veröffentlichungsturnus .................................................................... 21

2.6.3. Zugriffsrechte .................................................................................... 21

2.6.4. Repositories ....................................................................................... 22

2.7. Konformitätsprüfung [noch nicht implementiert] [Review nach Implementierung] ............................................................................................ 22

2.7.1. Turnus der Konformitätsprüfung....................................................... 22

2.7.2. Person und Qualifikation eines CA-Auditors.................................... 23

2.7.3. Verhältnis des Auditors zur geprüften CA ........................................ 23

2.7.4. Gegenstand der Konformitätsprüfung ............................................... 23

2.7.5. Maßnahmen, die aufgrund einer Konformitätsprüfung zu treffen sind......................................................................................... 23

2.7.6. Bekanntgabe des Prüfungsberichts.................................................... 24

2.8. Vertraulichkeitskonzept................................................................................... 24

2.8.1. Vertraulich zu behandelnde Informationen ....................................... 24

2.8.2. Als öffentlich zugänglich zu betrachtende Informationen ................ 25

2.8.3. Zugang zu Informationen aus dem Widerruf von Zertifikaten ......... 26

2.8.4. Zugang zu Informationen für Vollstreckungsbehörden .................... 26

2.8.5. Sonstige Umstände, die den Zugang zu Informationen rechtfertigen....................................................................................... 26

2.9. Rechte an geistigem Eigentum ........................................................................ 26

3. IDENTIFIZIERUNG UND AUTHENTIFIZIERUNG............................................. 26

3.1. Erstregistrierung .............................................................................................. 26

3.1.1. Namenstypen ..................................................................................... 26

3.1.2. Aussagekraft von Namen .................................................................. 27

3.1.3. Regelungen für die Interpretation von Namensformaten .................. 27

3.1.4. Eindeutige Namen ............................................................................. 27

3.1.5. Verfahren für die Regelung von Namenskonflikten ......................... 27

3.1.6. Anerkennung, Authentifizierung und Rolle von Warenzeichen .................................................................................... 27

3.1.7. Besitznachweis für geheime Schlüssel.............................................. 27

3.1.8. Authentifizierung der Identität von Organisationen.......................... 27

3.1.9. Authentifizierung der Identität von Einzelpersonen ......................... 28

3.1.10. Authentifizierung der Kommissionszugehörigkeit eines Teilnehmers ....................................................................................... 28

3.1.11. Authentifizierung der Identität eines Teilnehmers............................ 29

3.1.12. Authentifizierung von Geräten oder Anwendungen.......................... 29

3.2. Routinemäßige Schlüsselerneuerung .............................................................. 29


4/10

3.3. Schlüsselerneuerung nach einem Widerruf ..................................................... 29

3.4. Antrag auf Widerruf ........................................................................................ 29

4. ANFORDERUNGEN AN DEN BETRIEB.............................................................. 29

4.1. Beantragung eines Zertifikats.......................................................................... 29

4.2. Ausgabe von Zertifikaten ................................................................................ 30

4.3. Annahme des Zertifikats.................................................................................. 32

4.4. Suspendierung und Widerruf von Zertifikaten................................................ 33

4.4.1. Widerrufsgründe................................................................................ 33

4.4.2. Antragsberechtigte............................................................................. 33

4.4.3. Antragsverfahren für einen Widerruf [noch nicht implementiert] [Review nach Implementierung] .............................. 34

4.4.4. Aufschubfrist bei einem Antrag auf Zertifikatswiderruf................... 34

4.4.5. Suspendierungsgründe....................................................................... 35

4.4.6. Antragsberechtigte............................................................................. 35

4.4.7. Antragsverfahren für eine Suspendierung......................................... 35

4.4.8. Befristung einer Suspendierung ........................................................ 35

4.4.9. CRL-Ausgabeturnus .......................................................................... 35

4.4.10. Anforderungen an die Prüfung von CRL .......................................... 35

4.4.11. Online-Widerrufs-/Statusprüfung...................................................... 35

4.4.12. Anforderungen an eine Online-Widerrufsprüfung ............................ 35

4.4.13. Sonstige Formen der Widerrufsbekanntgabe .................................... 35

4.4.14. Anforderungen an die Prüfung sonstiger Formen der Widerrufsbekanntgabe....................................................................... 36

4.4.15. Besondere Anforderungen bei Schlüsselkompromittierung.............. 36

4.5. Verfahren für Sicherheitsaudits [noch nicht implementiert] [Review nach Implementierung].................................................................................... 36

4.5.1. Aufgezeichnete Ereignisarten............................................................ 36

4.5.2. Verarbeitungsturnus für die Audit-Logdateien ................................. 37

4.5.3. Aufbewahrungsfristen für die Audit-Logdateien .............................. 37

4.5.4. Schutz der Audit-Logdateien............................................................. 37

4.5.5. Backup-Verfahren für die Audit-Logdateien .................................... 37

4.5.6. Sammeln der Audit-Logdateien ........................................................ 38

4.5.7. Benachrichtigung der Ereignisauslöser ............................................. 38

4.5.8. Schwachstellenanalyse ...................................................................... 38

4.6. Archivierung [noch nicht implementiert] [Review nach Implementierung] ............................................................................................ 38

4.6.1. Archivierte Daten .............................................................................. 38


5/10

4.6.2. Aufbewahrungsfristen für die Archivierung ..................................... 39

4.6.3. Archivsicherheit ................................................................................ 39

4.6.4. Backup-Verfahren für das Archiv ..................................................... 39

4.6.5. Archivsammelsystem ........................................................................ 40

4.6.6. Verfahren für das Abrufen und Verifizieren von Archivdaten ......... 40

4.7. Änderung von Schlüsseln ................................................................................ 40

4.8. Wiedererlangung nach Kompromittierung oder Desaster [noch nicht implementiert] [Review nach Implementierung] ............................................ 40

4.8.1. Kompromittierte Rechnerressourcen, Software und/oder Daten.................................................................................................. 40

4.8.2. Wiedererlangen des Schlüssels eines Subjekts ................................. 41

4.8.3. Wiedererlangung nach einem Desaster ............................................. 43

4.9. Einstellung des CA-Betriebs ........................................................................... 44

5. PHYSISCHE, VERFAHRENSTECHNISCHE UND PERSONALBEZOGENE SICHERHEITSKONTROLLEN.................................... 44

5.1. Physische Sicherheitskontrollen...................................................................... 44

5.1.1. Örtliche und bauliche Vorgaben für Standorte.................................. 44

5.1.2. Zutritt ................................................................................................. 44

5.1.3. Stromversorgung und Klimatisierung ............................................... 44

5.1.4. Gefahr durch Wasser ......................................................................... 45

5.1.5. Brandschutz ....................................................................................... 45

5.1.6. Aufbewahrung der Datenträger ......................................................... 45

5.1.7. Entsorgung......................................................................................... 45

5.1.8. Externe Sicherung [nicht anwendbar] ............................................... 45

5.2. Verfahrenstechnische Kontrollen .................................................................... 45

5.2.1. Vertrauenswürdige Rollen................................................................. 45

5.2.2. Für eine Aufgabe benötigte Personenzahl......................................... 47

5.2.3. Identifizierung und Authentifizierung für die Rollen........................ 47

5.3. Personalbezogene Sicherheitskontrollen......................................................... 48

5.3.1. Hintergrund, Qualifikation, Erfahrung und Unbedenklichkeitsanforderungen...................................................... 48

5.3.2. Verfahren zur Hintergrundüberprüfung ............................................ 48

5.3.3. Schulungsanforderungen ................................................................... 48

5.3.4. Fortbildungsintervalle und -anforderungen....................................... 48

5.3.5. Job Rotation....................................................................................... 48

5.3.6. Sanktionen für unbefugte Handlungen.............................................. 48

5.3.7. Mitarbeiter von Auftragnehmern....................................................... 49


6/10

5.3.8. An Mitarbeiter ausgehändigte Dokumentation ................................. 49

6. TECHNISCHE SICHERHEITSKONTROLLEN..................................................... 49

6.1. Erstellung und Installation von Schlüsselpaaren............................................. 49

6.1.1. Erstellung von Schlüsselpaaren......................................................... 49

6.1.2. Lieferung des geheimen Schlüssels an ein Subjekt........................... 49

6.1.3. Lieferung öffentlicher Schlüssel an Aussteller von Zertifikaten ........................................................................................ 49

6.1.4. Lieferung öffentlicher CA-Schlüssel an Nutzer ................................ 49

6.1.5. Größe der asymmetrischen Schlüssel ................................................ 50

6.1.6. Parametererstellung für öffentliche Schlüssel ................................... 50

6.1.7. Parameterqualitätsprüfung................................................................. 50

6.1.8. Schlüsselerzeugung durch Hardware/Software................................. 50

6.1.9. Verwendungszweck der Schlüssel (je X.509v3-Feld) ...................... 50

6.2. Schutz geheimer Schlüssel .............................................................................. 50

6.2.1. Standards für kryptografische Module .............................................. 50

6.2.2. Kontrolle geheimer Schlüssel durch mehrere Personen.................... 50

6.2.3. Hinterlegung geheimer Schlüssel (Private Key Escrow) .................. 51

6.2.4. Sicherung geheimer Schlüssel........................................................... 51

6.2.5. Archivierung geheimer Schlüssel...................................................... 51

6.2.6. Eingabe geheimer Schlüssel in das kryptografische Modul.............. 51

6.2.7. Methode zum Aktivieren geheimer Schlüssel................................... 51

6.2.8. Methode zum Deaktivieren geheimer Schlüssel ............................... 51

6.2.9. Methode zur Vernichtung geheimer Schlüssel.................................. 51

6.3. Sonstige Aspekte der Verwaltung von Schlüsselpaaren ................................. 51

6.3.1. Archivierung öffentlicher Schlüssel .................................................. 51

6.3.2. Nutzungsfristen für öffentliche und geheime Schlüssel.................... 52

6.4. Aktivierungsdaten ........................................................................................... 52

6.4.1. Erstellung und Installation von Aktivierungsdaten ........................... 52

6.4.2. Schutz der Aktivierungsdaten ........................................................... 52

6.4.3. Sonstige Aspekte der Aktivierungsdaten .......................................... 52

6.5. Computer-Sicherheitskontrollen ..................................................................... 53

6.5.1. Spezifische technische Anforderungen an die Computersicherheit............................................................................ 53

6.5.2. Bewertung der Computersicherheit ................................................... 53

6.6. Kontrollen über den Lebenszyklus.................................................................. 53

6.6.1. Systementwicklungskontrollen.......................................................... 53


7/10

6.6.2. Kontrollen des Sicherheitsmanagements........................................... 53

6.7. Netzwerk-Sicherheitskontrollen...................................................................... 54

6.8. Konstruktionskontrollen für Kryptografiemodule........................................... 54

7. ZERTIFIKATS- UND CRL-PROFIL....................................................................... 54

7.1. Zertifikatsprofil ............................................................................................... 54

7.1.1. Versionsnummer................................................................................ 54

7.1.2. Erweiterungen für Zertifikate ............................................................ 55

7.1.3. Objektkennungen für Algorithmen.................................................... 55

7.1.4. Namen................................................................................................ 55

7.1.5. Namenseinschränkungen................................................................... 55

7.1.6. Objektkennung der PKI-CP............................................................... 55

7.1.7. Verwendung der Erweiterungen für Einschränkungen der PKI-CP .............................................................................................. 55

7.1.8. Syntax und Semantik von Policy Qualifiers...................................... 55

7.1.9. Kritikalität von Erweiterungen und ihre Verarbeitungssemantik für die CP..................................................... 56

7.2. CRL-Profil [Review nach Implementierung].................................................. 56

7.2.1. Versionsnummer................................................................................ 56

7.2.2. Erweiterungen der CRL und CRL-Einträge ...................................... 56

8. PFLEGE DIESES CPS.............................................................................................. 58

8.1. Änderungsverfahren ........................................................................................ 58

8.1.1. Änderungen ohne Benachrichtigung ................................................. 58

8.1.2. Änderungen mit Benachrichtigung.................................................... 58

8.2. Veröffentlichungs- und Benachrichtigungskonzepte ...................................... 59

8.3. CPS-Genehmigungsverfahren ......................................................................... 59

9. ANHÄNGE ............................................................................................................... 59

9.1. Abkürzungen ................................................................................................... 59

9.2. Definitionen..................................................................................................... 60

9.3. Quellen ............................................................................................................ 63


8/10

1. EINFÜHRUNG

Dieses Dokument folgt in seinem allgemeinen Aufbau dem Request for Comments (RFC, Aufruf zur Kommentierung) 2527, der eine ausführliche Darstellung des Themas enthält.

Der durch das Dokument RFC 2527 vorgegebene Rahmen bietet eine umfassende Liste der Themen, die in einem Certificate Practice Statement (CPS, Beschreibung der Zertifizierungspraxis) zu behandeln sind.

Es gelten folgende Konventionen:

• Normalschrift: implementiert und einsatzbereit;

• Kursivschrift: noch nicht implementiert, für zukünftige Entwicklungen;

• Text in eckigen Klammern: diskussionsbedürftig.

Einige englische Begriffe und alle Abkürzungen wurden beibehalten, um den Bezug auf RFC 2527 zu erleichtern. Eine Übersetzung der Begriffe und Abkürzungen finden Sie beim ersten Vorkommen im Text und in den Abschnitten 9.1 „Abkürzungen“ sowie 9.2 „Definitionen“.

Die Europäische Kommission baut derzeit eine Public Key Infrastructure (PKI, Infrastruktur für öffentliche Schlüssel) auf, um die Sicherheit ihrer elektronischen Informationen zu gewährleisten. Diese PKI besteht aus Systemen, Produkten und Diensten, die X.509-konforme Zertifikate für die Kryptografie von öffentlichen Schlüsseln bereitstellen und verwalten.

Das vorliegende Dokument beschreibt die Zertifizierungspraktiken, die von der „CommisSign“ genannten Certification Authority (CA, Zertifizierungsstelle) der Europäischen Kommission implementiert wurden, um ihre Vertrauenswürdigkeit bei der Vergabe von Zertifikaten für öffentliche Schlüssel an Teilnehmer sicherzustellen. Bei der Abfassung des Dokuments wurde auf Einhaltung der Anforderungen der Certificate Policy (CP) for the European Public Key Infrastructure (PKI) (Zertifizierungskonzept für die europäische Infrastruktur für öffentliche Schlüssel, im Folgenden: PKI-CP) geachtet. Die PKI-CP der Europäischen Kommission und das vorliegende Dokument stehen in folgendem Zusammenhang: Die PKI-CP stellt das von der CommisSign CA verfolgte Konzept dar, während das CPS die Umsetzung dieses Konzepts im Einzelnen beschreibt.

Weitere Informationen zum Konzept der CommisSign CA, das dem CPS zugrunde liegt, entnehmen Sie bitte dem Dokument Certificate Policy (CP) for the European Public Key Infrastructure (PKI).

1.1. Überblick

Diese Spezifikation orientiert sich an und ist konform mit Teil 4 des Certificate Policy and Certification Practice Statement Framework der Internet Engineering Task Force Public Key Infrastructure X.509 (IETF PKIX).


9/10

Adressaten dieses Dokuments sind die Europäische Kommission und andere, die die Vertrauenswürdigkeit der CommisSign CA bewerten und entscheiden müssen, ob die Zertifikate der CommisSign CA ihren Anforderungen an die Sicherheit elektronischer Informationen entsprechen.

Sofern nicht anders angegeben, bieten die in diesem Dokument dargestellten Praktiken mittlere Sicherheit. In dem Maße, wie die Europäische Kommission weitere Sicherheitsebenen ergänzt, wird das Dokument um die Beschreibung von Praktiken für diese Ebenen erweitert werden.

Das CPS der CommisSign CA beschreibt die Erstellung, Verwaltung und Verwendung von Zertifikaten für öffentliche Schlüssel der X.509 Version 3 für Anwendungen, die eine Kommunikation zwischen vernetzten Computer-Systemen erfordern, sowie für Anwendungen, die Integrität und Vertraulichkeit von elektronischen Informationen voraussetzen. Zu diesen Anwendungen gehören unter anderem E-Mail, Übertragungen von EU-Informationen bis einschließlich Geheimhaltungsgrad „EU – Nur für den Dienstgebrauch“ und die digitale Signatur elektronischer Formulare. Beachten Sie bitte, dass sich der Begriff „X.509-Zertifikate” in diesem Dokument auf Zertifikate der X.509 Version 3 bezieht. Beachten Sie außerdem, dass sich „PKI-Clientsoftware” oder „PKI-Software” auf die Software bezieht, die die PKI-Funktionalität innerhalb der Domain der CommisSign CA bietet.

Zertifikate für öffentliche Schlüssel gemäß den Regelungen dieses CPS

• dürfen nicht erteilt werden, um Informationen der Geheimhaltungsgrade „EU – Vertraulich“, „EU – Geheim“ und „EU – Streng geheim“ zu schützen;

• erlauben keine Rückschlüsse darauf, dass der Teilnehmer berechtigt ist, im Namen der Europäischen Kommission geschäftliche Vorgänge abzuwickeln.

Die PKI Policy Authority (PA, für Grundsatzentscheidungen zu CP und CPS in der gesamten PKI verantwortliche Stelle) der Europäischen Kommission bewertet dieses CPS. Sämtliche CPS von Zertifizierungsstellen innerhalb der PKI der Europäischen Kommission unterliegen der Genehmigung durch die PA.

Die Durchsetzbarkeit, Erstellung, Auslegung und Gültigkeit dieses CPS und des zugehörigen Zertifizierungskonzepts der CommisSign CA wird durch Vorschriften der Europäischen Kommission geregelt.

Die PA der Europäischen Kommission ist für die gesamte PKI der Europäischen Kommission verantwortlich. Sie bestimmt die Politik, die dem Betrieb der PKI der Europäischen Kommission zugrunde liegt. Der PA obliegt es unter anderem, darüber zu wachen, dass die CommisSign CA ihre Aufgaben in Übereinstimmung mit den Konzepten und Praktiken erfüllt, die in den einschlägigen Dokumenten zu Zertifizierung und Zertifikaten festgelegt sind; darüber hinaus genehmigt und verwaltet die PA Cross-


10/10

Zertifizierungen. Die PA ist bei der Europäischen Kommission selbst angesiedelt.

Die Zertifizierungsstelle (CA) der Europäischen Kommission erstellt und verwaltet für den Gebrauch der Europäischen Kommission PKI-Zertifikate der X.509 Version 3, die mit der PKI-CP der Europäischen Kommission und mit diesem CPS übereinstimmen.

Die Europäische Kommission setzt eine zentrale Registration Authority (RA, Registrierungsstelle) und mehrere Local Registration Authorities (LRA, lokale Registrierungsstellen) ein, um Daten zu sammeln, Identitäten und Berechtigungen zu verifizieren und für den Kreis ihrer Nutzer Maßnahmen der Zertifikatsverwaltung anzufordern und zu genehmigen.

1.2. Dokumentidentifikation

Dieses Dokument ist das CPS der Zertifizierungsstelle der Europäischen Kommission. Die beschriebenen Praktiken entsprechen der Security Policy for the European Commission Public Key Infrastructure (PKI) (Sicherheitskonzept für die PKI der Europäischen Kommission, im Folgenden: PKI-Sicherheitskonzept).

1.3. Mitwirkende Stellen und Anwendungsbereich

Dieses CPS soll die allgemeinen Anforderungen der Europäischen Kommission an Zertifikate für öffentliche Schlüssel abdecken.

Die CommisSign CA ist eine Zertifizierungsstelle innerhalb der PKI der Europäischen Kommission.

1.3.1. Zertifizierungsstelle (CA)

Die CommisSign CA soll innerhalb der Europäischen Kommission und potenziell auch im E-Mailverkehr mit Organisationen und Personen außerhalb der Europäischen Kommission tätig werden.

Die CommisSign CA vergibt Zertifikate für öffentliche Schlüssel, signiert und verwaltet sie. Sie gibt Nutzerzertifikate nur nach Bedarf und ausschließlich an Kommissionsbedienstete aus.

Zur CommisSign CA gehören Personen, die für den allgemeinen Betrieb der Zertifizierungsstelle zuständig sind, sowie Personen, die die CA-Server und –Software betreiben und warten. Die CA Operations Authority (OA) erstellt und verwaltet das CPS und pflegt den Masterschlüssel. Die OA prüft den Betrieb der RA innerhalb ihrer CA-Domain. Sie erstattet der PA über Fragen des CA-Betriebs Bericht.

Die CA-Betreuer betreiben und verwalten die Server und die Software der Zertifizierungsstelle.

Die CommisSign CA:


11/10

• erstellt und signiert X.509-Zertifikate, die Kommissionsbedienstete und deren öffentliche Schlüssel miteinander verknüpfen;

• verbreitet X.509-Zertifikate über Verzeichnisse;

• gibt in Certificate Revocation Lists (CRL, Widerrufslisten) den Status von Zertifikaten bekannt; [nicht betriebsbereit]

• betreibt die Zertifizierungsstelle gemäß diesem CPS;

• genehmigt das Personal zur Besetzung von Stellen als PKI-Beauftragte;

• kontrolliert und auditiert den Betrieb der RA und LRA innerhalb ihrer Domain;

• regelt Konflikte zwischen den Endanwendern und der Zertifizierungsstelle, RA oder LRA;

• beantragt den Widerruf von Zertifikaten der PKI-Beauftragten oder RA.

Dieses CPS unterscheidet, wo nötig, zwischen den verschiedenen Nutzern und Rollen, die auf CA-Funktionen zugreifen. Wenn diese Unterscheidung nicht erforderlich ist, bezieht sich der Begriff CA auf die Gesamtheit der Zertifizierungsstelle einschließlich Software und Betrieb.

(* Hinweis: Cross-Zertifizierungen müssen gemäß diesem CPS und den weiteren Anforderungen der PA der Europäischen Kommission erfolgen. Alle Cross-Zertifizierungen zwischen Nutzern innerhalb der Kommission und anderen Zertifizierungsstellen müssen laut Anweisungen der PA der Kommission erfolgen. Wenn Zertifikate anderer Zertifizierungsstellen anerkannt werden, ist dies zu dokumentieren und die einschlägigen Haftungsausschlüsse sind den Nutzern in der Kommission zugänglich zu machen.)

1.3.2. Registrierungsstellen (RA)

Eine Registrierungsstelle ist eine Organisationseinheit, die im Auftrag der Zertifizierungsstelle der Kommission die Endanwender verwaltet. Es gibt eine zentrale Registrierungsstelle (RA) und mehrere lokale Registrierungsstellen (LRA).

Die Begriffe RA/LRA bezeichnen Personen innerhalb der Europäischen Kommission, die RA/LRA-Rechte haben und RA/LRA-Funktionen ausüben.

Die RA:

• identifiziert und authentifiziert die administrative Identität von Zertifikatsantragstellern;

• erstellt und ändert die Namen der Zertifikatsinhaber (Feld SubjectName) auf den Zertifikaten;


12/10

• überwacht die Audit-Protokolle und meldet verdächtige Ereignisse an die CA OA;

• erstellt verschiedene Berichte zum Status von Nutzern.

Die LRA:

• identifiziert und authentifiziert die physische Identität von Zertifikatsantragstellern;

• verifiziert die Authentizität eines Zertifikatsantrags;

• verifiziert den Namen (SubjectName) eines Zertifikatsinhabers;

• nimmt die Autorisierungsdaten von Teilnehmern entgegen und verteilt sie;

• erledigt Zertifizierungs- und Verwaltungsfunktionen für die Endanwender in ihrem Bereich, beispielsweise aktiviert sie Nutzer oder widerruft/suspendiert Zertifikate;

• aktualisiert [und widerruft] Zertifikate und sorgt für die Wiedererlangung der Schlüssel von Endanwendern.

1.3.3. Repositories

Die CommisSign CA veröffentlicht und verteilt die Zertifikate[, Authority Revocation Lists (ARL, Widerrufslisten von Cross-Zertifikaten)] und CRL im Verzeichnis der Europäischen Kommission. Die Direktion Datenverarbeitung verwaltet das Verzeichnis der Europäischen Kommission. Das Verzeichnis ist 24 Stunden täglich verfügbar, Support durch die Betreiber wird an fünf Tagen der Woche je 12 Stunden angeboten.

1.3.4. Teilnehmer

Teilnehmer benutzen geheime Schlüssel (private keys), die von der CommisSign CA für genehmigte Anwendungen [ausgegeben und/oder] zertifiziert wurden. Teilnehmer sind Kommissionsbedienstete.

Ein Zertifikat kann einer gemeinsamen Mailbox erteilt werden. In diesem Fall muss die für diesen nicht-menschlichen Endanwender zuständige Person ein Zertifikat für die Mailbox anwenden und pflegen. Diese Person kann ihre Rechte an eine weitere Person als Vertretung delegieren.

Teilnehmer können die Zertifikate der CommisSign CA ferner verwenden, um Informationen für andere Teilnehmer zu verschlüsseln und deren digitale Signaturen zu verifizieren. Sie dürfen dies für Teilnehmer innerhalb der CommisSign-CA-Domain und in cross-zertifizierten Domains tun. In dieser Eigenschaft sind Teilnehmer auch vertrauende Parteien (relying parties).

Der Begriff Endanwender wird in diesem CPS für Benutzer im Allgemeinen verwendet und schließt ihre Rollen als Teilnehmer und als vertrauende Partei ein. Muss im Rahmen dieses CPS zwischen den beiden Rollen


13/10

unterschieden werden, so bezeichnet der Begriff Teilnehmer den Endanwender in seiner Eigenschaft als Zertifikatsinhaber, während der Begriff vertrauende Partei den Endanwender bezeichnet, der von der CommisSign CA ausgegebene Zertifikate verifiziert.

1.3.5. Vertrauende Parteien

Vertrauende Partei kann entweder ein Zertifikatsinhaber der CommisSign CA oder der Teilnehmer einer externen CA sein, wenn die externe CA der CommisSign CA vertraut [oder eine Vereinbarung zur Cross-Zertifizierung mit der CommisSign CA unterschrieben hat]. Rechte und Pflichten einer vertrauenden Partei, die Zertifikatsinhaber der CommisSign CA ist, sind in diesem CPS festgelegt. [Rechte und Pflichten einer vertrauenden Partei, die zu einer externen CA gehört, sind in einer Vereinbarung zur Cross-Zertifizierung zwischen den beiden CA-Eigentümern festgelegt.]

1.3.6. Anwendungsbereich

Die in diesem CPS festgelegte Praxis gilt für die CommisSign CA und ihre Administratoren, die RA der Europäischen Kommission und ihre Administratoren, das von der CommisSign CA verwendete Repository, für von der CommisSign CA zertifizierte Endanwender und vertrauende Parteien.

Die in diesem CPS festgelegte Praxis ist geeignet für den Einsatz von Zertifikaten bei der elektronischen Authentifizierung, bei der Autorisierung und zur Sicherstellung der Datenintegrität von Informationen der Europäischen Kommission bis einschließlich zur Ebene als „critical“ eingestufter Informationssysteme (siehe ICT Security Policy (IKT-Sicherheitskonzept)).

Die in diesem CPS festgelegte Praxis ist geeignet für den Einsatz von Zertifikaten für Informationen der Europäischen Kommission bis einschließlich Geheimhaltungsgrad „EU – Nur für den Dienstgebrauch“ (siehe ICT Security Policy).

Als nicht autorisiert gelten die von der PA der Europäischen Kommission als solche gekennzeichneten Anwendungen. Allgemein sind solche Anwendungen für den Einsatz von Zertifikaten untersagt, die

• Informationen der Geheimhaltungsgrade „EU – Vertraulich“, „EU – Geheim“ und „EU – Streng geheim“ verwenden oder enthalten;

• keinen Bezug zur Arbeit der Kommission haben.

1.4. Kontakt

Für dieses CPS ist die Direktion SPS – Dienst Protokoll und Sicherheit – der Europäischen Kommission zuständig.

Ihr Ansprechpartner ist:

Herr Gérard BREMAUD


14/10

CommisSign CA Operations Authority

Dienst Protokoll und Sicherheit

Jean-Monnet-Gebäude B2/072

L-2920 LUXEMBURG

2. ALLGEMEINE BESTIMMUNGEN

2.1. Pflichten

2.1.1. Pflichten der CA

Die CommisSign CA hat alle Regelungen des IKT-Sicherheitskonzepts, dieses CPS und alle einschlägigen europäischen und nationalen Vorschriften einzuhalten.

Die CommisSign CA muss:

• ein CPS verfassen, pflegen und veröffentlichen;

• die Dienste einer CA entsprechend der in diesem CPS festgelegten Praxis anbieten;

• den CA-Server 24 Stunden täglich an allen Tagen der Woche verfügbar halten; dabei gilt jedoch die Vereinbarung, dass daraus keine Garantie für 100-prozentige Verfügbarkeit abzuleiten ist (die Verfügbarkeit kann durch Wartung und Reparatur des Systems oder durch Umstände, die sich der Kontrolle der CA entziehen, eingeschränkt werden);

• Zertifikate für Bedienstete der Europäischen Kommission [und für andere CA] herausgeben; dabei muss sie sich an die in diesem CPS und der X.509-PKI-CP der Europäischen Kommission dargestellte Praxis halten;

• Zertifikate widerrufen, wenn sie eine entsprechende gültige Anforderung erhält; dabei muss sie sich an die in diesem CPS und der X.509-PKI-CP der Europäischen Kommission dargestellte Praxis halten;

• einen Dienst zum Wiedererlangen von Kryptografieschlüsseln bereitstellen; dabei muss sie sich an die in diesem CPS und der X.509-PKI-CP der Europäischen Kommission dargestellte Praxis halten;

• in regelmäßigen Abständen Widerrufslisten von Zertifikaten (CRL) [und Widerrufslisten von Cross-Zertifikaten (ARL)] erstellen und veröffentlichen, wie in diesem CPS und der X.509-PKI-CP der Europäischen Kommission dargestellt;

• Dritte (beispielsweise vertrauende Parteien) benachrichtigen, wenn Zertifikate ausgegeben oder widerrufen werden, indem sie ihnen Zugang zu den Zertifikaten[, ARL] und CRL im Repository der CommisSign CA ermöglicht;


15/10

• für die Kenntnis und Einhaltung dieses CPS im Kreis der CommisSign-CA-Teilnehmer und RA sorgen, indem sie das CPS und die X.509-PKI-CP der Europäischen Kommission veröffentlicht und die RA in der Domain der CommisSign CA in einer Konformitätsprüfung auditiert;

• in Abstimmung mit der PA der Europäischen Kommission Abhilfe für Mängel schaffen, die in einer Konformitätsprüfung bei CA oder RA festgestellt wurden;

• der PA über den Stand der Abhilfemaßnahmen Bericht erstatten.

Teilnehmerzertifikate werden bei ihrer Erstellung im Verzeichnis der Europäischen Kommission veröffentlicht. Wird das Zertifikat eines Teilnehmers widerrufen, wird es in die CRL eingetragen und im Verzeichnis der Europäischen Kommission veröffentlicht.

Die CommisSign CA bestätigt durch die Veröffentlichung eines Zertifikats im Verzeichnis der Europäischen Kommission, dass sie für den genannten Teilnehmer ein Zertifikat ausgestellt hat, dass die Informationen im Zertifikat gemäß diesem CPS verifiziert wurden und dass der Teilnehmer das Zertifikat akzeptiert hat.

Die CommisSign CA unterrichtet Teilnehmer und vertrauende Parteien über ihre Rechte und Pflichten gemäß diesem CPS durch die Veröffentlichung des CPS und der X.509-PKI-CP der Europäischen Kommission.

Ihre geheimen Schlüssel schützt die CommisSign CA gemäß den Vorschriften in Abschnitt 6 dieses CPS.

[Eigene oder im Auftrag gehaltene geheime Schlüssel schützt die CommisSign CA gemäß den Vorschriften in den Abschnitten 4 und 6 dieses CPS.]

Der Signaturschlüssel der CommisSign CA dient zur Signatur von Zertifikaten und CRL.

[Cross-Zertifikate mit anderen CA darf die CommisSign CA nur nach ausdrücklicher Autorisierung durch die PA der Europäischen Kommission ausgeben und signieren.]

2.1.2. Pflichten der RA und LRA

RA und LRA der Europäischen Kommission in der Domain der CommisSign CA sind verpflichtet, die Auflagen dieses CPS und der X.509-PKI-CP der Europäischen Kommission einzuhalten.

Die RA muss:

• RA-Dienste für die jeweiligen LRA bereithalten; die Betriebszeiten der RA entsprechen den normalen Arbeitszeiten der Kommission;

• sicherstellen, dass die Dienste der RA den Auflagen dieses CPS und der X.509-PKI-CP der Europäischen Kommission entsprechen;


16/10

• Transaktionen im Auftrag der CA verantworten;

• ihre Teilnehmer auf alle einschlägigen Informationen bezüglich Rechte und Pflichten der CA, RA und der Teilnehmer aufmerksam machen, die in diesem CPS, in der Teilnehmervereinbarung und anderen einschlägigen Dokumenten festgelegt sind, die Nutzungsvereinbarungen und -bedingungen enthalten.

Wenn sich die RA am CA-Server anmeldet, um eine Zertifikatsanforderung zu bearbeiten, bestätigt sie damit, dass sie die Identität dieses Teilnehmers gemäß Abschnitten 3 und 4 dieses CPS authentisiert hat.

LRA sind verpflichtet,

• Richtigkeit und Authentizität der Informationen zu verifizieren, die Teilnehmer für ein Zertifikat bereitstellen (diese Verifizierung erledigen die LRA im Auftrag der CommisSign CA);

• [den Widerruf eines Teilnehmerzertifikats gemäß den Auflagen in diesem Dokument anzufordern;]

• sicherzustellen, dass die Dienste der LRA den Auflagen dieses CPS und der X.509-PKI-CP der Europäischen Kommission entsprechen;

• Transaktionen im Auftrag der CA zu verantworten;

• die Bearbeitung von Anträgen auf Ausgabe [und Widerruf] eines Zertifikats zu verantworten;

• den Teilnehmer zu benachrichtigen, wenn der Antrag genehmigt wurde, und wenn weitere Aktionen des Teilnehmers erfolgen müssen.

Jede RA und LRA muss sicherstellen, dass ihre geheimen Schlüssel gemäß den Schutzmechanismen geschützt werden, die in Abschnitt 6 dieses CPS festgelegt sind.

RA und LRA dürfen ihre geheimen Schlüssel ausschließlich im Auftrag der Europäischen Kommission verwenden; die Zwecke müssen durch die X.509-PKI-CP der Europäischen Kommission autorisiert sein und im Einklang mit diesem CPS stehen.

2.1.3. Pflichten der Teilnehmer

In der Domain der CommisSign CA sind Endanwender sowohl Teilnehmer als auch vertrauende Parteien. Als Teilnehmer sind sie verpflichtet,

• sowohl gegenüber der CommisSign CA als auch der RA stets wahrheitsgemäße Angaben zu machen, was ihre Zertifikate und andere Angaben zur Identifizierung und Authentifizierung betrifft;

• Zertifikate ausschließlich für rechtmäßige und autorisierte Tätigkeiten der Europäischen Kommission zu verwenden, die mit der einschlägigen CP und diesem CPS vereinbar sind;


17/10

• geheime Schlüssel sicher aufzubewahren, indem sie sie entweder auf Festplatte [, Smartcard] oder Diskette speichern, je nach Vorgaben der Generaldirektion (GD);

• das Zubehör für ihren geheimen Schlüssel aus dem Computer zu entfernen, wenn sie ihn nicht benutzen, sofern sich die geheimen Schlüssel auf Diskette [oder Smartcard] befinden;

• das Zubehör für ihren geheimen Schlüssel mit sich zu führen oder in einem verschlossenen und sicheren Behälter aufzubewahren, sofern sich die geheimen Schlüssel auf Diskette [oder Smartcard] befinden;

• ihr Teilnehmerpasswort gemäß den Regeln des IKT-Sicherheitskonzepts zu schützen;

• ihre lokale RA innerhalb von 48 Stunden über alle Änderungen zu informieren, die Daten zum Zertifikat oder Zertifikatsantrag betreffen;

• ihre lokale RA innerhalb von 8 Stunden zu informieren, wenn einer oder beide geheimen Schlüssel kompromittiert worden sein könnten;

• angemessene Vorkehrungen zu treffen, damit ihre geheimen Schlüssel weder verloren gehen noch von Dritten ausgespäht, geändert oder unbefugt genutzt werden können.

Teilnehmer erfüllen ihre Pflichten gemäß den Sicherheits- und Zertifizierungskonzepten, nach denen ihre Zertifikate ausgegeben wurden, indem sie die in diesem CPS festgelegten Praktiken befolgen.

[Mit seiner Signatur unter eine Zertifikatsanforderung (beispielsweise Ausgabe, Widerruf, Wiedererlangung) bestätigt ein Teilnehmer der CommisSign CA und RA, dass alle Daten vollständig und richtig sind, die er oder sie dieser CA oder RA übermittelt hat.]

Teilnehmer dürfen ihre geheimen Schlüssel ausschließlich für Arbeiten der Europäischen Kommission verwenden; die Zwecke müssen durch die X.509-PKI-CP der Europäischen Kommission autorisiert sein und im Einklang mit diesem CPS stehen.

2.1.4. Pflichten der vertrauenden Partei

In der Domain der CommisSign CA sind Endanwender sowohl Teilnehmer als auch vertrauende Parteien. Als vertrauende Parteien sind sie verpflichtet,

• beim Einsatz von Zertifikaten der CommisSign CA die Zweckbindung einzuhalten, in Übereinstimmung mit der X.509-PKI-CP der Europäischen Kommission und mit diesem CPS;

• Zertifikate zu verifizieren, unter anderem, indem sie CRL [und ARL] nutzen [und dabei Erweiterungen berücksichtigen, die als „critical“ definiert sind]. [(Die Verifizierung von Zertifikaten erfolgt in Übereinstimmung mit der Validierungsprozedur für die Zertifikatskette (certification path), die in ITU-T Recommendation X.509 Information


18/10

Technology – Open Systems Interconnection – The Directory: Authentication Framework ISO/IEC 9594-8 (1997) festgelegt ist.)]

• Zertifikate nur dann einzusetzen und sich auf sie zu verlassen, wenn zwischen Zertifikatsinhaber und vertrauender Partei eine gültige Zertifikatskette besteht.

Bevor vertrauende Parteien Zertifikate von Teilnehmern nutzen, müssen sie sich vergewissern, dass die Zertifikate für den geplanten Einsatz geeignet sind, indem sie prüfen, nach welcher CP und welchem CPS das Zertifikat ausgegeben wurde.

Vertrauende Parteien müssen die CommisSign-CA-Signatur und die Gültigkeitsdauer eines Zertifikats prüfen, bevor sie dessen öffentlichen Schlüssel nutzen. Die vertrauende Partei muss außerdem die digitale Signatur des Teilnehmers verifizieren, bevor sie digital signierte Daten akzeptiert. Beide Parteien sollten sicherstellen, dass sie kompatible Software benutzen, wenn die Verifizierung automatisch durch ein kryptografisches Verfahren mit entsprechender Hard- und Software auf den Rechnern der vertrauenden Parteien erfolgt.

Bevor vertrauende Parteien ein Zertifikat verwenden, müssen sie den Status des Zertifikats anhand einer aktuellen CRL prüfen. Die vertrauende Partei muss die digitale Signatur auf der CRL verifizieren, um sicherzustellen, dass sie von der CommisSign CA stammt.

2.1.5. Pflichten des Repository

[Wurzelzertifikate der CommisSign CA, CPS, CRL [und Teilnehmerzertifikate] erhalten die vertrauenden Parteien gemäß Abschnitt 4.4.9 „CRL-Ausgabeturnus“ dieses CPS.]

2.2. Haftung [vom Juristischen Dienst zu überprüfen]

[Die Europäische Kommission stellt sowohl die Funktionen der CommisSign CA als auch die der RA zur Verfügung, weshalb die Haftung für beide Funktionen in diesem CPS zusammengefasst ist.]

Die CommisSign CA, RA, LRA und die Europäische Kommission haften nicht für die Verwendung von PKI-Zertifikaten der Europäischen Kommission oder der zugehörigen Paare von öffentlichen und geheimen Schlüsseln außer für die Verwendungszwecke, die in der PKI-CP der Europäischen Kommission und in diesem CPS beschrieben sind.

2.2.1. Gewährleistung und Einschränkungen der Gewährleistung

Die CommisSign CA und RA gewährleisten und sichern zu,

• dass sie Zertifizierungsdienste in Übereinstimmung mit der X.509-PKI-CP der Europäischen Kommission und mit diesem CPS leisten;

• dass sie die Identifizierungs- und Authentifizierungsverfahren gemäß Abschnitt 3 dieses CPS durchführen;


19/10

• dass sie die Schlüsselverwaltung einschließlich Ausgabe der Zertifikate, Veröffentlichung, Widerruf, Wiedererlangung und Aktualisierung von Schlüsseln in Übereinstimmung mit der X.509-PKI-CP der Europäischen Kommission und mit diesem CPS leisten.

Über die Darlegungen, Gewährleistungen und Konditionen hinaus, die ausdrücklich in der X.509-PKI-CP der Europäischen Kommission und in diesem CPS festgelegt sind, geben die Europäische Kommission und ihre Mitarbeiter keine Zusagen, weder explizit noch implizit.

2.2.2. Haftungsausschluss und –beschränkungen

Die Europäische Kommission und die CommisSign CA und RA haften nicht für

• den Ausfall von CA- oder RA-Diensten im Kriegsfall, bei Naturkatastrophen oder anderer höherer Gewalt;

• Schäden, die durch die Verzögerung zwischen dem Widerruf eines Zertifikats und der nächsten planmäßigen Ausgabe einer CRL entstehen;

• Schäden durch unberechtigte Nutzung von Zertifikaten der CommisSign CA und durch die Nutzung für Zwecke außerhalb derjenigen, die in der X.509-PKI-CP der Europäischen Kommission und in diesem CPS festgelegt sind;

• Schäden, die durch betrügerische oder fahrlässige Nutzung von Zertifikaten und/oder CRL [und/oder ARL] der CommisSign CA entstehen;

• Schäden durch die Offenlegung persönlicher Daten aus Zertifikaten und Widerrufslisten.

Die CommisSign CA und RA schließen die Gewährleistung und Verpflichtungen jeglicher Art aus, darunter für Marktgängigkeit, Eignung für bestimmte Zwecke, Richtigkeit der bereitgestellten Informationen (außer der Zusicherung, dass die Informationen aus autorisierter Quelle stammen); sie schließen außerdem jegliche Gewährleistung für Schäden durch Fahrlässigkeit oder mangelnde Sorgfalt der Teilnehmer und vertrauenden Parteien aus.

Die Europäische Kommission, CommisSign CA, RA und LRA lehnen jede Haftung gleich aus welchem Rechtsgrund in Bezug auf Dienstleistungen im Zusammenhang mit der Ausgabe, Verwendung oder dem Vertrauen auf PKI-Zertifikate der Europäischen Kommission oder das zugehörige Schlüsselpaar von öffentlichem und geheimem Schlüssel, die von Teilnehmern oder vertrauenden Parteien verwendet werden, ab.

Antragsteller und vertrauende Parteien haben keinen Anspruch auf Ersatz für Schäden, die aus einer zweckfremden oder betrügerischen Nutzung dieser PKI entstehen.


20/10

CommisSign CA und RA sind auch keine Vermittler bei Transaktionen zwischen Teilnehmern und vertrauenden Parteien. Ansprüche gegenüber der CommisSign CA und/oder RA sind auf solche Fälle beschränkt, in denen der Betrieb einer CA oder RA nachgewiesenermaßen nicht der X.509-PKI-CP der Europäischen Kommission und diesem CPS entspricht.

2.2.3. Weitere Vereinbarungen und Bedingungen

[Keine Vereinbarungen.]

2.3. Finanzielle Verantwortung

2.3.1. Entschädigung durch vertrauende Parteien

Keine Vereinbarungen.

2.3.2. Treuhänderische Beziehungen

Aus der Vergabe von Zertifikaten durch die CommisSign CA und der Unterstützung bei dieser Vergabe durch die RA der Europäischen Kommission erwächst weder der Europäischen Kommission, ihrer CA oder RA die Rolle eines Agenten, Treuhänders, Sachwalters oder sonstigen Repräsentanten von Antragstellern oder vertrauenden Parteien noch ergibt sich daraus eine Verantwortung anderer, die die PKI der Europäischen Kommission nutzen.

2.4. Auslegung und Durchsetzung

2.4.1. Geltendes Recht

Für die Durchsetzung, Erstellung, Auslegung und Gültigkeit dieses CPS gilt das nationale und europäische Recht.

2.4.2. Aufteilung, Fortbestehen, Zusammenlegung, Kündigung

Eine Aufteilung oder Zusammenlegung kann zu Änderungen im Zuständigkeitsbereich, der Verwaltung und/oder dem Betrieb der CommisSign CA führen. In einem solchen Fall kann es auch erforderlich werden, die X.509-PKI-CP der Europäischen Kommission und dieses CPS zu ändern. Änderungen im Betrieb erfolgen gemäß den Verfahrensanforderungen in Abschnitt 8 dieses CPS.

2.4.3. Streitbeilegungsverfahren

Falls Streitigkeiten im Zusammenhang mit der Verwaltung der Schlüssel und Zertifikate zwischen der Europäischen Kommission und einer Organisation oder Person außerhalb der Europäischen Kommission auftreten, ist ein geeignetes Streitbeilegungsverfahren einzusetzen. Die Streitigkeiten sind möglichst in Verhandlungen beizulegen. Lässt sich ein Konflikt nicht durch Verhandlungen bereinigen, ist er durch Schiedsspruch der PA der Europäischen Kommission zu lösen.


21/10

In der Domain der CommisSign CA sind Streitfälle zwischen Nutzern innerhalb der Europäischen Kommission, bei denen eine Partei Teilnehmer und die andere vertrauende Partei ist, oder zwischen Nutzern innerhalb der Europäischen Kommission und der CA oder RA zunächst an die CommisSign CA OA zur Beilegung zu verweisen.

2.5. Gebühren


2.6. Veröffentlichung und Repository

2.6.1. Veröffentlichung von Informationen der CA

Die CommisSign CA veröffentlicht:

• CommisSign-Wurzelzertifikate auf einer Website;

• dieses CPS [und die ICT Security Policy der Europäischen Kommission] auf einer Website;

• alle von der CommisSign CA ausgegebenen Zertifikate für öffentliche Schlüssel im Verzeichnis der Europäischen Kommission;

• die aktuelle CRL mit den Zertifikaten für öffentliche Nutzerschlüssel, die durch die CommisSign CA widerrufen wurden, im Verzeichnis der Europäischen Kommission und auf einer Website;

• [die aktuelle ARL mit den Cross-Zertifikaten der externen CA, die durch die PA der Europäischen Kommission widerrufen wurden, im Verzeichnis der Europäischen Kommission.]

2.6.2. Veröffentlichungsturnus

Durch die CommisSign CA ausgegebene Zertifikate werden nach ihrer Aktivierung einmal täglich im Verzeichnis der Europäischen Kommission aktualisiert. Widerrufene Zertifikate werden in CRL eingetragen, die gemäß Abschnitt 4.4.9 „CRL-Ausgabeturnus“ dieses CPS veröffentlicht werden. [Widerrufene Cross-Zertifikate werden in ARL eingetragen, die gemäß Abschnitt 4.4.9 „CRL-Ausgabeturnus“ dieses CPS veröffentlicht werden.]

2.6.3. Zugriffsrechte

Für das CPS der CommisSign CA und die PKI-CP der Europäischen Kommission besteht nur Leserecht; beides ist auf der Website verfügbar. Schreib- oder Änderungsrecht für diese Dokumente haben nur Mitarbeiter der CommisSign CA.

[Für die Zertifikate und CRL besteht nur Leserecht; sie sind im Verzeichnis der Europäischen Kommission verfügbar. Nur die CommisSign CA hat Schreib- und Lese- sowie Löschrecht.]


22/10

2.6.4. Repositories

Das Repository für von der CommisSign CA ausgegebene Zertifikate[, ARL] und CRL wird vom Verzeichnissystem der Europäischen Kommission bereitgestellt. [Auf das Verzeichnis wird mit Lightweight Directory Access Protocol (LDAP) Version 2 zugegriffen, gemäß Request for Comment (RFC) 1777 Lightweight Directory Access Protocol (1995). LDAP Version 2 wird mit TCP benutzt, gemäß Abschnitt 3.1 RFC 1777.]

[Bei der Übertragung von LDAP Anforderungen und Ergebnissen werden die in X.500 definierten Attribute nach der Zeichenketten-Darstellung kodiert, die in RFC 1778, String Representation of Standard Attribute Syntaxes (1995) festgelegt ist. Diese Zeichenketten-Kodierung basiert auf den Attributdefinitionen aus X.500 (1988). Daher gelten die folgenden Zeichenketten-Darstellungen für Zertifikate und CRL der Version 1:

• userCertificate (RFC 1778 Abschnitt 2.25)

• CACertificate (RFC 1778 Abschnitt 2.26)

• authorityRevocationList (RFC 1778 Abschnitt 2.27)

• certificateRevocationList (RFC 1778 Abschnitt 2.28)

• crossCertificatePair (RFC 1778 Abschnitt 2.29)

Da das vorliegende CPS Zertifikate der Version 3 und CRL der Version 2 nutzt, wie in X.509 definiert, passt die Zeichenketten-Kodierung laut RFC 1778 nicht für diese Attribute. Die Attribute werden daher nach einer Syntax kodiert, die der Undefined-Syntax aus Abschnitt 2.1 der RFC 1778 entspricht: Attributwerte werden wie Werte vom Typ OCTET STRING kodiert, der Zeichenkettenwert für die Kodierung ist die DER-Kodierung des Wertes selbst.]

Das Repository für dieses CPS und die PKI-CP der Europäischen Kommission ist auf folgender Website verfügbar: [wird nachgeliefert - URL noch zuzuweisen].

2.7. Konformitätsprüfung [noch nicht implementiert] [Review nach Implementierung]

2.7.1. Turnus der Konformitätsprüfung

Der Betrieb der CommisSign CA wird jährlich formal und vollständig geprüft.

Die PA kann jederzeit eine Konformitätsprüfung durch einen Auditor anordnen.

Die CommisSign CA behält sich das Recht vor, für jede RA-Einrichtung in ihrer Domain turnusmäßig wie außerturnusmäßig Inspektionen und Prüfungen anzuordnen. Auf diese Weise soll sichergestellt werden, dass der


23/10

RA-Betrieb der Sicherheitspraxis und den Verfahren in diesem CPS entspricht.

2.7.2. Person und Qualifikation eines CA-Auditors

Personen oder Einheiten, die eine Konformitätsprüfung durchführen sollen, müssen von der PA genehmigt werden. Der Auditor muss folgende Anforderungen erfüllen: Sicherheitsaudits von Zertifizierungsstellen und Informationssystemen müssen seine Hauptaufgabe darstellen; er muss ausreichende Erfahrung mit PKI- und Kryptografie-Technik und der Handhabung wichtiger PKI-Software nachweisen und mit den Vorschriften und den Sicherheits- und Zertifizierungskonzepten der Europäischen Kommission vertraut sein.

2.7.3. Verhältnis des Auditors zur geprüften CA

Der von der PA genehmigte Auditor und die CommisSign CA sind voneinander unabhängige Einheiten in der Organisationsstruktur der Europäischen Kommission.

2.7.4. Gegenstand der Konformitätsprüfung

Im Rahmen einer Konformitätsprüfung wird geprüft, wie die CommisSign CA und die RA die technische, verfahrenstechnische und personalbezogene Praxis umsetzen, die in diesem CPS festgelegt ist. Dazu gehören folgende Prüfbereiche:

• Identifizierung und Authentifizierung,

• Funktionen und Dienste im Betrieb,

• physische, verfahrenstechnische und personalbezogene Sicherheitsmaßnahmen,

• technische Sicherheitsmaßnahmen.

2.7.5. Maßnahmen, die aufgrund einer Konformitätsprüfung zu treffen sind

Falls Mängel aufgedeckt werden, sind drei Vorgehensweisen möglich:

(1) Betrieb wie bisher aufrechterhalten,

(2) Betrieb aufrechterhalten, aber mit geringeren Sicherheitszusagen,

(3) Betrieb einstellen.

Wenn ein Mangel aufgedeckt wird, entscheidet der Auditor unter Mitwirkung der PA der Europäischen Kommission über das weitere Vorgehen. Welche der angegebenen Vorgehensweisen gewählt wird, hängt davon ab, wie gravierend die Mängel sind, welche Risiken entstehen und welche Auswirkungen die Unterbrechung des Betriebs für die Teilnehmer hat.


24/10

Wird die erste oder zweite Vorgehensweise gewählt, stellen die PA der Europäischen Kommission und die OA sicher, dass innerhalb von 30 Tagen Abhilfe geschaffen wird. Bei Ablauf dieser Frist – mit Genehmigung der PA und des Auditors auch zu einem früheren Zeitpunkt – findet eine erneute Bewertung durch den Auditor statt. Erweist sich bei dieser erneuten Prüfung, dass keine Abhilfemaßnahmen getroffen wurden, entscheidet der Auditor, ob ein härteres Vorgehen erforderlich ist (beispielsweise Vorgehensweise 3).

Im Falle der Betriebseinstellung werden zuvor alle von der CommisSign CA ausgegebenen Zertifikate widerrufen, einschließlich Endanwender-Zertifikaten und Cross-Zertifikaten für CA.

Die PA und die CA OA der Europäischen Kommission sind dafür verantwortlich, dass der Stand der Abhilfemaßnahmen dem Auditor wöchentlich gemeldet wird. Die PA und der Auditor entscheiden gemeinsam über den Zeitpunkt einer erneuten Bewertung. Wird bei der erneuten Bewertung festgestellt, dass die Mängel beseitigt wurden, nimmt die CommisSign CA den Betrieb wieder auf und gibt neue Zertifikate an die Endanwender und andere externe CA aus. Sie geht dabei so vor, wie es in den jeweiligen Vereinbarungen zur Cross-Zertifizierung festgelegt wurde.

2.7.6. Bekanntgabe des Prüfungsberichts

Die Ergebnisse der jährlichen Konformitätsprüfung werden der PA der Europäischen Kommission, der CommisSign CA und den IT-Sicherheitsbeauftragten aller LRA der Europäischen Kommission mitgeteilt. Wenn die Vorgehensweise 2 gewählt wurde, entscheidet die PA der Europäischen Kommission unter Mitwirkung des Auditors, ob die Teilnehmer informiert werden müssen. Wenn die Vorgehensweise 3 gewählt wurde, stellt die PA der Europäischen Kommission sicher, dass alle Nutzer informiert werden. Wenn möglich, werden die Teilnehmer über Mängel und das folgende Vorgehen per E-Mail unterrichtet. Teilnehmer, die keinen E-Mailzugang haben, werden auf dem Postweg benachrichtigt.

Art und Umfang der Bekanntgabe des Prüfungsberichts an durch die CommisSign CA cross-zertifizierte CA wird in der Vereinbarung zur Cross-Zertifizierung zwischen den Parteien festgelegt. Ohne entsprechende Festlegung in einer Vereinbarung zur Cross-Zertifizierung findet keine Bekanntgabe des Prüfungsberichts außerhalb der Europäischen Kommission statt.

2.8. Vertraulichkeitskonzept

Informationen sind vertraulich, wenn sie nicht von der PA der Europäischen Kommission als öffentlich eingestuft werden.

2.8.1. Vertraulich zu behandelnde Informationen

Die geheimen Signaturschlüssel von Teilnehmern sind nur dem betreffenden Teilnehmer zugänglich. Die CommisSign CA und die zentrale Registrierungsstelle haben keinen Zugang zu diesen Schlüsseln.


25/10

Der geheime Vertraulichkeitsschlüssel eines Teilnehmers ist nur dem betreffenden Teilnehmer zugänglich.

Vorübergehend ist nur ein Satz von öffentlichem und geheimem Schlüssel verfügbar, der auf den Vertraulichkeitsschlüssel zurückgeht. Die Regeln für Signaturschlüssel sind nicht anwendbar. Vertraulichkeitsschlüssel werden von der LRA gesichert und gemäß Abschnitt 6 dieses CPS geschützt.

Informationen aus Audit-Protokollen sind nur der Europäischen Kommission zugänglich und werden außerhalb der Europäischen Kommission nur dann veröffentlicht, wenn geltendes Recht dies verlangt.

Personenbezogene Daten und ihre Erhebung, Pflege, Speicherung und ihr Schutz können der Verordnung Nr. 45/2001 des Europäischen Parlaments und des Rates vom 18. Dezember 2000 unterliegen. Personenbezogene Daten, die lokal von der CommisSign CA oder der Registrierungsstelle gespeichert werden, werden als „EU – Nur für den Dienstgebrauch“ eingestuft und dürfen nur denjenigen zugänglich gemacht werden, für deren offizielle Aufgaben sie erforderlich sind.

Personenbezogene Daten und Unternehmensdaten im Besitz der PA, CA und RA der Europäischen Kommission, soweit nicht ausdrücklich als Teil eines Zertifikats [, einer ARL] oder einer CRL veröffentlicht, werden als „EU – Nur für den Dienstgebrauch“ eingestuft und sind nur zugänglich, wenn geltendes Recht dies vorsieht.

Die Ergebnisse der jährlichen Konformitätsprüfung werden im Allgemeinen als „EU – Nur für den Dienstgebrauch“ eingestuft, Ausnahmen sind in Abschnitt 2.7 dieses CPS aufgeführt.

Logdateien von Konformitätsprüfungen sind im Allgemeinen nicht öffentlich zugänglich.

Schlüssel im Besitz der CommisSign CA werden als „EU – Nur für den Dienstgebrauch“ eingestuft und werden nur berechtigten Stellen der Europäischen Kommission zur Verfügung gestellt, und nur dann, wenn es mit diesem CPS und dem PKI-Sicherheitskonzept der Europäischen Kommission vereinbar ist. Einer Vollstreckungsbehörde werden sie dann zur Verfügung gestellt, wenn es mit den Vorschriften der Europäischen Kommission, mit geltendem Recht der Europäischen Union und der Mitgliedstaaten und mit diesem CPS vereinbar ist.

2.8.2. Als öffentlich zugänglich zu betrachtende Informationen

Informationen in von der CommisSign CA ausgegebenen öffentlichen Zertifikaten[, ARL] und CRL sind öffentlich.

Informationen in der PKI-CP der Europäischen Kommission und in diesem CPS sind öffentlich.


26/10

2.8.3. Zugang zu Informationen aus dem Widerruf von Zertifikaten

Wird ein Zertifikat von der CommisSign CA widerrufen, so wird der Eintrag in die CRL mit einem Code für den Anlass des Widerrufs versehen. Dieser Anlasscode ist öffentlich und kann allen anderen Teilnehmern und vertrauenden Parteien zugänglich gemacht werden. Weitere Angaben zum Widerruf werden nicht mitgeteilt.

2.8.4. Zugang zu Informationen für Vollstreckungsbehörden

Die CommisSign CA und RA geben keine Zertifikate oder Informationen aus Zertifikaten an Dritte heraus, es sei denn,

• sie sind dazu durch das PKI-Sicherheitskonzept der Europäischen Kommission und dieses CPS ermächtigt;

• die Herausgabe der Informationen wird aufgrund geltenden Rechts, Vorschriften der Europäischen Kommission, der Europäischen Union oder der Mitgliedstaaten oder aufgrund eines Gerichtsurteils verlangt;

• der Teilnehmer hat sie dazu berechtigt, um die angemessene Nutzung des Zertifikats sicherzustellen.

Anträge auf Zugang zu den Informationen müssen signiert und der lokalen RA der Europäischen Kommission oder der CommisSign CA zugestellt werden.

2.8.5. Sonstige Umstände, die den Zugang zu Informationen rechtfertigen


2.9. Rechte an geistigem Eigentum

Die Europäische Kommission hält die Rechte an von der CommisSign CA ausgegebenen Zertifikaten[, ARL] und CRL, an der PKI-CP der Europäischen Kommission und an diesem CPS.

3. IDENTIFIZIERUNG UND AUTHENTIFIZIERUNG

3.1. Erstregistrierung

3.1.1. Namenstypen

Die RA verwendet folgende Informationen aus dem Verzeichnissystem der Europäischen Kommission:

• Nachname des Teilnehmers (LASTNAME),

• Vorname des Teilnehmers (FIRSTNAME),

• CUID (Common User Identifier, allgemeine Nutzerkennung) des Teilnehmers (eindeutige, einheitliche interne Nutzerkennung),


27/10

• SMTP-E-Mailadresse des Teilnehmers bei der Kommission (SMTP).

Die RA geht davon aus, dass

• die CUID und SMTP des Teilnehmers innerhalb der Kommissionsdienststellen eindeutig sind;

• zwischen der CUID und der SMTP-E-Mailadresse des Teilnehmers bei der Kommission eine Eins-zu-eins-Relation besteht.

• Die RA bildet den Namen des Zertifikatsinhabers (SubjectName) folgendermaßen: /CN=LASTNAME FIRSTNAME (CUID) /E=SMTP.

Die RA trägt den SubjectName des Teilnehmers in die CA-Datenbank ein.

3.1.2. Aussagekraft von Namen

Wenn der Teilnehmer eine Einzelperson ist, enthält das Common-Name-Attribut den Namen des Teilnehmers.

Wenn der Teilnehmer eine Organisationseinheit ist, enthält das Common-Name-Attribut den Namen der gemeinsamen Mailbox.

3.1.3. Regelungen für die Interpretation von Namensformaten


3.1.4. Eindeutige Namen

Der SubjectName der Zertifikate ist innerhalb der Domain der CommisSign CA für alle Endanwender eindeutig. Die Nutzerverwaltung der Kommission hat dafür Sorge zu tragen, dass die CUID und SMTP-E-Mailadressen der Teilnehmer bei der Kommission eindeutig sind.

3.1.5. Verfahren für die Regelung von Namenskonflikten

Bei Namenskonflikten entscheidet die Nutzerverwaltung der Kommission.

3.1.6. Anerkennung, Authentifizierung und Rolle von Warenzeichen


3.1.7. Besitznachweis für geheime Schlüssel

Der Nachweis über den Besitz eines geheimen Schlüssels wird durch die Funktionsweise eines sicheren Übertragungsprotokolls automatisch erbracht.

3.1.8. Authentifizierung der Identität von Organisationen

Zertifikate für öffentliche Schlüssel werden möglichst für Einzelpersonen ausgestellt. Wenn mehrere Personen in einer Funktion tätig sind, wird nur ein Verschlüsselungszertifikat auf den Namen der gemeinsamen Mailbox ausgestellt. Zertifikate für die digitale Signatur werden für eine gemeinsame Mailbox nicht ausgestellt.


28/10

Einzelpersonen, die für eine gemeinsame Mailbox handeln, benutzen ihr persönliches Zertifikat für die digitale Signatur.

Eine gemeinsame Mailbox für eine Organisation muss von einer Einzelperson eingerichtet werden, die berechtigt ist, im Namen des potenziellen Teilnehmers zu handeln. Diese berechtigte Person muss innerhalb der Organisation für die Zertifikate und die zugehörigen geheimen Schlüssel zuständig sein und darüber wachen, wer wann über welche Schlüssel verfügt.

Die Identifizierung und Authentifizierung potenzieller Teilnehmer geschieht folgendermaßen:

• Die RA überprüft Identität und Berechtigungen der Person, die im Namen des potenziellen Teilnehmers handelt, und ihre Autorisierung, die Schlüssel für die Organisation entgegenzunehmen.

• Die RA oder CA bewahrt Art und Details der verwendeten Identifikation auf und archiviert den Namen des/der Verantwortlichen für die gemeinsame Mailbox, für die das Organisationszertifikat ausgegeben wurde.

Die Verfahren bei Ausgabe eines Organisationszertifikats kollidieren nicht mit anderen Vereinbarungen in diesem CPS (beispielsweise Generierung der Schlüssel, Schutz geheimer Schlüssel, Pflichten der Nutzer).

[Wenn die CommisSign CA Cross-Zertifikate an andere CA ausgibt, tut sie dies mit Zustimmung der PA der Europäischen Kommission. Die PA der Europäischen Kommission prüft Konzepte und Verfahren der anderen CA, bevor sie eine Cross-Zertifizierung genehmigt. Der anderen CA ihrerseits werden das CPS der CommisSign CA und die X.509-PKI-CP der Europäischen Kommission zur Prüfung vorgelegt.]

3.1.9. Authentifizierung der Identität von Einzelpersonen

Wenn eine Einzelperson Teilnehmer werden möchte, muss sie dies selbst beantragen oder durch Vorgesetzte beantragen lassen. Wenn Vorgesetzte den Antrag stellen, müssen sie den Teilnehmer darüber informieren. Für potenzielle Teilnehmer erfolgt die Identifizierung und Authentifizierung wie unten beschrieben; zusätzlich müssen sie persönlich zur Authentifizierung bei ihrer LRA erscheinen, bevor das Zertifikat ausgegeben werden kann.

Die RA lässt sich die Zugehörigkeit des Teilnehmers zur Europäischen Kommission bestätigen. Dabei muss sie eine Bestätigung über die Identität des Teilnehmers einholen, der ein Zertifikat beantragt. Das Authentifizierungsverfahren umfasst die in den folgenden Abschnitten beschriebenen Prozesse.

3.1.10. Authentifizierung der Kommissionszugehörigkeit eines Teilnehmers

Die Zugehörigkeit eines Teilnehmers zur Europäischen Kommission muss gegenüber der RA nachgewiesen werden, bevor sie ein Zertifikat an den Teilnehmer ausgeben kann. Der Nachweis der Zugehörigkeit eines


29/10

Teilnehmers wird durch das Verzeichnis der Europäischen Kommission geliefert. Verwaltungsverfahren sorgen für zutreffende Teilnehmereinträge im Verzeichnis der Europäischen Kommission.

3.1.11. Authentifizierung der Identität eines Teilnehmers

Die LRA verifiziert die Identität eines Teilnehmers spätestens bei der Beantragung des Zertifikats. Sie verwendet dazu die RA-Dateien und archiviert die Dokumentation über die Authentifizierung.

Die Identitätsbestätigung eines Teilnehmers muss von der LRA anhand des Dienstausweises verifiziert werden.

3.1.12. Authentifizierung von Geräten oder Anwendungen


3.2. Routinemäßige Schlüsselerneuerung

Bei einer Schlüsselerneuerung wird ein neues Zertifikat erzeugt. Es enthält

• denselben SubjectName,

• eine neue laufende Nummer,

• einen neuen öffentlichen Schlüssel,

• möglicherweise eine andere Gültigkeitsdauer.

Das Verfahren für routinemäßige Schlüsselerneuerung wird angewendet, wenn das Zertifikat eines Nutzers nicht mehr gültig ist. Es ist identisch mit dem Verfahren zur Erstregistrierung.

3.3. Schlüsselerneuerung nach einem Widerruf

Teilnehmer, deren Zertifikat widerrufen wurde, müssen dasselbe Verfahren wie bei einer routinemäßigen Schlüsselerneuerung durchlaufen.

3.4. Antrag auf Widerruf

Das Verfahren bei einem Widerruf ist in Abschnitt 4.4 „Suspendierung und Widerruf von Zertifikaten“ dieses CPS beschrieben.

4. ANFORDERUNGEN AN DEN BETRIEB

4.1. Beantragung eines Zertifikats

Bevor ein Zertifikat ausgegeben werden kann, muss es der Teilnehmer beantragen. Der Antrag muss folgende Angaben enthalten:

• Vor- und Nachname des Teilnehmers,

• Art der Zugehörigkeit des Teilnehmers zur Europäischen Kommission,


30/10

• Nachweis der Kommissionszugehörigkeit des Teilnehmers,

• SMTP-E-Mailadresse des Teilnehmers bei der Kommission,

• CUID des Teilnehmers,

• Zustimmung zu den Vereinbarungen dieses CPS.

Abhängig vom Authentifizierungsprozess der RA kann sie im Zertifikatsantrag weitere Informationen verlangen, um die Bestätigung der Identität zu erleichtern.

Der Zertifikatsantrag wird sowohl vom Teilnehmer signiert (wenn es sich um den Antrag einer Einzelperson handelt) als auch von der LRA (als signierte E-Mail). Die LRA leitet den Antrag an die RA weiter.

RA und LRA verifizieren die Identität anhand der Angaben des Antragstellers. Dabei halten sie die in Abschnitt 3.1.8 „Authentifizierung der Identität von Organisationen“ und 3.1.9 „Authentifizierung der Identität von Einzelpersonen“ beschriebenen Anforderungen ein. Abhängig vom Ergebnis der Verifizierung akzeptiert die RA den Zertifikatsantrag oder lehnt ihn ab; der Teilnehmer wird über das Ergebnis informiert. Die RA notiert ihre Schritte auf dem Zertifikatsantrag, notiert die Verifizierungsschritte, signiert und datiert den Zertifikatsantrag und archiviert ihn.

4.2. Ausgabe von Zertifikaten

Das hier beschriebene Verfahren ist das Standardverfahren.

(1) Entweder sendet der Teilnehmer den Zertifikatsantrag an die LRA seiner Generaldirektion (expliziter Antrag), oder die LRA erhält eine Liste potenzieller Teilnehmer von deren Vorgesetzten (impliziter Antrag).

(2) Die LRA übermittelt den Antrag als signierte E-Mail an die RA.

(3) Die LRA benachrichtigt den/die potenziellen Teilnehmer und weist sie darauf hin, dass sie einen Identifizierungscode von der RA und einen weiteren von der LRA erhalten werden.

(4) Die RA überprüft die Verwaltungsdaten des Teilnehmers und trägt den SubjectName des Teilnehmers in die CA-Datenbank ein.

(5) Die CA sendet auf einem sicheren Weg eine Registrierungsdatei an die RA, die den SubjectName und den Identifizierungscode C1 des Teilnehmers enthält.

(6) Die RA sendet die Registrierungsdatei als sichere E-Mail an die LRA, die den Antrag stellt.

(7) Die RA sendet dem Teilnehmer ein gedrucktes Dokument als vertrauliches Schreiben, das seinen Identifizierungscode C1 enthält.


31/10

(8) Die LRA prüft das physische Vorhandensein des Teilnehmers, nachdem sie von der RA die Registrierungsdatei erhalten hat.

(9) Die LRA nimmt Kontakt zur CA auf, um die Existenz des Teilnehmers zu bestätigen.

(10) Die CA aktualisiert die Registrierungsdatei und schickt einen zusätzlichen Identifizierungscode C2 an die LRA.

(11) Die LRA schickt dem Teilnehmer die Registrierungsdatei (auf Diskette oder als E-Mail) und ein gedrucktes Dokument, das den Identifizierungscode C2 enthält.

(12) Die LRA unterstützt den/die registrierten Teilnehmer, die im Besitz der Registrierungsdatei und der Identifizierungscodes C1 und C2 sind, bei der Erzeugung ihrer Schlüssel und beim Erhalt des Zertifikats von der CA. Während der Erzeugung des Schlüssels muss der registrierte Teilnehmer anwesend sein, um die Identifizierungscodes von RA und LRA sowie ein erstes (Initialisierungs-)Passwort für seinen geheimen Schlüssel einzugeben.

(13) Der registrierte Teilnehmer sichert seinen geheimen Schlüssel auf Festplatte, Diskette [oder Smartcard], je nach Speicherverfahren seiner Generaldirektion.

Veröffentlichung von Zertifikaten:

(1) Die CA-Betreuer erzeugen täglich eine Datei, die alle Zertifikate enthält, und senden sie um 21.15 Uhr an den Administrator des Kommissionsverzeichnisses.

(2) Der Administrator des Kommissionsverzeichnisses aktualisiert das Kommissionsverzeichnis täglich um 22.00 Uhr mit den Zertifikaten.

Das unten beschriebene Verfahren ist ein verändertes und temporäres Verfahren, um auf Ebene der Generaldirektion ein Wiedererlangen der Schlüssel zu ermöglichen. Es wird durch das normale Verfahren ersetzt, sobald je ein Schlüsselpaar für Signatur und Verschlüsselung sowie ein zentraler Wiedererlangungsdienst für die Verschlüsselung verfügbar sind. Das temporäre Verfahren für einen Zertifikatsantrag ist das folgende (* bedeutet, dass das Standardverfahren unverändert bleibt):

(1) Der Teilnehmer sendet einen Zertifikatsantrag an die LRA seiner GD (expliziter Antrag), oder die LRA erhält eine Liste potenzieller Teilnehmer von deren Vorgesetzten (impliziter Antrag). (*)

(2) Die LRA übermittelt den Antrag als signierte E-Mail an die RA. (*)

(3) Die LRA benachrichtigt den/die potenziellen Teilnehmer und weist sie darauf hin, dass sie einen Identifizierungscode von der RA und einen weiteren von der LRA erhalten werden. (*)


32/10

(4) Die RA überprüft die Verwaltungsdaten des Teilnehmers und trägt den SubjectName des Teilnehmers in die CA-Datenbank ein. (*)

(5) Die CA sendet auf einem sicheren Weg eine Registrierungsdatei an die RA, die den SubjectName und den Identifizierungscode C1 des Teilnehmers enthält. (*)

(6) Die RA sendet die Registrierungsdatei und den Identifizierungscode C1 als sichere E-Mail an die LRA, die den Antrag stellt.

(7) Die RA sendet dem Teilnehmer als E-Mail eine Nachricht, die den Zertifikatsantrag enthält.

(8) Die LRA prüft das physische Vorhandensein des Teilnehmers, nachdem sie von der RA die Registrierungsdatei erhalten hat. (*)

(9) Die LRA nimmt Kontakt zur CA auf, um die Existenz des Teilnehmers zu bestätigen. (*)

(10) Die CA aktualisiert die Registrierungsdatei und schickt einen zusätzlichen Identifizierungscode C2 an die LRA. (*)

(11) Die LRA, die die Registrierungsdatei und die beiden Identifizierungscodes des Teilnehmers besitzt, erzeugt ein Schlüsselpaar.

(12) Die LRA kontaktiert die CA und fordert ein Zertifikat an (die LRA identifiziert sich gegenüber der CA mit den beiden Identifizierungscodes des Teilnehmers).

(13) Die LRA kopiert das Initialisierungs-Passwort sowie die Schlüsseldatei mit dem geheimen Schlüssel und dem Zertifikat für den öffentlichen Schlüssel des Teilnehmers.

(14) Die LRA deponiert die Schlüsseldatei und das Initialisierungs-Passwort in einem Safe unter der Kontrolle des Sicherheitsbeauftragten.

(15) Die LRA übergibt die Schlüsseldatei und das Initialisierungs-Passwort an den Teilnehmer.

(16) Die LRA unterstützt den registrierten Teilnehmer bei der Speicherung der Schlüsseldatei entweder auf Festplatte oder auf Diskette, je nach dem Speicherverfahren seiner Generaldirektion.

4.3. Annahme des Zertifikats

Wie Teilnehmer in ihre Verpflichtungen bei der Nutzung des Zertifikats einwilligen, ist festgelegt im Prozess für Zertifikatsanträge, der in Abschnitt 4.1 dieses CPS beschrieben ist. Teilnehmer müssen eine Erklärung unterzeichnen, dass sie die Vereinbarungen in diesem CPS sowie die Teilnehmervereinbarung akzeptieren.


33/10

Die Annahme des Zertifikats ist Teil des Prozesses zur Zertifikatsausgabe, der in Abschnitt 4.2 dieses CPS beschrieben wird. Das dabei zwischen Teilnehmer und CommisSign CA eingesetzte sichere Kommunikationsprotokoll schließt die wechselseitige Authentifizierung beider Parteien ein sowie ein Anforderung-Antwort-Verfahren, bei dem der Teilnehmer die daraus hervorgehenden Zertifikate für öffentliche Schlüssel akzeptiert.

4.4. Suspendierung und Widerruf von Zertifikaten

4.4.1. Widerrufsgründe

Zertifikate für die Verschlüsselung oder Verifizierung von Signaturen werden widerrufen, wenn die Zertifikate aus irgendeinem Grund nicht mehr vertrauenswürdig sind. Ein solcher Vertrauensverlust kann Zertifikate von Teilnehmern, RA und CA-Betreuern betreffen und beispielsweise aus folgenden Gründen eintreten:

• begründete Entlassung oder Beurlaubung,

• Kompromittierung oder vermutete Kompromittierung von geheimen Schlüsseln und/oder Nutzerpassworten und –profilen,

• Beendigung des Beschäftigungsverhältnisses,

• Nichteinhalten von Verpflichtungen, die in diesem Dokument und den einschlägigen CP festgelegt sind, durch die Antragsteller.

4.4.2. Antragsberechtigte

Den Widerruf eines Zertifikats können nur beantragen:

• der Teilnehmer, in dessen Namen das Zertifikat ausgegeben wurde,

• die Person, die das Zertifikat für eine gemeinsame Mailbox beantragt hat,

• Vorgesetzte des Teilnehmers, wenn der Teilnehmer dem Personal der Europäischen Kommission angehört,

• Mitarbeiter der CommisSign CA,

• Mitarbeiter einer RA, die mit der CommisSign CA assoziiert ist,

• der Direktor der Direktion SPS – Dienst Protokoll und Sicherheit,

• die "Autorité investi du pouvoir de nomination" (AIPN),

• die PA der Europäischen Kommission.


34/10

4.4.3. Antragsverfahren für einen Widerruf [noch nicht implementiert] [Review nach Implementierung]

Um den Widerruf eines Zertifikats zu beantragen, muss der Antragsteller seine LRA benachrichtigen, ein schriftliches Genehmigungsformular für den Widerruf ausfüllen und unterschreiben und sich persönlich mit seinem Dienstausweis einstellen.

Die LRA bearbeitet Zertifikatswiderrufe und –erneuerungen. Zertifikatswiderrufe sind schriftlich bei der lokalen RA zu beantragen. Wenn sich die RA am CA-Server anmeldet, um den Widerruf eines Zertifikats zu bearbeiten, aktualisiert die CommisSign CA unverzüglich die CRL. Der Antragsteller wird so bald wie möglich von der LRA über die Ausführung des Widerrufs benachrichtigt.

Widerrufene Zertifikate werden in CRL veröffentlicht und im Verzeichnis der Europäischen Kommission aktualisiert, wie in Abschnitt 4.4.9 „CRL-Ausgabeturnus“ dieses CPS festgelegt. Falls erforderlich, können RA eine CRL auch unmittelbar aktualisieren.

Für Auditzwecke muss eine schriftliche Genehmigung eingeholt werden, die folgende Informationen enthält:

• Datum des Antrags auf Zertifikatswiderruf,

• Name des Zertifikatsinhabers (Teilnehmers),

• ausführliche Begründung des Antrags auf Zertifikatswiderruf,

• Name und Stellung der Person, die den Antrag auf Zertifikatswiderruf stellt,

• Kontaktdaten der Person, die den Antrag auf Zertifikatswiderruf stellt,

• Unterschrift der Person, die den Antrag auf Zertifikatswiderruf stellt.

Schriftliche Genehmigungen werden an die RA geschickt. Wenn das Zertifikat eines Teilnehmers unverzüglich widerrufen werden muss, ist der Antrag telefonisch oder per E-Mail zu stellen und durch schriftliche Genehmigung zu bestätigen.

Nach Erhalt und Bestätigung der schriftlichen Genehmigung widerruft die RA das Zertifikat des Teilnehmers, indem sie sich am CA-Server anmeldet und den Widerruf ausführt. Die RA vermerkt dieses Ereignis im Logbuch der RA-Administration. Sie notiert ihre Schritte auf der schriftlichen Widerrufsgenehmigung, signiert und datiert die Genehmigung und archiviert sie.

4.4.4. Aufschubfrist bei einem Antrag auf Zertifikatswiderruf



35/10

4.4.5. Suspendierungsgründe


4.4.6. Antragsberechtigte


4.4.7. Antragsverfahren für eine Suspendierung


4.4.8. Befristung einer Suspendierung


4.4.9. CRL-Ausgabeturnus

Die CommisSign CA aktualisiert CRL [und ARL] im Verzeichnis der Europäischen Kommission im 24-Stunden-Turnus. CRL [und ARL] werden an 7 Tagen der Woche ausgegeben. Ausnahmsweise können CRL [und ARL] auch außerhalb dieses Turnus ausgegeben werden (wenn beispielsweise eine ernste Kompromittierung festgestellt wird).

4.4.10. Anforderungen an die Prüfung von CRL

[Jedes von der CommisSign CA ausgegebene Zertifikat enthält den vollständigen DN (Distinguished Name) des CRL Distribution Point (Verteilerstelle für Widerrufslisten), der bei der Verifizierung des Zertifikats zu prüfen ist.]

Bevor vertrauende Parteien Zertifikate von Teilnehmern nutzen, müssen sie den Status der Zertifikate anhand einer aktuellen CRL überprüfen. Sollten die Widerrufsinformationen vorübergehend nicht zugänglich sein, muss die vertrauende Partei entweder darauf verzichten, das Zertifikat zu nutzen, oder in Kenntnis der Sachlage das Risiko, die Verantwortung und die Konsequenzen auf sich nehmen, die mit der Nutzung eines Zertifikats verbunden sind, dessen Authentizität nach den Standards dieses CPS nicht garantiert werden kann.

4.4.11. Online-Widerrufs-/Statusprüfung

Zurzeit unterstützt die PKI der Europäischen Kommission die Online-Prüfung des Zertifikats- bzw. Widerrufsstatus nicht.

4.4.12. Anforderungen an eine Online-Widerrufsprüfung


4.4.13. Sonstige Formen der Widerrufsbekanntgabe



36/10

4.4.14. Anforderungen an die Prüfung sonstiger Formen der Widerrufsbekanntgabe


4.4.15. Besondere Anforderungen bei Schlüsselkompromittierung

Schlüsselkompromittierung ist ein Sicherheitsvorkommnis, das eine Reaktion zwingend erforderlich macht.

Wenn ein Schlüssel eines Endanwenders kompromittiert wurde, muss bei der lokalen RA ein Bericht über die Umstände archiviert werden, unter denen der Schlüssel kompromittiert wurde. Hat der Antragsteller selbst den Schlüssel versehentlich kompromittiert, sind keine weiteren Schritte nötig. In anderen Fällen berichtet die lokale RA dem Dienst Protokoll und Sicherheit über den Vorfall, um weitere Ermittlungen und Maßnahmen zu ermöglichen, wie sie die Verfahren des IKT-Sicherheitskonzepts vorsehen.

Wenn der Signaturschlüssel der CommisSign CA kompromittiert wurde oder entsprechender Verdacht besteht, benachrichtigt die CommisSign CA unverzüglich die PA. Mit Unterstützung der PA der Europäischen Kommission benachrichtigt die CommisSign CA alle CA, an die sie Cross-Zertifikate ausgegeben hat.

4.5. Verfahren für Sicherheitsaudits [noch nicht implementiert] [Review nach Implementierung]

4.5.1. Aufgezeichnete Ereignisarten

[Alle wesentlichen Sicherheitsereignisse in der Software der CommisSign CA erhalten automatisch einen Zeitstempel und werden in Audit-Logdateien protokolliert. Dazu gehören u. a. folgende Ereignisse:

• erfolgreiche und gescheiterte Versuche, Teilnehmer zu initialisieren, zu entfernen, zu aktivieren, zu deaktivieren und zu aktualisieren, sowie Versuche, Teilnehmer, ihre Schlüssel und Zertifikate wiederzuerlangen;

• erfolgreiche und gescheiterte Versuche, sich als CA-Betreuer, RA oder Teilnehmer anzumelden oder CA-Betreuer, RA oder Teilnehmer einzurichten, zu entfernen, ihre Passwörter zu setzen, neu zu setzen oder zu ändern, ihre Privilegien zu widerrufen oder ihre Schlüssel und Zertifikate zu erzeugen, zu aktualisieren oder wiederzuerlangen;

• gescheiterte Interaktionen mit dem Verzeichnis, einschließlich erfolgreicher und gescheiterter Verbindungsversuche sowie Lese- und Schreibzugriffe des CA-Systems;

• alle Ereignisse im Zusammenhang mit Zertifikatswiderrufen, Änderung und Validierung des Sicherheitskonzepts, Starten und Beenden der CA-Software, Backup der Datenbank, Cross-Zertifizierung, Validierung von Zertifikaten und Zertifikatsketten, Verwaltung der Zertifikatsattribute, Erweiterung von Nutzerrechten, Datenbank- oder Audit-Protokolle, Änderungen von DN;


37/10

• Management, einschließlich Management des Lebenszyklus von Zertifikaten, und verschiedene andere Ereignisse;

• Starten und Beenden des Systems.

Die Systemverwaltung der CA pflegt Informationen zu:

• Änderung und Wartung der Systemkonfiguration,

• Administrator-Privilegien,

• Berichten über Abweichungen und kompromittierende Ereignisse,

• unberechtigten Zugriffsversuchen auf das CA-System aus dem Netz.

Die Anlage der CA ist mit einem elektronischen Überwachungssystem ausgestattet, das Informationen über den Zutritt zur CommisSign CA-Anlage liefert.]

4.5.2. Verarbeitungsturnus für die Audit-Logdateien

[Die CA-Betreuer verarbeiten die Audit-Logdateien wöchentlich und untersuchen die darin aufgezeichneten Warnmeldungen oder Abweichungen.]

4.5.3. Aufbewahrungsfristen für die Audit-Logdateien

[In der Konfiguration der CommisSign CA werden die Audit-Logdateien ohne zeitliche Begrenzung elektronisch archiviert. Abschnitt 4.5.5 „Backup-Verfahren für die Audit-Logdateien“ dieses CPS beschreibt das Archivierungsverfahren.]

4.5.4. Schutz der Audit-Logdateien

[Die Audit-Protokolle sind reguläre, unstrukturierte Dateien (flat files) des Betriebssystems. Jedes Audit-Protokoll enthält einen Audit-Kopf mit den Informationen über die in dieser Datei enthaltenen Audits und eine Ereignisliste. Für jedes Audit-Ereignis und den Audit-Kopf wird ein Message Authentication Code (MAC, Authentifizierungscode für die Nachricht) erzeugt. Zum Generieren des MAC wird für jede Audit-Logdatei ein anderer Audit-Schlüssel benutzt. Der Audit-Schlüssel ist im Audit-Kopf gespeichert und wird vom Masternutzer der CA der Europäischen Kommission für die CommisSign CA gesichert.

Audit-Protokolle können sich über viele Dateien erstrecken. Ein neues Audit-Protokoll wird dann erzeugt, wenn die Größe des aktuellen Audit-Protokolls die Voreinstellung von 100 KB überschreitet oder der Masterschlüssel der CA aktualisiert wird.]

4.5.5. Backup-Verfahren für die Audit-Logdateien

[Audit-Protokolle werden jede Nacht mit dem regulären System-Backup der CA gesichert und wöchentlich von der Systemverwaltung der CA archiviert.


38/10

Alle Dateien, auch die aktuellen Audit-Protokolle, werden auf Bänder ausgelagert und in einer sicheren Archiveinrichtung aufbewahrt.]

4.5.6. Sammeln der Audit-Logdateien

[Die Audit-Protokolle werden in einem internen Verfahren der CommisSign CA-Software akkumuliert.]

4.5.7. Benachrichtigung der Ereignisauslöser

[Wenn das Audit-Sammelsystem ein Ereignis protokolliert, wird die Person, die das Ereignis ausgelöst hat, nicht benachrichtigt. Sie kann erfahren, ob die Aktion erfolgreich oder erfolglos war, aber nicht, dass die Aktion protokolliert wurde.]

4.5.8. Schwachstellenanalyse

[Die Systemverwaltung und die Betreuer der CommisSign CA setzen die Prozesse ein, die im Abschnitt 4.5 „Verfahren für Sicherheitsaudits“ dieses CPS beschrieben werden, um Schwachstellen des Systems wie vorgeschrieben zu beobachten, zu bewerten und abzusichern.]

4.6. Archivierung [noch nicht implementiert] [Review nach Implementierung]

4.6.1. Archivierte Daten

[Für die Ausübung ihrer Funktion erhalten die RA und LRA verschiedene Dokumente wie:

• Identifikationsdaten,

• Zertifikatsanträge,

• Genehmigungen von Zertifikatswiderrufen,

• Genehmigungen für das Wiedererlangen von Schlüsseln.

Die bereitgestellten Daten sind teilweise personenbezogen und fallen somit in den Geltungsbereich der Verordnung (EG) Nr. 45/2001 des Europäischen Parlaments und des Rates vom 18. Dezember 2000. Diese Daten sind sicher und gemäß den Anforderungen dieser Verordnung aufzubewahren. Zugang haben nur Mitarbeiter der RA.

Unter anderem werden folgende Ereignisse in der Datenbank des CA-Systems gespeichert:

• Erzeugen des CA-Signatur-Schlüsselpaars,

• Hinzufügen und Entfernen von Endanwendern im System,


39/10

• Änderungen in der History des Verschlüsselungs-Schlüsselpaars und des öffentlichen Verifizierungsschlüssels für alle Nutzer, einschließlich der Ausgabe von Zertifikaten und von Widerrufsereignissen,

• DN-Änderungen bei Endanwendern,

• Hinzufügen und Entfernen von Privilegien der RA und der CA-Betreuer,

• Änderung von Privilegien der RA und der CA-Betreuer,

• Änderung bestimmter Aspekte des Zertifizierungskonzepts wie der Gültigkeitsdauer der Zertifikate,

• Erzeugen und Widerrufen von Cross-Zertifikaten.

Das CommisSign-CA-System bietet außerdem Audit-Logdateien wie in Abschnitt 4.5 dieses CPS beschrieben.]

4.6.2. Aufbewahrungsfristen für die Archivierung

[Daten zum Audit (gemäß Abschnitt 4.5 dieses CPS), Schlüssel, Anträge und Genehmigungen zu Zertifikaten für Teilnehmer und Daten zur Identifizierung und Authentifizierung werden für die Dauer von fünf Jahren archiviert.]

[Für die Archivierung von Zertifikaten für digitale Signaturen, geheimen Vertraulichkeitsschlüsseln, die von einer CA aufbewahrt werden[, ARL] und CRL, die von einer CA generiert werden, gelten die in den einschlägigen Vorschriften der Europäischen Kommission und der Mitgliedstaaten festgelegten Fristen.]

4.6.3. Archivsicherheit

[Die Systemdatenbank der CommisSign CA wird [verschlüsselt und ]vom CA-System geschützt. Die Audit-Protokolle werden so geschützt, wie es in Abschnitt 4.5.4 „Schutz der Audit-Logdateien“ dieses CPS festgelegt ist.]

Die Archivierungsmedien werden physisch geschützt, indem sie in einer geschützten Anlage der CA mit Zugangskontrolle aufbewahrt werden, zu der nur die Systemverwaltung und Masternutzer der CommisSign CA Zugang haben.

4.6.4. Backup-Verfahren für das Archiv

[Archivdateien werden bei ihrer Erzeugung gesichert. Die Originale werden vor Ort aufbewahrt und innerhalb des CommisSign-CA-Systems untergebracht. Backup-Dateien werden an einem anderen sicheren und geografisch entfernten Ort aufbewahrt.]


40/10

4.6.5. Archivsammelsystem

[Das Archivsammelsystem (die Backup-Einrichtung) für die Systemdatenbank der CommisSign CA ist in das CommisSign-CA-System integriert.

Das Archivsammelsystem (die Backup-Einrichtung) für die Dateien mit den Audit-Protokollen wird in Abschnitt 4.5.5 „Backup-Verfahren für die Audit-Logdateien“ und 4.5.6 „Sammeln der Audit-Logdateien“ dieses CPS beschrieben.

Die Archivierung beider Datensammlungen auf getrennten Medien und deren sichere Aufbewahrung finden außerhalb des CommisSign-CA-Systems statt.]

4.6.6. Verfahren für das Abrufen und Verifizieren von Archivdaten

[Die Archivbänder werden zweimal jährlich vom CommisSign CA-Betreuer abgerufen und daraufhin überprüft, ob Daten beschädigt wurden oder verloren gegangen sind. Sollte dies der Fall sein, wird das Backup-Archiv abgerufen. Das Backup-Archiv wird zum neuen Masterarchiv und ein neues Backup wird erzeugt.

Alle fünf Jahre wird ein neues Backup von sämtlichen Archivbändern erzeugt, auch wenn sich kein Schaden oder Verlust von Daten feststellen lässt. Das neue Backup wird zum Masterarchiv, das bisherige Masterarchiv wird zum Backup, und das bisherige Backup-Band wird unter Einhaltung der Sicherheitsmaßnahmen ins Recycling gegeben.]

4.7. Änderung von Schlüsseln

Siehe Abschnitte 3.2 und 3.3 dieses CPS.

4.8. Wiedererlangung nach Kompromittierung oder Desaster [noch nicht implementiert] [Review nach Implementierung]

4.8.1. Kompromittierte Rechnerressourcen, Software und/oder Daten

Nach einem Desaster oder einer bedeutenden Kompromittierung haben die CommisSign CA und RA die folgenden Schritte einzuhalten:

(1) Alle Systempasswörter für das CommisSign-CA-System müssen für folgende Anwender geändert werden: Masternutzer der CA, CA-Betreuer und RA (wenn eine CA kompromittiert wurde).

(2) Je nach Art und Ausmaß des Desasters müssen einige oder alle Zertifikate widerrufen werden.

(3) Wenn das Verzeichnis nicht mehr konsistent ist oder der Verdacht besteht, dass es kompromittiert wurde, müssen die Daten des Verzeichnisses, die Verschlüsselungszertifikate und CRL wiedererlangt werden. Wenn der Verzeichnisadministrator das Verzeichnis vom Backup eingespielt hat, aktualisiert der


41/10

Masternutzer der CA die PKI-Daten im Verzeichnis. Zu den PKI-Daten gehören CRL und Zertifikate, die seit der letzten Sicherung des Verzeichnisses geändert wurden.

(4) Müssen die Profile eines CA-Betreuers oder einer RA wiedererlangt werden, kann dies ein anderer CA-Betreuer oder eine andere RA tun.

Das Vorgehen bei Kompromittierung eines CA-Schlüssels ist in Abschnitt 4.4.15 „Besondere Anforderungen bei Schlüsselkompromittierung“ beschrieben.

4.8.2. Wiedererlangen des Schlüssels eines Subjekts

Das Standardverfahren wurde erweitert, um das Wiedererlangen von Schlüsseln auf Ebene der Generaldirektion zu ermöglichen. Eine Kopie des geheimen Schlüssels und des zugehörigen Passworts wird vom Sicherheitsbeauftragten der GD in einem sicheren Bereich mit Zugangskontrolle aufbewahrt. Zugriff auf Schlüssel und Passwörter haben nur der Sicherheitsbeauftragte und berechtigte offizielle Vertreter. Nur LRA sind zur Wiedererlangung von Schlüsseln berechtigt. Die Schritte zur Wiedererlangung von Schlüsseln werden in Anwesenheit der LRA und des Sicherheitsbeauftragten vollzogen, die sie auch autorisieren. Sollten LRA und Sicherheitsbeauftragter nicht verfügbar sein, können sie in Notfällen durch CA-Betreuer ersetzt werden. Es gibt drei Anlässe für das Wiedererlangen eines Schlüssels:

• auf Antrag des Nutzers,

• im Rahmen einer Disziplinarmaßnahme oder eines gleichrangigen Antrags eines internen Subjekts,

• auf Antrag des Generaldirektors, wenn der Nutzer auf Dauer oder in wichtigen Fällen nicht verfügbar ist und die Belange der Einrichtung ernsthaft beeinträchtigt sind.

[Wenn es sich nicht um einen Notfall handelt, wird ein Antrag auf Wiedererlangung eines Schlüssels innerhalb von 48 Stunden erledigt. Bei Notfällen wird die lokale RA angesprochen.]

4.8.2.1.Wiedererlangen eines Schlüssels auf Antrag des Nutzers

Nutzer können das Wiedererlangen ihres Schlüssels unter anderem beantragen, wenn

• ein Teilnehmer ein Passwort vergisst;

• ein Teilnehmer die Datei mit seinem geheimen Schlüssel beschädigt oder verliert.

Um den Teilnehmer vor unberechtigten Anträgen zu schützen, muss er

• sich persönlich einstellen und


42/10

• der LRA eine schriftliche Genehmigung vorlegen, die den Anlass für die Wiedererlangung darlegt.

Wenn der LRA die schriftliche Genehmigung vorliegt, überzeugt sie sich anhand des Dienstausweises durch Augenschein von der Identität des Teilnehmers und führt das Verfahren zur Wiedererlangung des Schlüssels durch. Für Auditzwecke protokolliert die LRA das Ereignis der Wiedererlangung. Die LRA notiert ihre Schritte auf der schriftlichen Genehmigung der Wiedererlangung, signiert, datiert und archiviert die Genehmigung.

Die LRA übergibt dem Teilnehmer die Anleitung, wie er die neuen Autorisierungsdaten erhält.

4.8.2.2.Wiedererlangen eines Schlüssels auf Antrag Dritter

Das Wiedererlangen eines Schlüssels ohne Zustimmung des Teilnehmers kann unter anderem beantragt werden, wenn

• ein Teilnehmer die Organisation verlassen hat und sein Vorgesetzter oder die Abteilungsleitung zur Fortführung der Geschäfte Dateien entschlüsseln muss;

• Handlungen eines Teilnehmers von der Europäischen Kommission in Frage gestellt werden und seine Dateien überprüft werden müssen;

• Handlungen eines Teilnehmers von einer externen Vollstreckungsbehörde in Frage gestellt werden und seine Dateien überprüft werden müssen.

Um die Wiedererlangung eines Schlüssels zu beantragen, muss der Antragsteller seinen Sicherheitsbeauftragten kontaktieren. Der LRA muss eine schriftliche Genehmigung sowohl des Generaldirektors des Teilnehmers als auch der Einrichtung, die die Wiedererlangung des Schlüssels beantragt, vorliegen, bevor das Verfahren erledigt wird. Ein Antrag muss folgende Angaben enthalten:

• Datum des Antrags auf Wiedererlangung,

• Name des Schlüsselinhabers (Teilnehmers),

• Name des Antragstellers und der Einrichtung der Europäischen Kommission,

• ausführliche Begründung, weshalb der Zugriff auf die Dateien des Teilnehmers beantragt wird;

• Name(n) der Person(en), die Einblick in die Dateien des Teilnehmers erhalten sollen und verantwortlich sind, falls nicht aufgeführte Dritte zu einem späteren Zeitpunkt Einblick in die Dateien bekommen sollten;

• Beschreibung (und/oder Dateinamen) der Dateien des Teilnehmers, in die Einblick gewährt werden soll, oder Zustimmung zum Zugriff auf alle Dateien;


43/10

• Beschreibung der Rolle, die die LRA über die Wiedererlangung des Schlüssels hinaus übernimmt, darunter Angaben, welche Auskunft sie erteilen darf, wenn der Teilnehmer nach der Änderung seiner Zugriffsmöglichkeiten in der CommisSign CA fragt.

Wenn der LRA die schriftliche Genehmigung vorliegt, kontaktiert sie die Beteiligten und plant die Schritte zur Wiedererlangung des Schlüssels.

[Hinweis: In bestimmten Situationen kann ein Gericht die Wiedererlangung eines Schlüssels anordnen. Eine solche gerichtliche Anordnung ist einer schriftlichen Genehmigung gleichgestellt.]

Die Antragsteller sollten ggf. zum Termin der Wiedererlangung eine Diskette mit den Dateien des Teilnehmers mitbringen, in die Einblick gewährt werden soll. Die LRA darf (unter Aufsicht des Sicherheitsbeauftragten) die Dateien auf einen lokalen Rechner laden, um sie zu entschlüsseln und anzusehen. Im Anschluss an das Verfahren müssen die entschlüsselten Dateien gelöscht werden, um eine unautorisierte Einsicht auszuschließen.

Die Antragsteller sollten vorab klären, ob die LRA über Rechner mit der benötigten Software für die Einsicht in die Dateien verfügt. Ist dies nicht der Fall, kann die LRA die Dateien beim Antragsteller vor Ort bei der Europäischen Kommission einsehen.

Wenn der LRA die schriftliche Genehmigung vorliegt, überzeugt sie sich anhand des Dienstausweises durch Augenschein von der Identität der autorisierten Person(en) und führt das Verfahren zur Wiedererlangung des Schlüssels durch. Sie protokolliert das Ereignis der Wiedererlangung. Die LRA notiert ihre Schritte auf der schriftlichen Genehmigung, signiert und datiert die Genehmigung und archiviert sie für Auditzwecke.

Bleiben die Zugangsrechte des Teilnehmers zur CommisSign CA auch nach der beantragten Wiedererlangung des Schlüssels bestehen, führt die RA einen weiteren Wiedererlangungsprozess durch, damit der Teilnehmer sicher ist, dass niemand mehr Zugang zu seinen Schlüsseldaten hat.

Wenn nötig, kann die LRA das Teilnehmerkonto bei der CommisSign CA nach der Wiedererlangung deaktivieren, falls für die Einsicht ein kurzer, deutlich später liegender Zeitraum beantragt wurde. Das Teilnehmerkonto wird dann den Angaben des Antragstellers entsprechend reaktiviert.

Externe Subjekte können sich an eine Vollstreckungsbehörde wenden. Anträge externer Subjekte müssen vom Dienst Protokoll und Sicherheit bearbeitet werden.

Bei Anträgen externer Subjekte ist das Verfahren zum Wiedererlangen eines Schlüssels auf Antrag Dritter anzuwenden.

4.8.3. Wiedererlangung nach einem Desaster

[Die CommisSign CA hat einen Notfallplan erstellt, der die Verfahren beschreibt, die zur Wiedererlangung nach einem Desaster oder einer


44/10

bedeutenden Kompromittierung angewendet werden. An einem anderen Standort der Europäischen Kommission wird eine Reserve-CA für die Wiedererlangung nach einem Desaster konfiguriert.]

4.9. Einstellung des CA-Betriebs

Wenn die CommisSign CA den Betrieb einstellt, führt die PA der Europäischen Kommission die Aufsicht über diesen Prozess. RA und LRA kooperieren mit der CA bei der Benachrichtigung aller Teilnehmer über die Einstellung des Betriebs der CommisSign CA.

Alle von der CommisSign CA ausgegebenen Zertifikate werden widerrufen.

In Übereinstimmung mit dem Sicherheitskonzept für Informationssysteme und den einschlägigen Vorschriften der Europäischen Kommission und der Mitgliedstaaten unterhält die Europäische Kommission ein Archiv mit der Datenbank der CommisSign CA.

5. PHYSISCHE, VERFAHRENSTECHNISCHE UND PERSONALBEZOGENE SICHERHEITSKONTROLLEN

5.1. Physische Sicherheitskontrollen

5.1.1. Örtliche und bauliche Vorgaben für Standorte

Die CommisSign CA befindet sich in einem Bereich, der durch eine Zugangskontrolle überwacht wird und zu dem der Zutritt nur berechtigten Mitarbeitern gestattet ist. Der Bereich, in dem die CommisSign CA untergebracht ist, ist verschlossen und an allen 7 Wochentagen rund um die Uhr durch elektronische Einrichtungen bewacht. [Über die Zutritte zum Dienst Protokoll und Sicherheit werden elektronische Protokolle geführt.]

5.1.2. Zutritt

Der Bereich der CommisSign CA ist verschlossen, der Zutritt ist nur berechtigten und sicherheitstechnisch überprüften Mitarbeitern gestattet. Nur Masternutzer der CommisSign CA, CA-Betreuer und CA-Systemverwaltung haben Zutritt.

[RA-Systeme sind in Zonen mit eingeschränktem Zugang untergebracht.] Die zentralen RA werden mit Smartcards logisch geschützt.

Teilnehmer sind verpflichtet, ihre Schlüssel gemäß diesem CPS und der PKI-CP der Europäischen Kommission zu nutzen und zu schützen. Die Teilnehmer werden über diese Anforderungen unterrichtet, aber nicht regelmäßig überprüft oder überwacht.

5.1.3. Stromversorgung und Klimatisierung

Die Einrichtung der CommisSign CA wird ausreichend mit Strom versorgt und klimatisiert, um die Bedingungen für einen zuverlässigen Betrieb zu gewährleisten. Die Räume für das Personal werden ausreichend ausgestattet,


45/10

um die Anforderungen hinsichtlich Sicherheit und Gesundheitsschutz am Arbeitsplatz zu erfüllen.

5.1.4. Gefahr durch Wasser

Es besteht keine Gefahr, dass die Workstation der CommisSign CA Wasser ausgesetzt sein könnte.

5.1.5. Brandschutz

[Die Einrichtung der CommisSign CA verfügt über ein Löschsystem, das den maßgeblichen Bestimmungen der Europäischen Kommission für Arbeitssicherheit und -hygiene entspricht.]

5.1.6. Aufbewahrung der Datenträger

[Die von der CommisSign CA verwendeten Datenträger sind geschützt vor Umwelteinflüssen wie Temperatur, Feuchtigkeit und magnetischer Einwirkung.]

5.1.7. Entsorgung

Von der CommisSign CA für ihre Dateien verwendete Datenträger werden vor ihrer Freigabe zur Entsorgung physisch zerstört oder unlesbar gemacht.

Normaler Büroabfall wird gemäß den lokalen Regelungen der Europäischen Kommission vernichtet oder abtransportiert.

5.1.8. Externe Sicherung [nicht anwendbar]

[Sicherheit und Überwachung der Reserve-Einrichtung der CA sind denen der CommisSign Haupt-CA gleichwertig.]

5.2. Verfahrenstechnische Kontrollen

5.2.1. Vertrauenswürdige Rollen

[Mitarbeiter, die vertrauenswürdige Rollen ausüben, müssen eine vollständige Überprüfung ihres Hintergrunds für sicherheitskritisch-sensible Funktionen bestehen. Die Kriterien für die Überprüfung ihres Hintergrunds und andere Sicherheitsüberprüfungen werden in den folgenden Abschnitten festgelegt.]

5.2.1.1.Vertrauenswürdige Rollen in der CA

Die CommisSign CA wird vom Dienst Protokoll und Sicherheit betrieben, der die im Folgenden beschriebenen Rollen ausübt: CA OA, CA-Betreuer und CA-Systemverwaltung.

Damit nicht eine Person allein die Sicherungsmechanismen umgehen kann, teilen sich mehrere Rollen und Personen die Verantwortung in der CommisSign CA. Im CommisSign-CA-System verfügt ein Konto nur über beschränkte Befugnisse, wie sie die Rolle der betreffenden Person erfordern. Innerhalb der CommisSign CA gibt es folgende Rollen:


46/10

• Masternutzer der CA

[Als Masternutzer der CA werden drei Personen benannt. ]Die Masternutzer werden von der CA OA ernannt. Masternutzer sind berechtigt,

– den Masterschlüssel der CommisSign CA zu erzeugen und zu pflegen;

– die Passwörter für den CA-Server zu ändern;

– die Zugriffsrechte der CA-Betreuer wiederherzustellen, wenn diese ihr Passwort vergessen haben sollten.

• CA-Betreuer

[Als CA-Betreuer werden drei Personen benannt. ]Die CA-Betreuer werden von der CA OA ernannt. CA-Betreuer sind berechtigt,

– das Sicherheitskonzept der CommisSign CA entsprechend diesem CPS und der PKI-CP der Europäischen Kommission festzulegen und zu verändern;

– festzulegen, wie viele Berechtigungen für sicherheitsrelevante Aktivitäten erteilt werden;

– RA und LRA hinzuzufügen und zu löschen;

– [auf Anordnung der PA der Europäischen Kommission Vereinbarungen zur Cross-Zertifizierung zu treffen, zu aktualisieren und zu widerrufen;]

– PIN-Codes von RA- und LRA-Smartcards zu ändern;

– Standardprofile für Zertifikate festzulegen (Gültigkeitsdauer, usw.);

– Audit-Logdateien zu verarbeiten und sicherzustellen, dass die Datenbank des PKI-Systems gesichert wird.

• CA-Systemverwalter

[Als CA-Systemverwalter werden zwei Personen benannt, eine davon als Vertretung. ]Die CA-Systemverwalter werden von der CA OA ernannt. CA-Systemverwalter

– konfigurieren die Hardware und Software der CommisSign CA und sorgen für den einwandfreien Betrieb;

– führen die Sicherungen des CommisSign-CA-Systems durch.

5.2.1.2.Vertrauenswürdige Rollen in der RA

Als RA werden mindestens zwei Personen benannt. Die RA sind befugt,

• Zertifikatsanträge[, Anträge auf Widerruf oder Suspendierung von Zertifikaten und auf Wiedererlangung von Schlüsseln] anzunehmen und zu bearbeiten;


47/10

• die Identität von Antragstellern zu verifizieren;

• Daten von Antragstellern an die CA zu übertragen;

• Daten zur Autorisierung von Teilnehmern entgegenzunehmen und zu verteilen.

5.2.1.3.Vertrauenswürdige Rollen in der LRA

Als LRA werden in jeder Generaldirektion oder eigenständigen Einheit (beispielsweise Delegation) mindestens zwei Personen benannt. Die LRA sind befugt,

• Anträge auf Zertifikate anzunehmen und zu bearbeiten;

• Daten von Antragstellern an die CA zu übertragen;

• Daten zur Autorisierung von Teilnehmern von der RA entgegenzunehmen;

• die Identität von Antragstellern und ihr physisches Vorhandensein zu verifizieren;

• Daten zur Autorisierung von Teilnehmern zu verteilen;

• Teilnehmer beim Prozess der Schlüssel- und Zertifikatserstellung zu unterstützen.

5.2.2. Für eine Aufgabe benötigte Personenzahl

Folgende Aufgaben sind sicherheitsrelevant; für ihre Erledigung sind mindestens zwei Personen erforderlich.

Zwei CA-Betreuer sind erforderlich, um

• andere CA-Betreuer oder RA hinzuzufügen oder zu löschen;

• Standardprofile für Zertifikate festzulegen.

LRA und SO sind erforderlich, um

• Schlüssel wiederzuerlangen.

5.2.3. Identifizierung und Authentifizierung für die Rollen

Für das Personal der RA und LRA sind die Identifizierung und Authentifizierung in Abschnitt 5.3 festgelegt.

Nachdem diese Mitarbeiter autorisiert sind, wird ihnen ein Zertifikat und eine Smartcard ausgestellt, durch die sie gegenüber dem CommisSign-CA-System identifiziert und authentisiert sind. Sie werden mit ihren Rollen und Berechtigungen in die Datenbank der CommisSign CA eingetragen. Wenn


48/10

sie sicherheitsrelevante Aufgaben erfüllen, authentifizieren sich die Mitarbeiter der RA und LRA mit ihren Smartcards.

5.3. Personalbezogene Sicherheitskontrollen

5.3.1. Hintergrund, Qualifikation, Erfahrung und Unbedenklichkeitsanforderungen

[Mitarbeiter, die in diesen Rollen arbeiten, müssen einen Nachweis des erforderlichen Hintergrunds für sicherheitsrelevante Stellen erbringen. Die Stellen von CA-Masternutzern, CA-Betreuern und RA sind als sicherheitskritisch-sensible Funktionen mit hohem Sicherheitsrisiko zu betrachten. Die Stellen von LRA sind als sicherheitskritisch-sensible Funktionen mit mittlerem Sicherheitsrisiko zu betrachten.]

5.3.2. Verfahren zur Hintergrundüberprüfung

Hintergrundüberprüfungen werden gemäß den Sicherheitskonzepten für Mitarbeiter der Europäischen Kommission und der europäischen Regierungen durchgeführt.

5.3.3. Schulungsanforderungen

Mitarbeiter, die Aufgaben im Betrieb einer CA, RA oder LRA durchführen, werden in folgenden Aspekten geschult:

• Betrieb der Software und/oder Hardware im CommisSign-CA-System,

• zu erledigende Aufgaben,

• Festlegungen in diesem CPS und der PKI-CP der Europäischen Kommission.

5.3.4. Fortbildungsintervalle und -anforderungen

Die Anforderungen im vorigen Abschnitt werden bei Änderungen im System der CommisSign CA laufend aktualisiert. Fortbildungen werden abhängig von solchen Änderungen nach Bedarf durchgeführt.

5.3.5. Job Rotation


5.3.6. Sanktionen für unbefugte Handlungen

Bei unbefugten Handlungen einer Person, die Aufgaben im Betrieb der CommisSign CA oder RA erfüllt, oder wenn der Verdacht einer solchen Handlung besteht, können entsprechende Disziplinarmaßnahmen (im Einklang mit dem Statut der Europäischen Kommission) getroffen werden.

Fahrlässige oder vorsätzliche Verstöße gegen dieses CPS oder die PKI-CP der Europäischen Kommission können mit Entzug von Privilegien und/oder disziplinarischen Maßnahmen geahndet werden.


49/10

5.3.7. Mitarbeiter von Auftragnehmern

Mitarbeiter von Auftragnehmern, die Teile der CommisSign CA oder RA betreiben, unterliegen denselben Kriterien wie Bedienstete der Europäischen Kommission. Sie sind ebenso den Sicherheitsüberprüfungen in Abschnitt 5.3 für die jeweilige Rolle zu unterziehen.

5.3.8. An Mitarbeiter ausgehändigte Dokumentation

Dieses CPS wird den Mitarbeitern der CommisSign CA und RA und den Teilnehmern ausgehändigt. Mitarbeiter der CA und RA erhalten ferner die erforderlichen Betriebshandbücher, damit sie die Hardware und PKI-Software nutzen und warten können.

Zusätzlich zum CPS erhalten die Teilnehmer Informationen zu Einsatz und Schutz der Software, die innerhalb der Domain der Europäischen Kommission eingesetzt wird. Der technische Helpdesk der CommisSign CA unterstützt alle Nutzer in der Domain.

6. TECHNISCHE SICHERHEITSKONTROLLEN

6.1. Erstellung und Installation von Schlüsselpaaren

6.1.1. Erstellung von Schlüsselpaaren

Das Signatur-Schlüsselpaar der CommisSign CA wird beim Initialisierungslauf der Hauptanwendung für die CA-Steuerung erzeugt und durch den CA-Masterschlüssel geschützt.

Für die Nutzer erzeugt die PKI-Clientsoftware das Signatur-Schlüsselpaar. Von der Software erzeugte Schlüssel können in einer Datei auf Festplatte oder Diskette gespeichert werden.

6.1.2. Lieferung des geheimen Schlüssels an ein Subjekt

Das Signatur-Schlüsselpaar muss nicht an die Nutzer geliefert werden, weil es von der Software der Teilnehmer erzeugt wird.

6.1.3. Lieferung öffentlicher Schlüssel an Aussteller von Zertifikaten

Der öffentliche Schlüssel für die Signaturverifizierung wird unter Einsatz eines sicheren Kommunikationsprotokolls an das CommisSign-CA-System geliefert.

6.1.4. Lieferung öffentlicher CA-Schlüssel an Nutzer

Der öffentliche Schlüssel für die Verifizierung der CommisSign CA wird im CA-Zertifikat (CA certificate) unter Einsatz eines sicheren Kommunikationsprotokolls an die Teilnehmer geliefert. Die CommisSign CA verifiziert, dass der öffentliche Schlüssel unter Einsatz eines sicheren Kommunikationsprotokolls in einem CA-Zertifikat, das auf einem Webserver der Europäischen Kommission vorhanden ist, an die externe vertrauende Partei geliefert wurde.


50/10

6.1.5. Größe der asymmetrischen Schlüssel

Signatur-Schlüsselpaare für Nutzer sind 1024 Bit RSA.

Das Signatur-Schlüsselpaar der CommisSign CA ist 1024 Bit RSA. Sitzungsschlüssel für das sichere Kommunikationsprotokoll entsprechen Triple DES.

6.1.6. Parametererstellung für öffentliche Schlüssel


6.1.7. Parameterqualitätsprüfung


6.1.8. Schlüsselerzeugung durch Hardware/Software

Der Masterschlüssel der CommisSign CA ist hardwarebasiert. Die Schlüssel aller anderen Subjekte werden in der PKI-Clientsoftware erzeugt.

6.1.9. Verwendungszweck der Schlüssel (je X.509v3-Feld)

Das Signatur-Schlüsselpaar dient zur Authentifizierung, Integritätsprüfung und als Unterstützung für Verbindlichkeitsdienste.

Das Signatur-Schlüsselpaar dient zum Schutz eines symmetrischen Schlüssels für die Datenverschlüsselung und bietet daher Vertraulichkeit.

Mit dem Signaturschlüssel der CA werden die von dieser CA ausgegebenen Zertifikate[, ARL] und CRL signiert. Die Sitzungsschlüssel für das sichere Kommunikationsprotokoll werden eingesetzt, um eine sichere Kommunikation bei Operationen der Schlüsselverwaltung zu gewährleisten.

Vorübergehend gibt es nur ein Schlüsselpaar.

6.2. Schutz geheimer Schlüssel

Die folgenden Abschnitte beschreiben die technische und verfahrensbezogene Vorgehensweise beim Schutz geheimer Schlüssel. Die Verantwortung der Teilnehmer für den Schutz ihrer geheimen Schlüssel bleibt davon unberührt.

6.2.1. Standards für kryptografische Module

Das Kryptografiemodul der Software, die die CommisSign CA einsetzt, entspricht [...].

6.2.2. Kontrolle geheimer Schlüssel durch mehrere Personen

Zum Wiedererlangen geheimer Schlüssel sind mehrere Personen erforderlich. Siehe Abschnitt 5.2.2 „Für eine Aufgabe benötigte Personenzahl“.


51/10

6.2.3. Hinterlegung geheimer Schlüssel (Private Key Escrow)

Die CommisSign CA hinterlegt keine geheimen Schlüssel bei Dritten.

6.2.4. Sicherung geheimer Schlüssel

Die CommisSign-CA-Schlüssel werden in der Datenbank des CommisSign-CA-Systems gespeichert. Der geheime Signaturschlüssel eines Teilnehmers wird grundsätzlich nicht im CommisSign-CA-System gesichert, um Verbindlichkeit zu gewährleisten. [Die Datenbank des CommisSign-CA-Systems ist verschlüsselt.] [Die Datenbank des CommisSign-CA-Systems wird jede Nacht gesichert.]

6.2.5. Archivierung geheimer Schlüssel

Informationen zur Schlüsselarchivierung finden Sie in Abschnitt 4.6 dieses CPS.

6.2.6. Eingabe geheimer Schlüssel in das kryptografische Modul

Der geheime Signaturschlüssel der CommisSign CA und die geheimen Signaturschlüssel der Teilnehmer werden im Kryptografiemodul der Software erstellt. Sie werden nicht von anderen Subjekten in das Modul eingegeben.

Geheime Schlüssel sind im Kryptografiemodul verschlüsselt gespeichert und werden erst zum Zeitpunkt ihrer tatsächlichen Benutzung entschlüsselt.

6.2.7. Methode zum Aktivieren geheimer Schlüssel

Geheime Schlüssel werden aktiviert, wenn die Teilnehmer sich bei der Kryptografiesoftware des Client anmelden. Das Login erfolgt mit einem Passwort, das bei der Eingabe geschützt ist.

6.2.8. Methode zum Deaktivieren geheimer Schlüssel

Während einer Sitzung bleibt der geheime Schlüssel aktiviert. Die Sitzung wird durch das Logout des Teilnehmers oder durch die Deaktivierung des Teilnehmerschlüssels beendet.

6.2.9. Methode zur Vernichtung geheimer Schlüssel

Geheime Schlüssel werden durch eine sichere Löschaktion endgültig vernichtet.

6.3. Sonstige Aspekte der Verwaltung von Schlüsselpaaren

6.3.1. Archivierung öffentlicher Schlüssel

Die Sicherung und Archivierung von Schlüsseln ist in Abschnitt 6.2 festgelegt.


52/10

6.3.2. Nutzungsfristen für öffentliche und geheime Schlüssel

Öffentlicher Schlüssel und Zertifikat der CommisSign CA – [10 Jahre]

Geheimer Signaturschlüssel der CommisSign CA – [10 Jahre]

Öffentlicher Verifizierungsschlüssel und Zertifikat des Teilnehmers – zwei Jahre

6.4. Aktivierungsdaten

6.4.1. Erstellung und Installation von Aktivierungsdaten

Subjekte, die sich bei der PKI-Software anmelden, benötigen Passwörter oder Smartcards. Für jedes Passwort hält die Software einen strengen Regelsatz ein, der seine Sicherheit gewährleistet. Passwörter sind für CA vorgeschrieben, RA und LRA sind durch Smartcards geschützt.

Unter anderem gelten folgende Regeln für Passwörter:

• Ein Passwort muss mindestens zwölf Zeichen lang sein.

• Es muss mindestens einen Großbuchstaben, Sonderzeichen und eine Ziffer enthalten.

• Es muss mindestens einen Kleinbuchstaben enthalten.

• Ein Zeichen darf sich nicht oft wiederholen.

• Das Passwort darf nicht mit dem Profilnamen des Subjekts übereinstimmen und

• es darf keine längere Zeichenkette enthalten, die Teil des Profilnamens des Subjekts ist.

Die Daten für die Initialisierung von Teilnehmern sind in Abschnitt 4.2 dieses CPS beschrieben.

6.4.2. Schutz der Aktivierungsdaten

Nutzerkennungen und Prüfsummen für die Passwörter der CommisSign CA Server-Systemverwaltung, der CA-Betreuer und der RA sind in der Systemdatenbank der CommisSign CA gespeichert.

6.4.3. Sonstige Aspekte der Aktivierungsdaten



53/10

6.5. Computer-Sicherheitskontrollen

6.5.1. Spezifische technische Anforderungen an die Computersicherheit

Folgende Funktionalität wird durch das Betriebssystem des CommisSign-CA-Systems und das Zusammenwirken von Betriebssystem, CommisSign-CA-Software und physischen Kontrollen gewährleistet:

• Zugangskontrolle zu den Diensten der CA und den Rollen der PKI,

• erzwungene Trennung der Aufgaben für die Rollen der PKI,

• Identifizierung und Authentifizierung von PKI-Rollen und zugehörigen Personen,

• Einsatz kryptografischer Verfahren für die Kommunikation während einer Sitzung und für die Sicherheit der Datenbank,

• Archivierung von History- und Audit-Aufzeichnungen der CA und der Endanwender,

• Audit von sicherheitsrelevanten Ereignissen und

• Wiedererlangungsmechanismen für Schlüssel und das CA-System.

Informationen zu dieser Funktionalität finden Sie in den jeweiligen Abschnitten dieses CPS.

6.5.2. Bewertung der Computersicherheit


6.6. Kontrollen über den Lebenszyklus

6.6.1. Systementwicklungskontrollen


6.6.2. Kontrollen des Sicherheitsmanagements

Zu den Kontrollen des Sicherheitsmanagements für die CommisSign CA gehören:

• ein Mechanismus und/oder vorhandene Konzepte zur Kontrolle und Überwachung der CA-Systemkonfiguration;

• die ausschließliche Verwendung der Ausstattung der CommisSign CA zur Verwaltung der Infrastruktur für das Schlüsselmanagement;

• der Verzicht der CommisSign CA auf Anwendungen oder Softwarekomponenten, die nicht Teil der CA-Konfiguration sind, ausgenommen Virenschutzsoftware; und


54/10

• Installation von Aktualisierungen der CommisSign-CA-Ausstattung durch vertrauenswürdige, geschulte Mitarbeiter in der vorgeschriebenen Weise.

6.7. Netzwerk-Sicherheitskontrollen

[Der Zugriff von entfernten Rechnern auf das System der CommisSign CA erfolgt nur mit einem sicheren Kommunikationsprotokoll. Andere Formen des entfernten Zugriffs sind unzulässig, Dienste wie ankommendes FTP nicht möglich. TCP/IP-Ports sind nur für die folgenden Kommunikationen aktiviert: PKI-Audit für aktivierte Ereignisse und Audit gescheiterter Operationen und erfolgreicher seltener Operationen.]

6.8. Konstruktionskontrollen für Kryptografiemodule

Das Kryptografiemodul der PKI-Software entspricht […]. Der Masterschlüssel der CommisSign CA wird in einem Hardware-Gerät gespeichert, das [...] entspricht.

Das Kryptografiemodul zur Schlüsselerzeugung für die PKI-Software entspricht […].

7. ZERTIFIKATS- UND CRL-PROFIL

7.1. Zertifikatsprofil

7.1.1. Versionsnummer

Die CommisSign CA gibt Zertifikate der X.509 Version 3 aus, die dem Profil der PKIX-Zertifikate und CRL entsprechen. Folgende X.509-Felder werden unterstützt:

Feld Beschreibung

version: Das Feld version wird auf v3 gesetzt.

serial number: Beim Erzeugen eines neuen Teilnehmerzertifikats wird vom System der CommisSign CA eine laufende Nummer erzeugt, die innerhalb der Domain der CommisSign CA eindeutig ist.

signature Algorithm: Kennzeichen für den Algorithmus, den die CommisSign CA zum Signieren des Zertifikats verwendet.

issuer: Ausgabestelle des Zertifikats: Distinguished Name der CommisSign CA

validity: Gültigkeitsdauer des Zertifikats. Als Anfangsdatum wird notBefore start date


55/10

Feld Beschreibung

und als Enddatum notAfter end date angegeben.

subject: Distinguished Name des Zertifikatsinhabers

public key information: Kennzeichen für den Algorithmus

des öffentlichen Schlüssels

Thumbprint Algorithm: Kennzeichen für den Algorithmus

Thumbprint

7.1.2. Erweiterungen für Zertifikate

Erweiterungen werden nicht unterstützt.

7.1.3. Objektkennungen für Algorithmen

Die CommisSign CA unterstützt folgende Algorithmen:

Algorithmus Objektkennung (Object Identifier)

Ausgebende Stelle

SHA1WithRSAEncryption 1 2 840 113549 1 1 5 UTIMACO

DES-EDE3-CBC 1 2 840 113549 3 7 UTIMACO

7.1.4. Namen

Die Felder issuer DN (Distinguished Name der ausgebenden Stelle) und subject DN (Distinguished Name des Subjekts) enthalten den vollständigen X.500-Distinguished-Name der ausgebenden Stelle oder des Zertifikatsinhabers.

7.1.5. Namenseinschränkungen

Die CommisSign CA verwendet keine Namenseinschränkungen.

7.1.6. Objektkennung der PKI-CP


7.1.7. Verwendung der Erweiterungen für Einschränkungen der PKI-CP

Die CommisSign CA verwendet keine Einschränkungen ihrer CP.

7.1.8. Syntax und Semantik von Policy Qualifiers



56/10

7.1.9. Kritikalität von Erweiterungen und ihre Verarbeitungssemantik für die CP

[Die einzige Zertifikatserweiterung, die in ausgegebenen Zertifikaten als „critical“ angesehen werden kann, ist die Erweiterung cRLDistributionPoints. CRL oder ARL werden von dem Verzeichniseintrag geholt, der als CRL-Verteilerstelle im Zertifikat eingetragen ist, es sei denn, eine aktuelle Version der CRL oder ARL ist im Cache der Clientsoftware des Teilnehmers vorhanden.]

7.2. CRL-Profil [Review nach Implementierung]

7.2.1. Versionsnummer

Bei den von der CommisSign CA ausgegebenen CRL handelt es sich um CRL der X.509 Version 2 gemäß PKIX-Zertifikat und CRL-Profil.

Die folgende Liste enthält die Felder im CRL-Format der X.509 Version 2, die von der CommisSign CA benutzt werden.

Feld Beschreibung

Version Wird auf v2 gesetzt.

Signature Kennung für den Algorithmus, der für die Signatur der CRL benutzt wird.

Issuer Vollständiger Distinguished Name der CommisSign CA

this update Ausgabedatum der CRL

next update Datum der voraussichtlich nächsten Aktualisierung der CRL

revoked certificates

Liste mit den Daten widerrufener Zertifikate

7.2.2. Erweiterungen der CRL und CRL-Einträge

Der folgende Abschnitt beschreibt die Erweiterungen der CRL und CRL-Einträge der X.509 Version 2, die von der CommisSign CA unterstützt werden, und diejenigen, die in den von der CommisSign CA ausgegebenen CRL nicht unterstützt werden.

7.2.2.1.Unterstützte Erweiterungen

Die folgende Tabelle zeigt die Erweiterungen der CRL und CRL-Einträge, die von der CommisSign CA unterstützt werden

ERWEITE-RUNG

KRITIKA-LITÄT

OPTIONAL ANMERKUNGEN

AuthorityKeyI Non critical Nicht Nur ein Element [0]


57/10

ERWEITE-RUNG

KRITIKA-LITÄT

OPTIONAL ANMERKUNGEN

dentifier optional (authorityKeyIdentifier) wird eingetragen.

Enthält einen 20-Byte Hashwert der subjectPublicKeyInfo im CA-Zertifikat.

CRLNumber particular

Non critical Nicht optional

Wird bei jeder Änderung einer CRL/ARL erhöht.

ReasonCode Non critical Nicht optional

Erweiterung der CRL-Einträge (Anlasscode) – nur ReasonCodes (0), (1), (3), (4) und (5) werden zurzeit unterstützt.

IssuingDistributionPoint

Critical Nicht optional

Element [0] (distributionPoint) enthält den vollständigen DN der Verteilerstelle.

Element [1] (onlyContainsUserCerts) ist enthalten für CRL.

Element [2] (onlyContainsCACerts) ist enthalten für ARL.

Element [1] und [2] schließen sich innerhalb einer Widerrufsliste wechselseitig aus.

Element [3] und [4] werden nicht verwendet.

7.2.2.2.Nicht unterstützte Erweiterungen

Erweiterungen der CRL der X.509 Version 2, die von der CommisSign CA nicht unterstützt werden:

• issuer alternative name,

• hold instruction code,


58/10

• invalidity date,

• certificate issuer,

• delta CRL indicator.

8. PFLEGE DIESES CPS

8.1. Änderungsverfahren

Dieses CPS wird jedes Jahr vollständig überprüft. Fehler, Aktualisierungen und Änderungsvorschläge teilen Sie bitte der im Abschnitt 1.4 genannten Kontaktperson mit.

8.1.1. Änderungen ohne Benachrichtigung

Teile dieses CPS können dann ohne Änderungen der Versionsnummer und Benachrichtigung der Nutzer geändert werden, wenn sie nach dem Ermessen der PA keine oder geringe Auswirkungen auf Teilnehmer und cross-zertifizierte CA-Domains haben, die Zertifikate und CRL gemäß diesem CPS nutzen.

8.1.2. Änderungen mit Benachrichtigung

Wenn Änderungen der auf diesem CPS basierenden CP oder dieses CPS selbst notwendig werden, die nach dem Ermessen der PA wesentliche Auswirkungen auf Teilnehmer und cross-zertifizierte CA-Domains haben, die Zertifikate und CRL gemäß diesem CPS nutzen, dann werden die Nutzer 30 Tage vorher benachrichtigt. Die Versionsnummer dieses Dokuments wird erhöht.

8.1.2.1.Betroffene Teile dieses CPS

Änderungsmitteilungen gemäß Abschnitt 8.1.1 „Änderungen ohne Benachrichtigung“ und 8.1.2 „Änderungen mit Benachrichtigung“ können alle Teile dieses CPS betreffen.

8.1.2.2.Benachrichtigungsverfahren

30 Tage vor wesentlichen Änderungen dieses CPS werden die geplanten Änderungen auf der Website der CommisSign CA angekündigt und den cross-zertifizierten Zertifizierungsstellen per sichere E-Mail mitgeteilt. Die Benachrichtigung enthält die vorgeschlagenen Änderungen, das Datum, bis zu welchem Kommentare berücksichtigt werden können, und das voraussichtliche tatsächliche Änderungsdatum. Die PA kann die Zertifizierungsstellen um die Ankündigung der Änderungen gegenüber deren Teilnehmern bitten.

8.1.2.3.Kommentierungsphase

Wenn nicht anders festgelegt, dauert die Kommentierungsphase 30 Tage. Sie wird in der Benachrichtigung mitgeteilt.


59/10

8.1.2.4.Kommentierungsverfahren

Kommentare zu vorgeschlagenen Änderungen sind an die CA OA zu richten. Ein Kommentar muss enthalten: Beschreibung und Begründung der Änderung, Kontaktdaten und Signatur der Person, die die Änderung beantragt.

Die OA kann nach Ablauf der Kommentierungsphase eine vorgeschlagene Änderung übernehmen, mit Änderungen übernehmen oder ablehnen. Wie die OA mit den vorgeschlagenen Änderungen verfährt, wird von der PA der Europäischen Kommission überprüft. Die Entscheidung über eine vorgeschlagene Änderung liegt im Ermessen von OA und PA.

8.1.2.5.Frist für endgültige Änderungsmitteilung

Die OA legt die Frist für die endgültige Änderungsmitteilung fest.

8.1.2.6.Änderungen, die eine Neuausgabe der CP erforderlich machen

Gibt eine konzeptionelle Änderung nach Ansicht der PA Anlass, eine Neuausgabe der CP herauszugeben, kann die PA für die geänderte CP eine neue Objektkennung (OID, Object Identifier) vergeben.

8.2. Veröffentlichungs- und Benachrichtigungskonzepte

Die OA veröffentlicht dieses CPS und die PKI-CP der Europäischen Kommission auf der Website der CommisSign CA. Auf Nachfrage sendet sie sie auch per E-Mail zu.

8.3. CPS-Genehmigungsverfahren

Die Feststellung, dass das CPS der CommisSign CA der PKI-CP der Europäischen Kommission entspricht, obliegt der PA der Europäischen Kommission.

9. ANHÄNGE

9.1. Abkürzungen

ARL Authority Revocation List

Widerrufsliste von Cross-Zertifikaten

CA Certification Authority

Zertifizierungsstelle

CP Certificate Policy

Zertifizierungskonzept


60/10

CPS Certificate Practice Statement

Beschreibung der Zertifizierungspraxis

CRL Certificate Revocation List

Widerrufsliste

CUG Closed User Group

Geschlossene Nutzergruppe

GD Generaldirektion

IDA Interchange of Data between Administrations

Datenaustausch zwischen Verwaltungen

LRA Local Registration Authority

Lokale Registrierungsstelle

OA Operations Authority

PA Policy Authority

PASS SPS

Protocol and Security Service

Dienst Protokoll und Sicherheit

PKI Public Key Infrastructure

Infrastruktur für öffentliche Schlüssel

RA Registration Authority

Registrierungsstelle

SO Security Officer

Sicherheitsbeauftragter

TCP/IP Transmission Control Protocol/Internet Protocol

URL Unified Resource Locator

9.2. Definitionen

Aktivierungsdaten (Activation Data). Private Daten, die keine Schlüssel sind, aber für den Zugriff auf kryptografische Module benötigt werden.

Ausgebende Zertifizierungsstelle (Issuing CA). Die CA, die ein bestimmtes Zertifikat ausgegeben und signiert hat.


61/10

CA-Administratoren (CA Administrators). Die Systemadministratoren der CA sind die Personen, die für den korrekten Betrieb und die Konfiguration der Hard- und Software für die CommisSign CA sowie für Sicherungen des CommisSign-CA-Systems verantwortlich sind.

CA-Betreuer (CA Officers). Die CA-Betreuer sind die Personen, die für den Betrieb und die Systemverwaltung des Servers und der Software der Zertifizierungsstelle verantwortlich sind.

CA Operations Authority (OA). Die CA OA erstellt und verwaltet das CPS der CA und pflegt den Masterschlüssel.

Digitale Signatur. Ergebnis der Umwandlung einer Nachricht durch ein Kryptografiesystem. Dabei werden Schlüssel verwendet, so dass der Empfänger einer Nachricht mit digitaler Signatur feststellen kann,

(1) ob die Verschlüsselung mit einem Schlüssel durchgeführt wurde, der dem der signierenden Person entspricht, und

(2) ob die Nachricht nach der Verschlüsselung verändert wurde.

Endanwender (End Entity). Subjekt, das in der PKI erzeugte Schlüssel und Zertifikate für andere Zwecke nutzt als die Verwaltung eben dieser Schlüssel und Zertifikate. Ein Endanwender kann ein Teilnehmer – eine vertrauende Partei – sein.

Hochsicherheitsbereich. Bereich, der durch eine Zugangskontrolle überwacht wird und zu dem der Zutritt nur sicherheitstechnisch überprüften Mitarbeitern und Besuchern in Begleitung gestattet ist. Hochsicherheitsbereiche sollten räumlich abgetrennt sein. Sie werden an allen 7 Wochentagen rund um die Uhr von Sicherheitskräften oder anderen Mitarbeitern oder aber durch elektronische Einrichtungen bewacht.

Kommissionsbedienstete (Commission staff). Personen, die bei der Europäischen Kommission in einem regulären Beschäftigungsverhältnis tätig sind und im Rahmen ihrer Funktion Verantwortung tragen und Pflichten innerhalb der Europäischen Kommission erfüllen.

Masternutzer der CA (CA Master users). Die Masternutzer sind berechtigt, den Masterschlüssel der CommisSign CA zu erzeugen und zu pflegen. Sie dürfen Passwörter für den Server der Zertifizierungsstelle ändern und die Zugriffsrechte der CA-Betreuer wiederherstellen, wenn diese ihr Passwort vergessen haben sollten.

MD5. Von der RSA Data Security Inc. entwickelter Verschlüsselungsalgorithmus für Nachrichten.

Mitarbeiter. Personen, die bei der Europäischen Kommission beschäftigt sind.

Objektkennung (OID, Object Identifier). Eindeutiges numerisches oder alphanumerisches Kennzeichen, das ein bestimmtes Objekt oder eine Objektklasse nach dem ISO Registrierungsstandard bezeichnet.


62/10

Operational Authority. Mitarbeiter, die für den gesamten Betrieb einer PKI-Zertifizierungsstelle der Europäischen Kommission zuständig sind. Zu ihrem Verantwortungsbereich gehören Personalwesen, Finanzen und Konfliktregelung. Die Rolle der Operational Authority erfordert kein Konto auf der Workstation der Zertifizierungsstelle.

Organisation. Abteilung, Niederlassung, Unternehmen, Partnerschaft, Trust, Jointventure oder sonstiger Zusammenschluss.

PKI-Beauftragte (PKI Officers). Personen, die zur Durchführung der mit dem Betrieb einer PKI verbundenen Aufgaben befugt sind.

Policy Authority (PA). Organ der Europäischen Kommission, das Grundsatzentscheidungen zu CP und CPS in der gesamten PKI der Europäischen Kommission trifft, implementiert und verwaltet.

Infrastruktur für öffentliche Schlüssel (PKI, Public Key Infrastructure). Infrastruktur, bestehend aus Hard- und Software, Menschen, Prozessen und Politiken. Im Rahmen dieser Infrastruktur wird den vertrauenden Parteien die Verwaltung des öffentlichen Teils eines asymmetrischen Schlüsselpaars mit überprüfbarem Bezug zum Teilnehmer geboten, unter Einsatz der Technik für digitale Signaturen.

Registrierungsstelle (RA, Registration Authority). Subjekt, das Teilnehmer vor Ausgabe des Zertifikats identifiziert und authentifiziert, die Zertifikate aber nicht selbst signiert oder ausgibt. Die CA delegiert also bestimmte Aufgaben an die RA.

Sponsor. Sponsor der PKI der Europäischen Kommission ist die Abteilung oder der Beamte, die die Entscheidung genehmigen, dass an eine Einzelperson oder Organisation ein Zertifikat ausgegeben wird. (Für einen Mitarbeiter kann dies beispielsweise sein Vorgesetzter sein.) Der Sponsor muss der CA oder RA mitteilen, wenn sich die Beziehung zum Teilnehmer geändert hat oder wenn sie beendet wurde, damit das Zertifikat widerrufen oder aktualisiert werden kann.

Subjekt (Entity). Autonomes Element innerhalb der PKI, das eine Zertifizierungsstelle sein kann, eine Registrierungsstelle oder ein Endanwender.

Teilnehmer (Subscriber). Einzelperson oder Organisation, deren öffentlicher Schlüssel in einem Zertifikat für den öffentlichen Schlüssel zertifiziert worden ist. In der PKI der Europäischen Kommission kann dies ein Beamter sein oder ein Vertragsnehmer der Europäischen Kommission. Teilnehmer können ein oder mehrere Zertifikate einer bestimmten CA besitzen, die ihnen persönlich zugeordnet sind. Meist haben sie mindestens zwei gültige Zertifikate, eins mit dem Schlüssel für die Verifizierung ihrer digitalen Signatur, das andere mit dem Schlüssel für die Verschlüsselung.

Vertrauende Partei (Relying Party). Person, die ein Zertifikat benutzt, das von einer PKI-CA der Europäischen Kommission signiert wurde, um damit eine digitale Signatur zu authentifizieren, oder um ihre Kommunikation mit


63/10

dem Zertifikatsinhaber zu verschlüsseln. Die Person muss außerdem Teilnehmer einer PKI-CA der Europäischen Kommission oder einer PKI sein, die bei der Europäischen Kommission cross-zertifiziert ist.

Verzeichnis (Directory). Verzeichnissystem, das den Empfehlungen der Serie X.500 der ITU-T entspricht.

Widerrufsliste (CRL, Certificate Revocation List). Liste widerrufener Zertifikate, erzeugt und signiert von derselben Zertifizierungsstelle (CA), die die Zertifikate ausgegeben hat. Ein Zertifikat wird dann auf die Liste gesetzt, wenn es widerrufen wurde, weil beispielsweise der Schlüssel kompromittiert ist. Unter Umständen kann sich die CA für die Aufteilung einer Widerrufsliste in eine Reihe kleinerer Widerrufslisten entscheiden.

Widerrufsliste von Cross-Zertifikaten (ARL, Authority Revocation List). Eine ARL ist eine Liste mit widerrufenen Cross-Zertifikaten einer Zertifizierungsstelle.

Zertifikat (Certificate). Öffentlicher Schlüssel (mit zusätzlichen Daten) eines Nutzers, fälschungssicher durch eine digitale Signatur mit dem geheimen Schlüssel der Zertifizierungsstelle, die ihn ausgibt. Das Format des Zertifikats entspricht der Empfehlung X.509 der ITU-T.

Zertifizierungsstelle (CA, Certification Authority). Stelle, der von einem oder mehreren Nutzern die Ausgabe und Verwaltung von Zertifikaten für öffentliche Schlüssel nach X.509 und von Widerrufslisten dieser Zertifikate anvertraut wurde.

9.3. Quellen

[RD1] ICT Security Policy

[RD2] RFC 2527

[RD3] Verordnung (EG) Nr. 45/2001 des Europäischen Parlaments und des Rates vom 18. Dezember 2000

certificate practice statement · certificate practice statement 8/10 1. einfÜhrung dieses...

Documents