OS Corporate PKI Certificate Policy (CP) & Certification Practice Statement (CPS)

Transkript

1 OS Corporate PKI Certificate Policy (CP) & Certification Practice Statement (CPS) T-Systems International GmbH Version 1.0 Stand Status freigegeben Autor Ch. Rösner, S. Kölsch, J. Portaro, M. Dornhöfer Geheimhaltungsvermerk: öffentlich

2 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 Einrichtungen, vorbehalten. Herausgeber T-Systems International GmbH PRODUCTION CSS PSS Untere Industriestraße 20, Netphen Dateiname CP-CPS_CorpPKI_v1 0_(CMO) Version 1.0 Dokumentennummer Dokumentnummer: Datei > Eigenschaften Stand Dokumentenbezeichnung CP_CPS_CorpPKI_V1.0_(CM O) Status freigegeben Autor Ch. Rösner, S. Kölsch, J. Portaro, M. Dornhöfer Ansprechpartner Klaus Jungbluth Inhaltlich geprüft von Klaus Jungbluth Netphen im Juni 2011 Telefon / Fax Freigegeben von Klaus Jungbluth Netphen im Juni klaus.jungbluth@tsystems.com Kurzinfo In dem vorliegenden Dokument sind CP und CPS für die Corporate PKI in der Ausbaustufe 1 bzw. des Release 2.4 im Rahmen des Projekts Office Standardization (OS) zusammengefasst. Es beschreibt das für den Betrieb der Corporate PKI erforderliche Sicherheitsniveau und beinhaltet Sicherheitsvorgaben sowie Erklärungen hinsichtlich technischer, organisatorischer und rechtlicher Aspekte. Das Dokument orientiert sich an den dem internationalen Standard für Zertifizierungsrichtlinien RFC 3647 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework der Internet Society.

3 Inhaltsverzeichnis 1 Einleitung Überblick Dokumentenname und Identifikation PKI Teilnehmer Zertifizierungsstellen Registrierungsstellen Zertifikatsinhaber Zertifikatsprüfer (Relying Parties) Weitere Teilnehmer Anwendungsbereich Geeignete Zertifikatsnutzung Untersagte Zertifikatsnutzung Verwaltung der Zertifizierungsrichtlinie Änderungsmanagement Ansprechpartner Eignungsprüfer für Regelungen für den Zertifizierungsbetrieb (CPS) gemäß Zertifizierungsrichtlinie Verfahren zur Anerkennung von Regelungen für den Zertifizierungsbetrieb (CPS) Definitionen und Abkürzungen Veröffentlichungen und Verzeichnisdienst Verzeichnisdienste (Repositories) Veröffentlichung von Zertifikatsinformationen Aktualisierung der Informationen (Zeitpunkt, Frequenz) Zugangskontrolle zu Verzeichnisdiensten (Repositories) Identifikation und Authentifikation Namen Namensformen Aussagekraft von Namen Anonymität bzw. Pseudonyme für Zertifikatsinhaber Regeln zur Interpretation verschiedener Namensformate Eindeutigkeit von Namen Anerkennung, Authentifizierung und Funktion von Warenzeichen Identitätsprüfung bei Neuantrag Nachweis des Besitzes des privaten Schlüssels Authentifizierung einer Organisation Authentifizierung einer natürlichen Person Nicht überprüfte Teilnehmerangaben Überprüfung der Berechtigung Interoperabilitätskriterien Identifizierung und Authentifizierung bei einer Zertifikatserneuerung Routinemäßige Zertifikatserneuerung Zertifikatserneuerung nach einer Sperrung Identifizierung und Authentifizierung von Sperraufträgen Ablauforganisation (Zertifikatslebenszyklus) Zertifikatsantrag Wer kann Zertifikate beantragen Verfahren und Verantwortungen Bearbeitung von Zertifikatsanträgen Durchführung von Identifikation und Authentifizierung Annahme oder Ablehnung von Zertifikatsanträgen Zeit zur Verarbeitung von Zertifikatsaufträgen Zertifikatserstellung Aufgaben der Zertifizierungsstelle... 4 T-Systems, Stand:

