Deutsche Post Signtrust und DMDA GmbH

Transkript

1 Deutsche Post Signtrust und DMDA GmbH Berechtigungs-CA Version 1.5 OID Certificate Policy (CP) Einstufung: Öffentlich

2 Certificate Policy (CP) Inhaltsverzeichnis Inhaltsverzeichnis Inhaltsverzeichnis... 2 Dokumentenhistorie... 5 Akronyme... 6 Literaturverzeichnis... 8 Tabellenverzeichnis...10 Abbildungsverzeichnis Einleitung Überblick Name und Identifizierung des Dokumentes PKI-Teilnehmer Verwendung von Zertifikaten Administration der Policy Pflege der Certificate Policy Zuständigkeit für das Dokument Ansprechpartner / Kontaktperson CPS Abnahmeprozedur Verantwortlichkeit für Veröffentlichungen und Verzeichnisdienste Verzeichnisse Veröffentlichung von Informationen zur Zertifikatserstellung Zeitpunkt und Häufigkeit der Veröffentlichungen Zugriffskontrollen auf Verzeichnisse Identifizierung und Authentifizierung Regeln für die Namensgebung Arten von Namen Notwendigkeit für aussagekräftige Namen Anonymität oder Pseudonyme von Zertifikatsnehmern Interpretationsregeln für verschiedene Namensformen Eindeutigkeit von Namen Anerkennung, Authentifizierung und die Rolle von Markennamen Initiale Überprüfung der Identität...26

3 Certificate Policy (CP) Inhaltsverzeichnis Methoden zur Überprüfung bzgl. Besitz des privaten Schlüssels Authentifizierung von Organisationszugehörigkeiten Anforderungen zur Identifizierung und Authentifizierung des Zertifikats- Antragstellers Ungeprüfte Angaben zum Zertifikatsnehmer Prüfung der Berechtigung zur Antragstellung Kriterien für den Einsatz interoperierender Systeme/Einheiten Identifizierung und Authentifizierung von Anträgen auf Schlüsselerneuerung Identifizierung und Authentifizierung von Anträgen auf Sperrung Betriebsanforderungen für den Zertifikatslebenszyklus Zertifikatsantrag Verarbeitung von Zertifikatsanträgen Durchführung der Identifizierung und Authentifizierung Annahme oder Ablehnung von Zertifikatsanträgen Fristen für die Bearbeitung von Zertifikatsanträgen Ausgabe von Zertifikaten Annahme von Zertifikaten Verwendung von Schlüsselpaar und Zertifikat Verwendung des privaten Schlüssels und des Zertifikats durch den Zertifikatsnehmer Verwendung des öffentlichen Schlüssels und des Zertifikats durch den Zertifikatsnutzer Zertifikatserneuerung Zertifizierung nach Schlüsselerneuerung Änderungen am Zertifikat Sperrung und Suspendierung von Zertifikaten Service zur Statusabfrage von Zertifikaten Beendigung der Teilnahme Hinterlegung und Wiederherstellung von Schlüsseln Organisatorische, betriebliche und physikalische Sicherheitsmaßnahmen Technische Sicherheitsmaßnahmen Erzeugung und Installation von Schlüsselpaaren Erzeugung von Schlüsselpaaren Lieferung privater Schlüssel an Zertifikatsnehmer Lieferung öffentlicher Schlüssel an Zertifikatsherausgeber Lieferung öffentlicher Schlüssel der CA an Zertifikatsnutzer Schlüssellängen und kryptographische Algorithmen Festlegung der Parameter der öffentlichen Schlüssel und Qualitätskontrolle...37

4 Certificate Policy (CP) Inhaltsverzeichnis Verwendungszweck der Schlüssel Sicherung des privaten Schlüssels und Anforderungen an kryptographische Module Mehrpersonen-Zugriffssicherung zu privaten Schlüsseln Hinterlegung privater Schlüssel Backup privater Schlüssel Archivierung privater Schlüssel Transfer privater Schlüssel in oder aus kryptographischen Modulen Speicherung privater Schlüssel in kryptographischen Modulen Aktivierung privater Schlüssel Deaktivierung privater Schlüssel Zerstörung privater Schlüssel Beurteilung kryptographischer Module Andere Aspekte des Managements von Schlüsselpaaren Archivierung öffentlicher Schlüssel Gültigkeitszeitraum von Zertifikaten und Schlüsselpaaren Aktivierungsdaten Sicherheitsmaßnahmen für die Rechneranlagen Zeitstempel Validierungsmodell Profile für Zertifikate und Sperrlisten Profile für Zertifikate und Zertifikats-Requests Zugriffsrechte Zertifikatserweiterung Profile für Sperrlisten Profile für OCSP-Dienste Überprüfung und andere Bewertungen Sonstige finanzielle und rechtliche Regelungen Preise Finanzielle Zuständigkeiten...46

5 Certificate Policy (CP) Dokumentenhistorie Dokumentenhistorie Version: Datum: OID: Änderung(en): Erste Version der CP Einarbeitung der Kommentare des Bundesamtes für Sicherheit in der Informationstechnik (BSI): Akronyme MBS, NPKD, PKI und PKIn hinzugefügt Abschnitt 1.1 stark überarbeitet und erweitert, neue Abbildung 1 hinzugefügt Abschnitt 2.1 konkretisiert (Sperrstatus im internen Verzeichnis) Abschnitt 3.1.1: TLS-Server- DName geändert Abschnitt modifiziert Abschnitt 4.9: Punkt 3 hinzugefügt (MUSS-Anforderung) Abschnitt 6.1.1, Punkt 3 geändert: Schlüsselmaterial der TLS- Kommunikationszertifikate wird in SoftPSEs gespeichert Abschnitt 6.3.2: Gültigkeitsdauer der Wurzelinstanz von zehn auf acht Jahre gekürzt Einarbeitung der finalen Kommentare des BSIs; Freigabe der Certificate Policy durch die DP Signtrust Einarbeitung der Anforderungen an den Betrieb des HSM Entfall der Befristung der CP aufgrund des Betriebs des HSMs in der Übergangsphase Anpassung des Firmennamens

6 Certificate Policy (CP) Akronyme Akronyme AT Authentisierungsterminal AT hoh AT nhoh BerCA BMI BSI BVA C DV C Terminal C X.509 CMS-Signer C X.509 TLS-Client C X.509 TLS-Server CA CMS CP CPS CRL CSCA Hoheitliches Authentisierungsterminal Nicht-hoheitliches Authentisierungsterminal Berechtigungs-CA, siehe auch CA Bundesministerium des Innern Bundesamt für Sicherheit in der Informationstechnik Bundesverwaltungsamt (Köln) DV-Certificate (Card Verifiable) Terminal-Certificate (Card Verifiable) CMS-Signer-Zertifikat (X.509) TLS-Client-Zertifikat (X.509) TLS-Server-Zertifikat (X.509) Certificate Authority, auch: Certification Authority Cryptographic Message Syntax Certificate Policy Certification Practice Statement Certificate Revocation List Country Signing Certification Authority CVC Card Verifiable Certificate (ISO 7816, parts 4, 6, 8) CVCA Country Verifying Certification Authority (BSI) CVCA-eID CVCA für den elektronischen Identitätsnachweis (BSI) CVCA-eID PKD Verzeichnisdienst für die Domäne CVCA-eID (BSI) DA Diensteanbieter DN Distinguished Name DPST Deutsche Post Signtrust und DMDA GmbH DS Document Signer DV Document Verifier DVCA Document Verifier CA

