Namensregeln und -formate

Transkript

1 Zertifizierungsinfrastruktur für die PKI-1-Verwaltung Namensregeln und -formate Bundesamt für Sicherheit in der Informationstechnik Version 1.3 vom

2 Dr. Volker Hammer, Dr. Dörte Neundorf Jörg Völker Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D Karlsruhe hammer@secorvo.de neundorf@secorvo.de voelker@secovo.de Dr. Albrecht Rosenhauer Dr. Andreas Schmidt Michael Thiel Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee D Bonn Albrecht.Rosenhauer@bmi.bund.de Andreas.Schmidt@bsi.bund.de Michael.Thiel@bsi.bund.de Dieses Dokument einschließlich aller Teile ist urheberrechtlich geschützt. Die unveränderte Weitergabe (Vervielfältigung) des Dokuments ist ausdrücklich erlaubt. Jede weitergehende Verwertung außerhalb der engen Grenzen des Urhebergesetzes ist ohne Zustimmung des Bundesamtes für Sicherheit in der Informationstechnik unzulässig und strafbar Bundesamt für Sicherheit in der Informationstechnik Godesberger Allee , Bonn Telefon: 0228/ Telefax: 0228/

3 Inhaltsübersicht Änderungshistorie 4 Literaturverzeichnis 5 Glossar und Abkürzungen 6 1 Einleitung und Übersicht Zweck des Dokuments Anwendungsbereich Struktur des Dokuments 10 2 Grundlagen der Namensvergabe Namen in Verzeichnisdiensten Namen in Public-Key-Infrastrukturen Schreibweise von Distinguished Names 14 3 Organisatorische Verantwortlichkeiten der Namensvergabe 14 4 Generelle Vorgaben und Empfehlungen Eindeutigkeit von Distinguished Names Umlaute Bund, Länder und Kommunen 17 5 Subject Distinguished Names (DNs) Grundsätzliche Regeln für Subject DNs Subject-DNs für Wurzelzertifizierungsinstanz und Zertifizierungsinstanzen Namensregel für Subject-DNs von PCA und CAs Festgelegte Subject-DNs für Zertifizierungsinstanzen Beispiele für Subject-DNs von Zertifizierungsinstanzen Subject-DNs für natürliche und juristische Personen Namensregeln für Subject-DNs für Endanwender Beispiele für Subject-DNs für Endanwender Subject Distinguished Names bei Verwendung von Pseudonymen Namensregeln für Subject-DNs bei Verwendung von Pseudonymen Beispiele für Subject-DNs bei Verwendung von Pseudonymen 30 BSI Namensregeln und -formate Seite 3 von 53

4 5.5 Subject Distinguished Names für Personengruppen, Funktionen und automatisierte IT-Prozesse Namensregeln für Gruppen Beispiele für Subject-DNs bei Gruppen- und SSL-Server- Zertifikaten 33 6 Namen in Directories DIT-DN für Zertifizierungsinstanzen DIT-Namensregeln für Zertifizierungsinstanzen DIT-Namensregeln für Windows 2000 CAs Beispiele für DIT-DNs von Zertifizierungsinstanzen DIT-DNs für CRL Distribution Points DIT-Namensregeln für CDPs DIT-Namensregeln für CDPs für Windows 2000 CAs Beispiele für DIT-DNs von CDPs DIT-DN für Teilnehmer DIT-Namensregeln für Teilnehmer 37 Anhänge: Format-Spezifikationen für Namen 41 Änderungshistorie Version Datum Status, Änderungen Autoren Empfehlung für die konsolidierten Namensregen der PKI-1- Verwaltung. Vorlage zur internen Abstimmung im BSI. Entscheidungen, die vom BSI zu treffen sind, sind wie folgt gekennzeichnet: <?? Klärungsbedarf BSI??> Die Beispiele und Abbildungen müssen auf Eignung geprüft und gegebenenfalls angepasst werden, einschließlich Groß- und Kleinschreibung Anmerkungen eingearbeitet von: Sitzung des Editorial Board zum Verzeichnisdienstkonzept vom , Herr Klasen, Herr Gietz (DAASI), Herr Thiel (PCA) Anmerkungen eingearbeitet von: Projektgruppe PKI (BSI) Herr Thiel (PCA) Jörg Völker, Dörte Neundorf, Volker Hammer Volker Hammer Andreas Schmidt (Ref I 1.3) Einarbeitung von Korrekturen Andreas Schmidt (Ref I 1.3) BSI Namensregeln und -formate Seite 4 von 53

5 Version Datum Status, Änderungen Autoren Einarbeitung von Korrekturen nach Vorstellung der Namensregeln auf der AG KS des KoopA in Schwerin Freigabe der Erweiterung für SSL u. Änderungen aufgrund: SSL-Studie (Jörg Völker, Hans-Joachim Knobloch) Andreas Schmidt (Ref I 1.3) Andreas Schmidt (Ref I 1.3, BSI) Policy-Anpassung Literaturverzeichnis [ISIS 99] [ISIS-MTT] [MTT-PRO 99] [PKCS#9 00] [PKI1V Namensformat MTT] [PKI1V-VDK-Erg] [Regelung GrpZertifikate] Arbeitsgemeinschaft Trust-Center für digitale Signaturen: Industrial Signature Interoperability Specification ISIS, Version 1.2, ISIS-MTT - T7 & TeleTrusT (2001): ISIS-MTT Common ISIS-MTT Specification For PKI Applications, Version 1.0.2, September Juli 2002, oder PART 1 - Certificate and CRL Profiles PART 4 -Operational Protocols (LDAP, OCSP, TSP) TeleTrusT: MailTrusT-Spezifikation Version 2 - Profile für Zertifikate und Sperrlisten; März 1999 M. Nystrom, B. Kaliski: Selected Object Classes and Attribute Types PKCS #9 v2.0, <draft-nystrom-pkcs9-v2-00.txt>, March 2000 BSI - Bundesamt für Sicherheit in der Informationstechnik (Hrsg.) (2001): Zertifizierungsinfrastruktur für die PKI-1-Verwaltung Technische Grundlagen der Wurzelzertifizierungsstelle - Namensformat nach MTTv2, aktuelle Version BSI (Hrsg.): Zertifizierungsinfrastruktur für die PKI-1-Verwaltung: Verzeichnisdienstkonzept, (Abschlussdokument) BSI: Regelungen für Gruppenzertifikate, aktuelle Version [PKIX QC 00] S. Santesson, W. Polk, and P. Glöckner: Internet X.509 Public Key Infrastructure - Qualified Certificates Profile, <draft-ietf-pkix-qc-03.txt>, April 2000 [RFC 822] [RFC 2252] [RFC 2459] RFC 822 (1982): RFC Standard for ARPA Internet Text Messages, IETF, 1982, z.b. ftp://ietf.org/. Wahl, M. / Coulbeck, A./ Howes, T. / Kille, S. (1997): RFC Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, IETF, 1997, z.b. ftp://ietf.org/. Housley, R. / Ford, W. / Polk, W. / Solo, D. (1999): RFC Internet X.509 Public Key Infrastructure Certificate and CRL Profile, IETF, 1999, z.b. ftp://ietf.org/. [RFC 2632] B. Ramsdell: RFC S/MIME Version 3 Certificate Handling, June 1999 [Sphinx Namen] BSI - Bundesamt für Sicherheit in der Informationstechnik (Hrsg.) (2000): Sphinx - Sichere - Spezifikation und Verwendung von Namen in einer PKI (Namenskonzept), Version 1.1, Bonn, BSI Namensregeln und -formate Seite 5 von 53

6 [X.500 ff 1997] ITU-T X.500 International Telecommunication Union - Telecommunication Sector (1997): ITU-T Recommendation X.500 Ff Information Technology - Open Systems Interconnection- The Directory: X.500: Overview Of Concepts, Models, And Services X.501: Models X.509: Authentication Framework X.511: Abstract Service Definition X.518: Procedures For Distributed Operation X.519: Protocol Specifications X.520: Selected Attribute Types X.521: Selected Object Classes X.525: Replication X.530: Use of Systems Management for Administration of the Directory Glossar und Abkürzungen Attribut Attribut-Typ Austausch-DIT BSI CA CDP cn CRL Dienste des Verzeichnisdienstkonzepts Bezeichnet den Speicherplatz für Werte eines bestimmten Typs, z. B. Surname oder OrganizationalUnitName. Attribute treten in zwei Rollen auf: als Bestandteile eines eindeutigen Namens (Distinguished Name). Der Distinguished Name besteht aus einer Reihe von Attributen, deren Reihenfolge festgelegt ist. In der Reihenfolge können an unterschiedlichen Stellen Attribute gleichen Typs auftreten. als Speicherplatz für Werte in einem Entry. Ein Entry kann verschiedene Attribute enthalten. Ein Attribut kann so definiert werden, dass es nur einen einzelnen Wert (singlevalued) oder mehrere Werte des Typs aufnehmen kann (multi-valued). Attribut-Typen dienen der Spezifikation von Attributen für das Directory Schema. Mit ihnen wird die Semantik und die Codierung von Werten bestimmt. Sie werden benutzt, um Objektklassen zu definieren. Ein Attribut ist die Instanz eines Attribut-Typs in einem Entry oder Distinguished Name. Abkürzung für den gemeinsamen (einheitlichen) Directory Information Tree ( DIT) der drei Dienste des Verzeichnisdienstkonzepts. Abkürzung für Bundesamt für Sicherheit in der Informationstechnik. Abkürzung für Certification Authority. Abkürzung für CRL Distribution Point. 1) Im Directory kann es CDP-Entries geben, die Sperrlisten beinhalten. Unter bestimmten Umständen kann dies die Verwaltung der Sperrlisten oder den Zugriff darauf erleichtern. 2) Im Zertifikat kann ein CDP angegeben sein, der direkt auf den Speicherort der Sperrliste (nämlich den CDP im Verzeichnis) verweist. Dies kann Clients das Auffinden der zugehörigen Sperrliste erleichtern. Abkürzung für Common Name (Attribut-Typ). Abkürzung für Certificate Revocation List, Sperrliste mit Verweisen auf gesperrte Zertifikate von Teilnehmern und CAs. Zusammenfassend für die drei Dienste, die im Verzeichnisdienstkonzept spezifiziert werden: zentraler Verzeichnisdienst der Verwaltung, Austauschdienst und Veröffentlichungsdienst. BSI Namensregeln und -formate Seite 6 von 53

7 DIT DIT-DN Endanwender Entry Funktionszertifikat gn Gruppenzertifikat IVBB IETF Issuer DN ITU-T ksx l LDAP LDAP-Schreibweise von DIT-DNs Abkürzung für Directory Information Tree. Bezeichnet die Struktur, in der die Entries im Directory abgelegt werden. Der DIT wird durch eine Folge von Namen aufgespannt, die jeweils relativ zum übergeordneten Knoten eindeutig sein müssen. Jeder Entry im DIT wird durch seinen DIT-Distinguished Name eindeutig gekennzeichnet. Der DIT-DN entspricht damit einem Datenbankschlüssel für die Einträge im Directory. Abkürzung für Directory Information Tree Distinguished Name, eindeutiger Name (und Identifier) eines Entries im Directory. Siehe auch DIT und LDAP-Schreibweise von DIT-DNs. Zur Unterscheidung siehe Subject-DN und Issuer-DN. Der DIT-DN eines Teilnehmer-Entries und sein Subject-DN im Zertifikat können übereinstimmen, müssen dies aber nicht unbedingt. Abkürzung für -Address (Attribut-Typ) Natürliche oder juristische Person, die Teilnehmer und Inhaber eines Zertifikates der PKI ist. Die Informationen zu einem Objekt (Teilnehmer oder Zertifizierungsinstanz) werden in einem sogenannten Entry im Verzeichnisdienst gespeichert. Der Entry umfasst, quasi als Container, mehrere Attribute. In den Attributen werden die einzelnen Werte abgelegt, die dem Objekt zugeordnet sind, beispielsweise die -Adresse, der Nachname oder das Zertifikat eines Teilnehmers. Jeder Entry wird eindeutig durch einen eindeutigen Namen im Directory adressiert, dem sogenannten DIT Distinguished Name DIT-DN. Das Zertifikat wird auf den Namen einer Funktion, beispielsweise einen automatischen -Dienst, ausgestellt. Der Zugriff auf den geheimen Schlüssel kann, anders als für persönliche Schlüsselpaare, mehreren Personen eingeräumt werden. Abkürzung für Given Name (Attribut-Typ). Das Zertifikat wird auf den Namen einer Gruppe ausgestellt. Der Zugriff auf den geheimen Schlüssel wird, anders als für persönliche Schlüsselpaare, mehreren Personen eingeräumt. Abkürzung für Informationsverbund Berlin-Bonn. Abkürzung für Internet Engineering Task Force, Standardisierungsgremium (siehe Issuer Distinguished Name, eindeutiger Name des Ausstellers eines Zertifikats, im Zertifikat enthalten. Zur Unterscheidung siehe Subject-DN und DIT-DN. Abkürzung für International Telecommunication Union - Telecommunication Sector, internationale Standardisierungsorganisation für Telekommunikation, vormals Comité Consultatif International Télégraphique et Téléphonique (CCITT) Abkürzung für kommunales Szenario x, wobei x eine Nummer ist. Die Szenarien werden in Kapitel 4.3 erklärt. kleines "L" als Abkürzung für Locality (Attribut-Typ). Abkürzung für Lightweight Directory Access Protocol (standardisiert durch RFCs im Unterschied zum Directory Access Protocol (DAP) des X.500- Standards). LDAP legt lediglich fest, mit welchen Kommandos eine Information abgefragt oder geändert werden kann, macht aber keine Aussagen über die Ablage der Daten. Auch "echte" X.500 Server oder Standard-Datenbanken können LDAP "sprechen". Die LDAP-Schreibweise von DIT-DNs beginnt beim Blatt-Entry und folgt den Knoten aufsteigend zur Wurzel des DIT, also bspw. "cn=mustermann Peter, o=muster GmbH, c=de". BSI Namensregeln und -formate Seite 7 von 53

8 MTT Namensgebendes Attribut o ou pn PCA PCA-1-Verwaltung PKI PKI-1-Verwaltung PKI-Informationen Relative Distinguished Name RFC sn SSL Steuerungsgremium der PKI-1-Verwaltung Subject-DN Teilnehmer TESTA UNICODE UTF8 MailTrusT, Standard für Formate und Dienste von PKIs und für Anwendungen, die PKI-Leistungen nutzen, z. B. zur Verschlüsselung von E- Mails. Das "unterste" Attribut des DIT-DN, das den Namen des Entries von den anderen Entries auf der gleichen Ebene unterscheidet, wird als namensgebendes Attribut oder Relative Distinguished Name bezeichnet. Abkürzung für Organization Name (Attribut-Typ). Abkürzung für Organizational Unit Name (Attribut-Typ). Abkürzung für Pseudonym (Attribut-Typ). Abkürzung für Policy Certification Authority, PCA-1-Verwaltung. Wurzelzertifizierungsinstanz der PKI-1-Verwaltung, betrieben vom BSI Public Key Infrastruktur, Infrastruktur zur Bereitstellung von öffentlichen Schlüsseln, Zertifikaten und Sperrinformationen. PKI der öffentlichen Verwaltung der Bundesrepublik Deutschland. Sie umfasst alle PKIs, die durch die PCA-1-Verwaltung für die öffentliche Verwaltung zertifiziert werden. Oberbegriff für Teilnehmer-Zertifikate, CA-Zertifikate und Sperrlisten Der Relative Distinguished Name ist ein Namensteil des DIT Distinguished Name, der auf einer Ebene des DIT Eindeutigkeit sicherstellt. Für den Wert eines Relative Distinguished Names eines Entries ist gefordert, dass er sich von allen anderen Relative Distinguished Names auf der gleichen Ebene seines Teilbaums unterscheidet. Abkürzung für Request for Comment, Standardisierungsdokumente der IETF. Abkürzung für Surname Name (Attribut-Typ). Abkürzung für Secure Socket Layer, Protokoll zur Absicherung von Internet- Verbindungen, das Zertifikate zur Authentisierung von Server und (optional) Client nutzt. Gegenwärtig wird geklärt, wie die an der PKI-1-Verwaltung beteiligten Domänen und CAs gemeinsam die Weiterentwicklung dieser PKI und des Verzeichnisdienstkonzepts steuern. Das künftig zuständige Gremium wird zusammenfassend als "Steuerungsgremium der PKI-1-Verwaltung" bezeichnet. Subject Distinguished Name, eindeutiger Name des Inhabers eines Zertifikats, im Zertifikat enthalten. Zur Unterscheidung siehe Issuer DN und DIT DN. Personen, Personengruppen, Funktionen oder Dienste (IT-Prozesse), die im Rahmen der PKI-1-Verwaltung Schlüssel und Zertifikate erhalten oder aus dem Verzeichnisdienst PKI-Informationen von CAs oder Teilnehmern abrufen. Abkürzung für Trans European Services for Telematics between Administration Zeichentabelle zur Umsetzung von bestimmten Zeichnen (Buchstaben, Zahlen) in numerische Äquivalente. Enthält insbesondere auch Umlaute und weitere Sonderzeichen. Codierungsvorschrift zur Codierung von UNICODE-Zeichen in Texten und Nachrichten X.500 ff. Serie von Standards der ITU-T für Verzeichnisdienste. BSI Namensregeln und -formate Seite 8 von 53

9 1 Einleitung und Übersicht 1.1 Zweck des Dokuments Die in der PKI-1-Verwaltung ausgestellten Zertifikate und Sperrlisten (PKI-Informationen) enthalten Namen für Schlüsselinhaber. Die PKI-Informationen können außerdem in Verzeichnisdiensten bereitgestellt werden. Die PKI- Informationen sind im Verzeichnis in sogenannten Entries gespeichert. Die Datenbankschlüssel zum Zugriff auf die Entries sind ebenfalls wie Namen aufgebaut. Zertifikate können auch Hinweise auf solche Bezugsstellen für PKI- Informationen enthalten, z. B. auf Namen von CDPs im Directory. Um einen ordnungsgemäßen Betrieb der PKI-1-Verwaltung sicherzustellen und den Austausch von PKI-Informationen zwischen verschiedenen Verzeichnisdiensten zu ermöglichen, müssen die verwendeten Namen beider Typen Mindestanforderungen genügen. Dieses Dokument legt im erforderlichen Rahmen fest, wie in der PKI-1-Verwaltung Namen zu bilden sind. Die Namensregelung findet Verwendung für alle Zertifikate, die innerhalb der Infrastruktur erzeugt werden. Die Regeln sind normativ für alle Zertifizierungsinstanzen, die der PKI-1-Verwaltung beitreten ("Vertrags CAs") und für die diesen nachgeordneten Zertifizierungsinstanzen. Dieses Dokument löst die Namensregeln aus [Sphinx Namen] und [PKI1V Namensformat MTT] ab und konsolidiert die Inhalte. Das vorliegende Dokument führt die Namensregeln aus den Vorgänger-Dokumenten weiter und präzisiert sie in einigen Punkten. Die Namensregeln für Entries in den lokalen Verzeichnisdiensten der Vertrags-CAs stellen die Konsistenz mit den Prozessen des Verzeichnisdienstkonzepts [PKI1V-VDK-Erg] sicher. Die Regeln für Namen in den zentralen Diensten des Verzeichnisdienstkonzepts ("Austausch-DIT") sind in diesem Dokument nicht enthalten. Diese Namen werden durch Prozesse automatisch erzeugt und sind daher für die Vertrags- CAs nur mittelbar relevant. Diese speziellen Namensregeln sind in [PKI1V- VDK-Erg] dokumentiert. BSI Namensregeln und -formate Seite 9 von 53

10 Anfragen zur Weiterentwicklung der Namensregeln sind an die PCA der PKI-1- Verwaltung zu richten. Sie können dadurch in einen Change-Management-Prozess einfließen. 1.2 Anwendungsbereich Dieses Dokument regelt die Vergabe von Distinguished Names innerhalb der PKI-1-Verwaltung für die Wurzelzertifizierungsinstanz, alle nachgeordneten Zertifizierungsinstanzen, natürliche Personen, juristische Personen mit einem personenbezogenen Zertifikat, Gruppenzertifikate (z.b. für Personengruppen, Funktionen oder automatisierte IT-Prozesse) Zertifikate für SSL-Dienste und CRL Distribution Points. Die Namensregeln sind normativ für alle Zertifizierungsinstanzen, die der PKI-1- Verwaltung beitreten (Vertrags-CAs) und den diesen nachgeordneten CAs. Soweit Regeln für die Einträge in Verzeichnisdienste enthalten sind, sind diese ebenfalls für alle Beteiligten verbindlich. Für Teilnehmer werden die Namen für Zertifikate zur Sicherung von und zur Sicherung von Web-Verbindungen über SSL definiert. Namen für andere Typen von Zertifikaten müssen bei Bedarf ergänzt werden. 1.3 Struktur des Dokuments Das Dokument ist wie folgt aufgebaut: Kapitel 2 gibt einen Überblick über die Grundlagen der Namensvergabe in Public-Key-Infrastrukturen. BSI Namensregeln und -formate Seite 10 von 53

11 Kapitel 3 bestimmt die organisatorischen Verantwortlichkeiten der Namensvergabe innerhalb der PKI-1-Verwaltung. Kapitel 4 beschreibt die grundsätzlichen Anforderungen, die an Namen innerhalb der PKI-1-Verwaltung gestellt werden. Kapitel 5 legt die Regeln für die Vergabe von Subject Distinguished Names für verschiedene Typen von Zertifikatinhabern fest. Kapitel 6 beschreibt die Regeln für die Vergabe von Distinguished Names für Entries in lokalen Verzeichnisdiensten. In den Anhängen finden sich technische Formatbeschreibungen für Distinguished Names. 2 Grundlagen der Namensvergabe Das Kapitel gibt einen knappen Überblick über die Verwendung von Namen in Public-Key-Infrastrukturen (PKI) und den dort eingesetzten Verzeichnisdiensten. Es führt dabei die Begriffe ein, die in diesem Dokument verwendet werden. Historisch ist der Aufbau von Namen in Zertifikaten aus denen für Entries in Verzeichnisdiensten übernommen. 2.1 Namen in Verzeichnisdiensten Dieser Abschnitt gibt einen knappen Überblick über die Art, wie Informationen in Verzeichnisdiensten gespeichert werden. Verzeichnisdienste (Directories) sind wie eine hierarchische Datenbank organisiert. Jedes Objekt, zu dem Informationen in einem Directory gespeichert werden, erhält im Verzeichnisdienst als eindeutigen Schlüssel einen "Directory Namen", den sogenannten Distinguished Name (DN). Objekte sind z. B. ein Teilnehmer, eine Zertifizierungsinstanz oder eine Organisationseinheit. Jeder Name kennzeichnet einen sogenannten Entry, in dem die Informationen zum Objekt abgelegt werden. Die Distinguished Names der Objekte werden hierarchisch organisiert. Beispielsweise werden die Entries der Mitarbeiter einer BSI Namensregeln und -formate Seite 11 von 53

12 Organisation "unter" dem Entry der Organisation gespeichert. Die Organisation wiederum wird dem Land untergeordnet, in dem sie angesiedelt ist, z. B. für Deutschland unter "c=de". Der Distinguished Name ergibt sich dann aus der Folge der relativen Namen (der sogenannten Relative Distinguished Names, RDN) vom Teilnehmer-Knoten bis zur Wurzel, z. B. cn=müller Peter, l=berlin, ou=bmi, o=bund, c=de (vgl. Abb. 1). c=de c=de o=bund o=bund o=thüringen o=thüringen o=stadt Köln o=stadt Köln ou=bmwi ou=bmwi ou=bmi ou=bmi ou=bsi ou=bsi l=berlin l=berlin cn=müller Peter cn=peter Müller Abbildung 1: Beispiel für einen Directory Information Tree. Der Teilnehmer-Entry liegt im Teilbaum des IVBB) Die Entries der sich ergebenden Struktur bilden einen Baum, den sogenannten Directory Information Tree oder DIT. Um den Namen, der die Platzierung eines Entries im DIT bestimmt, von anderen Namen unterscheiden zu können, wird er im Weiteren als DIT-DN (Directory Information Tree Distinguished Name) bezeichnet. Für jeden Entry ergibt sich somit aus DIT-Struktur die Struktur seines eindeut i- gen Namens und die zulässigen Namens-Teile, die sogenannten Attribute. Das "unterste" Attribut, das den Namen des Entries von den anderen Entries auf der gleichen Ebene unterscheidet, wird auch als namensgebendes Attribut bezeichnet (entspricht dem Relative Distinguished Name dieser Ebene). In Abbildung 1 wäre dies für den Teilnehmer-Entry der cn. BSI Namensregeln und -formate Seite 12 von 53

13 2.2 Namen in Public-Key-Infrastrukturen Der DIT-Distinguished Name ist zu unterscheiden von den Namen im Zertifikat. Sie werden auch als Distinguished Names bezeichnet und müssen ebenfalls eindeutig gewählt werden. Das Format solcher Namen entspricht denen für Entries in Directories, allerdings haben sie andere Zwecke. Distinguished Names werden nach [ITU-T X ] in Zertifikaten und in Sperrlisten verwendet. In Zertifikaten sind mindestens zwei Namen enthalten: der Name des Zertifikatsinhabers (Subject-DN) und der Name der ausstellenden Instanz (Issuer-DN). In Sperrlisten wird der Aussteller einer Sperrliste (Issuer-DN) angegeben. In einer PKI werden Distinguished Names unter anderem verwendet zur eindeutigen Benennung der Wurzel-Zertifizierungsinstanz (Policy Certification Authority, PCA), von nachgeordneten Zertifizierungsinstanzen (Certification Authority, CA), von Verteilungsstellen für Sperrlisten (Certificate Revocation List Distribution Point, CDP) und von Teilnehmern (Personen, Gruppen, Funktionen oder Dienste bzw. IT- Prozesse). Die PKI-Informationen können in Verzeichnisdiensten bereitgestellt werden. Daher werden Distinguished Names aus der Sicht der PKI auch zur Adressierung von Entries für Teilnehmer und PKI-Komponenten in Verzeichnisdiensten verwendet. Die Namen für Entries im Verzeichnisdienst (DIT-DNs) müssen nicht zwingend identisch mit den Namen der zugehörigen Zertifikate sein (Subject-DN). Die in der PKI-1-Verwaltung zulässigen Abweichungen sind im Zusammenhang mit den Namensregeln aufgeführt. Für die genannten Komponenten definiert dieses Dokument Namensregeln mit den folgenden Zielen: BSI Namensregeln und -formate Seite 13 von 53

14 Die Namensgebung und Namensstruktur für die einzelnen PKI-Komponenten soll einheitlichen Konventionen folgen. Die Distinguished Names der verschiedenen PKI-Komponenten und der Teilnehmer sollen unterscheidbar sein. Auch verschiedene Typen von Teilnehmer-Namen sollen anhand gleicher Kennzeichen leicht zu unterscheiden sein, z. B. Namen für persönliche Zertifikate von solchen für Zertifikate von Gruppen. Es soll ein Austausch von PKI-Informationen zwischen verschiedenen Verzeichnisdiensten möglich werden, insbesondere die Bereitstellung von CA- Zertifikaten und Sperrlisten in den Diensten des Verzeichnisdienstkonzepts. 2.3 Schreibweise von Distinguished Names In diesem Dokument werden Distinguished Names in der LDAP-Schreibweise angegeben ([RFC 2252]). In dieser Form wird der "unterste" Relative Distinguished Name zuerst und der "oberste" Knoten im Namensbaum zuletzt angegeben, also beispielsweise der commonname zuerst und der countryname zuletzt. Werden weitere Attribute verwendet, sind sie entsprechend einzureihen, vgl. auch das Beispiel in Abbildung 1. Die genaue technische Syntax der Distinguished Names wird im Anhang beschrieben. 3 Organisatorische Verantwortlichkeiten der Namensvergabe Mit den Zertifizierungsinstanzen, die der PKI-1-Verwaltung beitreten (Vertrags- CAs), wird im Rahmen des Beitrittsverfahrens zur PKI-1-Verwaltung ein Namensraum für CAs (CA-Namensraum) und ein Namensraum für Teilnehmer (Teilnehmer-Namensraum) vereinbart. Die Vertrags-CAs sind gemäß ihrer Selbsterklärung verpflichtet, die Namensregeln der PKI-1-Verwaltung einzuhalten und die Eindeutigkeit von Subject-DNs in ihrem Namensraum BSI Namensregeln und -formate Seite 14 von 53

15 sicherzustellen. In diesem Namensraum dürfen sie Teilnehmer-Zertifikate ausstellen und auch nachgeordnete Zertifizierungsinstanzen bestätigen. Vertrags-CAs der PKI-1-Verwaltung müssen gewährleisten, dass innerhalb ihres CA-Namensraumes jede nachgeordnete CA einen eindeutigen Subject-DN nach den Regeln dieses Dokuments erhält, jede nachgeordnete CA die Regeln dieses Dokuments für die Subject-DNs von Teilnehmern einhält, gegebenenfalls ausgelagerte Registrierungsstellen auf die Einhaltung der Regeln verpflichtet werden und Verzeichnisdienste die Regeln für DIT-DNs von Entries einhalten, wenn diese in die Dienste des Verzeichnisdienstkonzepts repliziert werden. Andernfalls kann eine Veröffentlichung im Rahmen dieser Dienste nicht gewährleistet werden. Zumindest für CA- und CDP-Entries ist deshalb die Einhaltung der Regeln verbindlich. 4 Generelle Vorgaben und Empfehlungen Die folgenden Regelungen gelten grundsätzlich für alle im Rahmen der PKI-1- Verwaltung verwendeten Subject-DNs und DIT-DNs. 4.1 Eindeutigkeit von Distinguished Names Ein Distinguished Name muss einen Teilnehmer oder eine PKI-Komponente eindeutig identifizieren. In Zertifikaten und Sperrlisten ist dies nötig, um eindeutig auf den Schlüsselinhaber zurückschließen zu können. In Verzeichnisdiensten ist die Eindeutigkeit aus technischen Gründen erforderlich, da der Distinguished Name dort die Rolle des Datenbankschlüssels übernimmt. Die Namensraumvergabe für Zertifikate und Verzeichnisdienste ist hierarchisch strukturiert, um Eindeutigkeit auf einfache Weise erreichen zu können. BSI Namensregeln und -formate Seite 15 von 53

16 Für Namen in Zertifikaten und Sperrlisten vereinbart jede Vertrags-CA mit der PCA einen eindeutigen Namensraum. Die Namen, die die Vertrags-CA vergibt, dürfen nur innerhalb dieses Namensraumes liegen (vgl. auch Abbildung 1). Die Vertrags-CA muss ihrerseits sicherstellen, dass diese Namen eindeutig sind. Die Anforderungen an die Namen von Entries ergeben sich zum Teil ebenfalls aus dem mit der Vertrags-CA vereinbarten Namensraum. Außerdem können für Verzeichnisdienste auf andere Weise ebenfalls eindeutige Namensräume bestimmt werden, innerhalb derer dann die lokalen Namen vergeben werden. Soweit die Vertrags-CA die größeren Gestaltungsspielräume nutzt, muss sie jedoch darauf achten, dass die Übertragung der Entries aus dem lokalen Verzeichnisdienst in die Dienste des Verzeichnisdienstkonzepts möglich bleibt. In den folgenden Kapiteln wird jeweils angegeben, wie die Eindeutigkeit des DN zu erreichen ist. 4.2 Umlaute Die in der PKI-1-Verwaltung eingesetzten Sicherheitsprodukte, wie z. B. Endanwenderprodukte oder Produkte für Zertifizierungsstellen, müssen in der Lage sein, Sonderzeichen wie ä, ü, ö, ß etc., in den einzelnen Namenselementen zu verarbeiten und darzustellen. Es muss ein Zeichensatz gemäß [ISIS-MTT Part 4] unterstützt werden. Distinguished Names können daher generell mit diesen Sonderzeichen gebildet werden. Bei Kommunikationspartnern außerhalb Deutschlands kann die Verwendung von Umlauten allerdings zu Problemen führen, z.b. bei der Darstellung von Distinguished Names. Die zuständigen Instanzen für die Namensgebung müssen diese Problematik berücksichtigen und die Zertifikatsinhaber und die Behörden und Organisationen entsprechend informieren. Für Zertifikate, die für öffentliche (vom Internet aus zugreifbare) SSL-Server verwendet werden sollen, ist von der Verwendung von Umlauten und UTF8- BSI Namensregeln und -formate Seite 16 von 53

17 Codierungen dringend abzuraten, da diese z.zt. nicht von allen Browsern unterstützt werden. Für behörden-interne SSL-Server und SSL-Client-Zertifikate können Umlaute und UTF8-Codierungen verwendet werden, da auch für diese Komponenten eine Unterstützung eines Zeichensatzes gemäß [ISIS-MTT Part 4] (s.o.) erforderlich ist. Für SSL-Server-Zertifikate ist jedoch auch hier davon abzuraten, um technische Probleme zu vermeiden. Die jeweilige Organisation kann für ihren Bereich die Entscheidung treffen, ob Umlaute verwendet werden dürfen. 4.3 Bund, Länder und Kommunen Nutzer der PKI-1-Verwaltung können alle Einrichtungen der öffentlichen Verwaltung der Bundesrepublik Deutschland werden. Insofern umfasst die PKI Institutionen auf Bundes-, Länder- und kommunaler Ebene. Grundsätzlich gelten die Namensregeln für alle Nutzer gleichermaßen. Auch Kommunen können über eine eigene Vertrags-CA einen eigenen Namensraum vereinbaren. Alternativ können sie sich jedoch auch unter einer Vertrags-CA eines Landes einordnen. Welche Variante im Einzelfall sinnvoll ist, muss die Kommune anhand von Aufwands-Nutzen-Überlegungen entscheiden. Die Beispielen der folgenden Kapitel verdeutlichen die Alternativen, indem sie verschiedene fiktive Distinguished Names gegenüberstellen. Dabei werden drei Szenarios anhand unterschiedlicher Städte unterschieden: Im kommunalen Szenario 1 (ks1) wird angenommen, dass die Stadt Köln eine eigene Vertrags-CA eingerichtet hat. Im kommunalen Szenario 2 (ks2) wird angenommen, dass die Stadt Frankfurt eine nachgeordnete CA unter der Vertrags-CA des Landes Hessen betreibt. BSI Namensregeln und -formate Seite 17 von 53

18 Im kommunalen Szenario 3 (ks3) wird angenommen, dass die Stadt München ihre Zertifikate direkt von der MFCA Bayern (steht für mulitfunktionale CA des Bayerischen Behördennetzes) bezieht. 5 Subject Distinguished Names (DNs) In diesem Kapitel werden die Namensregeln für folgende Subject-DNs festgelegt: Zertifizierungsinstanzen, Natürliche und juristische Personen Pseudonyme und Gruppen (z.b. Personengruppen, Funktionen und IT-Prozesse). 5.1 Grundsätzliche Regeln für Subject DNs Grundsätzlich muss die namensvergebende Stellen bei der Namenvergabe sicherstellen, dass der mit der Wurzelzertifizierungsstelle vereinbarte Namensraum eingehalten wird, Zertifikate nur auf einen zulässigen Namen des Antragstellers, auf ein von ihm gewähltes Pseudonym oder eine von ihm vertretene Gruppe, Funktion oder Organisation ausgestellt werden, für ein Pseudonym, eine Gruppe, eine Funktion oder eine Organisation ausgestellte Zertifikate als solche erkennbar sind (zur Kennzeichnung siehe unten) und der gesamte Subject DN die Realität zum Zeitpunkt der Antragstellung wiederspiegelt, also beispielsweise Zertifikate für Personen außerhalb einer Organisation diese Differenzierung erkennen lassen. BSI Namensregeln und -formate Seite 18 von 53

19 5.2 Subject-DNs für Wurzelzertifizierungsinstanz und Zertifizierungsinstanzen Namensregel für Subject-DNs von PCA und CAs Sowohl für Vertrags-CAs als auch für deren nachgeordnete CAs gilt die gleiche Namensregel: CAs werden grundsätzlich der Gruppe einer Vertrags-CA zugeordnet. Gruppen werden gebildet für Länder und oder andere Organisationen (z.b. TESTA) und erhalten einen gemeinsamen ou-entry. Der Subject-DN für eine CA wird gebildet nach folgender Regel: cn=[name der CA], ou=[name der CA-Gruppe], o=pki-1-verwaltung, c=de Diese Regel gilt auch für Subject-DNs von CAs in Windows2000-PKIs, obwohl dort die DIT-DNs der CAs von dieser Regel abweichen (vgl. Kapitel 6). Ausnahme: Der Subject-DN von Instanzen der PCA enthält keinen Namensbestandteil vom Typ organizationalunitname (ou); die PCA wird direkt unter o=pki-1- Verwaltung, c=de eingeordnet. cn=[name der PCA-Instanz], o=pki-1-verwaltung, c=de Die einzelnen Namensbestandteile sind wie folgt zu wählen: c=de : Der Namensbestanteil ist festgelegt. o=pki-1-verwaltung : Der Namensbestandteil ist festgelegt. "ou=[name der CA-Gruppe] : Beim Beitritt einer Vertrags-CA zur PKI-1- Verwaltung schlägt die Vertrags-CA den Namensbestandteil vor. Er wird in Abstimmung mit der PCA festgelegt. Der Namensbestandteil muss von allen nachgeordneten CAs aus dem CA-Namensraum der Vertrags-CA geführt werden. cn=[name der CA] : der Name muss den Bestandteil CA enthalten und eindeutig innerhalb der CA-Gruppe sein. BSI Namensregeln und -formate Seite 19 von 53

20 Hinweis: Grundsätzlich müssen bei allen CAs (auch nachgeordneten CAs) die DIT-DNs gleich den Subject-DNs sein. Nur für Windows2000-CAs sind Abweichungen erlaubt (vgl. dazu Kapitel 6) Festgelegte Subject-DNs für Zertifizierungsinstanzen Der Name der Wurzel-Zertifizierungsinstanz der PKI-1-Verwaltung ist festgelegt wie folgt: Domäne PCA Subject-DN cn=pca-1-verwaltung, o=pki-1-verwaltung, c=de Tabelle 1: Festgelegte Subject-DNs für Zertifizierungsinstanzen Beispiele für Subject-DNs von Zertifizierungsinstanzen Die folgende Tabelle gibt Beispiele für Subject DNs anhand einiger bereits eingerichteter und einiger fiktiver CAs in der PKI-1-Verwaltung. Domäne Subject-DN Win 2000 PKI Bayern cn=ca-1-bybn, ou=freistaat Bayern, o=pki-1-verwaltung, c=de cn=mfca-1-bybn, ou=freistaat Bayern o=pki-1-verwaltung, c=de Ja Ja TESTA sk1: Stadt Köln sk2: Stadt Frankfurt sk3: Stadt München cn=ca testa deutschland, ou=testa deutschland, o=pki-1-verwaltung, c=de cn=ca Stadt Koeln, ou=stadt Koeln, o=pki-1-verwaltung, c=de cn=ca Stadt Frankfurt, ou=hessen, o=pki-1-verwaltung, c=de entfällt (keine eigene CA) Tabelle 2: Beispiele für Subject-DNs von Zertifizierungsinstanzen Nein Hinweise zu den entsprechenden DIT-DNs der in Tabelle 2 genannten Subject- DNs finden sich in Kapitel 6. Der Namensbaum für die Subject-DNs von Zertifizierungsinstanzen ergibt sich entsprechend Abbildung 2. BSI Namensregeln und -formate Seite 20 von 53

21 c=de c=de o=bund o=bund o=pki-1-verwaltung o=pki-1-verwaltung cn=pca-1- cn=pca-1- Verwaltung Verwaltung ou=freistaat ou=freistaat Bayern Bayern ou=testa ou=testa deutschland deutschland ou=stadt ou=stadt Köln Köln cn=ca-1- cn=ca-1- BYBN BYBN cn=mfca-1- cn=mfca-1- BYBN BYBN cn=ca testa cn=ca testa deutschland deutschland cn= CA cn= CA Stadt Köln Stadt Köln Abbildung 2: Beispiele aus dem Namensbaum von Subject-DNs für CAs Jede CAs wird auf einer Ebene unter der CA-Gruppe (ou=[gruppe]) eingerichtet. 5.3 Subject-DNs für natürliche und juristische Personen Namensregeln für Subject-DNs für Endanwender Endanwender der PKI können aus den Institutionen des Bundes, aus Bundes-, Landes- und kommunalen Behörden sowie aus Unternehmen stammen, die in einer engen Beziehung mit einer Behörde stehen. Der Subject-DN eines Endanwenders muss mindestens die folgenden X.520- Attribute [X.500 ff 1997] enthalten (die Abkürzungen für die Attribut-Typen sind in Klammern angegeben): commonname (cn), organizationalunitname (ou), organizationname (o) countryname (c) Auf Wunsch des Antragstellers können Pseudonyme verwendet werden, die durch den Zusatz ":PN" am Ende des commonname gekennzeichnet werden BSI Namensregeln und -formate Seite 21 von 53

22 (siehe Kapitel 5.4). Das in [PKIX QC 00] und in [PKCS#9 00] definierte Attribut pseudonym (PN) wird nicht verwendet 1. Bemerkung: Abweichend von obiger Festlegung würde das BSI die Notation "PN: " am Anfang des "commonname" aufgrund besserer Sichtbarkeit und Handhabung bei der Suche nach Einträgen bevorzugen. Die Konformität mit dem ISIS-MTT Standard ist aber höher zu bewerten. In der o.g. Frage der Notation des commonname wird hiermit um Kommentar gebeten. Neben den genannten Pflicht-Attributen können folgende X.520-Attribute optional verwendet werden (die Abkürzungen für die Attribut-Typen sind in Klammern angegeben): address ( ); ist nur für eine Übergangsphase zulässig, localityname (l). Folgende Attribute werden nicht verwendet, solange eine dahingehende Interoperabilität der Produkte noch nicht mit positivem Ergebnis getestet 1 Die ISIS-MTT-Spezifikation [ISIS-MTT] lässt zum Attribut commonname zusätzlich die Verwendung von pseudonym zu. ISIS-MTT schlägt folgendes vor: Pseudonyme sind durch den Zusatz ":PN" am Ende des commonname zu kennzeichnen. Gleichzeitig kann (für nach dem ausgestellte Zertifikate: muss) das Pseudonym auch im Attribut pseudonym angegeben werden. Um Pseudonyme mehrfach vergeben zu können, muss als weiteres Attribut serialnumber dem Namen hinzugefügt werden. Hierdurch wird die Eindeutigkeit der Pseudonyme gewährleistet. Im Internet-Draft [PKIX QC 00] wird die Empfehlung gegeben, dass Zertifikate immer das Attribut commonname enthalten sollten, auch wenn das Attribut pseudonym angegeben ist. Der Grund ist, dass viele Produkte von dem Vorhandensein des Attributs commonname ausgehen. BSI Namensregeln und -formate Seite 22 von 53

23 worden ist: surname (sn), givenname (gn), postalcode, stateorprovincename (st) und title (t) 2. Die Eigenschaften der Attribute sn, gn und t können im Rahmen der Bildungsregeln für den cn umgesetzt werden. Unterstrukturierungen, wie sie z.b. durch mehrere organizationalunitname - Attribute oder zusätzliche localityname -Attribute möglich sind, bleiben den Institutionen überlassen. Der Subject-DN für einen Endanwender wird nach folgender Regel gebildet: cn=[name], [[optionales Attribut=[xxx], [...]], ou=[[institution] Service [Firma]], o=[teilnehmer-namensraum der Vertrags-CA], c=de Ausnahme: Für eine Übergangszeit darf der Subject-DN für Endanwender die Adresse des Endanwenders enthalten, sofern das Zertifikat zur Sicherung von bestimmt ist. Für andere Zertifikate, beispielsweise solche, die ausschließlich zur Sicherung von Web-Verbindungen über SSL bestimmt sind, gilt diese Ausnahme nicht. [ =[ -adresse],] cn=[name], [[optionales Attribut=[xxx], [...]], ou=[[institution] Service [Firma]], o=[teilnehmer-namensraum der Vertrags- CA], c=de Es wird dringend empfohlen, für die Subject-DNs von Endanwendern nur die Pflicht-Bestandteile (cn=, ou=, o=, c=) zu verwenden. Weitere Differenzierungen, die beispielsweise die interne Struktur der Organisation ausdrücken, führen regelmäßig zu zusätzlichen Re-Zertifizierungen. Werden beispielsweise das Referat oder der Sitz der Behörde angegeben, muss ein Zertifikatswechsel erfolgen, sobald der Mitarbeiter das Referat wechselt oder eine Abteilung von 2 Das title-attribut aus X.520 beschreibt eine Position/Funktion innerhalb einer Organisation und keinen akademischen Grad. Persönliche Titel sollen nach den Beispielen in X.520 im commonname geführt werden vgl. die Regel unten). BSI Namensregeln und -formate Seite 23 von 53

24 einem Ort an einen anderen verlegt wird. Zusätzliche Angaben sollten daher nur verwendet werden, wenn dies für die Außendarstellung unbedingt erforderlich ist. Die Eindeutigkeit des gewählten Subject-DNs wird von der Vertrags-CA durch die Vergabe von Namensräumen an die Institutionen bzw. Registrierungsstellen sichergestellt. Die Institutionen bzw. Registrierungsstellen müssen die verbleibenden Namensbestandteile so wählen, dass sie innerhalb ihres Namensraumes eindeutig sind. Die einzelnen Namensbestandteile für Mitarbeiter von Behörden sind wie folgt zu wählen: c=de : Der Namensbestanteil ist festgelegt. organizationname=[teilnehmer-namensraum der Vertrags-CA] : Der Namensbestandteil organizationname wird beim Beitritt einer Vertrags-CA zur PKI-1-Verwaltung mit der PCA vereinbart. Er entspricht dem vereinbarten Teilnehmer-Namensraum der Vertrags-CA. Der Namensbestandteil muss von allen Teilnehmern aus dem Zuständigkeitsbereich der Vertrags-CA geführt werden. Je nach Zuständigkeitsbereich der Vertrags-CA wird er in der Regel den Namen eines Bundeslandes oder einer Kommune enthalten. Bundesbehörden sind unter "Bund", Institutionen des Deutschen Bundestages unter "DBT" eingeordnet. organizationalunitname=[institution] Service [Firma] : Das Pflicht- Attribut organizationalunitname (oberster ou-knoten im Subject DN) muss den Namen der Behörde (rechtlich eigenständige Organisation) enthalten. Weitere ("tiefere") ou-angaben können z. B. das Referat oder die Abteilung beinhalten. Wenn Subject-DNs für Teilnehmer aus einer Kommune gebildet werden, muss entweder aus dem o-attribut oder dem ou-attribut die Kommune erkennbar sein, für die der Teilnehmer arbeitet. Die Optionen ergeben sich daher aus dem Namensraum der Vertrags-CA (vgl. die Beispiele unten). BSI Namensregeln und -formate Seite 24 von 53

25 Im IVBB wird die Gruppe "ou=service" verwendet, um Mitarbeiter externer Unternehmen zu zusammenzufassen. Alternativ könnte auch der Firmenname mit Rechtsform angegeben werden (vgl. auch unten). cn=name : Im Attributwert für commonname wird der natürliche Name des Endanwenders verwendet. Mindestens ein Vorname wird ausgeschrieben. Die für die Namensgebung zuständige Instanz muss sicherstellen, dass der Distinguished Name eines Endanwenders innerhalb des Namensraumes der jeweiligen Organisation eindeutig ist. Bei häufig vorkommenden Nachnamen, wie z.b. Maier, sollte die Eindeutigkeit des commonname entsprechend der in der Organisation üblichen Weise erreicht werden, z.b. durch Aufnahme weiterer Vornamen der Person oder Initialen mit in den commonname. Es wird dringend empfohlen, den cn so zu wählen, dass er innerhalb der Institution eindeutig ist. In diesem Falle bilden bereits die Pflichtattribute (cn=, ou=, o=, c=) einen eindeutigen Subject DN. 3 Die Reihenfolge der Bestandteile des Subject DN ist wie folgt zu wählen: Nachname Vorname[n] [Titel] [Initialen] Titel und Initialen sind optional. Für Initialen sollten bei Namensgleichheiten und gleichen Initialen aufsteigende Nummern verwendet werden. Die Bestandteile des CN werden durch jeweils ein Leerzeichen getrennt. Die 3 Der Gewinn dieser Vorgehensweise ist, dass der cn in dieser Form beibehalten werden kann, wenn die -Adresse oder optionale Attribute aus dem Subject DN bei einer Re- Zertifizierung weggelassen werden sollen. Beispiel: die beiden Distinguished Name "cn=müller Hans, l=berlin, ou=bmi, o=bund, c=de" und "cn=müller Hans, l=bonn, ou=bmi, o=bund, c=de" sind eindeutig, weil sie sich in der Locality Bonn bzw. Berlin unterscheiden. Wechselt Herr Müller aus Bonn nach Berlin, tritt bei der Re-Zertifizierung eine Namensdopplung auf. Entsprechendes, wenn später entschieden wird, dass grundsätzlich auf die Locality verzichtet wird. Würde von Anfang an, bspw. durch Initiale, für eine BMIweite Eindeutigkeit der Common Names gesorgt, können die cn's bei der Re-Zertifizierung unverändert übernommen werden. BSI Namensregeln und -formate Seite 25 von 53

26 gewählte Reihenfolge der Bestandteile des CN dient der einfachen Suche in Verzeichnissen. =[ -adresse] : Die Adresse sollte nicht Bestandteil des Subject-DNs sein, sondern in einem separaten Namenselement ( subject- AltName ) des Zertifikats angegeben werden. Dies ist konform zu den Empfehlungen des [RFC 2632] (S/MIME v3 Certificate Handling) und des Internet Profils [RFC 2459]. Da manche Clients gegenwärtig allerdings die -Adresse im Subject DN fordern, wird aus Gründen der Interoperabilität für eine Übergangszeit eine Ausnahmeregelung zugelassen. Der Wert des Attributs muss eine -Adresse im Format der Internet-Mails ([RFC 822]) sein. Sofern der Schlüsselinhaber über mehrere -Adressen verfügt, wird dringend empfohlen, die -Adresse auszuwählen, die hauptsächlich zur gesicherten Kommunikation verwendet werden soll. Mitarbeiter von Firmen müssen eindeutig als externe Mitarbeiter gekennzeichnet sein. Dies kann z.b. erfolgen durch die Erweiterung des commonname des Mitarbeiters durch den Zusatz (Ext.) oder die Belegung des organizationalunitname durch einen geeigneten Wert (z.b. den Firmenname mit Rechtsform). Zertifikate für eingeschränkte Verwendungszwecke dürfen durch Erweiterung des commonname um einen entsprechenden Zusatz gekennzeichnet werden [PKI1V Namensformat MTT]. Dies kann z.b. erfolgen durch den Zusatz (nur SSL) bei Zertifikaten, die ausschließlich zur Sicherung von Web-Verbindungen per SSL bestimmt sind. Die Vertrags-CA kann für Ihren Zuständigkeitsbereich frei über die geeignete Kennzeichnung für externe Mitarbeiter entscheiden. BSI Namensregeln und -formate Seite 26 von 53

27 5.3.2 Beispiele für Subject-DNs für Endanwender Beispiele für Subject-DNs von persönlichen Teilnehmern, die den obigen Regeln entsprechen: Subject-DN von Teilnehmern cn=bosch Stephanie, ou=lfstad, o=bayern, c=de cn=rosenhauer Ulrich Christian Albrecht, Dr. Dipl.-Phys., ou=bsi, o=ca Dienstausweis-Pilot, c=de cn=hammer Volker Dr., ou=secorvo GmbH, o=bund, c=de sk1: Stadt Köln sk2: Stadt Frankfurt sk3: Stadt München cn=krüger Katrin, ou=einwohnermeldeamt, o=stadt Koeln, c=de (im ou-attribut könnte im Unterschied zu sk2 und sk3 auf die Angabe der "Stadt Koeln" verzichtet werden, weil sie Bestandteil des Namensraumes der Vertrags-CA ist.) cn=frick Frider, ou=einwohnermeldeamt Stadt Frankfurt, o=hessen, c=de cn=mayer Michaela, ou=einwohnermeldeamt Stadt München, o=bayern, c=de (unterscheidet sich nicht von sk2) Tabelle 3: Beispiele für Subject-DNs von Teilnehmern 5.4 Subject Distinguished Names bei Verwendung von Pseudonymen Namensregeln für Subject-DNs bei Verwendung von Pseudonymen Auf Wunsch des Antragstellers können Pseudonyme verwendet werden, die durch den Zusatz ":PN" am Ende des commonname gekennzeichnet werden BSI Namensregeln und -formate Seite 27 von 53

28 (siehe Kapitel 5.4). Das in [PKIX QC 00] und in [PKCS#9 00] definierte Attribut pseudonym (PN) wird nicht verwendet 4. Der Subject-DN für einen Endanwender wird nach folgender Regel gebildet: cn=[name:pn], [[optionales Attribut=[xxx], [...]], ou=[[institution] Service [Firma]], o=[teilnehmer-namensraum der Vertrags-CA], c=de Ausnahme: Für eine Übergangszeit darf der Subject-DN für Teilnehmer die Adresse des Endanwenders enthalten, sofern das Zertifikat zur Sicherung von bestimmt ist (vgl. auch Kapitel 5.3.1). Für andere Zertifikate, beispielsweise solche, die ausschließlich zur Sicherung von Web-Verbindungen über SSL bestimmt sind, gilt diese Ausnahme nicht. [ =[ -adresse],] cn=[name:pn], [[optionales Attribut=[xxx], [...]], ou=[[institution] Service [Firma]], o=[teilnehmer-namensraum der Vertrags- CA], c=de Die einzelnen Namensbestandteile für Mitarbeiter von Behörden sind wie folgt zu wählen: Pseudonym (PN)=Name : Die Erweiterung ":PN" im commonname sollte immer dann verwendet werden, wenn statt des wirklichen Namens einer Person ein Pseudonym angegeben wird. Der Attributwert muss ein 4 Die ISIS-MTT-Spezifikation [ISIS_MTT] lässt zum Attribut commonname zusätzlich die Verwendung von pseudonym zu. ISIS-MTT schlägt folgendes vor: Pseudonyme sind durch den Zusatz ":PN" am Ende des commonname zu kennzeichnen. Gleichzeitig kann (für nach dem ausgestellte Zertifikate: muss) das Pseudonym auch im Attribut pseudonym angegeben werden. Um Pseudonyme mehrfach vergeben zu können, muss als weiteres Attribut serialnumber dem Namen hinzugefügt werden. Hierdurch wird die Eindeutigkeit der Pseudonyme gewährleistet. Im Internet-Draft [PKIX QC 00] wird die Empfehlung gegeben, dass Zertifikate immer das Attribut commonname enthalten sollten, auch wenn das Attribut pseudonym angegeben ist. Der Grund ist, dass viele Produkte von dem Vorhandensein des Attributs commonname ausgehen. BSI Namensregeln und -formate Seite 28 von 53

29 unverwechselbares, erkennbares Pseudonym zur Identifizierung des Zertifikatsinhabers beinhalten. Alle weiteren Namensbestandteile sind analog zu Kapitel zu bilden. Regeln für die Vergabe von Pseudonymen Ein Pseudonym muss von einer Pseudonymvergabe-Stelle vergeben werden. Hierbei kann es sich um die Vertrags-CA oder eine von der Vertrags-CA beauftragte Registrierungsstelle handeln, die diesen Dienst (Vergabe von Pseudonymen) anbietet. Diese Stelle muss jederzeit in der Lage sein, das Pseudonym aufzuheben bzw. in den realen Namen aufzulösen, falls dies z.b. für Gerichtsverfahren notwendig wird. Die Vertrags-CA weist der Pseudonymvergabe-Stelle einen eindeutigen Namensraum zu. Die Pseudonymvergabe-Stelle muss sicherstellen, dass die von ihr vergebenen Pseudonyme innerhalb dieses Namensraumes eindeutig sind. Folgende Regeln sind bei der Vergabe von Pseudonymen zu beachten: Im Subject DN, der das Attribut commonname mit dem Zusatz ":PN" enthält, muss die Pseudonymvergabe-Stelle ersichtlich sein. Das Pseudonym muss als solches auch ohne den Zusatz ":PN" erkennbar sein. Die Eindeutigkeit des DN und des Namensraums wird in gleicher Weise wie für den normalen commonname sichergestellt. Eine Verwechslung mit Personen (z.b. bekannten Persönlichkeiten), Positionen (z.b. Präsident) oder Bezeichnungen in Gruppenzertifikaten muss ausgeschlossen sein. Bereits anderweitig in der PKI verwendete, reservierte oder geschützte Namen bzw. Syntaxelemente (z.b. GRP, DNS-Namen, IP-Adressen) dürfen nicht verwendet werden. Das Pseudonym darf keinen beleidigenden oder anzüglichen Inhalt haben. Diskriminierungen müssen ausgeschlossen sein. BSI Namensregeln und -formate Seite 29 von 53

30 Die Verwendung eines Pseudonyms im Zertifikat ist nur dann sinnvoll, wenn auch die -Adresse des Antragstellers (des späteren Zertifikatsinhabers) ein Pseudonym beinhaltet. Die entsprechende Stelle zur Vergabe von Pseudonymen muss den Antragsteller über diesen Sachverhalt aufklären. Hinweise: Pseudonyme werden nur für persönliche Zertifikate von natürlichen Personen und nicht für Zertifikate von juristischen Personen oder Gruppenzertifikate vergeben. Sofern ein Schlüsselpaar für eine Gruppe zertifiziert werden soll, sind daher die Regeln aus Kapitel 5.5 zu verwenden. Es ist nicht Gegenstand dieser Namensregeln, Festlegungen zu treffen, welche Stelle Pseudonyme vergeben soll Beispiele für Subject-DNs bei Verwendung von Pseudonymen Beispiele für Subject-DNs von Endanwendern mit einem Pseudonym (ks2 steht stellvertretend für die kommunalen Szenarios): Subject-DN von Teilnehmern mit Pseudonymen = cn= VDK-Verwalter:PN, ou=behoerde, o=testa, c=de cn=vdk-editor:pn, ou=secorvo GmbH, o=bund, c=de ks2: Stadt Frankfurt cn=regensammler:pn, ou=stadt Frankfurt am Main, o=hessen, c=de Tabelle 4: Beispiele für Subject-DNs für Teilnehmer mit Pseudonymen 5.5 Subject Distinguished Names für Personengruppen, Funktionen und automatisierte IT-Prozesse Namensregeln für Gruppen In der PKI-1-Verwaltung gibt es neben den persönlichen Zertifikaten und Pseudonymzertifikaten für natürliche Personen, eine zweite "Klasse" von Zertifikaten für Personengruppen, Funktionen oder automatisierte IT-Prozesse, die als Gruppenzertifikate bezeichnet werden. Diese Zertifikate können für Verschlüsselung und/oder Signatur sowohl von Personengruppen (z.b. BSI Namensregeln und -formate Seite 30 von 53