4 4.3.2 Benachrichtigung des Antragstellers Akzeptanz der Zertifikate Annahme von Zertifikaten Veröffentlichung der Zertifikate durch die Zertifizierungsstelle Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle Schlüssel- und Zertifikatsverwendung Nutzung durch den Zertifikatsinhaber Nutzung des Zertifikats durch die Relying Party Zertifikatserneuerung unter Beibehaltung des alten Schlüssels (Re- Zertifizierung) Gründe für eine Zertifikatserneuerung Wer kann eine Zertifikatserneuerung beantragen? Ablauf der Zertifikatserneuerung Benachrichtigung des Antragstellers nach Zertifikatserneuerung Annahme einer Zertifikatserneuerung Veröffentlichungen der erneuerten Zertifikate durch die Zertifizierungsstelle Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle Schlüssel- und Zertifikatserneuerung (Re-key) Gründe für eine Schlüssel- und Zertifikatserneuerung Wer kann eine Schlüssel- und Zertifikatserneuerung beantragen? Ablauf der Schlüssel- und Zertifikatserneuerung Benachrichtigung des Zertifikatsinhabers Annahme der Schlüssel- und Zertifikatserneuerung Veröffentlichung einer Zertifikatserneuerung durch die Zertifizierungsstelle Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle Zertifikatsmodifizierung Gründe für die Modifikation eines Zertifikates Wer kann eine Modifikation eines Zertifikates beantragen? Ablauf der Zertifikatsmodifizierung Benachrichtigung des Zertifikatsinhabers Annahme der Zertifikatsmodifizierung Veröffentlichung einer Zertifikatsmodifizierung durch die Zertifizierungsstelle Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle Widerruf/Sperrung und Suspendierung von Zertifikaten Gründe für Widerruf/Sperrung Wer kann Widerruf/ Sperrung beantragen? Ablauf von Widerruf / Sperrung Fristen für den Zertifikatsinhaber Bearbeitungsfristen für die Zertifizierungsstelle Anforderung zu Sperrprüfungen durch eine Relying Party Häufigkeit der Sperrlistenveröffentlichung Maximale Latenzzeit für Sperrlisten Verfügbarkeit von Online-Statusabfragen (OCSP) Anforderungen an Online-Statusabfragen (OCSP) Andere Formen der Veröffentlichung von Sperrinformationen Anforderungen bei Kompromittierung von privaten Schlüsseln Gründe für eine Suspendierung Wer kann eine Suspendierung beantragen? Ablauf einer Suspendierung Maximale Suspendierungsdauer Statusabfrage von Zertifikaten (OCSP, CRL Betriebsbedingte Aspekte Verfügbarkeit Weitere Merkmale Beendigung des Vertragsverhältnisses Schlüsselhinterlegung und wiederherstellung (Key Escrow, Key Recovery) Richtlinien und Praktiken zur Schlüsselhinterlegung und wiederherstellung Richtlinien und Praktiken zum Schutz und Wiederherstellung von Sitzungsschlüsseln Infrastrukturelle, organisatorische und personelle Sicherheitsmaßnahmen... 4 T-Systems, Stand:

5 5.1 Infrastrukturelle Sicherheitsmaßnahmen Einsatzort und Bauweise Räumlicher Zugang Energieversorgung und Klimatisierung Wassergefährdung Brandschutz Aufbewahrung und Entsorgung von Datenträgern Externe Datensicherung Organisatorische Sicherheitsmaßnahmen Rollen Anzahl der pro Aufgabe involvierten Personen Identifizierung und Authentifizierung jeder Rolle Rollen, die eine Aufgabentrennung erfordern Personelle Sicherheitsmaßnahmen Anforderungen an Personal Sicherheitsüberprüfung von Personal Schulungsanforderungen Häufigkeit und Anforderungen an Fortbildungen Häufigkeit und Ablauf von Arbeitsplatzwechseln Sanktionen bei unerlaubten Handlungen Anforderungen an unabhängige, selbständige Zulieferer Dokumentation für Mitarbeiter Überwachung / Protokollierung Überwachte Ereignisse Bearbeitungsintervall der Protokolle Aufbewahrungsfrist für Log-Dateien Schutz von Log-Dateien Backup von Log-Dateien Überwachungssystem (intern / extern) Benachrichtigung bei schwerwiegenden Ereignissen Schwachstellenanalyse Archivierung Archivierte Daten Aufbewahrungsfrist für archivierte Daten Schutz der Archive Archivbackup Anforderungen an Zeitstempel Archivierungssystem (intern / extern) Abruf und Verifikation von archivierten Informationen Schlüsselwechsel der Zertifizierungsstelle Kompromittierung und Desaster Recovery Vorgehen bei Sicherheitsvorfällen und Kompromittierung Betriebsmittel, Software und/oder Daten wurden kompromittiert Kompromittierung des privaten Schlüssels Betriebswiederaufnahme nach einem Notfall Einstellung des Betriebs Technische Sicherheitsmaßnahmen Schlüsselerzeugung und installation Schlüsselerzeugung Übergabe des privaten Schlüssels an Zertifikatsinhaber Übergabe des öffentlichen Schlüssels an den Zertifikatsherausgeber Publikation öffentlicher Schlüssel der Zertifizierungsstelle Schlüssellängen Erzeugung der Public Key Parameter und Qualitätssicherung Schlüsselverwendungzwecke (nach X.509 v3, Attribut key usage ) Schutz von privaten Schlüsseln und Einsatz von Kryptomodulen Standard kryptographischer Module Aufteilung privater Schlüssel auf mehrere Personen (n-aus-m) Hinterlegung privater Schlüssel Backup privater Schlüssel... 4 T-Systems, Stand:

6 6.2.5 Archivierung des privaten Schlüssels Transfer eines privaten Schlüssels in oder aus einem Kryptomodul Ablage privater Schlüssel in Kryptomodulen Aktivierung privater Schlüssel Deaktivierung privater Schlüssel Vernichtung privater Schlüssel Güte von Kryptomodulen Weitere Aspekte des Zertifikats- und Schlüsselmanagements Archivierung öffentlicher Schlüssel Gültigkeit von Zertifikaten und Schlüsselpaaren Aktivierungsdaten Generierung und Installation von Aktivierungsdaten Schutz der Aktivierungsdaten Weitere Aspekte der Aktivierungsdaten Computerbezogene Sicherheitskontrollen Spezifische Anforderungen an technische Sicherheits-maßnahen Bewertung der Computersicherheit Technische Maßnahmen im Lebenszyklus Maßnahmen der Systementwicklung Maßnahmen des Sicherheitsmanagements Lebenszyklus der Sicherheitsmaßnahmen Sicherheitsmaßnahmen für das Netzwerk Zeitstempel Zertifikate, CRL und OCSP Profile Zertifikatsprofile Versionsnummern Zertifikatserweiterungen Objektidentifkatoren der Algorithmen Namensformen Namensbeschränkungen Objektidentifikatoren der Zertifizierungsrichtlinien Verwendung von Erweiterungen von Richtlinienbeschränkungen Syntax und Semantik von Policy Qualifiern Verarbeitung von kritischen Erweiterungen für Zertifizierungsrichtlinien Sperrlisten-Profil Versionsnummer Sperrlisten- und Sperrlisteneintragserweiterungen OCSP Profil Versionsnummer OCSP Erweiterungen Konformitätsprüfungen Häufigkeit und Umstände von Prüfungen Identität und Qualifikation von Prüfern Verhältnis von Prüfer zu Überprüftem Prüfungsbereiche Mängelbeseitigung Mitteilung der Ergebnisse Geschäftliche und rechtliche Angelegenheiten Entgelte Entgelte für initiale oder erneute Zertifikatsausstellung Entgelte für den Zugriff auf Zertifikate Entgelte für Sperrung oder Statusabfragen Weitere Entgelte Rückerstattungsregelungen Finanzielle Verantwortung Deckungsvorsorge (insurance coverage) Weitere Vermögenswerte Versicherung oder Garantie für Endteilnehmer Vertraulichkeit von Geschäftsinformationen... 4 T-Systems, Stand:

7 9.3.1 Vertraulich zu behandelnde Informationen Nicht- vertraulich zu behandelnde Informationen Verantwortung zum Schutz von vertraulichen Informationen Schutz personenbezogener Daten Richtlinie zur Verarbeitung personenbezogener Daten Vertraulich zu behandelnde Daten Nicht- vertraulich zu behandelnde Daten Verantwortung zum Schutz personenbezogener Daten Einwilligung und Nutzung personenbezogener Daten Offenlegung bei gerichtlicher Anordnung oder im Rahmen gerichtlicher Beweisführung Andere Umstände einer Offenlegung Urheberrechte Eigentumsrechte an Zertifikaten und Sperrungsinformationen Eigentumsrechte dieser CP/CPS Eigentumsrechte an Namen Eigentumsrechte an Schlüsseln und Schlüsselmaterial Verpflichtungen Verpflichtung der Zertifizierungsstelle(n) Verpflichtung der Registrierungsstellen Verpflichtung des Zertifikatsinhabers Verpflichtung der Zertifikatsprüfer (Relying Party) Verpflichtung anderer Teilnehmer Gewährleistung Haftungsbeschränkungen Haftungsfreistellungen Laufzeit und Beendigung Inkrafttreten Aufhebung Konsequenzen der Aufhebung Individuelle Benachrichtigung und Kommunikation mit Teilnehmern Änderungen/Anpassungen der Richtlinie Vorgehen bei Änderungen/Anpassungen Benachrichtigungsmechanismus und Fristen Notwendigkeit der Änderung des Richtlinienbezeichners (OID) Regelung von Unstimmigkeiten Geltendes Recht Konformität mit geltendem Recht Weitere Regelungen Vollständiger Vertrag Abtretung der Rechte Salvatorische Klausel Rechtliche Auseinandersetzungen /Erfüllungsort Höhere Gewalt Andere Regelungen... 4 A Mitgeltende Unterlagen... 4 B Abkürzungsverzeichnis... 4 C Änderungshistorie / Release Notes... 4 T-Systems, Stand:

8 Abbildungsverzeichnis Abbildung 1: CA-Hierachie der C-PKI... 4 T-Systems, Stand:

9 Tabellenverzeichnis Tabelle 1: Zuordnung der Zertifikate zu den CAs und den jeweiligen CRL Distribution Points (CMO)... 4 Tabelle 2: Zuordnung der Zertifikate zu den CAs und den jeweiligen AIA URIs (CMO)... 4 Tabelle 3: Schnittstellen zur Bereitstellung der Zertifikate zum Bezug der öffentlichen Schlüssel zur Datenverschlüsselung... 4 Tabelle 4: Gültigkeitszeiträume von Zertifikaten... 4 Tabelle 5: Basis-Felder des Zertifikatsprofils... 4 Tabelle 6: Zertifikatserweiterungen (hier: Key Usage)... 4 Tabelle 7: Zertifikatserweiterungen (hier: Extended Key Usage)... 4 Tabelle 8: Issuer DN und Subject DN (CMO)... 4 Tabelle 9: Einträge im Subject Alternative Name... 4 Tabelle 10: CRL Profil: Basiswerte... 4 Tabelle 11: CRL Profil: Extension-Einträge... 4 T-Systems, Stand:

10 1 Einleitung Das Certification Practice Statement (CPS) beschreibt konform zu den dokumentierten Prozessen und Funktionen der CPKI die wesentlichen Tätigkeiten des T-Systems Trust Center in der Funktion als Zertifizierungs- und Registrierungsstelle. Es ermöglicht die qualitative 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 Zertifizierungsrichtlinien 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.4) 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 Zertifikate, welche als elektronische Identitätsnachweise durch Mitarbeiter des Konzerns Deutsche Telekom verwendet werden können. Jeder Mitarbeiter des Konzerns Deutsche Telekom erhält durch Verwendung der durch die PKI bereitgestellten Funktionen, die Möglichkeit sich an elektronischen Services zu verlässlich zu identifizieren und mittels Signatur und Verschlüsselung (z.b. Medium ) auf sichere Art und Weise mit anderen Kommunikationspartnern 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). Die Realisierung der C-PKI vollzieht sich in zwei Schritten. Zunächst erfolgt mit der Ausbaustufe 1 die Bereitstellung des C-PKI Basisdienstes, um für die bereits heute vorhandene Arbeitsplatzumgebung (CMO = Current Mode of Operation bzw. heute vorhandene Arbeitsplatzumgebung) eine einheitliche, moderne und benutzerfreundliche Sicherheitsumgebung zu schaffen. Danach erfolgt in der Ausbaustufe 2 die Ergänzung weiterer Features für die neue OS Arbeitsplatzumgebung von morgen (FMO = Future Mode of Operation / zukünftige Arbeitsplatzumgebung). Die beiden Ausbaustufen der CPKI werden auf zwei für einen Übergangszeitraum von 3 Jahren parallel betriebenen Plattformen realisiert. Die Umstellung der Benutzer von der ersten in die zweite Ausbaustufe der CPKI erfolgt sukzessive bei Änderungen (z.b. Beauftragung Deputy oder Zertifikate für Mobile Devices im Future Mode of Operation) oder bei Ablauf von Benutzerzertifikaten. T-Systems, Stand:

11 Die nachfolgende Tabelle zeigt eine Übersicht der wesentlichen benutzerbezogenen Leistungsmerkmale: Leistungsmerkmal PKI Ausbaustufe 1 (Release 2.4) PKI Ausbaustufe 2 (Release 2.8) Signaturzertifikat X X Verschlüsselungszertifikat X X Authentifizierungszertifikat X X Management Zertifikatslebenszyklus X X TIKS2000 Migration (nur sog. Company CA s ) X mit Release 2.4 Backup und Historie für Verschlüsselungszertifikate und - schlüssel X X Vertreter Zertifikate begrenzt auf VIP Support X Vertreter-Zertifikate für Standard-Prüfer - X Support von mobilen Endgeräten (Windows mobile / Black Berry) begrenzt auf VIP-Support X (ggf. erst ab 3.0) Für die C-PKI in der Ausbaustufe 1 (Release 2.4) ergeben sich somit die folgenden Abgrenzungen gegenüber der Ausbaustufe 2 (Release 2.8): Ein Fallback wird durch die Bereitstellung einer Key History unterstützt. Weitere Fallback Mechanismen (z.b. Recovery via RA-Platz) wurden nicht implementiert. Ein Online-Update von Zertifikaten erfolgt nicht. Zertifikate für MyCard Nutzer werden für eine ggf. erforderliche Nutzung auf Mobile Devices nur eingeschränkt d.h. für VIP bereitgestellt. Das Deployment bzw. die Installation der erforderlichen Zertifikate auf mobilen Endgeräten ist nicht Bestandteil der aktuellen Version der C-PKI und erfolgt mit manueller Unterstützung im Rahmen des VIP-Supports. Eine Bereitstellung von Domain-Controller, Server-, Gateway-, Code Signing Zertifikaten durch die C-PKI ist derzeit nicht im Leistungsumfang enthalten, jedoch bereits für spätere Ausbaustufen im OS Future Mode of Operation in Planung. Das vorliegende CPS Dokument bezieht sich dementsprechend auf Personenzertifikate und die hierfür benötigten PKI-Workflow-Prozesse. Personenzertifikate für interne und externe Mitarbeiter werden grundsätzlich unter Verwendung einer Smart Card (MyCard) als Schlüsselträgermedium ausgegeben. Eine T-Systems, Stand:

12 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. Die Unterstützung von mobilen Endgeräten erfolgt in der aktuellen Version der PKI ausschließlich im Rahmen des VIP Supports. 1.2 Dokumentenname und Identifikation Name: CP & CPS CorpPKI FMO Version: 1.0 Datum Objektbezeichnung (Object Identifier) 1.3 PKI Teilnehmer Zertifizierungsstellen Die Struktur der involvierten Zertifizierungsstellen der PKI in der Ausbaustufe 1 wird in den folgenden Kapiteln vorgestellt. Das T-Systems Trust Center betreibt die Deutsche Telekom Root CA 2 Instanz für fortgeschrittene 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ültigkeitsüberprüfung aller in diesen Hierarchien ausgestellten Zertifikate über den Bereich des eigenen Intranets hinaus. Die genannte Root-CA Instanz zertifiziert ausschließlich Zertifikate von unmittelbar nachgeordneten Zertifizierungsstellen. Im Falle der C-PKI Ausbaustufe 1 ist dies die Deutsche Telekom AG Issuing CA i01. 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 i02 und Deutsche Telekom AG Issuing CA i03, wobei die CAi03 derzeit im CMO noch nicht zum Einsatz kommt (siehe Zertifizierungshierarchie). Zertifizierungshierarchie 1 Die Struktur der CA-Hierarchie der C-PKI in der aktuellen Ausbaustufe 1 in der folgenden Abbildung schematisch dargestellt: 1 Zum momentanen Zeitpunkt werden Zertifikate für Domänen Controller und Computer durch das AD ausgegeben und daher in diesem Dokument nicht weiter betrachtet. Für eine spätere Version der C-PKI ist eine Ausgabe über eine eigenständige CA (siehe transparente Bereiche) bereits vorgesehen. T-Systems, Stand:

13 Abbildung 1: CA-Hierachie der C-PKI Registrierungsstellen Die Zertifizierungsstelle Deutsche Telekom Root CA 2 betreibt eine zentrale Registrierungsstelle. Die Zertifizierungsstelle Deutsche Telekom Internal Root CA 1 betreibt eine zentrale Registrierungsstelle. Die Zertifizierungsstellen Deutsche Telekom Issuing CA i01 und Deutsche Telekom Issuing CA i02 betreiben jeweils eine Registrierungsstelle mit einer Schnittstelle zum Provisionierungssystem TAdmin2, sowie zum Verzeichnisdienst Corporate Active Directory Zertifikatsinhaber Zertifikate können je nach Zertifizierungsstelle an Personen oder Maschinen (bzw. Rollenträ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, -Adresse bei Erstellung eines Zertifikates). Der Zertifikatsinhaber beauftragt das Zertifikat, wird von der Registrierungsstelle authentifiziert und durch das Zertifikat identifiziert, ist im Besitz des privaten Schlüssels, der zum öffentlichen Schlüssel im Zertifikat gehört Zertifikatsprüfer (Relying Parties) Zertifikatsprüfer sind alle Personen und Maschinen (bzw. Rollenträger für den Betrieb derselben), die Zertifikate von Zertifikatsinhabern im Rahmen von Anwendungen nutzen. T-Systems, Stand:

14 1.3.5 Weitere Teilnehmer Teilnehmer, die keine Verpflichtung gegenüber der Corporate PKI eingegangen sind, werden in dieser Richtlinie nicht betrachtet. 1.4 Anwendungsbereich Geeignete Zertifikatsnutzung Die von der Corporate PKI zur Verfügung gestellten Zertifikate werden für Authentifizierung, 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, Festplattenverschlüsselung) 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) 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änderspezifischen 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 verwendet werden. 1.5 Verwaltung der Zertifizierungsrichtlinie Änderungsmanagement Dieses CPS wird von T-Systems International GmbH, PRODUCTION, CSS, Identity Management Solutions, Trust Center Applications heraus gegeben. T-Systems, Stand:

15 1.5.2 Ansprechpartner Adresse: T-Systems International GmbH PRODUCTION, CSS, SDM CSS & Special Services, PSS, IMS Trust Center Applications Untere Industriestraße Netphen Telefon: 01805/ WWW: Eignungsprüfer für Regelungen für den Zertifizierungsbetrieb (CPS) gemäß Zertifizierungsrichtlinie Siehe Kapitel Verfahren zur Anerkennung von Regelungen für den Zertifizierungsbetrieb (CPS) Dieses CPS behält seine Gültigkeit, solange sie nicht von der zuständigen Instanz widerrufen wird. Es wird bei Bedarf fortgeschrieben und erhält dann jeweils eine neue, aufsteigende Versionsnummer. 1.6 Definitionen und Abkürzungen Siehe Abkürzungsverzeichnis (Glossar). T-Systems, Stand:

16 2 Veröffentlichungen und Verzeichnisdienst 2.1 Verzeichnisdienste (Repositories) Das T-Systems Trust Center stellt den Nutzern der PKI 7 Tage x 24 Stunden verschiedene Informationsdienste zur Verfügung. Dazu gehören: Bereitstellung von Sperrlisten über die Schnittstellen (siehe Tabelle 1) o o o Web-Applikation, den LDAP-Server der Corporate PKI der DTAG oder 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 Bereitstellung der jeweiligen CA-Zertifikate über die Schnittstellen (siehe Tabelle 1: Zuordnung der Zertifikate zu den CAs und den jeweiligen CRL Distribution Points (CMO)Tabelle 2) o o o Web-Applikation, den LDAP-Server der Corporate PKI der DTAG oder das Active Directory der jeweiligen Domäne. Bereitstellung der Zertifikate zum Bezug der öffentlichen Schlüssel zur Datenverschlüsselung über die Schnittstellen (siehe Tabelle 3) o o o das Active Directory der jeweiligen Domäne, den LDAP-Server der Corporate PKI oder das X.500 Konzernverzeichnis. Die folgenden Tabellen geben einen Überblick, über die verschiedenen Verteilpunkte für die oben genannten Informationsdienste: Deutsche Telekom Issuing CA i01 Deutsche Telekom Issuing CA i02 Deutsche Telekom Issuing CA i03 CRL Distribution Points (CDP) pki1.telekom.de/cdp/deutsch pki1.telekom.de/cdp/deutsch pki1.telekom.de/cdp/deutsch e Telekom AG Issuing CA i01.crl e Telekom AG Issuing CA i02.crl e Telekom AG Issuing CA i03.crl URL= URL= CDP [1] http URL= T-Systems, Stand:

17 URL=ldap://corporate- URL=ldap://corporate- CDP [2] ldap URL=ldap://corporatepki1.telekom.de/CN=Deutsch pki1.telekom.de/cn=deutsch pki1.telekom.de/cn=deutsch e Telekom AG Issuing CA i01,ou=trust Center,O=Deutsche Telekom e Telekom AG Issuing CA i02,ou=trust Center,O=Deutsche Telekom e Telekom AG Issuing CA i03,ou=trust Center,O=Deutsche Telekom AG,C=DE?certificateRevocat AG,C=DE?certificateRevocat AG,C=DE?certificateRevocat ionlist ionlist ionlist X - - X X - X - - X X - Tabelle 1: Zuordnung der Zertifikate zu den CAs und den jeweiligen CRL Distribution Points (CMO) Deutsche Telekom Issuing CA i01 Deutsche Telekom Issuing CA i02 Deutsche Telekom Issuing CA i03 Deutsche Telekom AG Employee Encryption Deutsche Telekom AG Employee Signature Deutsche Telekom AG Employee Authentication Deutsche Telekom AG External Workforce Encryption Deutsche Telekom AG External Workforce Signature Deutsche Telekom AG External Workforce Authentication Authority Information Access (AIA) pki1.telekom.de/aia/deutsch pki1.telekom.de/aia/deutsch pki1.telekom.de/aia/deutsch e Telekom AG Issuing CA i01.crt e Telekom AG Issuing CA i02.crt e Telekom AG Issuing CA i03.crt URL= URL= AIA [1] http URL= pki1.telekom.de/cn=deutsch pki1.telekom.de/cn=deutsch pki1.telekom.de/cn=deutsch e Telekom AG Issuing CA i01,ou=trust Center, O=Deutsche Telekom AG,C=DE?cACertificate e Telekom AG Issuing CA i02,ou=trust Center, O=Deutsche Telekom AG,C=DE?cACertificate e Telekom AG Issuing CA i03,ou=trust Center, O=Deutsche Telekom AG,C=DE?cACertificate URL=ldap://corporate- URL=ldap://corporate- AIA [2] ldap URL=ldap://corporate- Deutsche Telekom AG Employee Encryption X - - T-Systems, Stand:

18 Deutsche Telekom AG Employee Signature Deutsche Telekom AG Employee Authentication Deutsche Telekom AG External Workforce Encryption Deutsche Telekom AG External Workforce Signature Deutsche Telekom AG External Workforce Authentication X X - X - - X X - Tabelle 2: Zuordnung der Zertifikate zu den CAs und den jeweiligen AIA URIs (CMO) Quelle URI Active Directory der jeweiligen Domäne - LDAP-Server der Corporate PKI der DTAG ldap://corporate-pki1.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 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 T-Systems, Stand:

19 CP und CPS: spätestens eine Woche nach Erstellung einer neuen Version CRLs: siehe Abschnitt Tabelle 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 Zertifikaten 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 Zertifikatsinhaber und -prüfer von Zertifikaten nicht vorgesehen. T-Systems, Stand:

20 3 Identifikation und Authentifikation 3.1 Namen Namensformen Die Namensregeln für den SubjectDistinguishedName (Subject DN) und IssuerDistinguishedName (Issuer DN) müssen nach dem X.501-Standard definiert sein. Die Anforderungen an die Nutzung von Namensattributen im Subject DN und Subject Alternative Name hängen konkret vom Anwendungskontext einer Zertifizierungsstelle ab. Beispielsweise muss für Zertifikate, die für sichere genutzt werden, die Adresse 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 dem Kapitel 7 entnommen werden Aussagekraft von Namen Die Eindeutigkeit der Namensangaben ist über den gesamten Subject DN betrachtet sichergestellt (Voraussetzung: Adresse oder CID kommen im Subject-DN vor) Anonymität bzw. Pseudonyme für Zertifikatsinhaber Pseudonyme werden nicht vergeben und akzeptiert Regeln zur Interpretation verschiedener Namensformate Siehe Kapitel Eindeutigkeit von Namen Siehe Kapitel Anerkennung, Authentifizierung und Funktion von Warenzeichen Es liegt in der Verantwortung des Zertifikatsinhabers, dass die Namenswahl keine Warenzeichen, Markenrechte usw. verletzt. Die Zertifizierungsstelle ist nicht verpflichtet, solche Rechte zu überprüfen. T-Systems, Stand:

21 Allein der Zertifikatsinhaber ist für solche Überprüfungen verantwortlich. Falls eine Zertifizierungsstelle über eine Verletzung solcher Rechte informiert wird, wird das Zertifikat widerrufen. 3.2 Identitätsprüfung bei Neuantrag 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 öffentlichem und geheimem Schlüssel implizit gegeben 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 ausreichende Authentifizierung von internen und externen Organisationen gewährleistet Authentifizierung einer natürlichen Person Die Zertifizierungsstelle nimmt in geeigneter Weise eine zuverlässige Überprüfung derjenigen Auftragsdaten vor, die in das Zertifikat eingehen. Given name, surname und sind in den Bezugssystemen für die PKI (TAdmin2 und Corporate AD) hinterlegt und werden durch diese der PKI bereitgestellt Nicht überprüfte Teilnehmerangaben Nicht verifizierte Informationen sind Informationen, die ohne Prüfung ins Zertifikat übernommen 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 Überprüfung der Berechtigung Ein Teilnehmer ist zum Erhalt von Zertifikaten berechtigt, wenn er einen gültigen Arbeitsvertrag besitzt oder eine definierte Vertragsbeziehung besteht (external Workforce) und in den Backend-Systemen (HR, CIAM, AD, TAdmin) administriert ist. T-Systems, Stand:

22 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). 3.3 Identifizierung und Authentifizierung bei einer Zertifikatserneuerung Routinemäßige Zertifikatserneuerung Zur Folge-Beauftragung muss die Identitätsprüfung wie bei Neuauftrag durchlaufen werden siehe 3.2.3, dabei werden für neue kryptographische Schlüssel neue Zertifikate ausgestellt Zertifikatserneuerung nach einer Sperrung Zur Folge-Beauftragung nach einer Sperrung (Replace) muss die Identitätsprüfung wie bei Neuauftrag durchlaufen werden siehe 3.2.3, dabei werden für neue kryptographische Schlüssel neue Zertifikate ausgestellt. 3.4 Identifizierung und Authentifizierung von Sperraufträgen Das T-Systems Trust Center bietet einen zentralen Sperrservice, um im Falle des Verlustes eines Schlüsselträgermediums (MyCard oder Software-PSE) oder bei unbefugtem Nutzungsverdacht 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, adresse). Der Sperrwunsch 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 innerhalb des Konzerns Deutschen Telekom bekannten Eingangskanäle des jeweilig zuständigen Service-Desk zu verwenden. T-Systems, Stand:

23 4 Ablauforganisation (Zertifikatslebenszyklus) 4.1 Zertifikatsantrag Wer kann Zertifikate beantragen Zertifikate können durch natürliche Personen und Organisationen vertreten durch handlungsbevollmächtigte Mitarbeiter (z.b. Server- Administratoren) beantragt werden Verfahren und Verantwortungen Die Vorregistrierung der Teilnehmer erfolgt über vorgelagerte Identifizierungs-, Registrierungs- 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 für die PKI. Konkret bedeutet dies, dass die Verarbeitung der Registrierungsdaten sowie deren Verifikation bereits in/durch die Vorsysteme (siehe oben) erfolgen. Auf Basis dieser Daten erfolgt 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 Durchführung von Identifikation und Authentifizierung Die Identifizierung und Authentisierung erfolgt im Rahmen von Adminstrations-Prozessen, durch die in Kapitel 3 genannten Einheiten/Systeme. T-Systems, Stand:

24 4.2.2 Annahme oder Ablehnung von Zertifikatsanträgen Zertifikatsanträge werden bei Dateninkonsistenzen und fehlenden Berechtigungen automatisch abgelehnt. Andernfalls erfolgt eine automatisierte Annahme der Anträge und der weitere Bearbeitungsprozess wird angestoßen 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 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 angegebenen Namen zu genehmigen sowie die Gültigkeit der Signatur der ausführenden Instanz Benachrichtigung des Antragstellers Der Zertifikatsinhaber erhält eine Benachrichtigung in Form einer . In dieser 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 unter Eingabe der PIN durch den jeweiligen Zertifikatsinhaber personalisiert, d.h. sein Zertifikat wird ausgestellt und auf die Karte geschrieben. 4.4 Akzeptanz der Zertifikate Annahme von Zertifikaten Der Zertifikatsinhaber ist verpflichtet, die Korrektheit des eigenen Zertifikats sowie des Zertifikats 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- T-Systems, Stand:

25 nahme des Zertifikats versichert der Zertifikatsinhaber, dass sämtliche Angaben und Erklärungen in Bezug auf die im Zertifikat enthaltenden Informationen der Wahrheit entsprechen 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 Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle 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 Nutzung durch den Zertifikatsinhaber Der Zertifikatsinhaber trägt die Verantwortung dafür, dass sein privater Schlüssel in angemessener 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 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 anderem 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. T-Systems, Stand:

26 4.6 Zertifikatserneuerung unter Beibehaltung des alten Schlüssels (Re-Zertifizierung) Gründe für eine Zertifikatserneuerung Eine Zertifikatserneuerung ist in der Ausbaustufe1 der C-PKI grundsätzlich nicht vorgesehen. 6 Wochen vor Ablauf der Zertifikate einer Person erfolgt die Initiierung einer Zertifikatserneuerung zum Zwecke der Migration in die Ausbaustufe 2 der C-PKI. Dieser Schritt ist gebunden an die Verwendung einer neuen MyCard und führt dazu, dass für neue kryptographische Schlüssel auf einer neuen MyCard neue Zertifikate ausgestellt werden Wer kann eine Zertifikatserneuerung beantragen? Die Zertifikatserneuerung wird durch die PKI initialisiert und kann nur durch den Zertifikatsinhaber ausgeführt werden Ablauf der Zertifikatserneuerung Es gelten die Regelungen von Kapitel Benachrichtigung des Antragstellers nach Zertifikatserneuerung Es gelten die Regelungen gemäß Kapitel Annahme einer Zertifikatserneuerung Eine Zertifikatserneuerung wird nur angenommen, wenn der Antragsteller über ein gültiges Benutzerkonto (AD- Account) verfügt Veröffentlichungen der erneuerten Zertifikate durch die Zertifizierungsstelle Es gelten die Regelungen gemäß Kapitel Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle Es gelten die Regelungen gemäß Kapitel T-Systems, Stand:

27 4.7 Schlüssel- und Zertifikatserneuerung (Re-key) Gründe für eine Schlüssel- und Zertifikatserneuerung Es gelten die Regelungen von Kapitel Wer kann eine Schlüssel- und Zertifikatserneuerung beantragen? Es gelten die Regelungen von Kapitel Ablauf der Schlüssel- und Zertifikatserneuerung Es gelten die Regelungen von Kapitel Benachrichtigung des Zertifikatsinhabers Es gelten die Regelungen gemäß Kapitel Annahme der Schlüssel- und Zertifikatserneuerung Es gelten die Regelungen gemäß Kapitel Veröffentlichung einer Zertifikatserneuerung durch die Zertifizierungsstelle Es gelten die Regelungen gemäß Kapitel Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle Es gelten die Regelungen gemäß Kapitel Zertifikatsmodifizierung 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 (z.b. Online Update, Detail Changes) erforderlich. T-Systems, Stand:

28 4.8.2 Wer kann eine Modifikation eines Zertifikates beantragen? Gemäß Kapitel tritt dieser Fall nicht auf Ablauf der Zertifikatsmodifizierung Gemäß Kapitel tritt dieser Fall nicht auf Benachrichtigung des Zertifikatsinhabers Gemäß Kapitel tritt dieser Fall nicht auf Annahme der Zertifikatsmodifizierung Gemäß Kapitel tritt dieser Fall nicht auf Veröffentlichung einer Zertifikatsmodifizierung durch die Zertifizierungsstelle Gemäß Kapitel tritt dieser Fall nicht auf Benachrichtigung weiterer Instanzen durch die Zertifizierungsstelle Gemäß Kapitel tritt dieser Fall nicht auf. 4.9 Widerruf/Sperrung und Suspendierung von Zertifikaten Gründe für Widerruf/Sperrung Die folgenden Gründe des Zertifikatsinhabers müssen zu einer Sperrung des Zertifikats führen: 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 Zertifikatsinhaber oder andere zur Nutzung des Schlüssels berechtigte Personen T-Systems, Stand:

29 Der Zertifikatsinhaber benötigt kein Zertifikat mehr und kündigt daher das Vertragsverhä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 endgültig gesperrt. Die folgenden Gründe des T-Systems Trust Centers führen zu einer Sperrung des Zertifikats: 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 Zahlungsverzug Es liegt ein Unbefugte Nutzung oder Verdacht auf Unbefugte Nutzung durch den Zertifikatsinhaber oder andere zur Nutzung des Schlüssels berechtigte Personen vor 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) Ablauf von Widerruf / Sperrung Zur Sperrung autorisierte Personen und Institutionen können die Sperrung eines Zertifikates 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 Frage/Antwort). Sind die Vorraussetzungen zur Sperrung erfüllt, wird die Sperrung vorgenommen, und das gesperrte Zertifikat in die Sperrinformationen übernommen. Die Sperrinformationen werden in standard-konformer Form (CRL) bereitgestellt. Die autorisierte Person oder Institution wird über die Durchführung der Sperrung in geeigneter Weise informiert. T-Systems, Stand:

30 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 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) 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 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 Maximale Latenzzeit für Sperrlisten Die Latenzzeit (Grace Period) für Sperrlisten beträgt 12 Stunden Verfügbarkeit von Online-Statusabfragen (OCSP) Sperrinformationen, werden für die Endteilnehmer der PKI online mit einem standardkonformen Verfahren bereitgestellt (OCSP). Es sind alle von dieser Zertifizierungsstelle gesperrten Zertifikate enthalten Anforderungen an Online-Statusabfragen (OCSP) Die Dienste CRL und OCSP müssen für die Nutzer hochverfügbar sein Andere Formen der Veröffentlichung von Sperrinformationen Derzeit werden keine anderen Formen der Bekanntmachung eingesetzt. T-Systems, Stand: