IEI Corporate PKI Certificate Policy (CP) & Certification...

75
IEI Corporate PKI Certificate Policy (CP) & Certification Practice Statement (CPS) T-Systems International GmbH Version 1.0 Stand 15.06.2011 Status freigegeben Autor Johannes Portaro Geheimhaltungsvermerk: öffentlich

Transcript of IEI Corporate PKI Certificate Policy (CP) & Certification...

Page 1: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

IEI Corporate PKI Certificate Policy (CP) & Certification Practice Statement (CPS) T-Systems International GmbH

Version 1.0 Stand 15.06.2011 Status freigegeben Autor Johannes Portaro

Geheimhaltungsvermerk: öffentlich

Page 2: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

Impressum

Copyright © 2011 by T-Systems T-Systems international GmbH, Frankfurt am Main, Germany

Rechte, auch die des auszugsweisen Nachdrucks, der fotomechanischen Wiedergabe (einschließlich Mikrokopie) sowie der Auswertung durch Datenbanken oder ähnliche Ein-richtungen, vorbehalten.

Herausgeber

T-Systems International GmbH PRODUCTION CSS PSS

Untere Industriestraße 20, 57250 Netphen

Dateiname

CP-CPS_CorpPKI_v1 0_(FMO)

Dokumentennummer

Dokumentnummer: Datei > Eigenschaften

Dokumentenbezeichnung

Certificate Policy (CP) & Certi-fication Practice Statement (CPS)

Version

1.0

Stand

15.06.2011

Status

freigegeben

Autor

Johannes Portaro

Inhaltlich geprüft von

Klaus Jungbluth

Netphen im Juni 2011

Freigegeben von

Klaus Jungbluth

Netphen im Juni 2011

Ansprechpartner

Klaus Jungbluth

Telefon / Fax

+49 271 708 16 84

E-Mail

[email protected]

Kurzinfo

In dem vorliegenden Dokument sind CP und CPS für die Corporate PKI in der Ausbau-stufe 2 bzw. des Release 2.8 im Rahmen des Projekts Office Standardization (OS) zu-sammengefasst. Es beschreibt das für den Betrieb der Corporate PKI erforderliche Si-cherheitsniveau und beinhaltet Sicherheitsvorgaben sowie Erklärungen hinsichtlich tech-nischer, organisatorischer und rechtlicher Aspekte.

Das Dokument orientiert sich an den dem internationalen Standard für Zertifizierungs-richtlinien RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certi-fication Practices Framework der Internet Society.

Page 3: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 3

Inhaltsverzeichnis

1 Einleitung ........................................................................................................... 10 1.1 Überblick ............................................................................................................ 10 1.2 Dokumentenname und Identifikation.................................................................. 11 1.3 PKI Teilnehmer .................................................................................................. 11 1.3.1 Zertifizierungsstellen .......................................................................................... 12 1.3.2 Registrierungsstellen.......................................................................................... 12 1.3.3 Zertifikatsinhaber................................................................................................ 13 1.3.4 Zertifikatsprüfer (Relying Parties)....................................................................... 13 1.3.5 Weitere Teilnehmer............................................................................................ 13 1.4 Anwendungsbereich........................................................................................... 13 1.4.1 Geeignete Zertifikatsnutzung ............................................................................. 13 1.4.2 Untersagte Zertifikatsnutzung ............................................................................ 14 1.5 Verwaltung der Zertifizierungsrichtlinie .............................................................. 14 1.5.1 Änderungsmanagement..................................................................................... 14 1.5.2 Ansprechpartner................................................................................................. 14 1.5.3 Eignungsprüfer für Regelungen für den Zertifizierungsbetrieb (CPS) gemäß

Zertifizierungsrichtlinie ....................................................................................... 14 1.5.4 Verfahren zur Anerkennung von Regelungen für den Zertifizierungsbetrieb

(CPS) ................................................................................................................. 15 1.6 Definitionen und Abkürzungen........................................................................... 15

2 Veröffentlichungen und Verzeichnisdienste....................................................... 16 2.1 Verzeichnisdienste (Repositories)...................................................................... 16 2.2 Veröffentlichung von Zertifikatsinformationen .................................................... 19 2.3 Aktualisierung der Informationen (Zeitpunkt, Frequenz) .................................... 19 2.4 Zugangskontrolle zu Verzeichnisdiensten (Repositories) .................................. 20

3 Identifikation und Authentifikation ...................................................................... 21 3.1 Namen ............................................................................................................... 21 3.1.1 Namensformen .................................................................................................. 21 3.1.2 Aussagekraft von Namen................................................................................... 21 3.1.3 Anonymität bzw. Pseudonyme für Zertifikatsinhaber ......................................... 21 3.1.4 Regeln zur Interpretation verschiedener Namensformate ................................. 21 3.1.5 Eindeutigkeit von Namen ................................................................................... 21 3.1.6 Anerkennung, Authentifizierung und Funktion von Warenzeichen .................... 21 3.2 Identitätsprüfung bei Neuantrag......................................................................... 22 3.2.1 Nachweis des Besitzes des privaten Schlüssels ............................................... 22 3.2.2 Authentifizierung einer Organisation.................................................................. 22 3.2.3 Authentifizierung einer natürlichen Person ........................................................ 22 3.2.4 Nicht überprüfte Teilnehmerangaben................................................................. 22 3.2.5 Überprüfung der Berechtigung........................................................................... 22 3.2.6 Interoperabilitätskriterien.................................................................................... 22 3.3 Identifizierung und Authentifizierung bei einer Zertifikatserneuerung ................ 23 3.3.1 Routinemäßige Zertifikatserneuerung................................................................ 23 3.3.2 Zertifikatserneuerung nach einer Sperrung........................................................ 23 3.4 Identifizierung und Authentifizierung von Sperraufträgen .................................. 23

4 Ablauforganisation (Zertifikatslebenszyklus)...................................................... 24 4.1 Zertifikatsantrag ................................................................................................. 24 4.1.1 Wer kann Zertifikate beantragen........................................................................ 24 4.1.2 Verfahren und Verantwortungen........................................................................ 24 4.2 Bearbeitung von Zertifikatsanträgen .................................................................. 24 4.2.1 Durchführung von Identifikation und Authentifizierung....................................... 24 4.2.2 Annahme oder Ablehnung von Zertifikatsanträgen............................................ 25 4.2.3 Zeit zur Verarbeitung von Zertifikatsaufträgen ................................................... 25 4.3 Zertifikatserstellung............................................................................................ 25 4.3.1 Aufgaben der Zertifizierungsstelle...................................................................... 25

Page 4: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 4

4.3.2 Benachrichtigung des Antragstellers.................................................................. 25 4.4 Akzeptanz der Zertifikate ................................................................................... 25 4.4.1 Annahme von Zertifikaten .................................................................................. 25 4.4.2 Veröffentlichung der Zertifikate durch die Zertifizierungsstelle .......................... 26 4.4.3 Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle ................. 26 4.5 Schlüssel- und Zertifikatsverwendung ............................................................... 26 4.5.1 Nutzung durch den Zertifikatsinhaber ................................................................ 26 4.5.2 Nutzung des Zertifikats durch die Relying Party ................................................ 26 4.6 Zertifikatserneuerung unter Beibehaltung des alten Schlüssels (Re-

Zertifizierung) ..................................................................................................... 26 4.6.1 Gründe für eine Zertifikatserneuerung ............................................................... 27 4.6.2 Wer kann eine Zertifikatserneuerung beantragen?............................................ 27 4.6.3 Ablauf der Zertifikatserneuerung........................................................................ 27 4.6.4 Benachrichtigung des Antragstellers nach Zertifikatserneuerung...................... 27 4.6.5 Annahme einer Zertifikatserneuerung................................................................ 27 4.6.6 Veröffentlichungen der erneuerten Zertifikate durch die Zertifizierungsstelle .... 27 4.6.7 Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle ................. 28 4.7 Schlüssel- und Zertifikatserneuerung (Re-key).................................................. 28 4.7.1 Gründe für eine Schlüssel- und Zertifikatserneuerung....................................... 28 4.7.2 Wer kann eine Schlüssel- und Zertifikatserneuerung beantragen? ................... 28 4.7.3 Ablauf der Schlüssel- und Zertifikatserneuerung ............................................... 28 4.7.4 Benachrichtigung des Zertifikatsinhabers .......................................................... 28 4.7.5 Annahme der Schlüssel- und Zertifikatserneuerung.......................................... 28 4.7.6 Veröffentlichung einer Zertifikatserneuerung durch die Zertifizierungsstelle ..... 28 4.7.7 Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle ................. 28 4.8 Zertifikatsmodifizierung ...................................................................................... 29 4.8.1 Gründe für die Modifikation eines Zertifikates.................................................... 29 4.8.2 Wer darf kann Modifikation eines Zertifikates beantragen? ............................... 29 4.8.3 Ablauf der Zertifikatsmodifizierung..................................................................... 29 4.8.4 Benachrichtigung des Zertifikatsinhabers .......................................................... 29 4.8.5 Annahme der Zertifikatsmodifizierung................................................................ 29 4.8.6 Veröffentlichung einer Zertifikatsmodifizierung durch die Zertifizierungsstelle .. 29 4.8.7 Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle ................. 29 4.9 Widerruf/Sperrung und Suspendierung von Zertifikaten .................................... 29 4.9.1 Gründe für Widerruf/Sperrung............................................................................ 29 4.9.2 Wer kann Widerruf/ Sperrung beantragen? ....................................................... 30 4.9.3 Ablauf von Widerruf / Sperrung.......................................................................... 30 4.9.4 Fristen für den Zertifikatsinhaber ....................................................................... 31 4.9.5 Bearbeitungsfristen für die Zertifizierungsstelle ................................................. 31 4.9.6 Anforderung zu Sperrprüfungen durch eine Relying Party ................................ 31 4.9.7 Häufigkeit der Sperrlistenveröffentlichung ......................................................... 31 4.9.8 Maximale Latenzzeit für Sperrlisten................................................................... 31 4.9.9 Verfügbarkeit von Online-Statusabfragen (OCSP) ............................................ 31 4.9.10 Anforderungen an Online-Statusabfragen (OCSP)............................................ 31 4.9.11 Andere Formen der Veröffentlichung von Sperrinformationen........................... 32 4.9.12 Anforderungen bei Kompromittierung von privaten Schlüsseln ......................... 32 4.9.13 Gründe für eine Suspendierung......................................................................... 32 4.9.14 Wer kann eine Suspendierung beantragen?...................................................... 32 4.9.15 Ablauf einer Suspendierung............................................................................... 32 4.9.16 Maximale Suspendierungsdauer........................................................................ 33 4.10 Statusabfrage von Zertifikaten (OCSP, CRL) .................................................... 33 4.10.1 Betriebsbedingte Aspekte .................................................................................. 33 4.10.2 Verfügbarkeit...................................................................................................... 33 4.10.3 Weitere Merkmale .............................................................................................. 33 4.11 Beendigung des Vertragsverhältnisses.............................................................. 33 4.12 Schlüsselhinterlegung und –wiederherstellung (Key Escrow, Key Recovery) ... 33 4.12.1 Richtlinien und Praktiken zur Schlüsselhinterlegung und –wiederherstellung ... 33 4.12.2 Richtlinien und Praktiken zum Schutz und Wiederherstellung von

Sitzungsschlüsseln............................................................................................. 34

5 Infrastrukturelle, organisatorische und personelle Sicherheitsmaßnahmen ...... 35

Page 5: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 5

5.1 Infrastrukturelle Sicherheitsmaßnahmen ........................................................... 35 5.1.1 Einsatzort und Bauweise.................................................................................... 35 5.1.2 Räumlicher Zugang............................................................................................ 35 5.1.3 Energieversorgung und Klimatisierung .............................................................. 36 5.1.4 Wassergefährdung............................................................................................. 36 5.1.5 Brandschutz ....................................................................................................... 36 5.1.6 Aufbewahrung und Entsorgung von Datenträgern............................................. 36 5.1.7 Externe Datensicherung..................................................................................... 37 5.2 Organisatorische Sicherheitsmaßnahmen......................................................... 37 5.2.1 Rollen................................................................................................................. 37 5.2.2 Anzahl der pro Aufgabe involvierten Personen.................................................. 37 5.2.3 Identifizierung und Authentifizierung jeder Rolle................................................ 38 5.2.4 Rollen, die eine Aufgabentrennung erfordern .................................................... 38 5.3 Personelle Sicherheitsmaßnahmen ................................................................... 38 5.3.1 Anforderungen an Personal ............................................................................... 38 5.3.2 Sicherheitsüberprüfung von Personal ................................................................ 39 5.3.3 Schulungsanforderungen................................................................................... 39 5.3.4 Häufigkeit und Anforderungen an Fortbildungen ............................................... 39 5.3.5 Häufigkeit und Ablauf von Arbeitsplatzwechseln ............................................... 39 5.3.6 Sanktionen bei unerlaubten Handlungen........................................................... 39 5.3.7 Anforderungen an unabhängige, selbständige Zulieferer .................................. 39 5.3.8 Dokumentation für Mitarbeiter............................................................................ 40 5.4 Überwachung / Protokollierung.......................................................................... 40 5.4.1 Überwachte Ereignisse ...................................................................................... 40 5.4.2 Bearbeitungsintervall der Protokolle .................................................................. 40 5.4.3 Aufbewahrungsfrist für Log-Dateien................................................................... 40 5.4.4 Schutz von Log-Dateien..................................................................................... 41 5.4.5 Backup von Log-Dateien.................................................................................... 41 5.4.6 Überwachungssystem (intern / extern) .............................................................. 41 5.4.7 Benachrichtigung bei schwerwiegenden Ereignissen........................................ 41 5.4.8 Schwachstellenanalyse...................................................................................... 41 5.5 Archivierung ....................................................................................................... 41 5.5.1 Archivierte Daten................................................................................................ 41 5.5.2 Aufbewahrungsfrist für archivierte Daten ........................................................... 41 5.5.3 Schutz der Archive ............................................................................................. 41 5.5.4 Archivbackup ..................................................................................................... 41 5.5.5 Anforderungen an Zeitstempel........................................................................... 42 5.5.6 Archivierungssystem (intern / extern)................................................................. 42 5.5.7 Abruf und Verifikation von archivierten Informationen ....................................... 42 5.6 Schlüsselwechsel der Zertifizierungsstelle......................................................... 42 5.7 Kompromittierung und Desaster Recovery ........................................................ 42 5.7.1 Vorgehen bei Sicherheitsvorfällen und Kompromittierung ................................. 42 5.7.2 Betriebsmittel, Software und/oder Daten wurden kompromittiert....................... 42 5.7.3 Kompromittierung des privaten Schlüssels ........................................................ 43 5.7.4 Betriebswiederaufnahme nach einem Notfall..................................................... 43 5.8 Einstellung des Betriebs..................................................................................... 43

6 Technische Sicherheitsmaßnahmen.................................................................. 44 6.1 Schlüsselerzeugung und –installation................................................................ 44 6.1.1 Schlüsselerzeugung........................................................................................... 44 6.1.2 Übergabe des privaten Schlüssels an Zertifikatsinhaber ................................... 44 6.1.3 Übergabe des öffentlichen Schlüssels an den Zertifikatsherausgeber .............. 44 6.1.4 Publikation öffentlicher Schlüssel der Zertifizierungsstelle ................................ 45 6.1.5 Schlüssellängen................................................................................................. 45 6.1.6 Erzeugung der Public Key Parameter und Qualitätssicherung .......................... 45 6.1.7 Schlüsselverwendungzwecke (nach X.509 v3, Attribut „key usage“)................. 45 6.2 Schutz von privaten Schlüsseln und Einsatz von Kryptomodulen ..................... 45 6.2.1 Standard kryptographischer Module .................................................................. 46 6.2.2 Aufteilung privater Schlüssel auf mehrere Personen (n-aus-m) ........................ 46 6.2.3 Hinterlegung privater Schlüssel ......................................................................... 46 6.2.4 Backup privater Schlüssel.................................................................................. 46

Page 6: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 6

6.2.5 Archivierung des privaten Schlüssels ................................................................ 46 6.2.6 Transfer eines privaten Schlüssels in oder aus einem Kryptomodul ................. 47 6.2.7 Ablage privater Schlüssel in Kryptomodulen...................................................... 47 6.2.8 Aktivierung privater Schlüssel ............................................................................ 47 6.2.9 Deaktivierung privater Schlüssel........................................................................ 47 6.2.10 Vernichtung privater Schlüssel........................................................................... 47 6.2.11 Güte von Kryptomodulen ................................................................................... 48 6.3 Weitere Aspekte des Zertifikats- und Schlüsselmanagements .......................... 48 6.3.1 Archivierung öffentlicher Schlüssel .................................................................... 48 6.3.2 Gültigkeit von Zertifikaten und Schlüsselpaaren................................................ 48 6.4 Aktivierungsdaten .............................................................................................. 48 6.4.1 Generierung und Installation von Aktivierungsdaten.......................................... 49 6.4.2 Schutz der Aktivierungsdaten ............................................................................ 49 6.4.3 Weitere Aspekte der Aktivierungsdaten ............................................................. 49 6.5 Computerbezogene Sicherheitskontrollen ......................................................... 49 6.5.1 Spezifische Anforderungen an technische Sicherheits-maßnahen.................... 49 6.5.2 Bewertung der Computersicherheit.................................................................... 49 6.6 Technische Maßnahmen im Lebenszyklus ........................................................ 49 6.6.1 Maßnahmen der Systementwicklung ................................................................. 49 6.6.2 Maßnahmen des Sicherheitsmanagements....................................................... 50 6.6.3 Lebenszyklus der Sicherheitsmaßnahmen ........................................................ 50 6.7 Sicherheitsmaßnahmen für das Netzwerk ......................................................... 50 6.8 Zeitstempel ........................................................................................................ 50

7 Zertifikate, CRL und OCSP Profile..................................................................... 51 7.1 Zertifikatsprofile.................................................................................................. 51 7.1.1 Versionsnummern .............................................................................................. 51 7.1.2 Zertifikatserweiterungen..................................................................................... 51 7.1.3 Objektidentifkatoren der Algorithmen................................................................. 53 7.1.4 Namensformen .................................................................................................. 53 7.1.5 Namensbeschränkungen ................................................................................... 56 7.1.6 Objektidentifikatoren der Zertifizierungsrichtlinien ............................................. 56 7.1.7 Anwendung von Erweiterungen von Richtlinienbeschränkungen ...................... 56 7.1.8 Syntax und Semantik von Policy Qualifiern ....................................................... 56 7.1.9 Verarbeitung von kritischen Erweiterungen für Zertifizierungsrichtlinien ........... 56 7.2 Sperrlisten-Profil................................................................................................. 56 7.2.1 Versionsnummer ................................................................................................ 57 7.2.2 Sperrlisten- und Sperrlisteneintragserweiterungen ............................................ 57 7.3 OCSP Profil........................................................................................................ 57 7.3.1 Versionsnummern .............................................................................................. 57 7.3.2 OCSP Erweiterungen......................................................................................... 57

8 Konformitätsprüfungen....................................................................................... 58 8.1 Häufigkeit und Umstände von Prüfungen .......................................................... 58 8.2 Identität und Qualifikation von Prüfern ............................................................... 58 8.3 Verhältnis von Prüfer zu Überprüftem................................................................ 58 8.4 Prüfungsbereiche............................................................................................... 59 8.5 Mängelbeseitigung............................................................................................. 59 8.6 Mitteilung der Ergebnisse................................................................................... 59

9 Geschäftliche und rechtliche Angelegenheiten.................................................. 60 9.1 Entgelte.............................................................................................................. 60 9.1.1 Entgelte für initiale oder erneute Zertifikatsausstellung ..................................... 60 9.1.2 Entgelte für den Zugriff auf Zertifikate................................................................ 60 9.1.3 Entgelte für Sperrung oder Statusabfragen ....................................................... 60 9.1.4 Weitere Entgelte ................................................................................................ 60 9.1.5 Rückerstattungsregelungen ............................................................................... 60 9.2 Finanzielle Verantwortung.................................................................................. 60 9.2.1 Deckungsvorsorge (insurance coverage) .......................................................... 60 9.2.2 Weitere Vermögenswerte................................................................................... 61 9.2.3 Versicherung oder Garantie für Endteilnehmer.................................................. 61 9.3 Vertraulichkeit von Geschäftsinformationen....................................................... 61