7 Certificate Policy (CP) Akronyme EC ECC HSM HTTP HTTPS eid epa GAP IPR IS MBS MRTD npa PKD PKI PKIn PSE RA SPOC SOAP SoftPSE SSL TLS VfB ZDA Elliptic Curve (Elliptische Kurve) Elliptic Curve Cryptography (Elliptische Kurven Kryptographie) Hardware Security Module Hypertext Transfer Protocol Hypertext Transfer Protocol over SSL (siehe SSL und TLS) Elektronischer Identitätsnachweis; auch: Kartenapplikation der Smartcard als Teil des npas Elektronischer Personalausweis; veraltetes Akronym, siehe npa General Authentication Procedure Intellectual Property Rights Inspection System Master Blacklisting Service Machine Readable Travel Document; hier: Synonym für epa bzw. npa Neuer (elektronischer) Personalausweis, vormals: epa Public Key Directory (Verzeichnisdienst) Public Key Infrastructure Deutscher Plural von Public Key Infrastructure Personal Security Environment Registration Authority Single Point Of Contact Ursprünglich: Simple Object Access Protocol; wird seit der Version 1.2 offiziell nicht mehr als Akronym verwendet! Software-PSE Secure Sockets Layer Transport Layer Security Vergabestelle für Berechtigungszertifikate; Organisationseinheit des BVAs; siehe auch RA Zertifizierungsdiensteanbieter

8 Certificate Policy (CP) Literaturverzeichnis Literaturverzeichnis [AnforderungenDAs] Anforderungen an Diensteanbieter für die Online- Authentisierung mit dem elektronischen Personalausweis, Bundesamt für Sicherheit in der Informationstechnik, Version 0.2, [BSI-TR-03110] [BSI-TR-03112] [BSI-TR ] [BSI-TR-03127] [BSI-TR-03128] [BSI-TR-03129] [BSI-TR-03130] Technical Guideline TR-03110, Advanced Security Mechanisms for Machine Readable Travel Documents Extended Access Control (EAC), Password Authenticated Connection Establishment (PACE), and Restricted Identification (RI), Version 2.03, , Bundesamt für Sicherheit in der Informationstechnik Technische Richtlinie TR-03112, ecard-api-framework, Version 1.1, Bundesamt für Sicherheit in der Informationstechnik Technische Richtlinie TR-03116, ecard-projekte der Bundesregierung Teil 2 Hoheitliche Ausweisdokumente, Stand 2010, Bundesamt für Sicherheit in der Informationstechnik Technische Richtlinie TR-03127, Architektur elektronischer Personalausweis und elektronischer Aufenthaltstitel, Version 1.11, , Bundesamt für Sicherheit in der Informationstechnik Technische Richtlinie TR-03128, EAC-PKI n für den elektronischen Personalausweis Rahmenkonzept für den Aufbau und den Betrieb von Document Verifiern, Version 1.02, , Bundesamt für Sicherheit in der Informationstechnik Technical Guideline TR-03129, PKIs for Machine Readable Travel Documents Protocols for the Management of Certificates and CRLs, Version 1.10, Bundesamt für Sicherheit in der Informationstechnik Technische Richtlinie TR-03130, Technische Richtlinie eid- Server, Version 1.3, , Bundesamt für Sicherheit in der Informationstechnik

9 Certificate Policy (CP) Literaturverzeichnis [CP-eID] [ČSN ] [FreigabeHSM] [PAuswG] [PAuswV] [PKCS#10] Certificate Policy für die eid-anwendung des epa - Elektronischer Identitätsnachweis mit dem elektronischen Personalausweis, Version 1.28, , Bundesamt für Sicherheit in der Informationstechnik; OID Information Technology Country Verifying Certification Authority: Key Management Protocol for SPOC, ČSN :2009 Technische Freigabe von HSM-Technologie für den Einsatz im Umfeld eid des epa, Bundesamt für Sicherheit in der Informationstechnik, Gesetz über Personalausweise und den elektronischen Identitätsnachweis (Personalausweisgesetz PauswG), tritt am in Kraft, 21 gilt ab Verordnung über Personalausweise und den elektronischen Identitätsnachweis (Personalausweisverordnung PauswV), Drucksache 240/10, (Bundesanzeiger), tritt am in Kraft, Verordnung des Bundesministeriums des Innern PKCS #10 v1.7: Certification Request Syntax Standard, RSA Laboratories, May 26, 2000 [PP-CM-m] Common Criteria Protection Profile: Protection Profile Cryptographic Modules, Security Level Moderate, Bundesamt für Sicherheit in der Informationstechnik, BSI-PP-0042 [RFC3647] [RFC5280] [SigG/SigV] [X.509] Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework, Network Working Group, November 2003 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, Network Working Group, May 2008 Gesetz über Rahmenbedingungen für elektronische Signaturen (Signaturgesetz SigG) und Verordnung zur elektronischen Signatur (Signaturverordnung SigV) in der jeweils gültigen Fassung ITU-T X.509 Information Technology Open Systems Interconnection The Directory: Public-key and attribute certificate frameworks, 08/2005

10 Certificate Policy (CP) Tabellenverzeichnis Tabellenverzeichnis Tabelle 1: Identifikation des Dokumentes...17 Tabelle 2: Verwendungszweck von X.509-Zertifikaten und zugehörigem privaten Schlüssel Tabelle 3: Kontaktadresse (Administration der Policy)...20 Tabelle 4: Aufbau von CAR und CHR Tabelle 5: Belegung des CHR-Feldes der BerCA DP Signtrust (DVCA) Tabelle 6: Belegung des CHR-Feldes der BerCA DP Signtrust (Terminals)...24 Tabelle 7: Kontaktadresse des Trustcenters der DP Signtrust (Darmstadt) Tabelle 8: Zertifikatsprofil der CMS-Signer-Zertifikate ( Blacklist Signer )...42 Tabelle 9: Kontaktadresse für Preisinformationen....46

11 Certificate Policy (CP) Abbildungsverzeichnis Abbildungsverzeichnis Abbildung 1: PKIn im Umfeld des neuen Personalausweises (oberste Ebene zeigt selbstsignierte Wurzelinstanzen) Abbildung 2: TLS-Kommunikationsbeziehungen zwischen BSI, BVA, BerCA und eid-server Abbildung 3: Zertifizierungshierarchie der X.509-TLS/CMS-CA (BerCA DP Signtrust)....18

12 Certificate Policy (CP) Einleitung 1 Einleitung Diese Certificate Policy wurde in Anlehnung an [RFC3647] und in Konformität zu der übergeordneten Certificate Policy [CP-eID] des Bundesamtes für Sicherheit in der Informationstechnik (BSI) erstellt. Wenn auf die [CP-eID] verwiesen wird und dortige Textpassagen in hoheitlich und nicht hoheitlich unterschieden werden, dann gelten für die vorliegende CP DVeIDDPST grundsätzlich nur die Festlegungen, die als nicht hoheitlich gekennzeichnet sind. Die übergeordnete Certificate Policy ist im Internet veröffentlicht unter: ode.html In der vorliegenden CP DVeIDDPST werden die beiden Rollen Diensteanbieter und eid-service-provider unter BerCA-Mandant zusammengefasst. Siehe Kapitel 1 Einleitung in [CP-eID]. Die Deutsche Post Signtrust und DMDA GmbH, betreibt als akkreditierter ZDA ein Trustcenter in Darmstadt. Das Dienstleistungsspektrum der DP Signtrust ist um den Betrieb einer DVCA (Berechtigungs-CA) im Umfeld des neuen Personalausweises (npa) erweitert worden. Die Berechtigungs-CA nimmt ihren Betrieb als Teil des Trustcenters auf und partizipiert damit an allen bestehenden Sicherheitsmaßnahmen und organisatorischen Abläufen des Trustcenter-Regelbetriebes. Der Definition nach betreibt die DP Signtrust eine DVCA im nicht hoheitlichen DV- Bereich. Diese werden als BerCAs bezeichnet. 1.1 Überblick Siehe Abschnitt 1.1 Überblick in [CP-eID]. Die BerCA der DP Signtrust stellt neben den Terminal-Berechtigungs-zertifikaten (CV-Zertifikate) auch X.509-Kommunikationszertifikate (TLS-Client- und -Server- Zertifikate) zur gesicherten Punkt-zu-Punkt-Kommunikation der nationalen SPOCs aus. Darüber hinaus generiert sie Schlüsselpaare und X.509-Zertifikate zum digitalen Signieren von CMS-Containern, die beispielsweise Black Lists enthalten. DP Signtrust und DMDA GmbH 12 Version 1.45 /

13 Certificate Policy (CP) Einleitung Abbildung 1 gibt einen Überblick über die PKIn im Umfeld des neuen Personalausweises (die farblich hervorgehobenen Instanzen liegen im Verantwortungsbereich der DP Signtrust): 1. Die Hierarchie der Berechtigungs-PKI (vgl. [BSI-TR-03127] und [BSI-TR ]) ist dreistufig (CVCA, DVCA, Terminal-Berechtigungszertifikat). Die Berechtigungs-PKI basiert auf CV-Zertifikaten gemäß [BSI-TR-03110]. Abbildung 1 simplifiziert die tatsächliche Komplexität der Berechtigungs-PKI auf den für die DP Signtrust maßgeblichen Rahmen. Auch die CVCA-Link- Zertifikate sind nicht dargestellt. Die Wurzelinstanz CVCA-eID wird vom BSI betrieben. Darunter befindet sich die Berechtigungs-CA der DP Signtrust, die Terminal-Berechtigungszertifikate für BerCA-Mandanten (End-Entitäten) ausstellt. Für den Zugriff auf die im npa gespeicherten Daten ist ein Berechtigungsnachweis notwendig: Ein BerCA-Mandant muss einen Antrag auf die Erteilung von Berechtigungen bei der VfB des Bundesverwaltungsamtes gemäß 21 [PAuswG] und 28 [PAuswV], ebenfalls beschrieben in [BSI-TR-03127] und [BSI-TR-03128], stellen. Nachdem die Berechtigungsvergabe an einen BerCA-Mandanten durch die VfB abgeschlossen wurde und per Bescheid belegt werden kann, darf die BerCA der DP Signtrust Terminal-Berechtigungszertifikate für diesen Ber- CA-Mandanten ausstellen. Das Terminal-Berechtigungszertifikat enthält die zugewiesenen Rechte, die es dem nicht hoheitlichen Authentisierungsterminal des BerCA-Mandanten ermöglichen, auf die eid-funktionen des npas zuzugreifen (Altersverifikation, Wohnortverifikation, Abfrage der bereichsspezifischen Kennung und Auslesen von personenbezogenen Daten). DP Signtrust und DMDA GmbH 13 Version 1.45 /

14 Certificate Policy (CP) Einleitung Abbildung 1: PKIn im Umfeld des neuen Personalausweises (oberste Ebene zeigt selbstsignierte Wurzelinstanzen). 2. Die Dokumenten-PKI (vgl. [BSI-TR-03127]) ist zweistufig und besteht aus der Country Signing CA (CSCA, BSI) sowie den End-Entitäten Document Signer (DS, Bundesdruckerei). Die Zertifikate beider Ebenen sind X.509- Zertifikate. Im Rahmen der Passive Authentication (vgl. [BSI-TR-03110] und [BSI-TR-03129]) werden zum einen die Vertrauensanker der Dokumenten-PKI und zum anderen die defekten bzw. gesperrten Vertrauensanker und Document Signer-Zertifikate der Dokumenten-PKI benötigt. Die Berechtigungs-CA der DP Signtrust ruft diese Informationen beim BSI (genauer: beim SPOC) ab und reicht sie an ihre BerCA-Mandanten weiter. DPCom GmbH, GF Signtrust 14 Version 1.4 /

15 Certificate Policy (CP) Einleitung 3. Die TLS/CMS-PKI der DP Signtrust ist zweistufig. Sie ist ebenfalls eine X.509-PKI. Die TLS/CMS-PKI gibt sowohl TLS-Client- und TLS-Server- Zertifikate an sich selbst als auch (auf Anfrage) an ihre BerCA-Mandanten aus. Die Zertifikate und ihre privaten Schlüssel werden zur gegenseitigen Authentisierung sowie zur Punkt-zu-Punkt-Absicherung der Kommunikationsstrecken zwischen der BerCA der DP Signtrust, dem BSI, dem BVA und den BerCA-Mandanten verwendet. Darüber hinaus stellt die Wurzelinstanz der TLS/CMS-PKI CMS-Signer- Zertifikate aus, deren zugehörige private Schlüssel CMS-Container signieren, die Blacklists enthalten. Die BerCA fragt dazu beim Sperrregister des BVAs (MBS) die globale Blacklist ab, die für jeden BerCA-Mandanten in eine mandantenspezifische Blacklist umgerechnet wird. Die BerCA erhält die globale Blacklist in einem CMS-Container und stellt die mandantenspezifische Blacklists ebenfalls in CMS-Containern ihren BerCA- Mandanten zur Verfügung. Die TLS-Kommunikationszertifikate für einen BerCA-Mandanten können entweder: 1. von der TLS/CMS-CA der BerCA der DP Signtrust für den BerCA- Mandanten ausgestellt oder: 2. einer TLS-CA entstammen, die der BerCA-Mandant selbst betreibt; die TLS-Hierarchie MUSS zweistufig sein (selbstsignierte Wurzelinstanz und End-Entitäten). Abbildung 2 illustriert die Kommunikationsbeziehungen der beteiligten Parteien in Bezug auf die PKI-Kommunikationsstrecken gemäß [BSI-TR-03129]: BSI (CVCA-eID) BVA (Sperrregister, MBS) eid-server (BerCA-Mandanten, d.h. Antragsteller der Terminal-Berechtigungszertifikate) Da die in [BSI-TR-03129] definierten Web-Dienste sowohl synchron als auch asynchron arbeiten, kann jeder der beiden Kommunikationspartner sowohl Client als auch Server sein. Daher müssen beide Kommunikationspartner jeweils Paare von TLS-Kommunikationszertifikaten ausstellen (lassen). DP Signtrust und DMDA GmbH 15 Version 1.45 /

16 Certificate Policy (CP) Einleitung Abbildung 2: TLS-Kommunikationsbeziehungen zwischen BSI, BVA, BerCA und eid-server. DP Signtrust und DMDA GmbH 16 Version 1.45 /

17 Certificate Policy (CP) Einleitung 1.2 Name und Identifizierung des Dokumentes Dieses Dokument ist die Certificate Policy (CP) der DP Signtrust Berechtigungs- CA (CP DVeIDDPST). Dieses Dokument kann unter (Downloadcenter) bezogen werden. Identifikator: Wert: Titel Kürzel Version 1.4 DP Signtrust Berechtigungs-CA Certificate Policy (CP) CP DVeIDDPST OID Tabelle 1: Identifikation des Dokumentes Die letzte Stelle der OID ( oid arc ) kennzeichnet die Revision dieser CP. Für jede aktualisierte und publizierte Dokumentenversion wird sie um eins (1) inkrementiert. 1.3 PKI-Teilnehmer Siehe Abschnitt 1.3 PKI-Teilnehmer in [CP-eID]. Die BerCA der DP Signtrust stellt auch X.509-Zertifikate für die folgenden PKI- Teilnehmer aus: [ZWINGEND] DP Signtrust BerCA: TLS-Client-/TLS-Server-Zertifikate sowie CMS-Signer-Zertifikate [OPTIONAL] BerCA-Mandanten (Diensteanbieter bzw. eid-service-provider): TLS-Client-/TLS-Server-Zertifikate Abbildung 3 zeigt die zweistufige Zertifizierungshierarchie der X.509-TLS/CMS-CA der DP Signtrust BerCA auf: DP Signtrust und DMDA GmbH 17 Version 1.45 /

18 Certificate Policy (CP) Einleitung 18 Abbildung 3: Zertifizierungshierarchie der X.509-TLS/CMS-CA (BerCA DP Signtrust). DPCom GmbH, GF Signtrust 18 Version 1.4 /

19 Certificate Policy (CP) Einleitung 1.4 Verwendung von Zertifikaten Siehe Abschnitt 1.4 Verwendung von Zertifikaten in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: Es ergeben sich die folgenden Verwendungszwecke für die in Abbildung 3 gezeigten X.509-Zertifikate: Zertifikat C X.509 CA C X.509 TLS-Server C X.509 TLS-Client C X.509 CMS-Signer Verwendungszweck und Eigenschaften Vertrauensanker der X.509-TLS/CMS-Zertifizierungshierarchie Mit dem privaten Schlüssel wird C X.509 CA (selbstsigniert) sowie alle EE-Zertifikate aus Abbildung 3 signiert. Der private Schlüssel wird im TLS-Handshake-Protokoll als Teil der gegenseitigen Authentisierung verwendet. Der private Schlüssel wird im TLS-Handshake-Protokoll als Teil der gegenseitigen Authentisierung verwendet. Mit dem privaten Schlüssel werden CMS-Container signiert, die die BerCA erstellt. Derzeitig erstellt die BerCA CMS-Container ausschließlich für die sektorspezifischen Black Lists gemäß [BSI-TR-03129], die an die BerCA-Mandanten übermittelt werden. Tabelle 2: Verwendungszweck von X.509-Zertifikaten und zugehörigem privaten Schlüssel. DP Signtrust und DMDA GmbH 19 Version 1.45 /

20 Certificate Policy (CP) Einleitung 1.5 Administration der Policy Die für dieses Dokument verantwortliche Organisation ist die Deutsche Post Signtrust und DMDA GmbH (DP Signtrust): Organisation Deutsche Post Signtrust und DMDA GmbH Adresse Charles-de-Gaulle-Str. 20, Bonn, Germany Telefon +49 (0) Fax +49 (0) Webseite Tabelle 3: Kontaktadresse (Administration der Policy) Pflege der Certificate Policy Die jeweils aktuelle und freigegebene Version dieser Certificate Policy wird der Öffentlichkeit unverzüglich über die Internetpräsenz der Deutsche Post Signtrust und DMDA GmbH, zur Verfügung gestellt (siehe Abschnitt 1.5). Jedwede Änderungen der übergeordneten Certificate Policy [CP-eID] des Bundesamtes für Sicherheit in der Informationstechnik, die Auswirkungen auf diese CP haben, werden ebenfalls unverzüglich in die vorliegende CP eingearbeitet Zuständigkeit für das Dokument Zuständig für die Erweiterung bzw. Modifikation dieser CP ist die Deutsche Post Signtrust und DMDA GmbH Ansprechpartner / Kontaktperson Siehe Abschnitt CPS Abnahmeprozedur Die Deutsche Post Signtrust und DMDA GmbH, verfasst derzeit kein gesondertes CPS. Sofern zukünftig ein CPS aufgesetzt werden sollte, werden sowohl die Anforderungen dieser CP und der übergeordneten CP [CP-eID] umgesetzt. DP Signtrust und DMDA GmbH 20 Version 1.45 /

21 Certificate Policy (CP) Verantwortl. für Veröff. und Verz.-Dienste 2 Verantwortlichkeit für Veröffentlichungen und Verzeichnisdienste 2.1 Verzeichnisse Die BerCA der DP Signtrust führt in ihrer Datenbank ein Verzeichnis mit Einträgen zu den von ihr verwalteten BerCA-Mandanten mit ihren Terminals, ausgestellten Terminal-Berechtigungszertifikaten sowie X.509-Zertifikaten (TLS/CMS). Die Datenbank wird dabei sowohl zur Bestandsführung als auch als Archiv verwendet. Die einzelnen Datenbankeinträge lassen sich über eine Tabellenspalte in Bestand und Archiv separieren. Das Verzeichnis der DP Signtrust BerCA ist nicht öffentlich. Diese gilt auch für die ausgestellten X.509-Kommunikationszertifikate, deren Sperrstatus ebenfalls im internen Verzeichnis organisiert wird. Die Zertifikate (CV- und X.509-Zertifikate) werden permanent in der Datenbank aufbewahrt. Sofern ein Ausleiten von Zertifikaten in ein externes Archiv erfolgen sollte, werden die Aufbewahrungszeiten, die in Abschnitt der CP [CP-eID] aufgelistet sind, nicht unterschritten. 2.2 Veröffentlichung von Informationen zur Zertifikatserstellung Die Veröffentlichung der für den Betrieb der DV erforderlichen Dokumente, beschrieben in [SigG/SigV] und [BSI-TR-03128], erfolgt nicht. Die jeweils aktuelle Version der vorliegenden CP DVeIDDPST wird auf der Website der DP Signtrust (vgl. Abschnitt 1.5 auf Seite 20) veröffentlicht. 2.3 Zeitpunkt und Häufigkeit der Veröffentlichungen Die BerCA der DP Signtrust stellt allen von ihr verwalteten BerCA-Mandanten mit allen Terminals die für die eid-authentisierung erforderlichen CV- und X.509- Zertifikate (C CVCA, Link-C CVCA, C DV, C CSCA ) sowie die Black- und Defect-Lists über die Kommunikationsschnittstelle gemäß [BSI-TR-03129] online zur Verfügung. Sofern die vorliegende CP DVeIDDPST modifiziert wird, geschieht dies unter Beachtung der Anforderungen der [CP-eID]. Die geänderte CP DVeIDDPST wird wie in Abschnitt 1.5 auf Seite 20 beschrieben, auf der Website der DP Signtrust veröffentlicht. DP Signtrust und DMDA GmbH 21 Version 1.5 /

22 Certificate Policy (CP) Verantwortl. für Veröff. und Verz.-Dienste 2.4 Zugriffskontrollen auf Verzeichnisse Die BerCA der DP Signtrust stellt durch die bestehenden Zugriffskontrollen und Handlungsabläufe des Trustcenter-Betriebes als akkreditierter ZDA sicher, dass die Vertraulichkeit und Integrität der Informationen in ihren Verzeichnissen gewahrt bleibt. DP Signtrust und DMDA GmbH 22 Version 1.45 /

23 Certificate Policy (CP) Identifizierung und Authentifizierung 3 Identifizierung und Authentifizierung Die BerCA der DP Signtrust stellt sicher, dass: a) die an die CVCA-eID übermittelten Zertifikats-Requests mit dem Profil in Anhang C.2 in [BSI-TR-03110] übereinstimmen; b) die vom eid-server an die BerCA der DP Signtrust übermittelten Zertifikats- Requests gegen das Profil in Anhang C.2 in [BSI-TR-03110] geprüft werden, bevor eine Weiterverarbeitung erfolgt. 3.1 Regeln für die Namensgebung Der Bezeichner eines CV-Zertifikates der BerCA der DP Signtrust entspricht den Vorgaben in Anhang A.6.1 in [BSI-TR-03110] und wird im Feld Certificate Holder Reference (CHR) angegeben. Tabelle 4 fasst den allgemeinen Aufbau der Elemente CAR und CHR zusammen (aus [BSI-TR-03110], F = Feste Länge, V = Variable Länge): Element: Kodierung: Länge: Typ: Ländercode ISO ALPHA-2 2F [A..Z]{2} Besitzerkürzel ISO/IEC V alphanumerisch Seriennummer ISO/IEC F alphanumerisch Tabelle 4: Aufbau von CAR und CHR. Der konkreteren Spezifizierung der CHR in [CP-eID] wird im folgenden Abschnitt Rechnung getragen. DP Signtrust und DMDA GmbH 23 Version 1.45 /

24 Certificate Policy (CP) Identifizierung und Authentifizierung Arten von Namen Nicht hoheitliches DV-Zertifikat (CV-Zertifikat): Das Feld Certificate Holder Reference besteht aus den folgenden verketteten Elementen: Certificate Holder Reference (DVCA) Ländercode Besitzerkürzel Seriennummer DE DVeIDDPST DPST ist das Betreiberkürzel (Überlauf: , nicht verwendet) Tabelle 5: Belegung des CHR-Feldes der BerCA DP Signtrust (DVCA). Nicht hoheitliches Terminal-Berechtigungszertifikat (CV-Zertifikat): Die BerCA der DP Signtrust verlangt von ihren Antragstellern, Certificate Holder References gemäß Tabelle 6 zu erzeugen: Certificate Holder Reference (Terminal) Ländercode Besitzerkürzel Seriennummer DE mindestens vier (4) und maximal neun (9) alphanumerische Zeichen (Überlauf: , nicht verwendet) ODER: DE001..DE999 (Überlauf: DE999 DE001, DE000 nicht verwendet) Tabelle 6: Belegung des CHR-Feldes der BerCA DP Signtrust (Terminals). DP Signtrust und DMDA GmbH 24 Version 1.45 /

25 Certificate Policy (CP) Identifizierung und Authentifizierung X.509-Zertifikate: Der Aufbau des Subject-DNs der X.509-Kommunikationszertifikate für den Webservice der BerCA orientiert sich an [ČSN ] und lautet im Falle der BerCA der DP Signtrust: TLS Client: cn=dveiddpst TLS client, o=deutsche Post Signtrust und DMDA GmbH, c=de TLS Server: cn=<dns-name der BerCA> 1, o=deutsche Post Signtrust und DMDA GmbH, c=de Für den CMS-Signer (Black List) lautet der Subject-DN: cn=blacklist Signer, o=deutsche Post Signtrust und DMDA GmbH, c=de Sofern Kommunikationszertifikate von den BerCA-Mandanten angefordert werden, übernimmt die BerCA die Subject-DNs aus den PKCS#10-Requests Notwendigkeit für aussagekräftige Namen Für das Besitzerkürzel im Feld Certificate Holder Reference von Terminal- Berechtigungszertifikaten (Tabelle 6) stellt die BerCA der DP Signtrust die Eineindeutigkeit sicher. Damit sind alle Zertifikatsnehmer eindeutig identifizierbar Anonymität oder Pseudonyme von Zertifikatsnehmern Die Anonymität und Pseudonymität des Zertifikatsnehmers ist nicht erlaubt. Die bis zu neun Zeichen des Besitzerkürzels im CHR der Terminal-Berechtigungszertifikate SOLLTEN vom BerCA-Mandanten bestmöglich in Anlehnung an den Namen der anfragenden Organisation gewählt werden Interpretationsregeln für verschiedene Namensformen Siehe Abschnitt Interpretationsregeln für verschiedene Namensformen in [CP-eID]. 1 In der Version 1.0 dieser CP (OID ) wurde als commonname DVeIDDPST TLS Server verwendet. Zur Verbesserung der Kompatibilität mit Kommunikationspartnern, die keine subjectalternativenames oder Netscape-Zertifikatserweiterungen auswerten, wird der commonname auf die statische IP-Adresse des BerCA-Web-Services der DP Signtrust gesetzt. DP Signtrust und DMDA GmbH 25 Version 1.45 /

26 Certificate Policy (CP) Identifizierung und Authentifizierung Eindeutigkeit von Namen Siehe Abschnitt Eindeutigkeit von Namen in [CP-eID] Anerkennung, Authentifizierung und die Rolle von Markennamen Siehe Abschnitt Anerkennung, Authentifizierung und die Rolle von Markennamen in [CP-eID]. 3.2 Initiale Überprüfung der Identität Siehe Abschnitt 3.2 Initiale Überprüfung der Identität in [CP-eID] (ohne Unterabschnitte) Methoden zur Überprüfung bzgl. Besitz des privaten Schlüssels Siehe Abschnitt Methoden zur Überprüfung bzgl. Besitz des privaten Schlüssels in [CP-eID]. In dem Fall, dass die BerCA der DP Signtrust X.509-Kommunikationszertifikate (TLS) für einen BerCA-Mandanten ausstellt, wird die Selbstsignatur des eingelieferten PKCS#10-Requests überprüft ( proof-of-possession ) Authentifizierung von Organisationszugehörigkeiten Siehe Abschnitt Authentifizierung von Organisationszugehörigkeiten in [CPeID]. Zusätzlich wird in Bezug auf die X.509-TLS-Kommunikationszertifikate, die die Ber- CA der DP Signtrust ausstellt, festgelegt (Unterabschnitt Diensteanbieter in Abschnitt Authentifizierung von Organisationszugehörigkeiten in [CP-eID]): 1. Der BerCA-Mandant KANN ein TLS-Client- und TLS-Server-Zertifikat zur Kommunikation mit der BerCA selbst ausstellen. In diesem Fall MUSS der BerCA-Mandant ein Public Key-Kryptoverfahren selektieren, das zu einer der Cipher-Suiten passt, die in Table 1 TLS Encryption suites in [ČSN ] 2 aufgeführt sind. Je nach der Ausgestaltung der Web-Services (vgl. Hinweis auf Seite 15) bzw. deren Protokollsegmente können bis zu drei (3) Paare von TLS-Client- und TLS-Server-Zertifikaten ausgestellt werden. Das CA-Zertifikat (selbstsigniert) der zweistufigen TLS-Hierarchie MUSS ebenfalls zur BerCA der DP Signtrust übermittelt werden. 2 Die beiden Cipher-Suiten DHE_RSA sind davon ausgenommen. DP Signtrust und DMDA GmbH 26 Version 1.45 /

27 Certificate Policy (CP) Identifizierung und Authentifizierung 2. Der BerCA-Mandant KANN ein TLS-Client- und TLS-Server-Zertifikat zur Kommunikation mit der BerCA durch die BerCA ausstellen lassen. In diesem Fall MUSS der BerCA-Mandant zwei PKCS#10-Requests einreichen. Der AlgorithmIdentifier der SubjectPublicKeyInfo MUSS ein Public Key- Kryptoverfahren spezifizieren, das zu einer der Cipher-Suiten in Table 1 TLS Encryption suites in [ČSN ] passt. Je nach der Ausgestaltung der Web-Services (vgl. Hinweis auf Seite 15) bzw. deren Protokollsegmente können bis zu drei (3) Paare von TLS-Client- und TLS-Server-PKCS#10- Requests eingereicht werden. 3. Zwischen dem BerCA-Mandanten und der BerCA der DP Signtrust wird ein Sperrkennwort vereinbart, durch das der BerCA-Mandant seine TLS- Kommunikationszertifikate in dem internen Sperrregister der BerCA sperren kann. Ein elektronischer Zugang über die Schnittstelle aus [BSI-TR-03129] ist bis zur Ausstellung / Einreichung von Folgezertifikaten dann nicht mehr möglich. 4. Der BerCA-Mandant erhält vom Trustcenter der DP Signtrust ein auf den Bevollmächtigten des BerCA-Mandanten ausgestelltes Zertifikatspaar (Signatur, Verschlüsselung) sowie das Zertifikatspaar (Signatur, Verschlüsselung) des BerCA-Betriebes. Damit kann eine vertrauliche und authentische (fortgeschrittene Signatur) elektronische Kommunikation zwischen der Ber- CA und seinem Mandanten erfolgen Anforderungen zur Identifizierung und Authentifizierung des Zertifikats- Antragstellers Siehe Abschnitt Anforderungen zur Identifizierung und Authentifizierung des Zertifikats-Antragstellers in [CP-eID]; die dort gestellte Forderung erstreckt sich für die BerCA der DP Signtrust auch auf etwaige X.509-Kommunikationszertifikats- Requests für Kommunikationszertifikate Ungeprüfte Angaben zum Zertifikatsnehmer Siehe Abschnitt Ungeprüfte Angaben zum Zertifikatsnehmer in [CP-eID] Prüfung der Berechtigung zur Antragstellung Siehe Abschnitt Prüfung der Berechtigung zur Antragstellung in [CP-eID] Kriterien für den Einsatz interoperierender Systeme/Einheiten Siehe Abschnitt Kriterien für den Einsatz interoperierender Systeme/Einheiten in [CP-eID]. DP Signtrust und DMDA GmbH 27 Version 1.45 /

28 Certificate Policy (CP) Identifizierung und Authentifizierung 3.3 Identifizierung und Authentifizierung von Anträgen auf Schlüsselerneuerung Siehe Abschnitt 3.3 Identifizierung und Authentifizierung von Anträgen auf Schlüsselerneuerung mit allen Unterabschnitten in [CP-eID]. 3.4 Identifizierung und Authentifizierung von Anträgen auf Sperrung Siehe Abschnitt 3.4 Identifizierung und Authentifizierung von Anträgen auf Sperrung mit allen Unterabschnitten in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Wenn sich der Zertifikatsnehmer selbst sperrt, indem er keinen routinemäßigen Wiederholungsantrag mehr stellt, hat dies keinen Einfluss auf den Sperrstatus der TLS-Kommunikationszertifikate, die für den BerCA- Mandanten (=Zertifikatsnehmer) ausgestellt worden sind. 2. Der BerCA-Mandant kann eine Sperrung seiner TLS- Kommunikationszertifikate bei der BerCA der DP Signtrust veranlassen. Hierzu muss der BerCA-Mandant die BerCA der DP Signtrust via 3 kontaktieren (vgl. Abschnitt 4.9 auf Seite 31). 3 verschlüsselt und (fortgeschritten) signiert, vgl. Abschnitt auf Seite 26 DP Signtrust und DMDA GmbH 28 Version 1.45 /

29 Certificate Policy (CP) Betriebsanf. für den Zertifikatslebenszyklus 4 Betriebsanforderungen für den Zertifikatslebenszyklus Siehe Kapitel 4 Betriebsanforderungen für den Zertifikatslebenszyklus (einleitende Sätze ohne Abschnitte) in [CP-eID]. 4.1 Zertifikatsantrag Siehe Abschnitt 4.1 Zertifikatsantrag in [CP-eID] inklusive Unterabschnitte. 4.2 Verarbeitung von Zertifikatsanträgen Durchführung der Identifizierung und Authentifizierung Siehe Abschnitt Durchführung der Identifizierung und Authentifizierung in [CP-eID] Annahme oder Ablehnung von Zertifikatsanträgen Siehe Abschnitt Annahme oder Ablehnung von Zertifikatsanträgen in [CPeID] Fristen für die Bearbeitung von Zertifikatsanträgen Siehe Abschnitt Fristen für die Bearbeitung von Zertifikatsanträgen in [CPeID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Initialer Antrag: 3 Werktage 2. Folgeantrag (bei Sperrung): unverzüglich 3. Folgeantrag (vor Ablauf): 3 Werktage DP Signtrust und DMDA GmbH 29 Version 1.45 /

30 Certificate Policy (CP) Betriebsanf. für den Zertifikatslebenszyklus 4.3 Ausgabe von Zertifikaten Siehe Abschnitt 4.3 Ausgabe von Zertifikaten in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Die BerCA der DP Signtrust stellt für sich selbst eine selbstsignierte Wurzelinstanz der TLS/CMS-Zertifizierungshierarchie aus. Darüber hinaus wird ein TLS-Kommunikationszertifikatepaar bestehend aus TLS-Client- und TLS- Server-Zertifikat auf die BerCA ausgestellt. 2. Der BerCA der DP Signtrust stellt für sich selbst ein CMS-Signaturzertifikat, den sogenannten Blacklist Signer aus. Der private Schlüssel dieses Zertifikates signiert die von der BerCA umgerechneten, sektorspezifischen Sperrlisten ( Black Lists ). 3. Die TLS-Client- bzw. TLS-Server-Zertifikate werden für einen BerCA- Mandanten auf Wunsch ausgestellt, nachdem sich der Antragsteller erfolgreich im Terminalberechtigungsbereich (vgl. Kapitel 3 in [CP-eID]) als berechtigt identifiziert und authentifiziert hat. 4.4 Annahme von Zertifikaten Siehe Abschnitt 4.4 Annahme von Zertifikaten in [CP-eID]. 4.5 Verwendung von Schlüsselpaar und Zertifikat Siehe Abschnitt 4.5 Verwendung von Schlüsselpaar und Zertifikat in [CP-eID] Verwendung des privaten Schlüssels und des Zertifikats durch den Zertifikatsnehmer Siehe Abschnitt Verwendung des privaten Schlüssels und des Zertifikats durch den Zertifikatsnehmer in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Wurzelebene ( Certification Authority ): Das selbstsignierte Wurzelzertifikat bildet den Vertrauensanker der TLS/CMS-Zertifizierungshierarchie für die durch die BerCA der DP Signtrust ausgestellten TLS/CMS-Zertifikate. DP Signtrust und DMDA GmbH 30 Version 1.45 /

31 Certificate Policy (CP) Betriebsanf. für den Zertifikatslebenszyklus 2. EE-Ebene (TLS): Sowohl TLS-Server- als auch TLS-Client-Zertifikat dürfen nur im TLS Handshake Protocol eingesetzt werden, um eine gegenseitige Authentisierung durchzuführen. 3. EE-Ebene (CMS): Das CMS-Zertifikat Blacklist Signer wird als Teil der Zertifikatskette im CMS-Container gespeichert, der eine Black List enthält. Mit dem zugehörigen privaten Schlüssel werden CMS-Container signiert Verwendung des öffentlichen Schlüssels und des Zertifikats durch den Zertifikatsnutzer Siehe Abschnitt Verwendung des öffentlichen Schlüssels und des Zertifikats durch den Zertifikatsnutzer in [CP-eID]. 4.6 Zertifikatserneuerung Siehe Abschnitt 4.6 Zertifikatserneuerung in [CP-eID]. 4.7 Zertifizierung nach Schlüsselerneuerung Siehe Abschnitt 4.7 Zertifizierung nach Schlüsselerneuerung in [CP-eID]. 4.8 Änderungen am Zertifikat Siehe Abschnitt 4.8 Änderungen am Zertifikat in [CP-eID]. 4.9 Sperrung und Suspendierung von Zertifikaten Siehe Abschnitt 4.9 Sperrung und Suspendierung von Zertifikaten in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Die BerCA der DP Signtrust verfügt über ein nicht-öffentliches TLS- Kommunikationszertifikatesperrregister, zu dem (aus technischer Sicht) CRLs generiert und publiziert werden könnten. Eine Generierung und Publizierung von CRLs findet nicht statt. 2. Der BerCA-Mandant kann eine Sperrung seiner TLS- Kommunikationszertifikate bei der BerCA der DP Signtrust veranlassen. DP Signtrust und DMDA GmbH 31 Version 1.45 /

32 Certificate Policy (CP) Betriebsanf. für den Zertifikatslebenszyklus Hierzu muss der BerCA-Mandant die BerCA der DP Signtrust via 4 kontaktieren (vgl. Tabelle 7) und die folgenden Informationen übermitteln: a. Seriennummern der zu sperrenden Zertifikate / des zu sperrenden Zertifikates b. Sperrkennwort c. zwei Sperrgründe (der Grund unspecified ist ebenfalls möglich) d. Im Fall, dass die TLS-Kommunikationszertifikate durch die BerCA ausgestellt wurden: Zwei PKCS#10-Requests für die TLS- Folgezertifikate; ansonsten: ein TLS-Kommunikationszertifikatepaar bestehend aus TLS-Client- und TLS-Server-Zertifikat Die BerCA meldet den Verlauf der Sperrung ebenfalls via an den BerCA-Mandanten. Sofern die TLS-Kommunikationszertifikate (Folgezertifikate) von der BerCA ausgestellt werden, übermittelt die BerCA auch die neuen Zertifikate via an den BerCA-Mandanten. 3. Der BerCA-Mandant MUSS die Sperrung eines TLS-Kommunikationszertifikates (selbst oder von der BerCA der DP Signtrust ausgestellt) unverzüglich beim Betrieb der BerCA veranlassen. Dies gilt auch für die selbstsignierte Wurzel der TLS-PKI eines BerCA-Mandanten (sofern zutreffend). 4. Eine Beendigung der Geschäftsbeziehung zwischen dem BerCA-Mandanten und der BerCA der DP Signtrust führt zur automatischen und unwiderruflichen Sperrung der TLS-Kommunikationszertifikate (Client und Server). Damit ist der Zugang zur BerCA über die Schnittstelle aus [BSI-TR-03129] nicht mehr möglich. 5. Eine Suspendierung (Sperrgrund certificatehold ) bzw. De- Suspendierung von TLS-Kommunikationszertifikaten ist nicht vorgesehen. 4 verschlüsselt und (fortgeschritten) signiert, vgl. Abschnitt auf Seite 26 DP Signtrust und DMDA GmbH 32 Version 1.45 /

33 Certificate Policy (CP) Betriebsanf. für den Zertifikatslebenszyklus Organisation Adresse Deutsche Post Signtrust und DMDA GmbH Charles-de-Gaulle Str. 20, Bonn, Germany Telefon +49 (0) 700 SIGNTRUST bzw. +49 (0) (12,4 ct je angefangene Minute) Webseite Tabelle 7: Kontaktadresse des Trustcenters der DP Signtrust und DMDA GmbH (Darmstadt). DP Signtrust und DMDA GmbH 33 Version 1.45 /

34 Certificate Policy (CP) Betriebsanf. für den Zertifikatslebenszyklus 4.10 Service zur Statusabfrage von Zertifikaten Siehe Abschnitt 4.10 Service zur Statusabfrage von Zertifikaten in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Für die TLS-Kommunikationszertifikate ist keine Statusabfrage, insbesondere via OCSP, möglich. 2. Für das CMS-Signer-Zertifikat ist keine Statusabfrage, insbesondere via OCSP, möglich Beendigung der Teilnahme Siehe Abschnitt 4.11 Beendigung der Teilnahme in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Bei einer Beendigung der Teilnahme erfolgt die sofortige Sperrung der TLS- Kommunikationszertifikate für den BerCA-Mandanten im internen Sperrregister der BerCA der DP Signtrust. Der elektronische Zugang zur BerCA über die PKI-Schnittstelle aus [BSI-TR-03129] ist dann nicht mehr möglich. 2. Bei einer Wiederaufnahme der Teilnahme stellt die BerCA nach der erneuten initialen Überprüfung des Antragstellers auf dessen Verlangen neue TLS- Kommunikationszertifikate aus Hinterlegung und Wiederherstellung von Schlüsseln Siehe Abschnitt 4.12 Hinterlegung und Wiederherstellung von Schlüsseln in [CPeID]. DP Signtrust und DMDA GmbH 34 Version 1.45 /

35 Certificate Policy (CP)Organisatorische, betriebliche und physikalische Sicherheitsmaß 5 Organisatorische, betriebliche und physikalische Sicherheitsmaßnahmen Siehe Kapitel 5 Organisatorische, betriebliche und physikalische Sicherheitsmaßnahmen in [CP-eID]. DPCom GmbH, GF Signtrust 35 Version 1.4 /

36 Certificate Policy (CP) Technische Sicherheitsmaßnahmen 6 Technische Sicherheitsmaßnahmen 6.1 Erzeugung und Installation von Schlüsselpaaren Siehe Abschnitt 6.1 Erzeugung und Installation von Schlüsselpaaren in [CP-eID] Erzeugung von Schlüsselpaaren Siehe Abschnitt Erzeugung von Schlüsselpaaren in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Die Schlüsselpaare für die Wurzelinstanz, die TLS-Client-, die TLS-Serverund die CMS-Signer-Zertifikate der BerCA der DP Signtrust werden in demselben Kryptographie-Modul wie die Schlüsselpaare der CVCA-eID PKI generiert und gespeichert. 2. Die Generierung von Schlüsselpaaren für X.509-Zertifikate erfolgt ebenfalls unter Einhaltung des 4-Augenprinzips. 3. Das Schlüsselmaterial der X.509-Kommunikationszertifikate wird nicht im Hardware-Kryptographie-Modul generiert bzw. vorgehalten, sondern in SoftPSEs organisiert. Es ist als zukünftige Erweiterung geplant, dass die BerCA-Mandanten, die X.509-Kommunikationszertifikate von der BerCA der DP Signtrust beziehen, die Wahlmöglichkeit zum Ort der Speicherung des Schlüsselmaterials eingeräumt bekommen (HSM oder SoftPSE) Lieferung privater Schlüssel an Zertifikatsnehmer Siehe Abschnitt Lieferung privater Schlüssel an Zertifikatsnehmer in [CPeID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Der BerCA-Mandant generiert seine Schlüsselpaare selbst. Es findet keine Lieferung von privaten Schlüsseln statt. Der BerCA-Mandant hat den Beweis des Besitzes des privaten Schlüssels über die Selbstsignatur der PKCS#10- Requests zu führen ( proof-of-possession ). DP Signtrust und DMDA GmbH 36 Version 1.5 /

37 Certificate Policy (CP) Technische Sicherheitsmaßnahmen Lieferung öffentlicher Schlüssel an Zertifikatsherausgeber Siehe Abschnitt Lieferung öffentlicher Schlüssel an Zertifikatsherausgeber in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. PKCS#10-Requests (u.a. Lieferung des öffentlichen Schlüssels) werden vom Bevollmächtigten des BerCA-Mandanten entweder persönlich oder via (fortgeschritten) signierter an die BerCA übermittelt. Alternativ kann die Übermittlung per ungesicherter erfolgen, wenn anschließend die SHA-1-Hashes telefonisch abgeglichen werden Lieferung öffentlicher Schlüssel der CA an Zertifikatsnutzer Siehe Abschnitt Lieferung öffentlicher Schlüssel der CA an Zertifikatsnutzer in [CP-eID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Die X.509-Zertifikate werden dem BerCA-Mandanten entweder persönlich oder via übergeben Schlüssellängen und kryptographische Algorithmen Siehe Abschnitt Schlüssellängen und kryptographische Algorithmen in [CPeID]. Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Die unterstützten Cipher-Suiten sind in [ČSN ], Table 1 TLS Encryption Suites aufgeführt. Die beiden DHE_RSA -Verfahren werden indes nicht unterstützt. 2. Für ECDH und ECDSA gelten die Schlüssellängen aus [BSI-TR ]; RSA-Schlüsselpaare MÜSSEN eine Mindestlänge von 2048 Bits aufweisen Festlegung der Parameter der öffentlichen Schlüssel und Qualitätskontrolle Siehe Abschnitt Festlegung der Parameter der öffentlichen Schlüssel und Qualitätskontrolle in [CP-eID]. DP Signtrust und DMDA GmbH 37 Version 1.45 /

38 Certificate Policy (CP) Technische Sicherheitsmaßnahmen Für die X.509-TLS/CMS-Zertifikate, die die BerCA der DP Signtrust ausstellt, wird zusätzlich festgelegt: 1. Der Antragsteller MUSS sicherstellen, dass sein Zertifikats-Request konform zu [PKCS#10] ist und den Anforderungen dieser Policy ist. 2. Ferner MÜSSEN die Systeme des Antragstellers eine automatische diesbezügliche Prüfung anschließend an die Generierung durchführen Verwendungszweck der Schlüssel Siehe Abschnitt Verwendungszweck der Schlüssel in [CP-eID]. 6.2 Sicherung des privaten Schlüssels und Anforderungen an kryptographische Module Siehe Abschnitt 6.2 Sicherung des privaten Schlüssels und Anforderungen an kryptographische Module in [CP-eID]. Die vorliegende CP DVeIDDPST konkretisiert die Vorgaben aus [CP-eID] für die BerCA der DP Signtrust wie folgt: 1. Es werden nur HSMs gemäß [PP-CM-m] eingesetzt. 2. Durch die Wahl des eingesetzten HSM-Produktes werden die Alternativanforderungen aus [CP-eID] und [FreigabeHSM] für den Übergangszeitraum bis zum Widerruf erfüllt, bis ein zertifiziertes Produkt vorliegt Mehrpersonen-Zugriffssicherung zu privaten Schlüsseln Siehe Abschnitt Mehrpersonen-Zugriffssicherung zu privaten Schlüsseln in [CP-eID] Hinterlegung privater Schlüssel Siehe Abschnitt Hinterlegung privater Schlüssel in [CP-eID] Backup privater Schlüssel Siehe Abschnitt Backup privater Schlüssel in [CP-eID]. DP Signtrust und DMDA GmbH 38 Version 1.5 /

39 Certificate Policy (CP) Technische Sicherheitsmaßnahmen Archivierung privater Schlüssel Siehe Abschnitt Archivierung privater Schlüssel in [CP-eID] Transfer privater Schlüssel in oder aus kryptographischen Modulen Siehe Abschnitt Transfer privater Schlüssel in oder aus kryptographischen Modulen in [CP-eID] Speicherung privater Schlüssel in kryptographischen Modulen Siehe Abschnitt Speicherung privater Schlüssel in kryptographischen Modulen in [CP-eID] Aktivierung privater Schlüssel Siehe Abschnitt Aktivierung privater Schlüssel in [CP-eID] Deaktivierung privater Schlüssel Siehe Abschnitt Deaktivierung privater Schlüssel in [CP-eID] Zerstörung privater Schlüssel Siehe Abschnitt Zerstörung privater Schlüssel in [CP-eID] Beurteilung kryptographischer Module Siehe Abschnitt Beurteilung kryptographischer Module in [CP-eID]. 6.3 Andere Aspekte des Managements von Schlüsselpaaren Archivierung öffentlicher Schlüssel Siehe Abschnitt Archivierung öffentlicher Schlüssel in [CP-eID]. Die BerCA der DP Signtrust archiviert öffentliche Schlüssel unbegrenzt. DP Signtrust und DMDA GmbH 39 Version 1.45 /