Page 7: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 7

9.3.1 Vertraulich zu behandelnde Informationen ........................................................ 61 9.3.2 Nicht- vertraulich zu behandelnde Informationen............................................... 61 9.3.3 Verantwortung zum Schutz von vertraulichen Informationen............................. 61 9.4 Schutz personenbezogener Daten..................................................................... 61 9.4.1 Richtlinie zur Verarbeitung personenbezogener Daten ..................................... 62 9.4.2 Vertraulich zu behandelnde Daten..................................................................... 62 9.4.3 Nicht- vertraulich zu behandelnde Daten ........................................................... 62 9.4.4 Verantwortung zum Schutz personenbezogener Daten .................................... 62 9.4.5 Einwilligung und Nutzung personenbezogener Daten ....................................... 62 9.4.6 Offenlegung bei gerichtlicher Anordnung oder im Rahmen gerichtlicher

Beweisführung ................................................................................................... 62 9.4.7 Andere Umstände einer Offenlegung................................................................. 62 9.5 Urheberrechte .................................................................................................... 63 9.5.1 Eigentumsrechte an Zertifikaten und Sperrungsinformationen .......................... 63 9.5.2 Eigentumsrechte dieser CP/CPS....................................................................... 63 9.5.3 Eigentumsrechte an Namen............................................................................... 63 9.5.4 Eigentumsrechte an Schlüsseln und Schlüsselmaterial..................................... 63 9.6 Verpflichtungen .................................................................................................. 63 9.6.1 Verpflichtung der Zertifizierungsstelle(n)............................................................ 63 9.6.2 Verpflichtung der Registrierungsstellen ............................................................. 64 9.6.3 Verpflichtung des Zertifikatsinhabers ................................................................. 64 9.6.4 Verpflichtung der Zertifikatsprüfer (Relying Party) ............................................. 65 9.6.5 Verpflichtung anderer Teilnehmer...................................................................... 65 9.7 Gewährleistung .................................................................................................. 65 9.8 Haftungsbeschränkungen .................................................................................. 65 9.9 Haftungsfreistellungen ....................................................................................... 65 9.10 Laufzeit und Beendigung ................................................................................... 66 9.10.1 Inkrafttreten........................................................................................................ 66 9.10.2 Aufhebung.......................................................................................................... 66 9.10.3 Konsequenzen der Aufhebung........................................................................... 66 9.11 Individuelle Benachrichtigung und Kommunikation mit Teilnehmern................. 66 9.12 Änderungen/Anpassungen der Richtlinie........................................................... 67 9.12.1 Vorgehen bei Änderungen/Anpassungen .......................................................... 67 9.12.2 Benachrichtigungsmechanismus und Fristen .................................................... 67 9.12.3 Notwendigkeit der Änderung des Richtlinienbezeichners (OID) ........................ 67 9.13 Regelung von Unstimmigkeiten ......................................................................... 67 9.14 Geltendes Recht ................................................................................................ 68 9.15 Konformität mit geltendem Recht....................................................................... 68 9.16 Weitere Regelungen .......................................................................................... 68 9.16.1 Vollständiger Vertrag.......................................................................................... 68 9.16.2 Abtretung der Rechte......................................................................................... 68 9.16.3 Salvatorische Klausel......................................................................................... 68 9.16.4 Rechtliche Auseinandersetzungen /Erfüllungsort .............................................. 68 9.16.5 Höhere Gewalt ................................................................................................... 69 9.17 Andere Regelungen ........................................................................................... 69

A Mitgeltende Unterlagen...................................................................................... 70

Abkürzungsverzeichnis....................................................................................................... 71

Änderungshistorie / Release Notes .................................................................................... 75

Page 8: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 8

Abbildungsverzeichnis

Abbildung 1: CA-Hierachie der Corporate PKI ................................................................... 12

Page 9: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 9

Tabellenverzeichnis

Tabelle 1: Zuordnung der Zertifikate zu den CAs und den jeweiligen CRL Distribution Points........................................................................................................................... 17

Tabelle 2: Zuordnung der Zertifikate zu den CAs und den jeweiligen AIA URIs ................ 19 Tabelle 3: Schnittstellen zur Bereitstellung der Zertifikate zum Bezug der öffentlichen

Schlüssel zur Datenverschlüsselung........................................................................... 19 Tabelle 4: Gültigkeitszeiträume von Zertifikaten................................................................. 48 Tabelle 5: Basis-Felder des Zertifikatsprofils...................................................................... 51 Tabelle 6: Zertifikatserweiterungen (hier: Key Usage)........................................................ 52 Tabelle 7: Zertifikatserweiterungen (hier: Extended Key Usage) ....................................... 53 Tabelle 8: Issuer DN und Subject DN (FMO) ..................................................................... 55 Tabelle 9: Einträge im Subject Alternative Name ............................................................... 56 Tabelle 10: CRL Profil: Basiswerte ..................................................................................... 57 Tabelle 11: CRL Profil: Extension-Einträge ........................................................................ 57

Page 10: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 10

1 Einleitung

Das Certification Practice Statement (CPS) beschreibt entsprechend der dokumentierten Prozesse und Funktionen der CPKI die wesentlichen Tätigkeiten des T-Systems Trust Center in der Funktion als Zertifizierungs- und Registrierungsstelle. Es ermöglicht die quali-tative Beurteilung der angebotenen Dienstleistung und dient als Entscheidungsgrundlage für eine Anerkennung der ausgestellten Zertifikate.

Das vorliegende Dokument orientiert sich an dem internationalen Standard für Zertifizie-rungsrichtlinien und Erklärungen zum Zertifizierungsbetrieb, dem „Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework“ [RFC3647] der Internet Society (ISOC).

Das vorliegende CPS stellt die Zertifizierungsrichtlinie (engl. Certificate Policy kurz CP) und die Erklärung zum Zertifizierungsbetrieb (engl. Certification Practice Statement, kurz CPS) der CPKI in der Ausbaustufe 2 Release 2.8) dar und beinhaltet Sicherheitsvorgaben sowie Beschreibungen technischer, organisatorischer und rechtlicher Aspekte.

1.1 Überblick

Im Rahmen von Office Standardization wird eine Public Key Infrastructure (PKI bzw. C-PKI) auf Basis von Microsoft Technologie realisiert, welche sich konform der Internet-Standards (RFC zu LDAP v2 und LDAP v3) verhält. Diese PKI erstellt und verwaltet Zertifi-kate, welche als elektronische Identitätsnachweise durch Mitarbeiter des Konzerns Deut-sche Telekom verwendet werden können. Jeder Mitarbeiter des Konzerns Deutsche Tele-kom erhält durch Verwendung der durch die PKI bereitgestellten Funktionen, die Möglich-keit sich an elektronischen Services zu verlässlich zu identifizieren und mittels Signatur und Verschlüsselung (z.B. Medium E-Mail) auf sichere Art und Weise mit anderen Kom-munikationspartnern Informationen auszutauschen.

Der Schwerpunkt der Aufgaben der C-PKI sind die CA-Prozesse zur Ausstellung, Bereitstellung und Verwaltung von Zertifikaten nach X.509 Standard. Diese gewährleisten eine integrierte Zertifikatsverwaltung in der Systeminfrastruktur der Deutschen Telekom und das Management des Schlüsselmaterials (Verschlüsselungsschlüssel) für die Interaktion mit IT-Systemen und Benutzern (siehe auch Anlage 1 Prozessbeschreibung).

Um für die bereits vorhandene Arbeitsplatzumgebung (CMO = Current Mode of Operation bzw. heute vorhandene Arbeitsplatzumgebung) eine einheitliche, moderne und benutzer-freundliche Sicherheitsumgebung zu schaffen, wurde die CPKI in zwei Ausbaustufen reali-siert. In der Ausbaustufe 1 erfolgte bereits die Bereitstellung des C-PKI Basisdienstes für den FMO. Mit der Ausbaustufe 2 integriert sich die CPKI in die neue OS Arbeitsplatzum-gebung von morgen (FMO = Future Mode of Operation / zukünftige Arbeitsplatzumgebung) und ergänzt weitere wichtige Features wie z.B. Vertreter-Zertifikate oder Zertifikate für die Nutzung mit Mobile Devices im Future Mode of Operation.

Page 11: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 11

Die beiden Ausbaustufen der CPKI wurden auf zwei für einen Übergangszeitraum von 3 Jahren (bis März 2014) parallel betriebenen Plattformen realisiert. Die Umstellung der Be-nutzer von der ersten in die zweite Ausbaustufe der CPKI erfolgt sukzessive bei Änderun-gen (z.B. Beauftragung Deputy oder Zertifikat für Mobile Devices im Future Mode of Ope-ration) oder bei Ablauf von Benutzerzertifikaten.

Die CPKI dient hauptsächlich zur Ausstellung und Verwaltung von Personenzertifikaten für interne und externe Mitarbeiter.

Personenzertifikate werden grundsätzlich unter Verwendung einer Smart Card (MyCard) als Schlüsselträgermedium ausgegeben. Eine Ausnahme ergibt sich bei Verwendung von Mobile Devices für Verschlüsselungszertifikate von MyCard Nutzern und in diesem Zusammenhang benötigte Zertifikate für eine Authentifizierung an Zielanwendungen, da das Deployment und die Nutzung dieser Zertifikate softwarebasierend (sogenannte Software-PSE) erfolgt.

Darüber hinaus stellt die CPKI in der vorliegenden Ausbaustufe 2 Zertifikate für weitere Anwendungszwecke bereit, hierzu gehören:

Webserver- und Gateway-Zertifikaten:

– Hierbei handelt es sich um Maschinenzertifikate, die auf einer sogenannten Software-PSE basieren.

Domain-Controller- und Computerzertifikaten (802.1x Zertifikate):.

– Im Zusammenhang mit der Ausstellung von 802.1x Zertifikaten für Computer (Devices) nutzt die C-PKI Funktionen, welche das Betriebssystem Windows Server 2008 für die automatische Registrierung und Ausstellung von Zertifika-ten für dieselben bietet.

Code-Signing Zertifikate zur Signatur von Programmcode. Softwaremodule können mit Hilfe dieser Zertifikate einer Code-Signatur versehen werden. Auf diese Weise kann sichergestellt werden, dass Anwender nur unveränderte Original-Software ver-wenden.

1.2 Dokumentenname und Identifikation

Name: CP & CPS CorpPKI FMO

Version: 1.0

Datum 15.06.2011

Objektbezeich-nung (Object Identifier)

1.3.6.1.4.1.7879.13.26

1.3 PKI Teilnehmer

Page 12: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 12

1.3.1 Zertifizierungsstellen

Die Struktur der involvierten Zertifizierungsstellen wird in den folgenden Kapiteln vorge-stellt.

Das T-Systems Trust Center betreibt die „Deutsche Telekom Root CA 2“ Instanz für fort-geschrittene Zertifikatsdienste. Das Root-CA Zertifikat ist ein selbst-signiertes Zertifikat und wird durch T-Systems im Internet veröffentlicht. Die Veröffentlichung erlaubt eine Gültig-keitsüberprüfung aller in diesen Hierarchien ausgestellten Zertifikate über den Bereich des eigenen Intranets hinaus. Die genannte Root-CA Instanz zertifiziert ausschließlich Zertifi-kate von unmittelbar nachgeordneten Zertifizierungsstellen. Im Falle der C-PKI Ausbaustu-fe 2 ist dies die „Deutsche Telekom AG Issuing CA 01“.

Zur Ausstellung von Zertifikaten, für die eine Validierung außerhalb des Telekom Intranets nicht obligatorisch ist, wird im T-Systems Trust Center außerdem die „Deutsche Telekom Internal Root CA 1“ betrieben. Diese zusätzliche Root-CA Instanz zertifiziert die beiden nachgeordneten Instanzen „Deutsche Telekom AG Issuing CA 02“ und „Deutsche Telekom AG Issuing CA 03“.

Zertifizierungshierarchie

Die Struktur der CA-Hierarchie der C-PKI in der Ausbaustufe 2 ist in der folgenden Abbil-dung schematisch dargestellt:

Abbildung 1: CA-Hierachie der Corporate PKI

1.3.2 Registrierungsstellen

Die Zertifizierungsstelle „Deutsche Telekom Root CA 2“ betreibt eine zentrale Registrie-rungsstelle.

Die Zertifizierungsstelle „Deutsche Telekom Internal Root CA 1“ betreibt eine zentrale Re-gistrierungsstelle.

Die Zertifizierungsstellen Deutsche Telekom Issuing CA 01, Deutsche Telekom Issuing CA 02, Deutsche Telekom Issuing CA 03 betreiben jeweils eine Registrierungsstelle mit einer

Page 13: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 13

Schnittstelle zum Provisionierungssystem TAdmin2, sowie zum Verzeichnisdienst Corpora-te AD .

Die Deutsche Telekom Issuing CA 03 betreibt zudem eine Registrierungsstelle mit einer Schnittstelle zum Verzeichnisdienst Corporate Active Directory.

1.3.3 Zertifikatsinhaber

Zertifikate können je nach Zertifizierungsstelle an Personen oder Maschinen (bzw. Rollen-träger für den Betrieb derselben) vergeben werden.

Zu diesem Zwecke werden in der Corporate PKI Daten erhoben, gespeichert und verarbeitet (z.B. Name, Nachname, E-Mail-Adresse bei Erstellung eines Zertifikates).

Der Zertifikatsinhaber

beauftragt das Zertifikat (im Fall von Maschinen vertreten durch einen Rollenträger für den Betrieb z.B. Server-Admin),

wird von der Registrierungsstelle authentifiziert und durch das Zertifikat identifiziert,

ist im Besitz des privaten Schlüssels, der zum öffentlichen Schlüssel im Zertifikat ge-hört.

1.3.4 Zertifikatsprüfer (Relying Parties)

Zertifikatsprüfer sind alle Personen und Maschinen (bzw. Rollenträger für den Betrieb der-selben), die Zertifikate von Zertifikatsinhabern im Rahmen von Anwendungen nutzen.

1.3.5 Weitere Teilnehmer

Teilnehmer, die keine Verpflichtung gegenüber der Corporate PKI eingegangen sind, wer-den in dieser Richtlinie nicht betrachtet.

1.4 Anwendungsbereich

1.4.1 Geeignete Zertifikatsnutzung

Die von der Corporate PKI zur Verfügung gestellten Zertifikate werden für Authentifizie-rung, digitale Signatur und Verschlüsselung im Rahmen unterschiedlicher Anwendungen je nach Belegung der Attribute („key usage“) zur Zertifikatsschlüsselverwendung und den Festlegungen der Zertifizierungsrichtlinie eingesetzt. Einige Beispiele sind:

Authentifizierung im Rahmen von Kommunikationsprotokollen (z.B. SSL, IPSec, S/MIME, XML-SIG, SOAP)

Authentifizierung im Rahmen von Prozessen (Windows Log-On, Festplattenver-schlüsselung)

Page 14: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 14

Verschlüsselung im Rahmen von Kommunikationsprotokollen (z.B. SSL, IPSec, S/MIME, XML-ENC, SOAP)

Digitale Signatur im Rahmen von Kommunikationsprotokollen (z.B. S/MIME)

Digitale Signatur zur Echtheitsbestätigung von Software (Code Signing)

1.4.2 Untersagte Zertifikatsnutzung

Zertifikate der C-PKI dürfen nicht außerhalb des zulässigen und geltenden gesetzlichen Rahmens verwendet werden. Dies gilt insbesondere unter Beachtung der länderspezifi-schen geltenden Ausfuhr- und Einfuhrbestimmungen.

Die Zertifikate der Corporate PKI unterstützen nicht das Attribut „Nichtabstreitbarkeit (non reputation)“ in Verbindung mit einer Identität oder Berechtigung.

Ferner dürfen Zertifikate für Zertifikatsinhaber (Endteilnehmer) nicht als CA-Zertifikate ver-wendet werden.

1.5 Verwaltung der Zertifizierungsrichtlinie

1.5.1 Änderungsmanagement

Dieses CPS wird von T-Systems International GmbH, PRODUCTION, CSS, Identity Ma-nagement Solutions, Trust Center Applications heraus gegeben.

1.5.2 Ansprechpartner

Adresse: T-Systems International GmbH PRODUCTION, CSS, SDM CSS & Special Services, PSS, IMS Trust Center Applications Untere Industriestraße 20 57250 Netphen Telefon: 01805/ 26 82 04 E-Mail: [email protected] WWW: http://www.telesec.de

1.5.3 Eignungsprüfer für Regelungen für den Zertifizierungsbetrieb (CPS) gemäß Zertifizierungsrichtlinie

Siehe Kapitel 1.5.2.

Page 15: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 15

1.5.4 Verfahren zur Anerkennung von Regelungen für den Zertifi-zierungsbetrieb (CPS)

Dieses CPS behält seine Gültigkeit, solange sie nicht von der zuständigen Instanz widerru-fen wird. Es wird bei Bedarf fortgeschrieben und erhält dann jeweils eine neue, aufsteigen-de Versionsnummer.

1.6 Definitionen und Abkürzungen

Siehe Kapitel 9.1 (Glossar).

Page 16: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 16

2 Veröffentlichungen und Verzeichnisdienste

2.1 Verzeichnisdienste (Repositories)

Das T-Systems Trust Center stellt den Nutzern der PKI 7 Tage x 24 Stunden verschiede-ne Informationsdienste zur Verfügung.

Dazu gehören:

Bereitstellung von Sperrlisten über die Schnittstellen (siehe Tabelle 1)

o Web-Applikation,

o den LDAP-Server der Corporate PKI der DTAG oder

o das Active Directory der jeweiligen Domäne.

Bereitstellung von Zertifikatsstatusdaten über das OCSP-Protokoll,

Die jeweiligen Full Name CDP sind in den jeweils zu überprüfenden Zertifikaten enthalten und können durch eine Applikation aufgerufen werden, siehe auch RFC 5280 Kapitel 4.2.2.1.

Bereitstellung der jeweiligen CA-Zertifikate über die Schnittstellen (siehe Tabelle 2)

o Web-Applikation,

o den LDAP-Server der Corporate PKI der DTAG oder

o das Active Directory der jeweiligen Domäne.

Bereitstellung der Zertifikate zum Bezug der öffentlichen Schlüssel zur Datenver-schlüsselung über die Schnittstellen (siehe Tabelle 3)

o das Active Directory der jeweiligen Domäne,

o den LDAP-Server der Corporate PKI der DTAG oder

o das X.500 Konzernverzeichnis.

Die folgenden Tabellen geben einen Überblick, über die verschiedenen Verteilpunkte für die oben genannten Informationsdienste:

Deutsche Telekom Issuing CA 01

Deutsche Telekom Issuing CA 02

Deutsche Telekom Issuing CA 03

CRL DistributionPoints (CDP)

CDP [1] http URL=http://corporate-

pki.telekom.de/cdp/Deutsche

Telekom AG Issuing CA

01.crl

URL=http://corporate-

pki.telekom.de/cdp/Deutsche

Telekom AG Issuing CA

02.crl

URL=http://corporate-

pki.telekom.de/cdp/Deutsche

Telekom AG Issuing CA

03.crl

CDP [2] ldap URL=ldap://corporate-

pki.telekom.de/CN=Deutsche

Telekom AG Issuing CA

01,OU=Trust Cen-

URL=ldap://corporate-

pki.telekom.de/CN=Deutsche

Telekom AG Issuing CA

02,OU=Trust Cen-

URL=ldap://corporate-

pki.telekom.de/CN=Deutsche

Telekom AG Issuing CA

03,OU=Trust Cen-

Page 17: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 17

ter,O=Deutsche Telekom

AG,C=DE?certificateRevocat

ionList

ter,O=Deutsche Telekom

AG,C=DE?certificateRevocat

ionList

ter,O=Deutsche Telekom

AG,C=DE?certificateRevocat

ionList

CDP [3] AD URL=ldap:///CN=Deutsche

Telekom AG Issuing CA

01,CN=HE101039,CN=CDP,

CN=Public Key Ser-

vices,CN=Services,CN=Conf

iguration,DC=cds,DC=t-

inter-

nal,DC=com?certificateRevo

cation-

List?base?objectClass=cRL

DistributionPoint

URL=ldap:///CN=Deutsche

Telekom AG Issuing CA

02,CN=HE101040,CN=CDP,

CN=Public Key Ser-

vices,CN=Services,CN=Conf

iguration,DC=cds,DC=t-

inter-

nal,DC=com?certificateRevo

cation-

List?base?objectClass=cRL

DistributionPoint

URL=ldap:///CN=Deutsche

Telekom AG Issuing CA

03,CN=HE101038,CN=CDP,

CN=Public Key Ser-

vices,CN=Services,CN=Conf

iguration,DC=cds,DC=t-

inter-

nal,DC=com?certificateRevo

cation-

List?base?objectClass=cRL

DistributionPoint

Deutsche Telekom AG

Employee Encryption X - -

Deutsche Telekom AG

Employee Signature X - -

Deutsche Telekom AG

Employee Authentica-

tion

- X -

Deutsche Telekom AG

External Workforce

Encryption

X - -

Deutsche Telekom AG

External Workforce

Signature

X - -

Deutsche Telekom AG

External Workforce

Authentication

- X -

Deutsche Telekom AG

Code Signing X - -

Deutsche Telekom AG

Telekom Computer - - X

Deutsche Telekom AG

Domain Controller - - X

Deutsche Telekom AG

Web Server X - -

Deutsche Telekom AG

VPN Gateway X - -

Tabelle 1: Zuordnung der Zertifikate zu den CAs und den jeweiligen CRL Distribution Points

Page 18: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 18

Deutsche Telekom Issuing CA 01

Deutsche Telekom Issuing CA 02

Deutsche Telekom Issuing CA 03

Authority Informa-tion Access (AIA)

AIA [1] http URL=http://corporate-

pki.telekom.de/aia/Deutsche

Telekom AG Issuing CA

01.crt

URL=http://corporate-

pki.telekom.de/aia/Deutsche

Telekom AG Issuing CA

02.crt

URL=http://corporate-

pki.telekom.de/aia/Deutsche

Telekom AG Issuing CA

03.crt

AIA [2] ldap URL=ldap://corporate-

pki.telekom.de/CN=Deutsche

Telekom AG Issuing CA

01,OU=Trust Center,

O=Deutsche Telekom

AG,C=DE?cACertificate

URL=ldap://corporate-

pki.telekom.de/CN=Deutsche

Telekom AG Issuing CA

02,OU=Trust Center,

O=Deutsche Telekom

AG,C=DE?cACertificate

URL=ldap://corporate-

pki.telekom.de/CN=Deutsche

Telekom AG Issuing CA

03,OU=Trust Center,

O=Deutsche Telekom

AG,C=DE?cACertificate

AIA [3] AD URL=ldap:///CN=Deutsche

Telekom AG Issuing CA

01,CN=AIA,CN=Public Key

Ser-

vices,CN=Services,CN=Conf

iguration,DC=cds,DC=t-

inter-

nal,DC=com?cACertificate?b

ase?objectClass=certification

Authority

URL=ldap:///CN=Deutsche

Telekom AG Issuing CA

02,CN=AIA,CN=Public Key

Ser-

vices,CN=Services,CN=Conf

iguration,DC=cds,DC=t-

inter-

nal,DC=com?cACertificate?b

ase?objectClass=certification

Authority

URL=ldap:///CN=Deutsche

Telekom AG Issuing CA

03,CN=AIA,CN=Public Key

Ser-

vices,CN=Services,CN=Conf

iguration,DC=cds,DC=t-

inter-

nal,DC=com?cACertificate?b

ase?objectClass=certification

Authority

Deutsche Telekom AG

Employee Encryption X - -

Deutsche Telekom AG

Employee Signature X - -

Deutsche Telekom AG

Employee Authentica-

tion

- X -

Deutsche Telekom AG

External Workforce

Encryption

X - -

Deutsche Telekom AG

External Workforce

Signature

X - -

Deutsche Telekom AG

External Workforce

Authentication

- X -

Page 19: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 19

Deutsche Telekom AG

Code Signing X - -

Deutsche Telekom AG

Telekom Computer - - X

Deutsche Telekom AG

Domain Controller - - X

Deutsche Telekom AG

Web Server X - -

Deutsche Telekom AG

VPN Gateway X - -

Tabelle 2: Zuordnung der Zertifikate zu den CAs und den jeweiligen AIA URIs

Quelle URI

Active Directory der jeweiligen Domäne -

LDAP-Server der Corporate PKI der DTAG ldap://corporate-pki.telekom.de

X.500 Konzernverzeichnis ldap://X500.telekom.de

Tabelle 3: Schnittstellen zur Bereitstellung der Zertifikate zum Bezug der öffentlichen Schlüssel zur Datenverschlüsselung

2.2 Veröffentlichung von Zertifikatsinformationen

Das T-Systems Trust Center stellt den Zertifikatsinhabern der PKI folgende Informationen zur Verfügung.

das Root-CA Zertifikat und dessen Fingerprint (MD5 und SHA1)

Dokumentation über den Wechsel eines Root-CA oder eines CA-Zertifikats

Informationen über eine Kompromittierung oder den Verdacht auf Kompromittierung oder die Sperrung eines Root-CA oder eines CA- Zertifikats

CP/CPS im Status Final

Weitere Informationen hierzu sind unter http://corporate-pki.telekom.de/ abrufbar.

2.3 Aktualisierung der Informationen (Zeitpunkt, Frequenz)

Für die Aktualisierung der in Abschnitt 2.2 genanten Informationen gelten folgende Fristen:

Zertifikate: spätestens drei Werktage nach der Ausstellung

CP und CPS: spätestens eine Woche nach Erstellung einer neuen Version

CRLs: Siehe Abschnitt 4.9.7.

Page 20: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 20

2.4 Zugangskontrolle zu Verzeichnisdiensten (Repositories)

Der lesende Zugriff auf die in Abschnitt 2.1und 2.2 aufgeführten Informationen unterliegt für die Zertifikatsinhaber und -prüfer von Zertifizierungsstelle keiner Zugangskontrolle.

Der schreibende Zugriff auf alle in Abschnitt 2.1und 2.2 genannten Informationen erfolgt ausschließlich durch berechtigte Mitarbeiter bzw. autorisierte Systeme und ist für Zertifi-katsinhaber und -prüfer von Zertifikaten nicht vorgesehen.

Page 21: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 21

3 Identifikation und Authentifikation

3.1 Namen

3.1.1 Namensformen

Die Namensregeln für den „SubjectDistinguishedName“ (Subject DN) und „IssuerDistingu-ishedName“ (Issuer DN) müssen nach dem X.501-Standard definiert sein.

Die Anforderungen an die Nutzung von Namensattributen im Subject DN und Subject Al-ternative Name hängen konkret vom Anwendungskontext einer Zertifizierungsstelle ab. Beispielsweise muss für Zertifikate, die für sichere E-Mail genutzt werden, die E-Mail Ad-resse des Zertifikatsinhabers eingetragen sein.

Allgemein sollte im Subject DN das Attribut „CommonName“ (CN) enthalten sein. Im Issuer DN muss das Attribut „CommonName“ (CN) enthalten sein.

Details zu den Inhalten des Issuer DN und des Subject DN können Tabelle 8 in Kapitel 7 entnommen werden.

3.1.2 Aussagekraft von Namen

Die Eindeutigkeit der Namensangaben ist über den gesamten Subject DN betrachtet si-chergestellt (Voraussetzung: Adresse oder CID kommen im Subject-DN vor).

3.1.3 Anonymität bzw. Pseudonyme für Zertifikatsinhaber

Pseudonyme werden nicht vergeben und akzeptiert.

3.1.4 Regeln zur Interpretation verschiedener Namensformate

Siehe Kapitel 3.1.2.

3.1.5 Eindeutigkeit von Namen

Siehe Kapitel 3.1.2.

3.1.6 Anerkennung, Authentifizierung und Funktion von Warenzei-chen

Es liegt in der Verantwortung des Zertifikatsinhabers, dass die Namenswahl keine Waren-zeichen, Markenrechte usw. verletzt. Die Zertifizierungsstelle ist nicht verpflichtet, solche Rechte zu überprüfen.

Allein der Zertifikatsinhaber ist für solche Überprüfungen verantwortlich. Falls eine Zertifi-zierungsstelle über eine Verletzung solcher Rechte informiert wird, wird das Zertifikat wi-derrufen.

Page 22: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 22

3.2 Identitätsprüfung bei Neuantrag

3.2.1 Nachweis des Besitzes des privaten Schlüssels

Der Zertifikatsinhaber muss bei einem Neuauftrag gegenüber der Zertifizierungsstelle in geeigneter Weise nachweisen, dass er im Besitz des privaten Schlüssels ist, der dem zu zertifizierenden öffentlichen Schlüssel zugeordnet ist. Der Besitznachweis ist durch die Methode PKCS#10 erbracht. Diese Anforderung gilt nicht, wenn die Schlüsselerzeugung durch die Zertifizierungsstelle stattfindet. In diesem Fall ist die Zuordnung zwischen öffent-lichem und geheimem Schlüssel implizit gegeben.

3.2.2 Authentifizierung einer Organisation

Grundvoraussetzung für einen Neuauftrag ist die Konzernzugehörigkeit einer Organisation oder ein definiertes Vertragsverhältnis zu einer externen Organisation. Damit ist die aus-reichende Authentifizierung von internen und externen Organisationen gewährleistet.

3.2.3 Authentifizierung einer natürlichen Person

Die Zertifizierungsstelle nimmt in geeigneter Weise eine zuverlässige Überprüfung derjeni-gen Auftragsdaten vor, die in das Zertifikat eingehen. Given name, surname und email sind in den Bezugssystemen für die PKI (TAdmin2 und Corporate AD) hinterlegt und werden durch diese der PKI bereitgestellt.

3.2.4 Nicht überprüfte Teilnehmerangaben

Nicht verifizierte Informationen sind Informationen, die ohne Prüfung ins Zertifikat über-nommen werden und umfassen:

Nicht relevant, da alle Informationen, welche die CPKI erhält, aus den Backend-Systemen TAdmin2, CIAM oder dem Corporate-AD der Deutschen Telekom bereitgestellt werden.

3.2.5 Überprüfung der Berechtigung

Ein Teilnehmer ist zum Erhalt von Zertifikaten berechtigt, wenn er einen gültigen Arbeits-vertrag besitzt oder eine definierte Vertragsbeziehung besteht (external Workforce) und in den Backend-Systemen (HR, CIAM, AD, TAdmin) administriert ist.

3.2.6 Interoperabilitätskriterien

Die Interoperabilität von Zertifikaten der PKI basiert auf gängigen Markt-Standards für Zertifikatsprofile (X.509v3, RFC 5280), Sperrlistenprofile (RFC 5280, Validierungsdiensten (CRL, OCSP).

Page 23: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 23

3.3 Identifizierung und Authentifizierung bei einer Zertifikatser-neuerung

3.3.1 Routinemäßige Zertifikatserneuerung

Zur Folge-Beauftragung muss die Identitätsprüfung wie bei Neuauftrag durchlaufen wer-den, siehe Abschnitt 3.2, dabei werden für neue kryptographische Schlüssel neue Zertifika-te ausgestellt.

3.3.2 Zertifikatserneuerung nach einer Sperrung

Zur Folge-Beauftragung nach einer Sperrung (Replace) muss die Identitätsprüfung wie bei Neuauftr 3.2, dabei werden für neue kryptographische Schlüssel neue Zertifikate ausge-stellt.

3.4 Identifizierung und Authentifizierung von Sperraufträgen

Das T-Systems Trust Center bietet einen zentralen Sperrservice, um im Falle des Verlus-tes eines Schlüsselträgermediums (MyCard oder Software-PSE) oder bei unbefugtem Nut-zungsverdacht Zertifikate sperren zu können. Im Falle der Sperrung wird das Zertifikat in eine Sperrliste aufgenommen. Die Authentisierung einer Sperrung geschieht durch die Angabe der Grunddaten (Name, Firma, Rückrufnummer, E-Mailadresse). Der Sperr-wunsch wird mittels einer im System durch den Zertifikatsinhaber hinterlegte Frage bzw. Antwort autorisiert.

Die Sperrung von Zertifikaten kann telefonisch beauftragt werden. Hierfür sind die inner-halb des Konzerns Deutschen Telekom bekannten Eingangskanäle des jeweilig zuständi-gen Service-Desk zu verwenden.

Darüber hinaus kann eine Sperrung aufgrund einer Kündigung des Arbeitsplatzsystems eines Mitarbeiters im IT-Shop durch den Vorgesetzten bzw. jeweils verantwortlichen KOSTV veranlasst werden, die Autorisierung dieser Sperraufträge beruht in diesem Zu-sammenhang auf dem Rollen- und Rechtekonzept des IT-Shops.

Page 24: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 24

4 Ablauforganisation (Zertifikatslebenszyklus)

4.1 Zertifikatsantrag

4.1.1 Wer kann Zertifikate beantragen

Zertifikate können durch

natürliche Personen und

Organisationen vertreten durch handlungsbevollmächtigte Mitarbeiter (z.B. Server-Administratoren)

beantragt werden.

4.1.2 Verfahren und Verantwortungen

Die Vorregistrierung der Teilnehmer erfolgt über vorgelagerte Identifizierungs-, Registrie-rungs- und Provisionierungsprozesse in der IT Infrastruktur der Deutschen Telekom.

Beteiligt sind daran:

SAP Personalverwaltungssystem (HR-Systeme),

CIAM als Identity & Access Management-System

Corporate Active Directory als zentrales Bezugsdirectory für die PKI,

und

TAdmin2 als Provisionierungsplattform.

Konkret bedeutet dies, dass die Verarbeitung der Registrierungsdaten sowie deren Verifi-kation bereits in durch die Vorsysteme (siehe oben) erfolgen. Auf Basis dieser Daten er-folgt die Ausstellung der Zertifikate.

Die Verantwortung für die Korrektheit der Daten wird durch die jeweils erfassende Stelle übernommen.

4.2 Bearbeitung von Zertifikatsanträgen

4.2.1 Durchführung von Identifikation und Authentifizierung

Die Identifizierung und Authentisierung erfolgt im Rahmen von Adminstrations-Prozessen, durch die in Kapitel 3 genannten Einheiten/Systeme.

Page 25: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 25

4.2.2 Annahme oder Ablehnung von Zertifikatsanträgen

Zertifikatsanträge werden bei Dateninkonsistenzen und fehlenden Berechtigungen automa-tisch abgelehnt. Andernfalls erfolgt eine automatisierte Annahme der Anträge und der wei-tere Bearbeitungsprozess wird angestoßen.

4.2.3 Zeit zur Verarbeitung von Zertifikatsaufträgen

Die Bearbeitung des Zertifikatauftrags beginnt innerhalb eines angemessenen Zeitraums nach Erhalt der Beauftragung. Die maximale Bearbeitungsdauer beträgt 14 Tage.

4.3 Zertifikatserstellung

4.3.1 Aufgaben der Zertifizierungsstelle

Die formalen Voraussetzungen für die Ausstellung eines Zertifikats werden durch die CA in angemessener Weise überprüft.

Die CA überprüft insbesondere

die Berechtigungen der ausführenden Instanz, ein Zertifikat für den im DN angege-benen Namen zu genehmigen sowie

die Gültigkeit der Signatur der ausführenden Instanz.

4.3.2 Benachrichtigung des Antragstellers

Der Zertifikatsinhaber erhält eine Benachrichtigung in Form einer E-Mail. In dieser E-Mail enthalten ist eine URL und ein OTP (One-Time Password = Einmalpasswort).

Der Zertifikatsinhaber ruft die URL auf, gibt sein OTP an entsprechender Stelle ein und steckt die Karte in den an seinem Benutzer-PC angeschlossenen Kartenleser.

Die Karte wird daraufhin personalisiert, d.h. sein Zertifikat wird auf die Karte geschrieben.

4.4 Akzeptanz der Zertifikate

4.4.1 Annahme von Zertifikaten

Der Zertifikatsinhaber ist verpflichtet, die Korrektheit des eigenen Zertifikats sowie des Zer-tifikats der ausstellenden CA nach Erhalt zu verifizieren.

Ein Zertifikat wird durch den Zertifikatsinhaber akzeptiert, wenn das Zertifikat verwendet wird oder wenn innerhalb von 14 Tagen nach Erhalt kein Widerspruch erfolgt. Durch An-nahme des Zertifikats versichert der Zertifikatsinhaber, dass sämtliche Angaben und Erklä-rungen in Bezug auf die im Zertifikat enthaltenden Informationen der Wahrheit entspre-chen.

Page 26: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 26

4.4.2 Veröffentlichung der Zertifikate durch die Zertifizierungsstelle

Jedes Personen-Zertifikat (interne Mitarbeiter und external Workforce) wird im Corporate Active Directory als zentrales Bezugsdirectory für die PKI, sowie in externem und internem Veröffentlichungsserver (LDAP) veröffenlicht. Darüber hinaus können Zertifikatsinformatio-nen durch IT-Systeme innerhalb des Intranet wie X.500 KONTEL als Konzerverzeichnis oder CIAM als Identity & Access Management-System über den internen Veröffentli-chungsserver (LDAP) abgerufen und anderen Anwendungen und/oder Benutzern bereit-gestellt werden.

4.4.3 Benachrichtigung weiterer Instanzen durch die Zertifizie-rungsstelle

Zertifikatsinformationen können von IT-Systemen innerhalb des Intranet wie z.B. X.500 KONTEL als Konzerverzeichnis oder CIAM als Identity & Access Management-System über den internen Veröffentlichungsserver (LDAP) abgerufen und anderen Anwendungen und/oder Benutzern bereitgestellt werden

4.5 Schlüssel- und Zertifikatsverwendung

4.5.1 Nutzung durch den Zertifikatsinhaber

Der Zertifikatsinhaber trägt die Verantwortung dafür, dass sein privater Schlüssel in ange-messener Weise auf einem Schlüsselträgermedium geschützt und das Zertifikat konform der Regelungen in diesem Dokument eingesetzt wird..

Eine Sperrung des Zertifikats ist umgehend vorzunehmen, wenn:

die Angaben im Zertifikat nicht mehr korrekt sind

oder

der private Schlüssel abhanden gekommen, kompromittiert oder gestohlen wurde.

4.5.2 Nutzung des Zertifikats durch die Relying Party

Jeder der ein Zertifikat einsetzt, welches im Rahmen dieses Dokuments ausgestellt wurde, sollte

vor der Nutzung eines Zertifikats dessen Gültigkeit überprüfen, in dem er unter ande-rem die gesamte Zertifikatskette bis zum Wurzelzertifikat validiert und

das Zertifikat ausschließlich für autorisierte und legale Zwecke in Übereinstimmung mit dem jeweiligen CPS einsetzen.

4.6 Zertifikatserneuerung unter Beibehaltung des alten Schlüs-sels (Re-Zertifizierung)

Page 27: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 27

4.6.1 Gründe für eine Zertifikatserneuerung

Vorausgesetzt, dass die eindeutige Zuordnung von Zertifikatsinhaber und Schlüssel erhal-ten bleibt, keine Kompromittierung des Schlüssels vorliegt und die kryptographischen Ver-fahren (z.B. Schlüssellänge) für die Gültigkeitsdauer des neuen Zertifikats noch ausrei-chend sind, werden bei einer Re-Zertifizierung dem Zertifikatsinhaber

für Signatur und Authentifizierung je ein neues Zertifikat unter Beibehaltung des al-ten Schlüsselpaares und

für Verschlüsselung ein neues Zertifikat unter Verwendung eines neuen Schlüssel-paares ausgestellt.

Insofern sich die im Zertifikat enthaltenen Informationen geändert haben, erfolgt statt einer Zertifikatserneuerung, ein Online Update (Änderung von Zertifikatstemplates) oder ein De-tail Change (Änderung von Personalisierungsdaten).

Eine Zertifikaterneuerung kann beantragt werden, wenn die Gültigkeit eines Zertifikats ab-läuft (eine vorherige Benachrichtigung der Zertifizierungsstelle erfolgt 6 Wochen vor Ab-lauf).

Eine Erneuerung von Zertifikaten für Zertifizierungsstellen ist nicht vorgesehen.

4.6.2 Wer kann eine Zertifikatserneuerung beantragen?

Die Zertifikatserneuerung wird durch die PKI bzw. einen Trust Center Administrator initiali-siert und kann nur durch den Zertifikatsinhaber oder bei Maschinenzertifikaten durch einen Administrator ausgeführt werden.

4.6.3 Ablauf der Zertifikatserneuerung

Es gelten die Regelungen von Kapitel 3.3Fehler! Verweisquelle konnte nicht gefunden werden..

4.6.4 Benachrichtigung des Antragstellers nach Zertifikatserneue-rung

Es gelten die Regelungen gemäß Kapitel 4.3.2.

4.6.5 Annahme einer Zertifikatserneuerung

Eine Zertifikatserneuerung wird nur angenommen, wenn der Antragsteller über ein gültiges Benutzerkonto (AD- Account) verfügt.

4.6.6 Veröffentlichungen der erneuerten Zertifikate durch die Zerti-fizierungsstelle

Es gelten die Regelungen gemäß Kapitel 4.4.2.

Page 28: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 28

4.6.7 Benachrichtigung weiterer Instanzen durch die Zertifizie-rungsstelle

Es gelten die Regelungen gemäß Kapitel 4.4.3.

4.7 Schlüssel- und Zertifikatserneuerung (Re-key)

4.7.1 Gründe für eine Schlüssel- und Zertifikatserneuerung

Es gelten die Regelungen von Kapitel 4.6.1.

4.7.2 Wer kann eine Schlüssel- und Zertifikatserneuerung bean-tragen?

Es gelten die Regelungen von Kapitel 4.6.2.

4.7.3 Ablauf der Schlüssel- und Zertifikatserneuerung

Es gelten die Regelungen von Kapitel Fehler! Verweisquelle konnte nicht gefunden werden..

4.7.4 Benachrichtigung des Zertifikatsinhabers

Es gelten die Regelungen gemäß Kapitel 4.3.2.

4.7.5 Annahme der Schlüssel- und Zertifikatserneuerung

Es gelten die Regelungen gemäß Kapitel 4.6.5

4.7.6 Veröffentlichung einer Zertifikatserneuerung durch die Zerti-fizierungsstelle

Es gelten die Regelungen gemäß Kapitel 4.4.2.

4.7.7 Benachrichtigung weiterer Instanzen durch die Zertifizie-rungsstelle

Es gelten die Regelungen gemäß Kapitel 4.4.3.

Page 29: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 29

4.8 Zertifikatsmodifizierung

4.8.1 Gründe für die Modifikation eines Zertifikates

Eine Modifikation einmal ausgestellter Zertifikate ist nicht vorgesehen. Wenn sich Inhalte von Attributen des Zertifikats ändern, ist eine erneute Identifizierung, Registrierung und Zertifikatsausstellung (Online Update, Detail Changes) erforderlich.

4.8.2 Wer darf kann Modifikation eines Zertifikates beantragen?

Gemäß Kapitel 4.8.1 tritt dieser Fall nicht auf.

4.8.3 Ablauf der Zertifikatsmodifizierung

Gemäß Kapitel 4.8.1 tritt dieser Fall nicht auf.

4.8.4 Benachrichtigung des Zertifikatsinhabers

Gemäß Kapitel 4.8.1 tritt dieser Fall nicht auf.

4.8.5 Annahme der Zertifikatsmodifizierung

Gemäß Kapitel 4.8.1 tritt dieser Fall nicht auf.

4.8.6 Veröffentlichung einer Zertifikatsmodifizierung durch die Zer-tifizierungsstelle

Gemäß Kapitel 4.8.1 tritt dieser Fall nicht auf.

4.8.7 Benachrichtigung weiterer Instanzen durch die Zertifizie-rungsstelle

Gemäß Kapitel 4.8.1 tritt dieser Fall nicht auf.

4.9 Widerruf/Sperrung und Suspendierung von Zertifikaten

4.9.1 Gründe für Widerruf/Sperrung

Die folgenden Gründe des Zertifikatsinhabers müssen zu einer Sperrung des Zertifikats führen:

Page 30: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 30

Abhandenkommen des privaten Schlüssels (z.B. Verlust oder Diebstahl)

Eine Kompromittierung oder der Verdacht auf eine Kompromittierung des privaten Schlüssels liegt vor

Die Angaben im Zertifikat sind nicht mehr korrekt

Verwendung und Handhabung des Zertifikats ist im Widerspruch zu vertraglichen Regelungen oder der CP/CPS des Zertifikatsinhabers oder Zertifikatsgebers

Ein Unbefugte Nutzung oder Verdacht auf Unbefugte Nutzung durch den Zertifikats-inhaber oder andere zur Nutzung des Schlüssels berechtigte Personen

Der Zertifikatsinhaber benötigt kein Zertifikat mehr und kündigt daher das Vertrags-verhältnis (Sperrung erfolgt 30 Tage nach Kündigung).

Gesetzliche Vorschriften

Der Prozess Delete User mit Fallback oder der Prozess Suspend wurde angestoßen und der Zertifikatsinhaber wird nach einer Suspendierungsdauer von 30 Tagen end-gültig gesperrt.

Die folgenden Gründe des T-Systems Trust Centers führen zu einer Sperrung des Zertifi-kats:

Abhandenkommen des privaten Schlüssels (z.B. Verlust oder Diebstahl).

Eine Kompromittierung oder der Verdacht auf eine Kompromittierung des privaten Schlüssels liegt vor.

Über die im Vertrag vereinbarten Zahlungsfristen hinaus gehender, erheblicher Zah-lungsverzug

Es liegt ein Unbefugte Nutzung oder Verdacht auf Unbefugte Nutzung durch den Zer-tifikatsinhaber oder andere zur Nutzung des Schlüssels berechtigte Personen vor.

4.9.2 Wer kann Widerruf/ Sperrung beantragen?

Die folgenden Personen und Institutionen sind in der Regel berechtigt, die Sperrung eines Zertifikates zu initiieren:

der Zertifikatsinhaber,

das T-Systems Trust Center,

Führungskräfte des Unternehmens nach Konsultation von Unternehmenssicherheit, Datenschutz und Betriebsrat (z.B. bei Tod des Zertifikatsinhabers).

Personalmanagement (z.B. PST)

4.9.3 Ablauf von Widerruf / Sperrung

Zur Sperrung autorisierte Personen und Institutionen können die Sperrung eines Zertifika-tes entweder über die Web-Seite der PKI, den Web-Shop oder telefonisch beauftragen. Die Authentisierung und Autorisierung einer Person geschieht dabei in geeigneter Art und Weise (z.B. Anruf bei Service Desk und Identifizierung des Anrufenden mittels Fra-ge/Antwort).

Page 31: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 31

Sind die Vorraussetzungen zur Sperrung erfüllt, wird die Sperrung vorgenommen, und das gesperrte Zertifikat in die Sperrinformationen übernommen. Die Sperrinformationen wer-den in standard-konformer Form (CRL) bereitgestellt.

Die autorisierte Person oder Institution wird über die Durchführung der Sperrung in geeig-neter Weise informiert.

4.9.4 Fristen für den Zertifikatsinhaber

Bei Vorliegen von Gründen für eine Sperrung (siehe Abschnitt 4.9.1), muss unverzüglich ein Sperrantrag gestellt werden.

4.9.5 Bearbeitungsfristen für die Zertifizierungsstelle

Eine Zertifikatssperrung muss durch die CA unverzüglich vorgenommen werden, wenn die Vorraussetzungen dafür vorliegen (siehe Abschnitt 4.9.3).

4.9.6 Anforderung zu Sperrprüfungen durch eine Relying Party

Sperrinformationen sind in standardisierter Form (CRL) im DER–Format bereitzustellen, um diese mit Standard-konformen Anwendungen prüfen zu können.

4.9.7 Häufigkeit der Sperrlistenveröffentlichung

Die Sperrinformationen werden in standardisierter Form (CRL) alle 12 Stunden aktualisiert und zur Verfügung gestellt. Wird innerhalb dieser 12 Stunden ein für die Liste relevantes Zertifikat gesperrt, kann bei Bedarf ereignisbezogen zu diesem Zeitpunkt die Ausstellung einer neuen CRL erfolgen.

4.9.8 Maximale Latenzzeit für Sperrlisten

Die Latenzzeit (Grace Period) für Sperrlisten beträgt 12 Stunden.

4.9.9 Verfügbarkeit von Online-Statusabfragen (OCSP)

Sperrinformationen, werden für die Endteilnehmer der PKI online mit einem standard-konformen Verfahren bereitgestellt (OCSP). Es sind alle von dieser Zertifizierungsstelle gesperrten Zertifikate enthalten.

4.9.10 Anforderungen an Online-Statusabfragen (OCSP)

Die Dienste CRL und OCSP müssen für die Nutzer hoch verfügbar sein.

Page 32: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 32

4.9.11 Andere Formen der Veröffentlichung von Sperrinformationen

Derzeit werden keine anderen Formen der Bekanntmachung eingesetzt.

4.9.12 Anforderungen bei Kompromittierung von privaten Schlüs-seln

Bei einer Kompromittierung eines privaten Schlüssels von Zertifikatsinhabern ist das ent-sprechende Zertifikat möglichst unverzüglich zu sperren.

Bei einer Kompromittierung des privaten Schlüssels einer CA werden alle von ihr ausge-stellten Zertifikate unverzüglich gesperrt.

4.9.13 Gründe für eine Suspendierung

Gründe für die Suspendierung von Zertifikaten können

temporäre Nicht-Verfügbarkeit eines Zertifikatsträgermediums (Smart Card),

längere geplante Abwesenheit von Mitarbeitern,

der Verdacht der unerlaubten Verwendung des Zertifikatsträgermediums oder

der Prozess „Delete User mit Fallback“ wurde ausgeführt, woraufhin der User für 30 Tage suspendiert wird, bevor er endgültig gelöscht wird.

4.9.14 Wer kann eine Suspendierung beantragen?

Die folgenden Personen und Institutionen sind berechtigt, die Suspendierung eines Zertifi-kates zu initiieren:

der Zertifikatsinhaber,

das T-Systems Trust Center,

Führungskräfte des Unternehmens nach Konsultation von Unternehmenssicherheit, Datenschutz und Betriebsrat.

Personalmanagement (z.B. PST)

4.9.15 Ablauf einer Suspendierung

Zur Suspendierung autorisierte Personen und Institutionen können die Suspendierung ei-nes Zertifikates entweder via Web-Seite der PKI, über den Web-Shop oder telefonisch beauftragen. Die Authentisierung und Autorisierung einer Person geschieht dabei in geeig-neter Art und Weise (z.B. Anruf bei Service Desk und Identifizierung des Anrufenden mit-tels Frage/Antwort).

Sind die Vorraussetzungen zur Suspendierung erfüllt, wird die Suspendierung vorgenom-men, und das suspendierte Zertifikat in die Sperrinformationen übernommen. Die Sperrin-formationen werden in standard-konformer Form (CRL bzw. OCSP) bereitgestellt.

Page 33: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 33

Die autorisierte Person oder Institution wird über die Durchführung der Suspendierung in geeigneter Weise informiert.

Eine Suspendierung kann nur aufgehoben werden, wenn das Zertifikat noch gültig ist.

4.9.16 Maximale Suspendierungsdauer

Die maximale Sperrdauer eine Suspendierung ist durch die Zertifikatsgültigkeit begrenzt. Wurde der Prozess Delete User mit Fallback angestoßen so erfolgt 30 Tage nach einer Suspendierung eine endgültige Sperrung der Zertifikate.

4.10 Statusabfrage von Zertifikaten (OCSP, CRL)

4.10.1 Betriebsbedingte Aspekte

Nicht anwendbar.

4.10.2 Verfügbarkeit

Der Zertifikatsstatus-Service steht rund um die Uhr an 7 Tagen die Woche zur Verfügung.

4.10.3 Weitere Merkmale

Nicht relevant.

4.11 Beendigung des Vertragsverhältnisses

Im Falle der Kündigung des Vertragsverhältnisses durch den Zertifikatsinhaber oder den jeweils verantwortlichen KOSTV erfolgt die Sperrung des Zertifikats.

4.12 Schlüsselhinterlegung und –wiederherstellung (Key Escrow, Key Recovery)

4.12.1 Richtlinien und Praktiken zur Schlüsselhinterlegung und –wiederherstellung

Die Schlüsselhinterlegung für Verschlüsselungszertifikate bzw. -schlüssel erfolgt auf Basis der PKI Funktionalitäten für key backup, key history und key recovery mit einer gesicherten Ablage von Schlüsselmaterial in der Betriebsumgebung des Trust Centers (CA-DB).

Page 34: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 34

4.12.2 Richtlinien und Praktiken zum Schutz und Wiederherstellung von Sitzungsschlüsseln

Session Key Kapselung: Nicht relevant.

Abläufe und Policies im Rahmen von Wiederherstellungsprozessen: Der Betrieb der C-PKI erfolgt in der zertifizierten Hochsicherheitsumgebung des T-Systems Trust Center. Alle Funktionen und Prozesse unterliegen strengen Sicherheitsmaßgaben, welche in einem Betriebskonzept (nicht öffentlich verfügbar) dokumentiert sind.

Page 35: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 35

5 Infrastrukturelle, organisatorische und personel-

le Sicherheitsmaßnahmen

Das T-Systems Trust Center ist in einem speziell geschützten Gebäude untergebracht und wird von fachkundigem Personal betrieben. Alle Prozesse für die Beauftragung und Erzeu-gung von Zertifikaten der dort betriebenen Zertifizierungsstellen sind genau definiert. Alle baulichen und organisatorischen Sicherheitsmaßnahmen sind in einem Sicherheitskonzept (nicht öffentlich verfügbar) dokumentiert.

Die folgenden Aussagen gelten für die vom T-Systems Trust Center betriebenen Zertifizie-rungsstellen. Bei Bedarf muss ergänzend auch das Sicherheitskonzept der externen Zerti-fizierungsstellen zur Prüfung auf Konformität mit dieser Richtlinie der T-Systems vorgelegt werden.

5.1 Infrastrukturelle Sicherheitsmaßnahmen

5.1.1 Einsatzort und Bauweise

T-Systems betreibt ein Trust Center, welches aus zwei voll redundant ausgelegten Hälften, zwei getrennt arbeitenden Energietrakten (Elektro, Klima, Wasser) mit Gebäudemanage-mentsystem und Notstromaggregaten sowie einem Verwaltungstrakt besteht.

Die Errichtung und der Betrieb des Trust Centers erfolgt unter Beachtung der entspre-chenden Richtlinien des Bundesamtes für Sicherheit in der Informationstechnik (BSI), des Verbandes der Schadenversicherer e.V. (VdS) / neu: Gesamtverband der Deutschen Ver-sicherungswirtschaft (GDV), der einschlägigen DIN-Normen zu Brandschutz, Rauchschutz und Angriffhemmung. Das Trust Center ist sicherheitstechnisch vom VdS / GDV abge-nommen. Die technischen Maßnahmen werden durch organisatorische Elemente ergänzt, die die Handhabung der sicherheitsrelevanten Techniken und Regelungen über den Zutritt zu Sicherheitszonen für Mitarbeiter und Dritte (Besucher, Fremd- und Reinigungsperso-nal), die Anlieferung von Material (Hardware, Zubehör, Betriebsmittel) und Ordnung am Arbeitsplatz sowie in Rechnerräumen beinhalten.

5.1.2 Räumlicher Zugang

Im Trust Center gilt eine Zutrittsregelung die die Zutrittsrechte für Mitarbeiter, Mitarbeiter von Fremdfirmen und Gästen in den einzelnen Sicherheitszonen regelt. Der Zutritt ist zwi-schen den Sicherheitsbereichen nur über Personenvereinzelungsanlagen möglich. Der kontrollierte Zutritt zu den verschiedenen Sicherheitsbereichen ist weiter mit einem rech-nergesteuerten Zutrittskontrollsystem geschützt. Gäste werden nur in Ausnahmefällen und nach vorheriger Anmeldung empfangen. Hier gelten besondere Sicherheitsvorschriften.

Page 36: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 36

5.1.3 Energieversorgung und Klimatisierung

Zum Ausfallschutz der Energieversorgung ist eine unabhängige Wechselspannungsver-sorgung entsprechend VDE-Vorschriften installiert. Sie bietet Schutz gegen Spannungs-schwankungen, unterbrechungsfreie Kurzzeitüberbrückung, eine Langzeitüberbrückung mit zwei getrennten, ortsfesten Notstromaggregaten deren Leistung die der Volllast-Leistungsaufnahme des Rechenzentrums entspricht.

Die Ansaugöffnungen für die Außenluft sind so angeordnet, dass keine Schadstoffe wie Staub und Schmutz, ätzende, giftige oder leicht brennbare Gase eindringen können. Die Systeme werden mit einem sehr geringen Außenluftanteil betrieben. Die erforderlichen Zuluftöffnungen sind zugangsgeschützt. Zum Schutz gegen Luftverunreinigung durch schwebende Partikel sind Filter installiert. Die Frischluftansaugung wird ständig auf ag-gressive Gase überwacht. Im Notfall (z.B. Brand in der Umgebung) wird die Außenluftan-saugung automatisch durch Luftklappen verschlossen.

5.1.4 Wassergefährdung

Das Trust Centers liegt in einer geschützten Lage, d.h. es liegt nicht in der Nähe von Ge-wässern und Niederungen (Hochwassergefahr). Die Brandbekämpfung erfolgt mit inertem Gas.

5.1.5 Brandschutz

Die geltenden Brandschutzbestimmungen (z.B. DIN 4102, Auflagen der örtlichen Feuer-wehr, Vorschriften über Feuerresistenz, VDE-gerechte Elektroinstallation) werden ein-gehalten. Alle Brandschutztüren besitzen automatische Schließeinrichtungen. In Abspra-che mit der Feuerwehr wird nur in äußersten Notfällen mit Wasser gelöscht.

Brandabschnitte sind durch feuerbeständige Bauteile gesichert. Durchgänge durch Brand-schutzwände sind mit selbsttätig schließenden Brandschutztüren ausgestattet

In Bereichen mit Doppelböden sowie abgehängten Decken sind Brandschutzwände durch-gehend bis zum Geschoßboden bzw. zur Geschoßdecke ausgeführt.

In alle Systemräume, Systemoperatorräume, Archivräume, USV-Räume sowie weitere ausgewählte Räume sind Brandfrühesterkennungssystemen (Ansaugsysteme) installiert. Überwacht wird die Zu- bzw. Abluft der Klimageräte der einzelnen Räume. In den weiteren Räumen sind Brandmelder verbaut.

5.1.6 Aufbewahrung und Entsorgung von Datenträgern

Datenträger, die Produktionssoftware und -daten, Audit-, Archiv- oder Sicherungsinforma-tionen enthalten,

werden in Räumen gelagert, die mit den entsprechenden physischen und logischen Zu-trittskontrollen versehen sind und Schutz vor Unfallschäden (z.B. Wasser-, Brand- und elektromagnetische Schäden) bieten.

Page 37: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 37

5.1.7 Externe Datensicherung

Nicht relevant.

5.2 Organisatorische Sicherheitsmaßnahmen

Das Change Advisory Board des T-Systems Trust Centers ist verantwortlich für die Initiie-rung, Durchführung und Kontrolle der Methoden, Prozesse und Verfahren, die in den Si-cherheitskonzepten (nicht öffentlich verfügbar) und CPS Dokumenten der vom T-Systems Trust Center betriebenen Zertifizierungsstellen dargestellt werden.

5.2.1 Rollen

Vertrauenswürdige Personen sind alle Personen (T-Systems Mitarbeiter, Auftragnehmer, und Berater) mit Zugang zu oder Kontrolle über Authentifizierungs- oder kryptographische Abläufe, die erhebliche Auswirkungen auf Folgendes haben können: die Validierung von Informationen in Zertifikatsaufträgen,

die Annahme, Ablehnung oder sonstige Bearbeitung von Zertifikatsaufträgen, Sperraufträgen oder Erneuerungsaufträgen,

die Vergabe oder den Widerruf von Zertifikaten, einschließlich Personal, das Zu-gang und Zugriff auf die Datenbanksysteme hat,

den Umgang mit Informationen oder Aufträgen von Endteilnehmern.

Vertrauenswürdige Personen sind insbesondere: Mitarbeiter des Trust Centers (z.B. Systemadministration),

Mitarbeiter kryptographischer Abteilungen,

Sicherheitspersonal,

zuständiges technisches Personal und

für die Verwaltung der vertrauenswürdigen Infrastruktur zuständige leitende Ange-stellte.

Die oben genannten vertrauenswürdigen Personen müssen die in diesem CP/CPS festge-legten Anforderungen (siehe Kapitel 5.3.1) erfüllen. Das Change Advisory Board des T-Systems Trust Centers ist verantwortlich für die Initiie-rung, Durchführung und Kontrolle der Methoden, Prozesse und Verfahren, die in den Si-cherheitskonzept en, im CP/CPS der vom T-Systems Trust Center betriebenen Zertifizie-rungsstellen dargestellt werden.

5.2.2 Anzahl der pro Aufgabe involvierten Personen

Gemäß internem Trust Center Rollenkonzept. Die Aufrechterhaltung des Betriebs der Zertifizierungsstelle und des Verzeichnisdienstes (Administration, Sicherung, Wiederherstellung) wird von fachkundigen und vertrauenswür-digen Mitarbeitern wahrgenommen.

Page 38: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 38

Arbeiten an hochsensitiven Komponenten (z.B. Schlüsselerstellungssystem, HSM) sind durch besondere interne Kontrollverfahren geregelt und werden von mindestens zwei Mit-arbeitern durchgeführt.

5.2.3 Identifizierung und Authentifizierung jeder Rolle

T-Systems Mitarbeiter, die als vertrauenswürdige Personen eingestuft sind und vertrau-enswürdige Tätigkeiten wahrnehmen, unterliegen einer T-Systems-internen Sicherheits-überprüfung (siehe Kapitel 5.3.2). T-Systems stellt sicher, dass Mitarbeiter einen vertrauenswürdigen Status erlangt haben und die Zustimmung der Abteilung erteilt wurde, bevor diese Mitarbeiter: Zugangsgeräte und Zugang zu den erforderlichen Einrichtungen erhalten,

die elektronische Berechtigung zum Zugriff auf die TeleSec ServerPass CA und andere IT-Systeme erhalten,

zur Durchführung bestimmter Aufgaben im Zusammenhang mit diesen Systemen zugelassen werden.

5.2.4 Rollen, die eine Aufgabentrennung erfordern

Die folgenden Rollen erfordern eine Aufgabentrennung und werden daher von verschiede-nen Mitarbeitern begleitet: Auftragsvalidierung und Auftragsfreigabe (nur ServerPass EV),

Sicherung und Rücksicherung von Datenbanken und HSMs,

Key Lifecycle Management von CA- und Root-CA-Zertifikaten.

5.3 Personelle Sicherheitsmaßnahmen

Die Zuverlässigkeit des Personals, das im T-Systems Trust Center arbeitet, wird durch eine unabhängige Organisation überprüft. Das Personal besucht in regelmäßigen Abstän-den Fortbildungen. Eine Rollentrennung bei kritischen Prozessen wird im jeweiligen Sicherheitskonzept (nicht öffentlich verfügbar) definiert. Organisationen, die als RA für das T-Systems Trust Center agieren, haben vertragliche Vereinbarungen geschlossen, die die Zuverlässigkeit und Fachkunde ihres Personals sowie die Einhaltung bestimmter zugewiesener Aufgaben si-cherstellen.

5.3.1 Anforderungen an Personal

T-Systems verlangt von seinen Mitarbeitern, die als vertrauenswürdige Personen tätig werden möchten, Nachweise vorzulegen über Qualifizierung und Erfahrung, die dazu not-wendig sind, ihre voraussichtlichen beruflichen Pflichten kompetent und zufriedenstellend zu erfüllen.

Page 39: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 39

5.3.2 Sicherheitsüberprüfung von Personal

Vor dem Beginn der Beschäftigung in einer vertrauenswürdigen Rolle führt T-Systems eine Sicherheitsüberprüfung durch mit folgendem Inhalt durch: Überprüfung und Bestätigung der bisherigen Beschäftigungsverhältnisse,

Überprüfung von Arbeitszeugnissen,

Bestätigung des höchsten oder maßgebenden Schul-/Berufsabschlusses,

Sofern die in diesem Abschnitt festgelegten Anforderungen nicht erfüllt werden können, macht T-Systems ersatzweise Gebrauch von einer gesetzlich zulässigen Ermittlungsme-thode, die im Wesentlichen die gleichen Informationen liefert.

5.3.3 Schulungsanforderungen

Das Personal der T-Systems besucht Fortbildungsmaßnahmen die zur kompetenten und zufriedenstellenden Erfüllung ihrer beruflichen Pflichten erforderlich sind. T-Systems führt Unterlagen über diese Schulungsmaßnahmen.

5.3.4 Häufigkeit und Anforderungen an Fortbildungen

Das Personal der T-Systems erhält im erforderlichen Umfang und den erforderlichen Ab-ständen Auffrischungsschulungen und Fortbildungslehrgänge.

5.3.5 Häufigkeit und Ablauf von Arbeitsplatzwechseln

Nicht anwendbar..

5.3.6 Sanktionen bei unerlaubten Handlungen

T-Systems behält sich vor, unbefugte Handlungen oder anderer Verstöße gegen dieses CP/CPS und der daraus abgeleiten Verfahren zu ahnden und entsprechende Disziplinar-maßnahmen einzuleiten. Diese Disziplinarmaßnahmen können Maßnahmen bis ein-schließlich der Kündigung beinhalten und richten sich nach der Häufigkeit und Schwere der unbefugten Handlungen.

5.3.7 Anforderungen an unabhängige, selbständige Zulieferer

T-Systems behält sich vor, unabhängige Auftragnehmer oder Berater zur Besetzung ver-trauenswürdiger Positionen einzusetzen. Diese Personen unterliegen denselben Funkti-ons- und Sicherheitskriterien wie Mitarbeiter von T-Systems in vergleichbarer Position. Obiger Personenkreis, der die in Kapitel 5.3.2 beschriebene Sicherheitsüberprüfung noch nicht abgeschlossen oder nicht erfolgreich durchlaufen hat, wird der Zugang zu den gesi-cherten Einrichtungen von T-Systems nur unter der Bedingung gestattet, dass sie stets von vertrauenswürdigen Personen begleitet und unmittelbar beaufsichtigt werden.

Page 40: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 40

5.3.8 Dokumentation für Mitarbeiter

Um die beruflichen Pflichten angemessen erfüllen zu können, stellt T-Systems seinen Mit-arbeitern alle dafür erforderliche Dokumente (Schulungsunterlagen, Verfahrensanweisun-gen) und Hilfsmittel zur Verfügung.

5.4 Überwachung / Protokollierung

5.4.1 Überwachte Ereignisse

Veränderungen im Lebenszyklus von Zertifikaten und relevanten Kontextinformationen werden protokolliert, dies bezieht sich im Einzelnen auf: Ereignissen im Lebenszyklus von Zertifikaten für Endteilnehmer:

o Erzeugung

o Sicherung

o Speicherung

o Wiederherstellung

o Archivierung

o Vernichtung

Ereignissen im Lebenszyklus von Zertifikaten von Zertifizierungsstellen:

o Zertifikatsauftrag (erfolgreich / fehlgeschlagene Bearbeitung und beiliegen-de Dokumente)

o Erstellung von Zertifikaten

o Zertifikatserneuerung

o Zertifikatssperrung / Suspendierung / Aufhebung der Suspendierung

Sperrlisten

Änderungen von Hardware und Software

Interne und externe Audits

5.4.2 Bearbeitungsintervall der Protokolle

Die erstellten Audit-Protokolle/Logging-Dateien werden regelmäßig auf wichtige si-cherheits- und betriebsrelevante Ereignisse untersucht. Ferner überprüft T-Systems die Audit-Protokolle/Logging-Dateien auf verdächtige und ungewöhnliche Aktivitäten, als Folge von Unregelmäßigkeiten und Störungen. Eingeleitete Maßnahmen, die als Reaktion aus der Auswertung von Audit-Protokollen/Logging-Dateien stammen, werden ebenfalls proto-kolliert.

5.4.3 Aufbewahrungsfrist für Log-Dateien

Audit-Protokolle/Logging-Dateien werden nach Bearbeitung gemäß Kapitel 5.5.2 archiviert.

Page 41: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 41

5.4.4 Schutz von Log-Dateien

Audit-Protokolle/Logging-Dateien werden gegen unbefugten Zugriff geschützt.

5.4.5 Backup von Log-Dateien

Eine Sicherung von Audit-Protokollen/Logging-Dateien wird regelmäßig durchgeführt.

5.4.6 Überwachungssystem (intern / extern)

Audit-Daten/Logging-Dateien von Anwendungs-, Netzwerk - und Betriebssystemebene werden automatisch erzeugt und aufgezeichnet. Manuell erzeugte Audit-Daten werden von T-Systems-Mitarbeitern aufgezeichnet.

5.4.7 Benachrichtigung bei schwerwiegenden Ereignissen

Ereignisse, die das Audit-Monitoringsystem erfasst, werden bewertet an das zuständige Trust Center Personal weiter geleitet. Ereignisse mit hoher Priorität werden unverzüglich auch außerhalb der Regelarbeitszeit an das Trust Center Personal weitergeleitet.

5.4.8 Schwachstellenanalyse

Die Trust-Center-Administratoren werden regelmäßig über bekanntgewordene Schwach-stellen von Software-Produkten informiert. Nach Auswertung der Information erfolgt eine Schwachstellenbewertung, aus der Gegenmaßnahmen abgeleitet und umgehend durchge-führt werden.

5.5 Archivierung

5.5.1 Archivierte Daten

Alle Identitäts- und Bearbeitungsdaten im Zusammenhang mit Zertifikaten und Identity Li-fecycle Management.

5.5.2 Aufbewahrungsfrist für archivierte Daten

Alle Audit/Logging Aufzeichnungen innerhalb des T-Systems Trust Centers werden min-destens 12 Monate aufbewahrt.

5.5.3 Schutz der Archive

T-Systems stellt sicher, dass nur autorisierte und vertrauenswürdige Personen Zutritt zu Archiven erhalten. Archivdaten sind gegen unbefugte Lesezugriffe, Änderungen, Löschun-gen oder andere Manipulationen geschützt.

5.5.4 Archivbackup

Eine Sicherung der elektronischen Archive wird regelmäßig durchgeführt.

Page 42: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 42

5.5.5 Anforderungen an Zeitstempel

Datensätze wie beispielsweise Zertifikate, Zertifikatssperrlisten, OSCP-Antworten, Log-ging-Dateien enthalten Informationen über Datum und Uhrzeit. Als Zeitquelle dient das Empfangssignal des DCF 77, aus dem die UTC abgeleitet wird.

5.5.6 Archivierungssystem (intern / extern)

T-Systems verwendet interne Archivierungssysteme.

5.5.7 Abruf und Verifikation von archivierten Informationen

Nur autorisiertes und vertrauenswürdiges Personal erhält Zutritt zu Archiven und Zugang/ Zugriff zu Archivdaten. Bei der Wiederherstellung der Archivdaten werden diese auf Au-thentizität verifiziert.

5.6 Schlüsselwechsel der Zertifizierungsstelle

Bei Schlüsselwechseln von Root-CA oder CA wird die Generierung neuer Schlüssel und Zertifikate dokumentiert und gemäß der Auflagen des jeweiligen Sicherheitskonzepts überwacht. Neue Zertifikate und ihre Fingerprints werden veröffentlicht.

5.7 Kompromittierung und Desaster Recovery

5.7.1 Vorgehen bei Sicherheitsvorfällen und Kompromittierung

Störungen werden über die in Kapitel 1.5.2 definierten Kontakte eingereicht und im Rah-men des Service Managements bearbeitet.

Bei Kompromittierung privater Schlüssel von Zertifizierungsstellen wird dies unverzüglich mitzuteilen. Zertifikate der Zertifizierungsstellen werden daraufhin unverzüglich gesperrt, und die entsprechende ARL wird unverzüglich zu veröffentlicht. Die Generierung neuer Schlüssel und Zertifikate wird dokumentiert, und gemäß der Auflagen des Sicherheitskon-zepts überwacht. Neue Zertifikate und ihre Fingerprints sind zu veröffentlichen.

5.7.2 Betriebsmittel, Software und/oder Daten wurden kompromit-tiert

Bei einer Beschädigung der EDV-Komponenten, Software und/oder Daten wird der Vorfall unmittelbar untersucht und der T-Systems Sicherheitsabteilung gemeldet. Das Ereignis zieht eine entsprechende Eskalation, Störfalluntersuchung, Störfallreaktion bis hin zur fina-len Störungsbeseitigung nach sich. Abhängig von der Störungsklassifizierung erfolgt die Wiederherstellung (Disaster Recovery).

Page 43: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 43

5.7.3 Kompromittierung des privaten Schlüssels

Bei Kenntnisnahme einer Kompromittierung des privaten Schlüssels einer CA wird der Vorfall unmittelbar untersucht, beurteilt und die notwendigen Schritte eingeleitet. Falls er-forderlich ist/sind das/die Zertifikate unverzüglich zu sperren und die entsprechende Zertifi-zierungsstellen-Sperrliste (ARL) zu generieren und zu veröffentlichen.

5.7.4 Betriebswiederaufnahme nach einem Notfall

T-Systems hat einen Notfallplan entwickelt, implementiert und getestet, um Katastrophen jeder Art (Naturkatastrophen oder Katastrophen menschlichen Ursprungs) zu mildern. Die-ser Plan wird regelmäßig geprüft, um im Falle einer Katastrophe schnellstmöglich eine Wiederherstellung der EDV-Komponenten, Software und Daten zu ermöglichen.

5.8 Einstellung des Betriebs

Eine Betriebsbeendigung kann nur durch die T-Systems Geschäftsleitung ausgesprochen werden.

Falls T-Systems in Gänze oder für Teile des Services den Betrieb einstellt, wird ein Been-digungsplan erstellt. Es werden wirtschaftlich angemessene (oder einzelvertraglich zuge-sagte) Anstrengungen unternommen, betroffene, nachgeordnete Stellen vorab über diese Betriebsbeendigungen zu informieren.

Ein Beendigungsplan kann die folgenden Regelungen enthalten:

Fortführung des Sperrservices

Sperrung von ausgegebenen CA Zertifikaten

eventuell erforderliche Übergangsregelungen auf eine Nachfolge CA

je nach Ausgestaltung bestehender Einzelverträge entstehende Kostenerstattung

Aufbewahrung der Unterlagen und Archive der CA

Wenn der Betrieb (insbesondere der Sperrdienst) nicht durch eine andere Zertifizierungs-stelle übernommen werden kann, sind alle ausgestellten Zertifikate zu sperren.

Page 44: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 44

6 Technische Sicherheitsmaßnahmen

Das T-Systems Trust Center ist in einem speziell geschützten Gebäude untergebracht und wird von fachkundigem Personal betrieben. Alle Prozesse für die Beauftragung und Erzeu-gung von Zertifikaten der dort betriebenen Zertifizierungsstellen sind genau definiert. Alle technischen Sicherheitsmaßnahmen sind in einem Sicherheitskonzept (nicht öffentlich ver-fügbar) dokumentiert.

6.1 Schlüsselerzeugung und –installation

6.1.1 Schlüsselerzeugung

Schlüsselpaare für CA´s werden auf einer sicherheitsüberprüften Hardwarekomponente erzeugt und auf einer anderen Hardwarekomponente als Trägermedium gesichert abge-legt.

Schlüsselpaare für ausgegebene Signatur- und Authentifizierungszertifikate von Endteil-nehmern basieren auf der myCard (einer speziellen Smart Card) als Trägermedium. Sie werden durch den Hersteller der myCard in einer speziellen, abgeschirmten Umgebung erzeugt, durch das TCOS Chipkarten-Betriebssystem gesichert auf der Karte abgelegt und mit einer speziellen Versiegelung, die den Auslieferungszustand der Karte definiert, ausge-liefert.

Schlüsselpaare für Verschlüsselungszertifikate von Endteilnehmern werden zentral in einer speziell geschützten Umgebung unter Verwendung von Hardware Security Modulen (HSM) erzeugt und auf der myCard, durch Mechanismen des TCOS Chipkarten Betriebssystems gesichert, abgelegt.

6.1.2 Übergabe des privaten Schlüssels an Zertifikatsinhaber

Im Falle der Nutzung von Smart Cards werden für Signatur und Authentifizierung die bei der Produktion auf die Karte aufgebrachten Schlüssel verwendet. Es findet keine Übermitt-lung dieser privaten Schlüssel statt. Verschlüsselungsschlüssel werden serverseitig gene-riert und über einen verschlüsselten Tunnel auf die Smart Card übertragen. Ein Auslesen der privaten Schlüssel ist hier nicht mehr möglich.

6.1.3 Übergabe des öffentlichen Schlüssels an den Zertifikatsher-ausgeber

Öffentliche Schlüssel werden in Form signierter PKCS#10 Requests an den Zertifikats-herausgeber ausgeliefert.

Page 45: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 45

6.1.4 Publikation öffentlicher Schlüssel der Zertifizierungsstelle

Die Verteilung erfolgt über den im AIA-Pfad (Authority Information Access) angegebenen Verzeichnisdienst, siehe auch 7.1Fehler! Verweisquelle konnte nicht gefunden wer-den..

6.1.5 Schlüssellängen

Die Schlüssellänge für alle Zertifikate beträgt 2048 Bit.

6.1.6 Erzeugung der Public Key Parameter und Qualitätssicherung

Nicht relevant.

6.1.7 Schlüsselverwendungzwecke (nach X.509 v3, Attribut „key usage“)

Die Schlüsselverwendungen der ausgegebenen Zertifikate ist im Attribut „key usage“ fest-gelegt.

Mögliche Werte sind:

Key Encipherment

Data Encipherment

Digital Signature

Die erweiterte Schlüsselverwendung ist im Attribut „extended key usage“ festgelegt.

Mögliche Werte sind:

Server Authentication (1.3.6.1.5.5.7.3.1)

Client Authentication (1.3.6.1.5.5.7.3.2)

Secure E-Mail (1.3.6.1.5.5.7.3.4)

Smartcard Logon (1.3.6.1.4.1.311.20.2.2)

6.2 Schutz von privaten Schlüsseln und Einsatz von Kryptomo-dulen

Die Verwendung privater Schlüssel ist grundsätzlich immer durch Besitz (PSE, Token) und Wissen (PIN), der für die Nutzung autorisierten Rollenträger, geschützt.

Im Falle von privaten Schlüsseln für Zertifikate von Zertifizierungsstellen werden private Schlüssel in Verantwortung der für den Betrieb Verantwortlichen im Trust Center gesichert abgelegt und gegen nicht autorisierte Verwendung geschützt (z.B. Verwendung spezieller Hardwaregeräte wie HSM oder Windows Data Protection API).

Page 46: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 46

6.2.1 Standard kryptographischer Module

Im Fall von Root-CA und CA Zertifikaten für fortgeschrittene Zertifizierungsstellen werden die privaten Schlüssel auf einem sicherheitsüberprüften Hardware Security Module (FIPS 140 – 2 evaluiert) abgelegt.

Im Fall von Zertifikaten für Endteilnehmer werden die privaten Schlüssel auf einer myCard, geschützt durch Mechanismen des TCOS Chipkartenbetriebssystems, abgelegt.

Im Falle von Computerzertifikaten, Serverzertifikaten, Domain-Controller-Zertifikaten VPN-Gateway-Zertifikaten und Zertifikaten auf mobilen Endgeräten sind private Schlüssel in Verantwortung nutzer bzw. verantwortlichen Rollenträger (z.B. Server Admin) gegen nicht autorisierte Verwendung zu schützen (z.B. Verwendung spezieller Hardwaregeräte wie HSM oder Windows Data Protection API).

6.2.2 Aufteilung privater Schlüssel auf mehrere Personen (n-aus-m)

T-Systems hat technische, organisatorische und prozessuale Mechanismen implementiert, die die Teilnahme mehrerer vertrauenswürdiger und geschulter Personen des T-Systems Trust Centers erfordern, um vertrauliche kryptographische CA-Operationen durchführen zu können. Die Verwendung privater Schlüssel von Zertifizierungsstellen wird durch einen geteilten Authentisierungsprozess (Trusted Path Authentification mit Key) geschützt. Jede am Prozess beteiligte Person verfügt über Geheimnisse, die nur in der Gesamtheit be-stimmte Arbeiten ermöglichen.

6.2.3 Hinterlegung privater Schlüssel

Eine Hinterlegung von privaten Schlüsseln von Zertifizierungsinstanzen und von Ver-schlüsselungsschlüsseln von Zertifikatsinhabern erfolgt im Trust Center. Eine Hinterlegung von privaten Schlüsseln für Signatur- und Authentifizierungszertifikate von Zertifikatsinha-bern erfolgt nicht.

6.2.4 Backup privater Schlüssel

Die Ablage privater Schlüssel von Zertifizierungsstellen (siehe 6.2.3) und von Verschlüsse-lungsschlüsseln von Zertifikatsinhabern erfolgt in der Betriebsumgebung des Trust Centers . Andere Schlüssel werden nicht gesichert.

6.2.5 Archivierung des privaten Schlüssels

Wenn CA-, Root-CA oder OCSP-Schlüssel das Ende ihrer Gültigkeitsdauer erreicht haben, werden sie vernichtet. Eine Archivierung findet nicht statt.

Page 47: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 47

6.2.6 Transfer eines privaten Schlüssels in oder aus einem Krypto-modul

Verschlüsselungsschlüssel von Personen-Zertifikaten werden ausschließlich im Rahmen definierter PKI-Prozesse, z.B. bei Neuausstellung, Verlängerung oder Update von Zertifika-ten, transferiert. Schlüssel von Zertifizierungsstellen werden auf kryptographischen Hardware-Modulen (HSM) erzeugt und abgelegt. Von diesen Schlüsseln werden Kopien für Wiederherstel-lungs- und Notfallzwecke (siehe Kapitel 6.2.4 und 6.2.5) erstellt. In diesem Falle erfolgt die Übertragung in verschlüsselter Form zwischen beiden Modulen.

6.2.7 Ablage privater Schlüssel in Kryptomodulen

Private Schlüssel von Zertifikaten von Zertifizierungsstellen werden in Hardware Krypto-modulen (HSM) abgelegt.

6.2.8 Aktivierung privater Schlüssel

Alle Endteilnehmer, Registratoren, Administratoren und Operatoren müssen die Aktivie-rungsdaten (z.B. PIN, Importpasswort) für ihren privaten Schlüssel gegen Verlust, Dieb-stahl, Änderung, Offenlegung und unbefugte Nutzung gemäß des vorliegenden CP/CPS schützen. Zertifikatsinhaber verpflichten sich Maßnahmen zum physikalischen Schutz der verwendeten Hardware/Software zu ergreifen, um die Nutzung des Platzes/Komponente und seines zugehörigen privaten Schlüssels ohne Genehmigung des Zertifikatsinhabers zu verhin-dern. Administratoren oder Operatoren im Trust Center haben zum Schutz des privaten Schlüs-sels folgende Vorgaben einzuhalten: Festlegung eines Passworts bzw. einer PIN (gemäß Kapitel 6.4.1) oder Integration

einer ähnlichen Sicherheitsmaßnahme, um den Administrator oder Operator vor der Aktivierung des privaten Schlüssels zu authentisieren. Dies kann z. B. auch ein Kennwort zum Betrieb des privaten Schlüssels, ein Windows Anmelde- oder Bild-schirmschonerkennwort, ein Anmeldekennwort für das Netzwerk beinhalten.

Ergreifung geeigneter Maßnahmen zum physikalischen Schutz des Administrator- oder Operator-Arbeitsplatzes vor unberechtigtem Zugriff.

6.2.9 Deaktivierung privater Schlüssel

Die Deaktivierung privater Schlüssel von Administratoren und Operatoren erfolgt ereignisbezogen und obliegt dem Personal des Trust Centers der T-Systems. Für die Deaktivierung von privaten Endteilnehmer Schlüsseln ist der Endteilnehmer verantwortlich.

6.2.10 Vernichtung privater Schlüssel

Die Vernichtung von CA-Schlüsseln erfordert die Teilnahme mehrerer vertrauenswürdiger Personen des Trust Centers. Dabei ist sicherzustellen, dass nach Vernichtung keine

Page 48: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 48

Fragmente des Schlüssels übrigbleiben, die zu einer Rekonstruktion des Schlüssels führen könnte. Die Vernichtung von privaten Schlüsseln der Endteilnehmer obliegt diesen selbst.

6.2.11 Güte von Kryptomodulen

Siehe 6.2.1

6.3 Weitere Aspekte des Zertifikats- und Schlüsselmanage-ments

6.3.1 Archivierung öffentlicher Schlüssel

Im Rahmen der regelmäßigen Sicherungs- und Archivierungsmaßnahmen von T-Systems werden die Zertifikate gesichert und archiviert.

6.3.2 Gültigkeit von Zertifikaten und Schlüsselpaaren

Ein Überblick über die Gültigkeit personenbezogener Zertifikate bzw. Schlüssel der ver-schiedenen Zertifikate gibt die folgende Tabelle:

Wurzelzertifizierungsstellen (Root-CA) 20 Jahre

Zertifizierungsstellen (CA) 6 Jahre

Deutsche Telekom AG Employee Encryption 3 Jahre

Deutsche Telekom AG Employee Signature 3 Jahre

Deutsche Telekom AG Employee Authentication 3 Jahre

Deutsche Telekom AG External Workforce Encryption 3 Jahre

Deutsche Telekom AG External Workforce Signature 3 Jahre

Deutsche Telekom AG External Workforce Authentica-tion

3 Jahre

Tabelle 4: Gültigkeitszeiträume von Zertifikaten

6.4 Aktivierungsdaten

Zertifikate und Schlüssel von Zertifizierungsstellen Um die auf dem HSM hinterlegten privaten Schlüssel der CA-Zertifikate schützen zu kön-nen, werden Aktivierungsdaten (Geheimnisanteile) in einer definierten „Key Ceremony“ generiert und protokolliert. Zertifikate von Zertifikatsinhabern (Endteilnehmern) Die Aktivierung von Zertifikaten ist grundsätzlich verknüpft mit Wissen (One Time Secret und/oder PIN) und dem Besitz eines Schlüsselträgermediums(Smart Card oder Software-PSE).

Page 49: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 49

6.4.1 Generierung und Installation von Aktivierungsdaten

Die Trust Center Administratoren bzw. von T-Systems autorisierte Personen verpflich-ten sich, die Geheimnisanteile für die Aktivierung der privaten Schlüssel zu schützen. Bei Zertifikaten von Zertifikatsinhabern (Endteilnehmer) werden One Time Secrets wird von der PKI generiert. Die Vergabe von PIN erfolgt durch die jeweiligen Zertifikatsinhaber.

6.4.2 Schutz der Aktivierungsdaten

Die Trust Center Administratoren bzw. von T-Systems autorisierte Personen verpflichten sich, die Geheimnisanteile für die Aktivierung der privaten Schlüssel der CA- und OCSP-Zertifikate zu schützen. PIN und One Time Secrets sind nur den jeweiligen Zertifikatsinhabern bekannt und von diesen nutzbar.

6.4.3 Weitere Aspekte der Aktivierungsdaten

Nicht relevant.

6.5 Computerbezogene Sicherheitskontrollen

Alle PKI-Funktionen werden mit Hilfe vertrauenswürdiger und geeigneter Systeme durch-geführt.

6.5.1 Spezifische Anforderungen an technische Sicherheits-maßnahen

T-Systems stellt sicher, das die Verwaltung der PKI-Systeme vor unbefugtem Zugriff Dritter gesichert ist. T-Systems verwendet Schutzmechanismen (z.B. Firewalls, Zutrittsschutz, Mehr-Augen-Prinzip), um die PKI-Funktionalitäten, Verzeichnisdienste und OCSP-Responder, welche im Trust Center betrieben werden vor internen und externen Eindring-ligen zu schützen. Der direkte Zugriff auf PKI-Datenbanken, die die PKI-Funktionalitäten unterstützen, ist dabei auf geeignetes, geschultes und vertrauenswürdiges Betriebsperso-nal beschränkt.

6.5.2 Bewertung der Computersicherheit

Im Rahmen des Sicherheitskonzeptes wurden unterschiedliche Bedrohungsanalysen durchgeführt, die die Wirksamkeit aller getroffenen Maßnahmen untersucht.

6.6 Technische Maßnahmen im Lebenszyklus

Nicht relevant.

6.6.1 Maßnahmen der Systementwicklung

Entsprechend T-Systems PM-Book und SE-Book.

Page 50: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 50

6.6.2 Maßnahmen des Sicherheitsmanagements

T-Systems hat Mechanismen und/oder Richtlinien implementiert, um die Konfiguration der PKI-Systeme im Trust Center kontrollieren und überwachen zu können. Die Integrität wird vor der Installation manuell verifiziert.

6.6.3 Lebenszyklus der Sicherheitsmaßnahmen

Nicht relevant.

6.7 Sicherheitsmaßnahmen für das Netzwerk

Folgende Netzwerk-Sicherheitsmaßnahmen wurden implementiert: Die Netzwerke des Zertifizierungsdienstes sind durch Firewalls vom Internet ge-

trennt und beschränken den Datenverkehr auf das für die Funktionen notwendige Maß.

Sicherheitskritische Komponenten und Systeme, die vom Internet aus erreichbar sind (z.B. Verzeichnisdienst, OCSP-Responder) werden durch Firewalls von Inter-net und den internen Netzen getrennt. Alle anderen sicherheitskritischen Kompo-nenten und Systeme (z.B. CA, DB, Signer) befinden sich in einem separaten Netz.

Die internen Netzwerke des Zertifizierungsdienstes sind nach dem Schutzbedarf der Systeme und Komponenten aufgeteilt und untereinander durch Firewalls ge-trennt.

6.8 Zeitstempel

Zertifikate, Sperrlisten, Online-Statusprüfungen und andere wichtige Informationen enthal-ten Datums- und Zeitinformationen die aus einer zuverlässigen Zeitquelle abgeleitet wer-den.

Page 51: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 51

7 Zertifikate, CRL und OCSP Profile

7.1 Zertifikatsprofile

Die von den CAs ausgestellten Zertifikate sind konform zu:

[ITU-T Recommendation X.509][2] (2005): Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, 08/05.

RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.

und

Common PKI Spezifikation 1.1.

Die ausgestellten Zertifikate enthalten in jedem Fall die im X.509-Standard festgelegten Felder:

Felder Wert

Serial Number Eindeutige Seriennummer (je Issuer DN)

Signature Algorithm Object Identifier (OID) des zur Signatur der Zertifikate verwende-ten Algorithmus (siehe Abschnitt 7.1.3)

Issuer DN siehe Abschnitt 7.1.4

Valid from („Not before“) UTC, codiert gemäß RFC 5280

Valid to („Not after“) UTC, codiert gemäß RFC 5280

Subject DN siehe Abschnitt 7.1.4

Subject Public Key Codiert gemäß RFC 5280

Signature Erstellt und codiert gemäß RFC 3280

Tabelle 5: Basis-Felder des Zertifikatsprofils

7.1.1 Versionsnummern

Zertifikate werden gemäß X.509 Standard in der Version 3 ausgestellt.

7.1.2 Zertifikatserweiterungen

7.1.2.1 Schlüsseleinsatz (Key Usage)

Page 52: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 52

Zertifikat Digital Signature Key Encipherment Data Encipherment

Deutsche Telekom AG Employee Encryp-tion

Nein Ja Ja

Deutsche Telekom AG Employee Signa-ture

Ja Nein Nein

Deutsche Telekom AG Employee Authen-tication

Ja Nein Nein

Deutsche Telekom AG External Workfor-ce Encryption

Nein Ja Ja

Deutsche Telekom AG External Workfor-ce Signature

Ja Nein Nein

Deutsche Telekom AG External Workfor-ce Authentication

Ja Nein Nein

Deutsche Telekom AG Code Signing

Ja Nein Nein

Deutsche Telekom AG Telekom Compu-ter

Ja Ja Nein

Deutsche Telekom AG Domain Controller

Ja Ja Nein

Deutsche Telekom AG Web Server

Ja Ja Nein

Deutsche Telekom AG VPN Gateway

Ja Ja Nein

Tabelle 6: Zertifikatserweiterungen (hier: Key Usage)

7.1.2.2 Erweiterter Schlüsseleinsatz (Extended Key Usage)

Server Au-thentication

Client Au-thentication

Code Sign-ing

Secure E-Mail

Smartcard Logon

OID 1.3.6.1.5.5.7.3.1

1.3.6.1.5.5.7.3.2

1.3.6.1.5.5.7.3.3

1.3.6.1.5.5.7.3.4

1.3.6.1.4.1. 311.20.2.2

Page 53: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 53

Deutsche Telekom AG Employee Enc-ryption

Nein Nein Nein Ja Nein

Deutsche Telekom AG Employee Signature

Nein Nein Nein Ja Nein

Deutsche Telekom AG Employee Au-thentication

Nein Ja Nein Nein Ja

Deutsche Telekom AG External Work-force Encryption

Nein Nein Nein Ja Nein

Deutsche Telekom AG External Work-force Signature

Nein Nein Nein Ja Nein

Deutsche Telekom AG External Work-force Authentication

Nein Ja Nein Nein Ja

Deutsche Telekom AG Code Signing

Nein Nein Ja Nein Nein

Deutsche Telekom AG Telekom Com-puter

Ja Ja Nein Nein Nein

Deutsche Telekom AG Domain Control-ler

Ja Nein Nein Nein Ja

Deutsche Telekom AG Web Server

Ja Nein Nein Nein Nein

Deutsche Telekom AG VPN Gateway

Ja Nein Nein Nein Nein

Tabelle 7: Zertifikatserweiterungen (hier: Extended Key Usage)

7.1.3 Objektidentifkatoren der Algorithmen

Als Algorithmus kommt ausschließlich RSA mit dem Object Identifier 1.2.840.113549.1.1.1 zum Einsatz.

7.1.4 Namensformen

Die ausgestellten Zertifikate enthalten in jedem Fall die Felder „Issuer Distinguished Name“ und „Subject Distinguished Name“:

Page 54: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 54

Zertifikat Issuer DN Subject DN

Deutsche Telekom AG Employee Encryp-tion

CN=Deutsche Telekom AG Issu-ing CA 01, OU = Trust Center, O = Deutsche Telekom AG, C = DE

E = primäre eMail aus AD, CN =Name Vorname, OU = CID OU = Employee, OU = Person O = DTAG

Deutsche Telekom AG Employee Signa-ture

CN=Deutsche Telekom AG Issu-ing CA 01, OU = Trust Center, O = Deutsche Telekom AG, C = DE

E = primäre eMail aus AD, CN =Name Vorname, OU = CID OU = Employee, OU = Person O = DTAG

Deutsche Telekom AG Employee Authen-tication

CN = Deutsche Telekom AG Issuing CA 02, OU = Trust Center, O = Deutsche Telekom AG, C = DE

E = primäre eMail aus AD, CN =Name Vorname, OU = CID OU = Employee, OU = Person O = DTAG

Deutsche Telekom AG External Workfor-ce Encryption

CN=Deutsche Telekom AG Issu-ing CA 01, OU = Trust Center, O = Deutsche Telekom AG, C = DE

E = primäre eMail aus AD, CN =Name Vorname, OU = CID OU = External Workforce, OU = Person O = DTAG

Deutsche Telekom AG External Workfor-ce Signature

CN=Deutsche Telekom AG Issu-ing CA 01, OU = Trust Center, O = Deutsche Telekom AG, C = DE

E = primäre eMail aus AD, CN =Name Vorname, OU = CID OU = External Workforce, OU = Person O = DTAG

Deutsche Telekom AG External Workfor-ce Authentication

CN = Deutsche Telekom AG Issuing CA 02, OU = Trust Center, O = Deutsche Telekom AG, C = DE

E = primäre eMail aus AD, CN =Name Vorname, OU = CID OU = External Workforce, OU = Person O = DTAG

Deutsche Telekom AG Code Signing

CN = Deutsche Telekom AG Issuing CA 01, OU = Trust Center, O = Deutsche Telekom AG, C = DE

CN = Company OU = OrgUnit, O = Deutsche Telekom AG, C = DE

Deutsche Telekom AG Telekom Compu-ter

CN = Deutsche Telekom AG Issuing CA 03, OU = Trust Center, O = Deutsche Telekom AG, C = DE

CN = DNS Name

Deutsche Telekom AG Domain Controller

CN = Deutsche Telekom AG Issuing CA 03, OU = Trust Center, O = Deutsche Telekom AG, C = DE

CN = DNS Name

Deutsche Telekom CN = Deutsche Telekom AG Issuing CA 01,

CN = Web Server URL OU = Web Server,

Page 55: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 55

AG Web Server OU = Trust Center, O = Deutsche Telekom AG, C = DE

O = Deutsche Telekom AG, C = DE

Deutsche Telekom AG VPN Gateway

CN = Deutsche Telekom AG Issuing CA 02, OU = Trust Center, O = Deutsche Telekom AG, C = DE

CN = NetBiosNamen OU = VPN Gateway, O = Deutsche Telekom AG, C = DE

Tabelle 8: Issuer DN und Subject DN (FMO)

Zusätzlich werden noch bei einigen Zertifikaten Einträge im „Subject Alternative Name“ vorgenommen:

Zertifikat Other Name Principal Name RFC822 Name

Deutsche Telekom AG Employee Encryp-tion

none none E-Mail Adresse

Deutsche Telekom AG Employee Signa-ture

none none E-Mail Adresse

Deutsche Telekom AG Employee Authen-tication

none UPN E-Mail Adresse

Deutsche Telekom AG External Workfor-ce Encryption

none none E-Mail Adresse

Deutsche Telekom AG External Workfor-ce Signature

none none E-Mail Adresse

Deutsche Telekom AG External Workfor-ce Authentication

none UPN E-Mail Adresse

Deutsche Telekom AG Code Signing

none none none

Deutsche Telekom AG Telekom Compu-ter

DNS none none

Deutsche Telekom AG Domain Controller

DNS none none

Deutsche Telekom AG Web Server

DNS none none

Deutsche Telekom none none none

Page 56: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 56

AG VPN Gateway

Tabelle 9: Einträge im Subject Alternative Name

7.1.5 Namensbeschränkungen

Namensbeschränkungen können sich aus dem verwendeten Zeichensatz und/oder Feld-längen ergeben.

7.1.6 Objektidentifikatoren der Zertifizierungsrichtlinien

Die Zertifikate enthalten einen Eintrag “Policy Qualifier”, der die OID der zum Zeitpunkt der Ausstellungen gültigen CP/CPS enthält.

7.1.7 Anwendung von Erweiterungen von Richtlinienbeschränkun-gen

Nicht relevant.

7.1.8 Syntax und Semantik von Policy Qualifiern

Die Zertifikate enthalten einen Eintrag “Policy Qualifier” sowie einen Verweis (URI) auf die zum Zeitpunkt der Ausstellung gültigen CP/CPS. Es ist jeweils die aktuelle CP/CPS hinter-legt. Ältere Versionen werden in entsprechender Ablage (Repository) abgelegt.

7.1.9 Verarbeitung von kritischen Erweiterungen für Zertifizie-rungsrichtlinien

Nicht relevant.

7.2 Sperrlisten-Profil

Ausgegebene Sperrlisten (CRL) enthalten in jedem Fall die folgenden Felder:

Felder Wert

Version X.509 Version 2

Issuer Enthält die Instanz, die die Sperrliste ausgegeben und signierthat.

This update / valid from Ausgabedatum/-zeit der Sperrliste.

Next update Datum und Zeit der nächsten Sperrliste.

Signature Algorithm Algorithmus der zum Signieren der Sperrliste verwendet wurde:

sha1WithRSAEncryption (OID: 1.2.840.113549.1.1.5)

Page 57: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 57

Revoked certificates Liste der gesperrten Zertifikate. Diese beinhaltet die Serien-nummer des gesperrten Zertifikats, sowie das Sperrdatum.

Tabelle 10: CRL Profil: Basiswerte

7.2.1 Versionsnummer

Sperrlisten werden ausschließlich in der Version X.509 Version 2 bereitgestellt.

7.2.2 Sperrlisten- und Sperrlisteneintragserweiterungen

Ausgegebene CRLs enthalten die folgenden “Extension”-Einträge:

Felder Wert

Authority Key Identifier Dieser Eintrag enthält den Key-Hash der ausgebenden Instanz.

CRL Number Eindeutige, aufsteigende Nummer der Sperrliste

CA Version Startwert: 0.0

Next CRL Publish Datum und Zeit der nächsten Sperrlistenveröffentlichung

Tabelle 11: CRL Profil: Extension-Einträge

7.3 OCSP Profil

OCSP (Online Certificate Status Protocol) stellt auf gleichnamigen Protokoll einen Validie-rungsdienst zur Verfügung, mit dessen Hilfe dem Vertrauende Dritten eine zeitgerechte Information zum Sperrstatus von Endteilnehmer-Zertifikaten übermittelt wird. Das OCSP-Zertifikat, ausgestellt von T-Systems, enthält das Attribut „Erweiterter Schlüsselverwen-dung“ mit der OID „1.3.6.1.5.5.7.3.9“ (OCSP noCheck), d.h. das OCSP-Zertifikat wird nicht validiert

7.3.1 Versionsnummern

Es wird die Version der OCSP Spezifikation gemäß RFC 2560 (full profile) unterstützt.

7.3.2 OCSP Erweiterungen

Access Method: OCSP Access (1.3.6.1.5.5.7.48.1).

Fullname CDP: Die jeweiligen Full Name CDP sind in den jeweils zu überprüfenden Zertifi-katen enthalten und können durch eine Applikation aufgerufen werden, siehe auch RFC 5280 Kapitel 4.2.2.1.

Page 58: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 58

8 Konformitätsprüfungen

Die PKI Prozesse werden regelmäßig einer Prüfung unterzogen. In Verantwortung des T-Systems Trust Center Betriebes werden dazu in regelmäßigen Abständen Selbstauf-sichtsmaßnahmen durchgeführt.

Bei Registrierungsinstanzen, die nicht durch das T-Systems Trust Center betrieben wird, ist das Trust Center berechtigt, nach Bedarf spezifische Compliance-Audits durchzuführen, um die Vertrauenswürdigkeit einer Registrierungsinstanz sicherzustel-len. Dies kann folgendes umfassen:

- Die Durchführung eines Compliance-Audits bei einer Registrierungsstelle jeder-zeit nach alleinigem und ausschließlichem Ermessen bei „Gefahr im Verzug“, falls Grund zu der Annahme besteht, dass die überprüfte Stelle Regelungen (insbesondere dieser CP/CPS) und/oder Standards nicht erfüllt hat, bei der Stelle eine Störung oder Kompromittierung stattgefunden hat oder die Stelle ei-ne Handlung begangen oder unterlassen hat, die dazu führte, dass die Störung, die Kompromittierung, die Handlung, der überprüften Stelle eine tatsächliche oder potenzielle Bedrohung der Sicherheit oder Integrität darstellt.

- Das Trust Center ist berechtigt, bei einer Registrierungsstelle „Ergänzende Ri-

sikomanagementüberprüfungen“ aufgrund unvollständiger oder außergewöhnli-cher Ergebnisse eines Compliance-Audit oder als Teil des Gesamt-Risikomanagementprozesses im Rahmen der ordentlichen Geschäftstätigkeit, durchzuführen.

- Die Stellen, die einem Audit, einer Überprüfung oder einer Untersuchung unter-

zogen werden, müssen das Trust Center oder einen beauftragten Dritten unter-stützen, damit so schnell wie möglich die Aufklärung des untersuchten Falles erfol-gen kann.

8.1 Häufigkeit und Umstände von Prüfungen

Compliance-Audits finden in der Regel jährlich oder je nach Bedarf (Kapitel 8) statt und werden auf Kosten der überprüften Stelle durchgeführt. Der Beginn dieser Maßnahme ist mindestens eine Woche vorher schriftlich anzukündigen.

8.2 Identität und Qualifikation von Prüfern

Die Trust Center-spezifischen Compliance-Audits werden von qualifizierten Mitarbeitern der T-Systems oder einem Dritten (z.B. qualifiziertes Unternehmen wie TÜV IT) durchge-führt, die Erfahrung in den Bereichen Public-Key-Infrastructure-Technologie, Sicherheits-Auditing und Verfahren und Hilfsmittel der Informationssicherheit vorweisen können.

8.3 Verhältnis von Prüfer zu Überprüftem

Selbstaufsichtsmaßnahmen werden von dafür qualifizierten T-Systems Mitarbeitern oder unabhängigen Dritten durchgeführt.

Page 59: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 59

8.4 Prüfungsbereiche

Den Umfang der Prüfung legt der Prüfer selbst fest. Zielsetzung der Überprüfung ist die Umsetzung dieses Dokuments. Es sind alle Prozesse zu prüfen, die mit der Lebenszyklus-verwaltung von Zertifikaten in Verbindung stehen:

Identitätsprüfungen der Endteilnehmer,

Zertifikatsbeauftragungsverfahren,

Zertifikatsausstellungsverfahren,

Zertifikatserneuerung/ Re-Zertifizierung (nur TeleSec ServerPass),

Zertifikatssperrungen,

Zutrittsschutz,

Berechtigungs- und Rollenkonzept ,

Einbruchshemmende Maßnahmen,

Personal.

8.5 Mängelbeseitigung

Werden bei einem Audit von T-Systems Mängel oder Fehler festgestellt, wird entschieden, welche Korrekturmaßnahmen zu treffen sind. Der Leiter Trust Center entscheidet zusam-men mit dem Prüfer über geeignete Maßnahmen. Der Leiter Trust Center ist verantwortlich für die Entwicklung eines Maßnahmenplans. Die Umsetzung der Maßnahmen ist in einem wirtschaftlich angemessenen Zeitraum durchzuführen. Bei schweren sicherheitskritischen Mängeln muss innerhalb von 30 Tagen ein Korrekturplan erstellt und die Abweichung in-nerhalb eines wirtschaftlich angemessen Zeitraums behoben werden. Bei weniger schwerwiegenden Defiziten entscheidet der Leiter Trust Center über den Zeitrahmen der Behebung.

8.6 Mitteilung der Ergebnisse

Die Ergebnisse der Prüfung werden in einem vom Prüfer erstellten Bericht dokumentiert und T-Systems übergeben. T-Systems behält sich vor, Ergebnisse bzw. Teilergebnisse zu veröffentlichen.

Page 60: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 60

9 Geschäftliche und rechtliche Angelegenheiten

9.1 Entgelte

Die Entgelte für PKI Services werden in den jeweiligen vertraglichen Vereinbarungen mit dem Auftraggeber festgelegt eine Publikation dieser Entgeltvereinbarungen erfolgt nicht. Es gelten die konzerninternen Geschäftsbedingungen (KIGB) in der jeweils gültigen Fas-sung.

9.1.1 Entgelte für initiale oder erneute Zertifikatsausstellung

Keine Angabe.

9.1.2 Entgelte für den Zugriff auf Zertifikate

Keine Angabe.

9.1.3 Entgelte für Sperrung oder Statusabfragen

Keine Angabe.

9.1.4 Weitere Entgelte

Keine Angabe.

9.1.5 Rückerstattungsregelungen

Keine Angabe.

9.2 Finanzielle Verantwortung

Die finanziellen Verantwortlichkeiten sind in den vertraglichen Regelungen zur Corporate PKI im Konzern Deutsche Telekom geregelt.

9.2.1 Deckungsvorsorge (insurance coverage)

Nicht anwendbar.

Page 61: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 61

9.2.2 Weitere Vermögenswerte

Nicht anwendbar.

9.2.3 Versicherung oder Garantie für Endteilnehmer

Nicht anwendbar.

9.3 Vertraulichkeit von Geschäftsinformationen

Daten von juristischen Personen und Organisationen als Zertifikatsinhabern werden in ei-nem Umfang erhoben und verifiziert, wie es für zur Ausstellung der Teilnehmerzertifikate und zur Sicherstellung des Vertrauens in diese Zertifikate notwendig ist.

Personenbezogene Informationen werden gemäß Bundesdatenschutzgesetz geschützt. Personenbezogene Daten werden Dritten nur dann zugänglich gemacht, insofern dies auf-grund gesetzlicher Anforderungen notwendig bzw. gestattet ist.

9.3.1 Vertraulich zu behandelnde Informationen

Alle in der Corporate PKI verwendeten, verarbeiteten und gespeicherten Informationen über deren Teilnehmer, die nicht unter Abschnitt 2.2 fallen, gelten als vertraulich.

9.3.2 Nicht- vertraulich zu behandelnde Informationen

Alle Daten und Informationen, die in den herausgegebenen Zertifikaten und Sperrlisten enthalten sind oder davon abgeleitet werden können, sind als nicht vertraulich eingestuft.

9.3.3 Verantwortung zum Schutz von vertraulichen Informationen

Trust Center, vertreten durch den Operation Manager für CPKI und den Leiter Trust Center Betrieb.

9.4 Schutz personenbezogener Daten

Es wird gewährleistet, dass personenbezogene Daten bei der elektronischen Übertragung oder während ihres Transports oder ihrer Speicherung auf Datenträger nicht unbefugt gelesen, kopiert, verändert oder entfernt werden können, und dass überprüft und festge-stellt werden kann, an welche Stellen eine Übermittlung personenbezogener Daten durch Einrichtungen zur Datenübertragung vorgesehen ist.

Page 62: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 62

9.4.1 Richtlinie zur Verarbeitung personenbezogener Daten

Die für den Betrieb der Corporate PKI geltenden Datenschutzbestimmungen sind im „Da-tenschutzkonzept für das IV-Verfahren: Public Key Infrastructure der Deutschen Telekom, Corporate PKI“ [DAKOC-PKI] geregelt.

9.4.2 Vertraulich zu behandelnde Daten

Alle in der Corporate PKI verwendeten, verarbeiteten und gespeicherten Informationen über deren Teilnehmer, die nicht unter Abschnitt 2.2 fallen, gelten als vertraulich.

9.4.3 Nicht- vertraulich zu behandelnde Daten

Alle Daten und Informationen, die in den herausgegebenen Zertifikaten und Sperrlisten enthalten sind oder davon abgeleitet werden können, sind als nicht vertraulich eingestuft.

9.4.4 Verantwortung zum Schutz personenbezogener Daten

Trust Center, vertreten durch den Operation Manager für CPKI und den Leiter Trust Center Betrieb.

9.4.5 Einwilligung und Nutzung personenbezogener Daten

Sind personenbezogene Daten für die Leistungserbringung erforderlich, so stimmt der Zer-tifikatsinhaber deren Nutzung im Rahmen des Betriebs der Corporate PKI zu.

Weiterhin können alle Informationen, die als nicht vertraulich gelten und deren Veröffentli-chung nicht explizit widersprochen wurde, veröffentlicht werden.

9.4.6 Offenlegung bei gerichtlicher Anordnung oder im Rahmen ge-richtlicher Beweisführung

Die Corporate PKI wird in der Bundesrepublik Deutschland betrieben. Die Verpflichtung zur Geheimhaltung der vertraulichen Informationen oder personenbezogener Daten entfällt, soweit die Offenlegung kraft Gesetzes oder kraft Entscheidung eines Gerichtes oder einer Verwaltungsbehörde angeordnet worden ist bzw. zur Durchsetzung von Rechtsansprüchen dient. Sobald Anhaltspunkte für die Einleitung eines gerichtlichen oder behördlichen Ver-fahrens bestehen, die zur Offenlegung vertraulicher oder privater Informationen führen könnten, wird die an dem Verfahren beteiligte Vertragspartei die andere Vertragspartei hierüber unter Beachtung der gesetzlichen Bestimmungen informieren.

9.4.7 Andere Umstände einer Offenlegung

Keine Bestimmungen.

Page 63: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 63

9.5 Urheberrechte

Die nachfolgenden Kapitel 9.5.1 bis 9.5.4 gelten für geistige Eigentumsrechte von Endteil-nehmern und ertrauenden Dritten.

9.5.1 Eigentumsrechte an Zertifikaten und Sperrungsinformationen

T-Systems behält sich für die CPKI jegliche geistigen Eigentumsrechte an Zertifikaten, Sperrungs- oder Statusinformationen, öffentlich zugängliche Verzeichnisdienste und Da-tenbanken mit den ihnen enthaltenen Informationen vor. Sofern Zertifikate und deren Inhalte die Herkunft dieser Zertifikatshierarchie vollständig wiedergegeben und nicht verändert werden, erteilt T-Systems die Zustimmung, Zertifikate auf nichtausschließlicher und entgeltfreier Basis zu vervielfältigen und zu publizieren. Unter Vorraussetzung, dass die Nutzung von Sperrungs- oder Statusinformationen und deren Inhalte, die Herkunft dieser Zertifikatshierarchie vollständig wiedergegeben und nicht verändert werden, erteilt T-Systems ihre Zustimmung, Sperrlisten und Statusinformationen auf nichtausschließlicher und entgeltfreier Basis zu vervielfältigen und zu publizieren, ins-besondere an Vertrauende Dritte.

9.5.2 Eigentumsrechte dieser CP/CPS

Dieses Dokument ist urheberrechtlich geschützt, alle geistigen Eigentumsrechte obliegen T-Systems. Jegliche andere Nutzung (z.B. Vervielfältigung, Verwendung von Texten und Bildern, Änderung oder Erzeugung eines vergleichbaren oder abgeleiteten Dokuments, Weitergabe an Personen ohne Interesse an dem in diesem Dokument beschriebenem Dienst), auch auszugsweise, bedarf der vorherigen ausdrücklichen schriftlichen Genehmi-gung des Herausgebers dieses Dokuments.

9.5.3 Eigentumsrechte an Namen

Der Endteilnehmer behält, sofern zutreffend, alle Rechte an Namen oder Marken, die im Zertifikat enthalten sind, sofern das Zertifikat einen eindeutigen Namen beinhaltet.

9.5.4 Eigentumsrechte an Schlüsseln und Schlüsselmaterial

Die geistigen Eigentumsrechte von Schlüsselmaterial der CA- verbleiben bei T-Systems, ungeachtet des Mediums, auf denen sie gespeichert sind. Kopien von CA- Zertifikate dür-fen vervielfältigt werden um diese in vertrauenswürdige Hardware- und Software-Komponenten zu integrieren. Die geistigen Eigentumsrechte an den Zertifikaten und der ARL verbleiben bei T-Systems.

9.6 Verpflichtungen

9.6.1 Verpflichtung der Zertifizierungsstelle(n)

T-Systems verpflichtet sich,

keine wesentlich unrichtigen Angaben im Zertifikaten aufzunehmen, die den Regist-rierungsstellen, die den Zertifikatsauftrag genehmigen oder das Zertifikat ausstel-len, bekannt sind oder von ihnen stammen,

Page 64: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 64

dass keine Fehler in Zertifikaten enthalten sind, die vom Personal der Registrie-rungsstellen, die den Zertifikatsauftrag genehmigen oder das Zertifikat ausstellen, gemacht wurden und auf unsachgemäße und sorglose Zertifikatserzeugung und Verwaltung zurück zu führen sind,

dass alle Zertifikate den wesentlichen Anforderungen dieses Dokuments genügen und dass die Sperrfunktionalitäten und die Nutzung der CA-Datenbank (Verzeich-nisdienst, OCSP-Responder) allen wesentlichen Anforderungen der geltenden CP/CPS erfüllen.

9.6.2 Verpflichtung der Registrierungsstellen

Alle Registrierungsstellen verpflichten sich:

keine wesentlich unrichtigen Angaben in Zertifikaten aufzunehmen, die den Regist-rierungsstellen, die den Zertifikatsauftrag genehmigen oder das Zertifikat ausstel-len, bekannt sind oder von ihnen stammen,

dass keine Fehler in Zertifikaten enthalten sind, die vom Personal der Registrie-rungsstellen, die den Zertifikatsauftrag genehmigen oder das Zertifikat ausstellen, gemacht wurden und auf unsachgemäße und sorglose Zertifikatserzeugung und Verwaltung zurück zu führen sind,

die rechtlichen Konsequenzen zu tragen, die durch die Nichteinhaltung der be-schriebenen Pflichten entstehen, dass alle Zertifikate den wesentlichen Anforde-rungen dieses Dokuments genügen.

9.6.3 Verpflichtung des Zertifikatsinhabers

Zertifikatsinhaber verpflichten sich,

ihren privaten Schlüssel vor unberechtigtem Zugriff durch Dritte zu schützen. Im Falle von privaten Schlüsseln von juristischen Personen erfolgt der Schutz durch autorisierte Personen,

das Endteilnehmer-Zertifikat nur bestimmungsgemäß und nicht missbräuchlich zu benutzen,

dass das Zertifikat gültig (nicht abgelaufen und nicht gesperrt ) verwendet wird,

zu überprüfen, dass die im Endteilnehmer-Zertifikat aufgenommenen Zertifikatsin-halte des Subject-DN der Wahrheit entsprechen. Im Falle von juristischen Perso-nen erfolgt die Prüfung der Zertifikatsinhalte durch autorisierte Personen,

die rechtlichen Konsequenzen zu tragen, die durch die Nichteinhaltung der vorlie-genden CP/CPS beschriebenen Pflichten entstehen,

bei Verlust oder Verdacht der Kompromittierung des geheimen Schlüssels eine Sperrung des entsprechenden Endteilnehmer-Zertifikat zu veranlassen bzw. selbst durchzuführen,

dass das ausgestellte Zertifikat ausschließlich für autorisierte und legale Zwecke die, diesem CPS entsprechen, verwendet wird und nicht den Regelungen dieser Erklärung widersprechen,

Page 65: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 65

dass alle, im Zertifikats-Auftrag gemachten Angaben, die zur Ausstellung des Zerti-fikats führten, der Wahrheit entsprechen,

dass der Endteilnehmer tatsächlich ein Endteilnehmer ist und mit seinem privaten Schlüssel, dem der im Zertifikat enthaltene öffentliche Schlüssel zugeordnet ist, keine CA-Funktionalitäten durchführt wie z.B. Signatur von Zertifikaten oder Sperr-listen.

dass Endteilnehmer-Zertifikat unverzüglich zu sperren und damit als ungültig zu er-klären, wenn die Zertifikatsangaben nicht mehr stimmen, der private Schlüssel ab-handen gekommen ist, gestohlen wurde, eine Kompromittierung vorliegt, oder ein sonstiger Unbefugte Nutzung vermutet wird.

Hinweis: T-Systems behält sich vor, weiteren Pflichten, Zusicherungen, Zusagen und Ge-währleistungen gegenüber dem Endteilnehmers abzuschließen.

9.6.4 Verpflichtung der Zertifikatsprüfer (Relying Party)

Vertrauende Dritte müssen selbst über hinreichende Informationen und Kenntnisse verfü-gen, um den Umgang mit Zertifikaten und dessen Validierung bewerten zu können. Der Vertrauende Dritte ist selbst für seine Entscheidungsfindung verantwortlich, ob die die zur Verfügung gestellten Informationen zuverlässig und vertrauensvoll sind.

9.6.5 Verpflichtung anderer Teilnehmer

Keine Bestimmungen.

9.7 Gewährleistung

Gewährleistungsansprüche werden einzelvertraglich mit dem Auftraggeber geregelt.

9.8 Haftungsbeschränkungen

Die Haftung für Schäden, die auf einer Verletzung von Pflichten beruhen werden in den konzerninternen Geschäftsbedingungen der Deutschen Telekom (KIGB) oder einzelver-traglich geregelt.

9.9 Haftungsfreistellungen

Haftungsfreistellungen werden in den konzerninternen Geschäftsbedingungen der Deut-schen Telekom (KIGB) oder einzelvertraglich geregelt.

Page 66: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand 15.06.2011 66

9.10 Laufzeit und Beendigung

9.10.1 Inkrafttreten

Dieses Dokument tritt sechs Wochen nachdem es über den entsprechenden Informations-dienst veröffentlicht wurde (siehe Kapitel 2.2) in Kraft. Für den Fall, dass die Veröffentli-chung einen anderen Zeitraum vorsieht, gilt ausschließlich dieser.

9.10.2 Aufhebung

Dieses Dokument verliert seine Gültigkeit mit dem Inkrafttreten einer neuen Version oder wenn der Betrieb der Corporate PKI eingestellt wird.

9.10.3 Konsequenzen der Aufhebung

Bei der Beendigung des Dienstes TeleSec ServerPass bleiben alle Benutzer an die, in der CP/CPS enthaltenen Regelungen gebunden, bis das letzte ausgegebene Zertifikat seine Gültigkeit verliert oder gesperrt wird.

.

9.11 Individuelle Benachrichtigung und Kommunikation mit Teil-nehmern

Für individuelle Mitteilungen und Absprachen mit den Zertifizierungsstellen werden die jeweils gültigen Kontaktinformationen (Anschrift, E-Mail etc.) bekannt gegeben. Außerdem ist eine Kontaktaufnahme über Helpdesk möglich:

GHS und T-Home

Kontakt: Mo-Sa 07.00 - 20.00 Uhr 0181-330-7877678 0181-330-SUPPORT

T-Systems

Telefon national: TSIHELP 0800 874 4357 Telefon international (für deutsche Travelling User): +49 391 555 1195 Fax: TSIFAXE (0800 874 3293)

Intranet http://tsihelp.telekom.de

T-Mobile

Telefon national:

(08 00) 9 36 16 99

Fax:

(08 00) 1 33 66 66

Page 67: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 67

9.12 Änderungen/Anpassungen der Richtlinie

Um auf sich ändernde Marktanforderungen, Sicherheitsanforderungen, Gesetzeslagen etc. zu reagieren, behält sich T-Systems das Recht vor, Änderungen und Anpassungen dieses Dokuments durchzuführen.

9.12.1 Vorgehen bei Änderungen/Anpassungen

Änderungen des CP/CPS gelten von dem Moment an, in dem sie in Kraft treten. Das CP/CPS tritt innerhalb von sechs Wochen nach Veröffentlichung der Änderungen in Kraft, außer für den Fall, dass die Veröffentlichung einen anderen Zeitraum vorsieht.

Falls das T-Systems Change Advisory Board der Ansicht ist, dass gravierende z.B. si-cherheitsrelevante Änderungen unverzüglich erforderlich sind, dann tritt die neue Doku-mentversion unverzüglich mit der Veröffentlichung in Kraft.

Änderungen des CPS können nur von T-Systems Change Advisory Board durchgeführt werden. Bei jeder Änderung des CPS wird deren Versionsnummer und Datum erneuert.

9.12.2 Benachrichtigungsmechanismus und Fristen

Die im Zusammenhang mit einzelvertraglichen Regelungen benannten Ansprechpartner werden über Änderungen informiert und erhalten Gelegenheit innerhalb von sechs Wo-chen Widerspruch einzulegen. Erfolgen keine Widersprüche, dann tritt die neue Doku-mentenversion nach Ablauf der Frist in Kraft. Darüber hinaus gehende Ansprüche auf die Benachrichtigung einzelner Endanwender sind explizit ausgeschlossen.

9.12.3 Notwendigkeit der Änderung des Richtlinienbezeichners (OID)

Im Falle sicherheitsrelevanter Änderungen an diesem Dokument vorgenommen, ist eine Änderung der OID erforderlich, andere Änderungen können davon unberührt erfolgen.

9.13 Regelung von Unstimmigkeiten

Im Fall von Unstimmigkeiten ist von den Parteien ein Eskalationsverfahren durchzuführen. Für die Konfliktbeilegung ist die in Kapitel 1.5.2Fehler! Verweisquelle konnte nicht ge-funden werden. genannte Stelle zuständig.

Page 68: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 68

9.14 Geltendes Recht

Der Betrieb der Corporate PKI unterliegt den Gesetzen der Bundesrepublik Deutschland und ist konform zu diesen aufgebaut.

9.15 Konformität mit geltendem Recht

Das vorliegende Dokument unterliegt den geltenden deutschen Gesetzen, Vorschriften, Richtlinien, Verordnungen, Erlassen und Anordnungen, insbesondere den darin beschrie-benen Import und Export Bestimmungen von Security-Komponenten (Software, Hardware oder technischer Informationen). Geltende zwingende Gesetze, Vorschriften, Richtlinien, Verordnungen, Erlasse und Anordnungen setzen die entsprechenden Bestimmungen des vorliegenden Dokuments außer Kraft.

9.16 Weitere Regelungen

9.16.1 Vollständiger Vertrag

Nicht anwendbar.

9.16.2 Abtretung der Rechte

Nicht anwendbar.

9.16.3 Salvatorische Klausel

Sollte eine Bestimmung dieses CP/CPS unwirksam oder undurchführbar sein oder wer-den, so berührt dies die Wirksamkeit dieser Erklärung im Übrigen nicht. Statt der unwirk-samen und undurchführbaren Bestimmung gilt eine solche Bestimmung als vereinbart, die dem wirtschaftlichen Zweck dieses Dokuments in rechtswirksamer Weise am nächsten kommt. Das Gleiche gilt für die Ergänzung etwaiger Vertragslücken.

9.16.4 Rechtliche Auseinandersetzungen /Erfüllungsort

Es gilt das Recht der Bundesrepublik Deutschland. Erfüllungsort und ausschließlicher Gerichtsstand ist Frankfurt am Main.

Page 69: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 69

9.16.5 Höhere Gewalt

Mit dieser Regelung soll sichergestellt werden, dass der Vertragspartner mit seinen End-teilnehmern vereinbart, dass er nicht in Verzug gerät, wenn sich die Leistung infolge hö-herer Gewalt verzögert oder unmöglich wird.

9.17 Andere Regelungen

Nicht anwendbar.

Page 70: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 70

A Mitgeltende Unterlagen

[BDSG] Datenschutzgesetz, Bundesgesetzblatt I 2003 S.66.

[EU-RL] Richtlinie des Europäischen Parlaments und des Rates über gemeinschaftliche Rahmen-bedingungen für elektronische Signaturen, 1999/93/EG, EU, 1999

[PKCS] RSA Security Inc., RSA Laboratories „Public Key Cryptography Standards“, http://www.rsasecurity.com/rsalabs

[PKIX] RFCs und Spezifikationen der IETF Arbeitsgruppe Public Key Infrastructure (X.509)

[SigG] Gesetz über Rahmenbedingungen für elektronische Signaturen und zur Änderung von weiteren Vorschriften, Bundesgesetzblatt I 2001, S. 876

[SigV] Signaturgesetzverordnung, „Verordnung zur elektronischen Signatur“, BGBl. I S. 3074, 21.November 2001

[X.509] Information technology - Open Systems Interconnection - The Directory:authentication framework, Version 3, ITU, 1997

[DTA-01] DTA-01-SLA_parameters_and_Harmonised_SLA-0708027-SEA, internes Dokument

[DAKOC-PKI] Datenschutzkonzept für das IV-Verfahren Public Key Infrastructure der Deutschen Tele-kom: 091214_Datenschutzkonzept_C-PKI_v10.

[1999/93/EG] EG Signaturrichtlinie, definiert die Vorgaben für die Regelungen elektronischer Signatu-ren, die durch die Mitgliedstaaten und die anderen Staaten des Europäischen Wirt-schaftsraumes in nationalen Gesetzen umgesetzt wurden.

Page 71: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 71

Abkürzungsverzeichnis

Abkürzung Beschreibung

ARL (Authority Revocation List)

Liste, in der gesperrte digitale Zertifikate von Zertifizierungsstellen auf-geführt sind. Vor der Verwendung eines digitalen Zertifikats einer Zerti-fizierungsstelle sollte anhand der ARL überprüft werden, ob dieses noch verwendet werden darf.

C Bestandteil des DN: Name (engl.:Country)

CA (Certifica-tion Authority)

Zertifizierungsstelle: Komponente, die digitale Zertifikate ausstellt, in-dem sie einen Datensatz bestehend aus öffentlichem Schlüssel, Name und verschiedenen anderen Daten digital signiert. Ebenso werden von der Zertifizierungsstelle Sperrinformationen herausgegeben

CN Bestandteil des DN: Name (engl.: Common Name)

CP (Certificate Policy)

Legt die Richtlinien für die Generierung und Verwaltung von Zertifika-ten eines bestimmten Typs fest.

CRL (Certifica-te Revocation List)

Sperrliste: Liste, in der gesperrte digitale Zertifikate aufgeführt sind. Vor der Verwendung eines digitalen Zertifikats sollte anhand einer Sperrliste überprüft werden, ob dieses noch verwendet werden darf.

CPS (Certifica-tion Practice Statement)

Erklärungen für den Betrieb einer Zertifizierungsstelle. Insbesondere setzt das CPS die Vorgaben und Richtlinien der CP einer Zertifizie-rungsstelle um.

Chipkarte Plastikkarte mit integriertem Computerchip. Ist der Computerchip dazu in der Lage, Berechnungen durchzuführen, so spricht man auch von einer Smartcard. Smartcards können auch für kryptographische An-wendungen eingesetzt werden.

DN Eindeutiger Name des Zertifikatinhabers oder -ausstellers eines Zertifi-kats. Ein DN wird aus mehreren Bestandteilen, wie C, O, OU, CN, ge-bildet. (engl.: Distinguished Name)

Digitale Signa-tur oder Elekt-ronische Sig-natur

Mit einem speziellen mathematischen Verfahren erstellte Prüfsumme. Sichert die Authentizität des Signierenden und die Integrität der Daten.

Digitales Zerti-fikat

Datensatz, der den Namen einer Person oder eines Systems, deren öffentlichen Schlüssel, gegebenenfalls einige andere Angaben und eine Signatur einer Zertifizierungsinstanz enthält.

DN (Distingu-ished Name)

Format, mit dem gemäß dem X.500-Standard eindeutige Namen an-gegeben werden können. In einem digitalen Zertifikat muss ein DN enthalten sein.

HSM (Hard-ware Security Modul)

Hardwarebox zur sicheren Erzeugung und Speicherung privater Schlüssel.

Page 72: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 72

Hash-Wert In diesem Zusammenhang eine kryptografische Prüfsumme fester Länge (die korrekte Bezeichnung wäre kryptografischer Hashwert). Es soll möglichst unwahrscheinlich sein, aus dem Hashwert die Eingabe berechnen oder mehrere mögliche Eingaben zu dem gleichen Hash-wert finden zu können (Hashwert wird synonym zu Fingerprint verwen-det). Statt einem gesamten digitalen Dokument wird meist nur ein Hashwert signiert.

ISIS-MTT Gemeinsame Spezifikation von TeleTrust und T7 Gruppe für elektroni-sche Signaturen, Verschlüsselung und Public Key Infrastrukturen, die neue Bezeichnung lautet Common-PKI.

Key Recovery Mechanismus zur Schlüsselwiederherstellung. Diese kann notwendig sein, wenn ein Benutzer seinen Schlüssel (etwa durch eine beschädig-te Datei) verliert.

Kompromittie-rung

Ein geheimer Schlüssel ist kompromittiert, wenn er Unbefugten be-kannt geworden ist oder von diesen genutzt werden kann. Eine Kom-promittierung kann etwa die Folge eines kriminellen Angriffs sein.

Kryptografie Wissenschaft, die sich mit der Verschlüsselung von Daten und ver-wandten Themen beschäftigt (etwa digitale Signatur).

LDAP Siehe: Lightweight Directory Access Protocol.

LDAP-Server Server, der Informationen speichert, die über LDAP abrufbar sind.

Lightweight Directory Ac-cess Protocol

Protokoll zur Abfrage von Verzeichnissen, welches das deutlich kom-pliziertere Directory Access Protocol (DAP) in vielen Bereichen ver-drängt hat. LDAP bietet mehr Möglichkeiten als HTTP und FTP (etwa das Einrichten eines Kontexts, der über mehrere Anfragen aufrechter-halten werden kann). LDAP wird insbesondere zur Abfrage von digita-len Zertifikaten und Sperrlisten innerhalb von Public-Key-Infrastrukturen verwendet.

Mail-Request Variante eines Zertifikatsauftrags, bei dem die Daten per E-Mail an die Zertifizierungsinstanz übermittelt werden.

O Bestandteil des DN: Organisation

OID Objekt Identifier eindeutige Referenz auf ein Objekt in einem Namens-raum

OU Bestandteil des DN: Organisationseinheit (engl.: Organizational Unit)

OCSP Das Online Certificate Status Protocol ermöglicht die Online-Abfrage der Gültigkeit von Zertifikaten.

PIN (Personal Identification Number)

Geheimzahl, wie sie zum Beispiel am Geldautomaten verwendet wird.

PKCS Serie von kryptografischen Spezifikationen (engl.: Public Key Cryp-tography Standard

PKCS#7 Datenaustauschformat zur Übermittlung von Signaturen und ver-schlüsselten Daten oder auch zum Austausch von Zertifikaten

PKCS#10 Datenaustauschformat zur Übersendung des öffentlichen Schlüssels und des DN eines Zertifikatantrags an eine CA

PKCS#12 Datenaustauschformat zur Speicherung von privatem und öffentlichem Schlüssel, deren Absicherung mit einem Passwort auf Basis eines symmetrischen Verschlüsselungsverfahrens erfolgt

Page 73: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 73

PKI (Public-Key-Infrastructure)

Gesamtheit der Komponenten, Prozesse und Konzepte, die zur Ver-wendung von Public-Key-Verfahren verwendet werden. Typischerwei-se besteht eine Public-Key-Infrastruktur aus zentralen Komponenten wie einer Zertifizierungsinstanz und einem Verzeichnisdienst und ver-schiedenen Client-Komponenten..

PKI-X.509 Public Key Infrastructure X.509. Standard der IETF, der alle relevanten Bestandteile einer PKI standardisiert.

PN Kennzeichen im CN: Pseudonyme

Policy Richtlinien, die das Sicherheitsniveau für die Erzeugung und Verwen-dung von Zertifikaten festlegen. Es wird zwischen Certificate Policy (CP) und Certification Practice Statement (CPS) unterschieden.

Privater Schlüssel

Schlüssel eines kryptographischen Schlüsselpaares, welcher nur dem Eigentümer zugänglich ist. Ein privater Schlüssel kann zur Erzeugung von elektronischen Signaturen verwendet werden (engl.: private key)

PSE (Personal Security Envi-ronment)

In der persönlichen Sicherheitsumgebung sind sicherheitsrelevante Informationen wie der private Schlüssel gespeichert. Das PSE kann als verschlüsselte Datei oder auf einer Smartcard vorliegen und ist durch ein Passwort bzw. eine PIN geschützt.

RA (Registra-tion Authority)

Registrierungsstelle. Komponente, mit der eine Person oder ein Sys-tem kommunizieren muss, um ein digitales Zertifikat zu erhalten.

Registrierung Vorgang, bei dem eine RA einen Zertifikatsantrag prüft und an die zu-ständige CA weiterleitet.

Rezertifizie-rung

Ausstellung eines neuen Zertifikates unter Beibehaltung des entspre-chenden Schlüsselpaares (z.B. nach Ablauf der Gültigkeit)

Root CA Siehe Wurzelzertifizierungsstelle.

RSA Verfahren zur Verschlüsselung, zur digitalen Signatur und zur sicheren Übertragung von Schlüsseln, das nach den drei Kryptografen Rivest, Shamir und Adleman benannt ist.

SCEP (Simple Certificate En-rollment Proto-col)

Protokoll zur Beauftragung und zum Laden von Zertifikaten in IPSec Devices.

SigG Deutsches Signaturgesetz

SigV Signaturverordnung

Single Key Variante, bei der für Verschlüsselung und Signatur dasselbe Schlüs-selpaar verwendet wird, das heißt, ein Benutzer besitzt ein Zertifikat.

Smart Card Chipkarte mit Rechenfunktionalität, die für kryptografische Zwecke verwendet werden kann.

SOAP (Simple Object Access Protocol)

SOAP stellt einen einfachen Mechanismus zum Austausch von struk-turierter Information zwischen Anwendungen in einer dezentralisierten, verteilten Umgebung zur Verfügung.

Soft(ware)-PSE

Durch Verschlüsselung geschützte Datei zur Speicherung des privaten Schlüssels eines Benutzers.

Sperrantrag Wenn ein Zertifikat vor Ablauf der Gültigkeit für ungültig erklärt werden soll, muss ein Sperrantrag ausgefüllt werden.

Sperrinstanz Komponente, die Zertifikatssperrungen durchführt.

Page 74: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 74

Sperrliste Liste, in der gesperrte digitale Zertifikate aufgeführt sind. Vor der Ver-wendung eines digitalen Zertifikats sollte anhand einer Sperrliste über-prüft werden, ob dieses noch verwendet werden darf. Wird auch als Certificate Revocation List (CRL) bezeichnet.

Verzeichnis-dienst

Datenspeicher, der den Abruf von Zertifikaten und Informationen über Zertifikate (insbesondere Sperrlisten) ermöglicht, z.B. LDAP-Server

Web-Request Variante eines Zertifikatsauftrags, bei dem die Daten über ein Web-Formular an die Zertifizierungsinstanz übermittelt werden.

Wurzelzertifi-zierungsstelle

Oberste Zertifizierungsinstanz einer CA-Hierarchie, deren Zertifikat somit nicht von einer anderen Zertifizierungsinstanz ausgestellt wurde, sondern selbstsigniert ist.

X.509 Standard, dessen wichtigster Bestandteil ein Format für digitale Zertifi-kate ist. Zertifikate der Version X.509v3 werden in allen gängigen Pub-lic-Key-Infrastrukturen unterstützt.

Zertifikatantrag Dokument in Papierform oder elektronisch, mit dem bei einer CA die Ausstellung eines Zertifikates beantragt wird. Er beinhaltet den Namen des Antragstellers, den gewünschten DN im Zertifikat sowie den öffent-lichen Schlüssel.

Zertifikatsin-haber

Instanz, die ein Zertifikat und den dazu gehörenden privaten Schlüssel verwendet.

Zertifizie-rungsstelle

Komponente, die digitale Zertifikate ausstellt, indem sie einen Daten-satz bestehend aus öffentlichem Schlüssel, Name und verschiedenen anderen Daten digital signiert. Ebenso werden von der Zertifizierungs-stelle Sperrinformationen herausgegeben.

Zuständig-keitsbereich

Teilbereich in der CA Administrationshierarchie, der von einem RA Operator verwaltet wird.

Page 75: IEI Corporate PKI Certificate Policy (CP) & Certification ...corporate-pki.telekom.de/cps/CP-CPS_CorpPKI_FMO.pdf · IEI Corporate PKI Certificate Policy (CP) & Certification Practice

T-Systems, Stand:01.07.2011 75

Änderungshistorie / Release Notes

Version Stand Autor/Bearbeiter Änderungen/Kommentar

0.1 14.02.2008 Ch. Rösner First draft

0.1a 11.03.2008 S. Kölsch Changes for RFC 3647-conformity

0.1b 18.03.2008 S. Kölsch Changes for European Bridge CA

0.2 25.03.2008 S. Kölsch English headlines, new Corporate Design

0.3 28.05.2008 S. Kölsch added Remarks for European BridgeCA-conformity after meeting with ChR, TP.

0.4 07.10.2008 S. Kölsch General changes

0.5 10.10.2008 S. Kölsch Revised version, first official draft

0.6 23.12.2009 J. Portaro Completion for coordination and formal re-lease

0.7 02.04.2010 K. Kirchhöfer

T. Pfeifer

J. Portaro

M. Dornhöfer

Additions

0.8 22.06.2010 M. Dornhöfer Änderung der Überschriften auf Englisch, C-PKI Ausbaustufe1 (CMO)

0.9 23.06.2010 M. Dornhöfer C-PKI Ausbaustufe 2 (FMO)

0.91 15.07.2010 J. Portaro Trennung CPS Dokumente für CMO und FMO

0.99 24.11.2010 J. Portaro

K.-H. Rödel

Prüfung und Bearbeitung offener Punkte