namensregeln und -formate

of 53 /53
Zertifizierungs- infrastruktur für die PKI-1-Verwaltung Namensregeln und -formate Bundesamt für Sicherheit in der Informationstechnik Version 1.3 vom 25.11.2002

Author: others

Post on 11-Sep-2021

3 views

Category:

Documents


0 download

Embed Size (px)

TRANSCRIPT

Zertifizierungsinfrastrukturfür die PKI-1-VerwaltungVersion 1.3 vom 25.11.2002
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.
Godesberger Allee 185-189, 53175 Bonn
Telefon: 0228/9582-0 - Telefax: 0228/9582-405
Albert-Nestler-Straße 9 D-76131 Karlsruhe
Michael Thiel Bundesamt für Sicherheit in der Informationstechnik
Godesberger Allee 185-189 D-53175 Bonn
[email protected] [email protected]
BSI Namensregeln und -formate Seite 3 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Inhaltsübersicht
1.2 Anwendungsbereich 10
2.3 Schreibweise von Distinguished Names 14
3 Organisatorische Verantwortlichkeiten der Namensvergabe 14
4 Generelle Vorgaben und Empfehlungen 15
4.1 Eindeutigkeit von Distinguished Names 15
4.2 Umlaute 16
5.1 Grundsätzliche Regeln für Subject DNs 18
5.2 Subject-DNs für Wurzelzertifizierungsinstanz und Zertifizierungsinstanzen 19
5.2.1 Namensregel für Subject-DNs von PCA und CAs 19
5.2.2 Festgelegte Subject-DNs für Zertifizierungsinstanzen 20
5.2.3 Beispiele für Subject-DNs von Zertifizierungsinstanzen 20
5.3 Subject-DNs für natürliche und juristische Personen 21
5.3.1 Namensregeln für Subject-DNs für Endanwender 21
5.3.2 Beispiele für Subject-DNs für Endanwender 27
5.4 Subject Distinguished Names bei Verwendung von Pseudonymen 27
5.4.1 Namensregeln für Subject-DNs bei Verwendung von Pseudonymen 27
5.4.2 Beispiele für Subject-DNs bei Verwendung von Pseudonymen 30
BSI Namensregeln und -formate Seite 4 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
5.5 Subject Distinguished Names für Personengruppen, Funktionen und automatisierte IT-Prozesse 30
5.5.1 Namensregeln für Gruppen 30
5.5.2 Beispiele für Subject-DNs bei Gruppen- und SSL-Server- Zertifikaten 33
6 Namen in Directories 33
6.1 DIT-DN für Zertifizierungsinstanzen 34
6.1.1 DIT-Namensregeln für Zertifizierungsinstanzen 34
6.1.2 DIT-Namensregeln für Windows 2000 CAs 34
6.1.3 Beispiele für DIT-DNs von Zertifizierungsinstanzen 35
6.2 DIT-DNs für CRL Distribution Points 35
6.2.1 DIT-Namensregeln für CDPs 35
6.2.2 DIT-Namensregeln für CDPs für Windows 2000 CAs 36
6.2.3 Beispiele für DIT-DNs von CDPs 37
6.3 DIT-DN für Teilnehmer 37
6.3.1 DIT-Namensregeln für Teilnehmer 37
Anhänge: Format-Spezifikationen für Namen 41
Änderungshistorie
0.91 03.04.2002 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.
Jörg Völker, Dörte Neundorf, Volker Hammer
0.92 26.04.2002 Anmerkungen eingearbeitet von:
• Sitzung des Editorial Board zum Verzeichnisdienstkonzept vom 10.4.2001,
• Herr Klasen, Herr Gietz (DAASI), • Herr Thiel (PCA).
Volker Hammer
• Projektgruppe PKI (BSI) • Herr Thiel (PCA)
Andreas Schmidt (Ref I 1.3)
1.1 03.06.02 Einarbeitung von Korrekturen Andreas Schmidt (Ref I 1.3)
BSI Namensregeln und -formate Seite 5 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Version Datum Status, Änderungen Autoren
1.2 14.06.02 Einarbeitung von Korrekturen nach Vorstellung der Namensregeln auf der AG KS des KoopA in Schwerin
Andreas Schmidt (Ref I 1.3)
1.3 25.11.02 Freigabe der Erweiterung für SSL u. Änderungen aufgrund:
• SSL-Studie (Jörg Völker, Hans-Joachim Knobloch)
• Policy-Anpassung
[ISIS-MTT] ISIS-MTT - T7 & TeleTrusT (2001): ISIS-MTT – Common ISIS-MTT Specification For PKI Applications, Version 1.0.2, September Juli 2002, http://www.teletrust.de oder http://www.t7-isis.de.
• PART 1 - Certificate and CRL Profiles • PART 4 -Operational Protocols (LDAP, OCSP, TSP)
[MTT-PRO 99] TeleTrusT: MailTrusT-Spezifikation Version 2 - Profile für Zertifikate und Sperrlis- ten; März 1999
[PKCS#9 00] M. Nystrom, B. Kaliski: Selected Object Classes and Attribute Types PKCS #9 v2.0, <draft-nystrom-pkcs9-v2-00.txt>, March 2000
[PKI1V Namensfor- mat MTT]
[PKI1V-VDK-Erg] BSI (Hrsg.): Zertifizierungsinfrastruktur für die PKI-1-Verwaltung: Verzeichnis- dienstkonzept, 2001 – 2002 (Abschlussdokument)
[Regelung GrpZertifikate]
[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 822 (1982): RFC 822 - Standard for ARPA Internet Text Messages, IETF, 1982, z.B. ftp://ietf.org/.
[RFC 2252] Wahl, M. / Coulbeck, A./ Howes, T. / Kille, S. (1997): RFC 2252 - Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions, IETF, 1997, z.B. ftp://ietf.org/.
[RFC 2459] Housley, R. / Ford, W. / Polk, W. / Solo, D. (1999): RFC 2459 - Internet X.509 Pub- lic Key Infrastructure Certificate and CRL Profile, IETF, 1999, z.B. ftp://ietf.org/.
[RFC 2632] B. Ramsdell: RFC 2632 - S/MIME Version 3 Certificate Handling, June 1999
[Sphinx Namen] BSI - Bundesamt für Sicherheit in der Informationstechnik (Hrsg.) (2000): Sphinx - Sichere E-Mail - Spezifikation und Verwendung von Namen in einer PKI (Namens- konzept), Version 1.1, Bonn, 2000.
BSI Namensregeln und -formate Seite 6 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
[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 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-Typ 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.
Austausch-DIT Abkürzung für den gemeinsamen (einheitlichen) Directory Information Tree (ÕDIT) der drei Dienste des Verzeichnisdienstkonzepts.
BSI Abkürzung für Bundesamt für Sicherheit in der Informationstechnik.
CA Abkürzung für Certification Authority.
CDP 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.
cn Abkürzung für Common Name (Attribut-Typ).
CRL Abkürzung für Certificate Revocation List, ÕSperrliste mit Verweisen auf ge- sperrte Zertifikate von Teilnehmern und CAs.
Dienste des Verzeich- nisdienstkonzepts
BSI Namensregeln und -formate Seite 7 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
DIT 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 Datenbank- schlüssel für die Einträge im ÕDirectory.
DIT-DN 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.
email Abkürzung für E-Mail-Address (Attribut-Typ)
Endanwender Natürliche oder juristische Person, die ÕTeilnehmer und Inhaber eines Zertifikates der PKI ist.
Entry 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 wer- den die einzelnen Werte abgelegt, die dem Objekt zugeordnet sind, beispiels- weise die E-Mail-Adresse, der Nachname oder das Zertifikat eines Teilnehmers. Jeder Entry wird eindeutig durch einen eindeutigen Namen im Directory adres- siert, dem sogenannten DIT Distinguished Name ÕDIT-DN.
Funktionszertifikat Das Zertifikat wird auf den Namen einer Funktion, beispielsweise einen automatischen E-Mail-Dienst, ausgestellt. Der Zugriff auf den geheimen Schlüssel kann, anders als für persönliche Schlüsselpaare, mehreren Personen eingeräumt werden.
gn Abkürzung für Given Name (Attribut-Typ).
Gruppenzertifikat 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.
IVBB Abkürzung für Informationsverbund Berlin-Bonn.
IETF Abkürzung für Internet Engineering Task Force, Standardisierungsgremium (siehe www.ietf.org).
Issuer DN Issuer Distinguished Name, eindeutiger Name des Ausstellers eines Zertifikats, im Zertifikat enthalten. Zur Unterscheidung siehe ÕSubject-DN und ÕDIT-DN.
ITU-T 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)
kSx Abkürzung für kommunales Szenario x, wobei x eine Nummer ist. Die Szenarien werden in Kapitel 4.3 erklärt.
l kleines "L" als Abkürzung für Locality (Attribut-Typ).
LDAP 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".
LDAP-Schreibweise von DIT-DNs
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 8 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
MTT 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.
Namensgebendes Attribut
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.
o Abkürzung für Organization Name (Attribut-Typ).
ou Abkürzung für Organizational Unit Name (Attribut-Typ).
pn Abkürzung für Pseudonym (Attribut-Typ).
PCA Abkürzung für Policy Certification Authority, ÕPCA-1-Verwaltung.
PCA-1-Verwaltung Wurzelzertifizierungsinstanz der ÕPKI-1-Verwaltung, betrieben vom ÕBSI
PKI Public Key Infrastruktur, Infrastruktur zur Bereitstellung von öffentlichen Schlüsseln, Zertifikaten und Sperrinformationen.
PKI-1-Verwaltung PKI der öffentlichen Verwaltung der Bundesrepublik Deutschland. Sie umfasst alle ÕPKIs, die durch die ÕPCA-1-Verwaltung für die öffentliche Verwaltung zertifiziert werden.
PKI-Informationen Oberbegriff für Teilnehmer-Zertifikate, CA-Zertifikate und Sperrlisten
Relative Distinguished Name
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.
RFC Abkürzung für Request for Comment, Standardisierungsdokumente der ÕIETF.
sn Abkürzung für Surname Name (Attribut-Typ).
SSL Abkürzung für Secure Socket Layer, Protokoll zur Absicherung von Internet- Verbindungen, das Zertifikate zur Authentisierung von Server und (optional) Client nutzt.
Steuerungsgremium der PKI-1-Verwaltung
Gegenwärtig wird geklärt, wie die an der PKI-1-Verwaltung beteiligten Domänen und CAs gemeinsam die Weiterentwicklung dieser PKI und des Verzeichnis- dienstkonzepts steuern. Das künftig zuständige Gremium wird zusammenfassend als "Steuerungsgremium der PKI-1-Verwaltung" bezeichnet.
Subject-DN Subject Distinguished Name, eindeutiger Name des Inhabers eines Zertifikats, im Zertifikat enthalten. Zur Unterscheidung siehe ÕIssuer DN und ÕDIT DN.
Teilnehmer 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.
TESTA Abkürzung für Trans European Services for Telematics between Administration
UNICODE Zeichentabelle zur Umsetzung von bestimmten Zeichnen (Buchstaben, Zahlen) in numerische Äquivalente. Enthält insbesondere auch Umlaute und weitere Sonderzeichen.
UTF8 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 9 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
1 Einleitung und Übersicht
1.1 Zweck des Dokuments
formationen) 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 Verzeichnis-
diensten 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 Zertifizierungsin-
stanzen, 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 10 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anfragen zur Weiterentwicklung der Namensregeln sind an die PCA der PKI-1-
Verwaltung zu richten. Sie können dadurch in einen Change-Management-Pro-
zess einfließen.
1.2 Anwendungsbereich
Dieses Dokument regelt die Vergabe von Distinguished Names innerhalb der
PKI-1-Verwaltung für
• die Wurzelzertifizierungsinstanz,
• Gruppenzertifikate (z.B. für Personengruppen, Funktionen oder automati-
sierte IT-Prozesse)
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 E-Mail 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.
• Kapitel 3 bestimmt die organisatorischen Verantwortlichkeiten der Namens-
vergabe innerhalb der PKI-1-Verwaltung.
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 Verzeichnis-
diensten. 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.
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 12 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
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
ou=BMI ou=BMI
l=Berlin l=Berlin
ou=BSI ou=BSI
ou=BMWI ou=BMWI
o=Thüringen o=Thüringen
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 ei-
nes 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 13 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
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.509 97] in Zertifikaten und in
Sperrlisten verwendet. In Zertifikaten sind mindestens zwei Namen enthalten:
der Name des Zertifikatsinhabers (Subject-DN) und der Name der ausstellen-
den Instanz (Issuer-DN). In Sperrlisten wird der Aussteller einer Sperrliste
(Issuer-DN) angegeben.
In einer PKI werden Distinguished Names unter anderem verwendet zur ein-
deutigen Benennung
• von Verteilungsstellen für Sperrlisten (Certificate Revocation List Distribution
Point, CDP) und
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:
• Die Namensgebung und Namensstruktur für die einzelnen PKI-Komponen-
ten soll einheitlichen Konventionen folgen.
• Die Distinguished Names der verschiedenen PKI-Komponenten und der
Teilnehmer sollen unterscheidbar sein. Auch verschiedene Typen von Teil-
nehmer-Namen sollen anhand gleicher Kennzeichen leicht zu unterscheiden
sein, z. B. Namen für persönliche Zertifikate von solchen für Zertifikate von
Gruppen.
zeichnisdiensten 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 Distin-
guished Name zuerst und der "oberste" Knoten im Namensbaum zuletzt ange-
geben, 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.
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 15 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
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 ein-
deutigen 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,
Regeln verpflichtet werden und
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 Verzeichnis-
diensten 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 16 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
• 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.
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 Ver-
wendung von Umlauten allerdings zu Problemen führen, z.B. bei der Darstel-
lung von Distinguished Names. Die zuständigen Instanzen für die Namensge-
bung 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 17 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Codierungen dringend abzuraten, da diese z.Zt. nicht von allen Browsern
unterstützt werden.
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.
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.
• 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 festge-
legt:
• Zertifizierungsinstanzen,
Grundsätzlich muss die namensvergebende Stellen bei der Namenvergabe
sicherstellen, dass
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 19 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
5.2 Subject-DNs für Wurzelzertifizierungsinstanz und
Zertifizierungsinstanzen
5.2.1 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 Organi-
sationen (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.
• „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 20 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
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 Abwei-
chungen erlaubt (vgl. dazu Kapitel 6).
5.2.2 Festgelegte Subject-DNs für Zertifizierungsinstanzen
Der Name der Wurzel-Zertifizierungsinstanz der PKI-1-Verwaltung ist festgelegt
wie folgt:
Domäne Subject-DN
Tabelle 1: Festgelegte Subject-DNs für Zertifizierungsinstanzen
5.2.3 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
cn=CA-1-BYBN, ou=Freistaat Bayern, o=pki-1-verwaltung, c=DE JaBayern
cn=MFCA-1-BYBN, ou=Freistaat Bayern o=pki-1-verwaltung, c=DE Ja
TESTA cn=ca testa deutschland, ou=testa deutschland, o=pki-1-verwaltung, c=DE
Nein
sK1: Stadt Köln
cn=CA Stadt Koeln, ou=Stadt Koeln, o=pki-1-verwaltung, c=DE
sK2: Stadt Frankfurt
cn=CA Stadt Frankfurt, ou=Hessen, o=pki-1-verwaltung, c=DE
sK3: Stadt München
Tabelle 2: Beispiele für Subject-DNs von Zertifizierungsinstanzen
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.
c=DE c=DE
o=Bund o=Bund
o=PKI-1-Verwaltung o=PKI-1-Verwaltung
Bayern
deutschland
BYBN
deutschland
cn= CA Stadt Köln
cn= CA 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
5.3.1 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):
durch den Zusatz ":PN" am Ende des „commonName“ gekennzeichnet werden
BSI Namensregeln und -formate Seite 22 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
(siehe Kapitel 5.4). Das in [PKIX QC 00] und in [PKCS#9 00] definierte Attribut
„pseudonym“ (PN) wird nicht verwendet1.
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):
• localityName (l).
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 31.12.2003 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.
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 E-Mail
Adresse des Endanwenders enthalten, sofern das Zertifikat zur Sicherung von
E-Mail bestimmt ist. Für andere Zertifikate, beispielsweise solche, die
ausschließlich zur Sicherung von Web-Verbindungen über SSL bestimmt sind,
gilt diese Ausnahme nicht.
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 Differenzierun-
gen, die beispielsweise die interne Struktur der Organisation ausdrücken, füh-
ren 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 24 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
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:
• „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.
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 25 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Im IVBB wird die Gruppe "ou=Service" verwendet, um Mitarbeiter externer
Unternehmen zu zusammenzufassen. Alternativ könnte auch der Firmen-
name 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 ausgeschrie-
ben. 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 In-
stitution 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 E-Mail-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 BMI-
weite Eindeutigkeit der Common Names gesorgt, können die cn's bei der Re-Zertifizierung
unverändert übernommen werden.
BSI Namensregeln und -formate Seite 26 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
gewählte Reihenfolge der Bestandteile des CN dient der einfachen Suche in
Verzeichnissen.
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
E-Mail-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 E-Mail-Adresse im Format der
Internet-Mails ([RFC 822]) sein. Sofern der Schlüsselinhaber über mehrere
E-Mail-Adressen verfügt, wird dringend empfohlen, die E-Mail-Adresse
auszuwählen, die hauptsächlich zur gesicherten Kommunikation verwendet
werden soll.
zeichnet sein. Dies kann z.B. erfolgen durch
• die Erweiterung des „commonName“ des Mitarbeiters durch den Zusatz
(Ext.) oder
(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 27 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
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:
[email protected], 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
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.)
sK2: Stadt Frankfurt
cn=Frick Frider, ou=Einwohnermeldeamt Stadt Frankfurt, o=Hessen, c=DE
sK3: Stadt München
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
Pseudonymen
durch den Zusatz ":PN" am Ende des „commonName“ gekennzeichnet werden
BSI Namensregeln und -formate Seite 28 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
(siehe Kapitel 5.4). Das in [PKIX QC 00] und in [PKCS#9 00] definierte Attribut
„pseudonym“ (PN) wird nicht verwendet4.
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 E-Mail Adresse
des Endanwenders enthalten, sofern das Zertifikat zur Sicherung von E-Mail
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.
„[email=[E-Mail-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:
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 31.12.2003 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.
unverwechselbares, erkennbares Pseudonym zur Identifizierung des
Zertifikatsinhabers beinhalten.
Alle weiteren Namensbestandteile sind analog zu Kapitel 5.3.1 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.
Namen bzw. Syntaxelemente (z.B. GRP, DNS-Namen, IP-Adressen) dürfen
nicht verwendet werden.
Diskriminierungen müssen ausgeschlossen sein.
BSI Namensregeln und -formate Seite 30 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
• Die Verwendung eines Pseudonyms im Zertifikat ist nur dann sinnvoll, wenn
auch die E-Mail-Adresse des Antragstellers (des späteren Zertifikatsinha-
bers) ein Pseudonym beinhaltet. Die entsprechende Stelle zur Vergabe von
Pseudonymen muss den Antragsteller über diesen Sachverhalt aufklären.
Hinweise:
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.
5.4.2 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
[email protected], 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
5.5.1 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 31 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Projektgruppe PKI) sowie Funktionen (z.B. Poststelle) als von auch
automatisierten IT-Prozessen (z.B. E-Mail-Responder, Mail-Server, SSL-
Server) verwendet werden. Hierdurch lässt sich auch eine elektronische
Stempel- bzw. Siegelfunktion realisieren. Für den Schlüsselverantwortlichen
gelten besondere Verpflichtungen (siehe hierzu das Dokument [Regelung
GrpZertifikate]).
Für den Subject-DN von Gruppen, Funktionen und automatisierten IT-
Prozessen gelten die in Kapitel 5.3.1 getroffenen Namensregelungen für
Teilnehmer. Zusätzlich muss aus dem Subject-DN und dem Gruppennamen
eindeutig hervorgehen, dass es sich bei diesem Teilnehmer um eine Gruppe,
Funktion oder einen automatisierten Prozess handelt. Dazu wird die folgende
Regel zur Namensbildung festgelegt:
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 Gruppen, Funktionen und
automatisierte IT-Prozesse eine E-Mail Adresse enthalten.
„[email=[E-Mail-Adresse],] cn=[GRP: Gruppenname], [[optionales Attribut=[xxx],
[...]], ou=[[Institution] | Service | [Firma]], o=[Teilnehmer-Namensraum der
Vertrags-CA], c=DE“
dürfen keine E-Mail-Adresse enthalten.
• „ cn=[GRP: Gruppenname]|[DNS-Name des SSL-Servers] “: Im
Attributwert für „commonName“ muss ersichtlich sein, dass der Teilnehmer
keine natürliche oder juristische Person ist, sondern es sich hierbei um eine
Gruppe, Funktion oder einen automatisierten Prozess handelt. Hierzu muss
der „commonName“ mit dem eindeutigen Kennzeichen „GRP:“ beginnen.
BSI Namensregeln und -formate Seite 32 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Für Gruppen, Funktionen und automatisierte IT-Prozesse wird die gleiche
Abkürzung "GRP:" verwendet. Die für die Namensgebung zuständige
Instanz muss sicherstellen, dass der Distinguished Name innerhalb des
Namensraumes der jeweiligen Organisation eindeutig ist. Eine Ausnahme
bilden die Namen von SSL-Servern: Hier muss der cn den genauen DNS-
Namen des Servers enthalten, um eine korrekte Verifikation der Zertifikate
beim Aufbau der SSL-Verbindung zu ermöglichen. (Da DNS-ähnliche
Formate in commonNames für alle anderen Fälle ausgeschlossen sind, ist
eine Verwechslung mit Zertifikaten für andere Zwecke trotzdem
ausgeschlossen).
• Die Verwendung von Personennamen als Gruppenname, wie z.B. "cn=GRP:
Müller Heinz Dr.", sollte vermieden werden.
• Bereits anderweitig in der PKI verwendete, reservierte oder geschützte
Namen bzw. Syntaxelemente (z.B. PN) dürfen nicht verwendet werden.
DNS-Namen und IP-Nummern dürfen ausschließlich für SSL-Server
verwendet werden.
Diensten sind Kapitel 5.3.1 zu entnehmen.
Grundsätzlich sollten Gruppenzertifikate nur für Gruppen, Dienste oder Server
ausgestellt werden, die entweder Teil der ausstellenden Behörde sind (z.B. die
Poststelle eines Ministeriums oder der E-Mail-Responder eines Finanzamts)
oder zum Verantwortungsbereich der Behörde gehören (z.B. der E-Mail-
Responder eines IT-Dienstleisters einer Kommune).
Bei Diensten und Servern ist darauf zu achten, dass aus dem Namen sowohl
hervorgeht, um welchen Dienst es sich handelt (z.B. cn=www.bund,de für das
Dienstleistungsportal des Bundes), als auch wer der Betreiber des Dienstes ist
(z.B. ou=telesec).
5.5.2 Beispiele für Subject-DNs bei Gruppen- und SSL-Server-
Zertifikaten
Beispiele für Subject-DNs für Gruppen, Funktionen und automatisierte IT-
Prozesse (die Unterschiede zwischen sK1, sK2 und sK3 entsprechend denen in
Tabelle 3):
cn=GRP: VDK-Editorenteam, ou=Secorvo GmbH, o=Bund, c=DE
[email protected], cn=GRP: VDK-Editorenteam, ou=Secorvo, o=Bund, c=de
cn=GRP: Automatischer E-Mail-Responder, ou=Poststelle, ou=BSI, o=Bund, c=DE
sK1: Stadt Köln
cn=GRP: Versicherungsamt, ou=Versicherungsamt, o=Stadt Koeln, c=DE
sK2: Stadt Frankfurt
cn=GRP: Versicherungsamt, ou=Versicherungsamt Stadt Frankfurt, o=Hessen, c=DE
sK3: Stadt München
cn=GRP: Versicherungsamt, ou=Versicherungsamt Stadt München, o=Bayern, c=DE (unterscheidet sich nicht relevant von sK2)
Tabelle 5: Beispiele für Subject-DNs für Gruppen, Funktionen und automatisierte IT- Prozesse
Subject-DN von SSL-Servern
cn=www.bsi.de, ou=Pressestelle, ou=BSI, o=Bund, c=DE
sK1: Stadt Köln
sK2: Stadt Frankfurt
sK3: Stadt München
cn=www.muenchen.de, ou=Pressestelle Stadt Muenchen, o=Bayern, c=DE (unterscheidet sich nicht relevant von sK2)
Tabelle 6: Beispiele für Subject-DNs für Gruppen, Funktionen und automatisierte IT- Prozesse
6 Namen in Directories
Das Kapitel beschreibt, wie die Namen von PKI-spezifischen Entries in
Verzeichnisdiensten gebildet werden müssen. Die hier getroffenen Vorgaben
stellen sicher, dass die Entries aus dem lokalen Verzeichnisdienst der
jeweiligen Zertifizierungsinstanz in die Dienste des Verzeichnisdienstkonzepts
repliziert werden können.
6.1 DIT-DN für Zertifizierungsinstanzen
6.1.1 DIT-Namensregeln für Zertifizierungsinstanzen
Bei allen CAs (auch nachgeordneten CAs) müssen die DIT-DNs gleich den
Subject-DNs sein. Nur für Windows2000-CAs gilt diese Regel nicht (vgl. hierzu
unten).
Es ergibt sich die folgende Namensregel für den DIT-DN:
„cn=[Name der CA], ou=[Name der CA-Gruppe], o=PKI-1-Verwaltung, c=DE“
Ausnahme:
„organizationalUnitName“ (ou):
6.1.2 DIT-Namensregeln für Windows 2000 CAs
Die folgenden Regeln stellen sicher, dass auch Systeme mit einer Windows
2000 PKI (die die Standard-Namensregeln aus technischen Gründen nicht un-
terstützen) am Verzeichnisdienstkonzept teilnehmen können.
Für Windows2000-PKIs werden abweichende DIT-DNs automatisch auf die
korrekten Subject-DNs im Austausch-DIT umgesetzt, wenn der DIT-DN der CA
die folgenden Bedingungen erfüllt5:
• alle CAs müssen im DIT unterhalb des Knotens cn=Public Key Services,
cn=Services, cn=Configuration, [Namensgebende DC-Komponenten]“
eingeordnet sein.
• Das unterste Attribute des DIT-DN der CA muss ein CN sein, der dem CN
im Zertifikat entspricht.
BSI Namensregeln und -formate Seite 35 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Es ergibt sich die folgende Namensregel:
„cn=[Name der CA], [[cn=[xxx], [...]], cn=Public Key Services, cn=Services,
cn=Configuration, [Namensgebende DC-Komponenten]“
Beispiele für DIT-DNs von Zertifizierungsinstanzen und dazugehörigem Sub-
ject-DN.
cn=PCA-1-Verwaltung, o=PKI-1- Verwaltung, c=DE
Nein
cn=ca testa deutschland, ou=testa deutschland, o=pki-1-verwaltung, c=DE
cn=ca testa deutschland, ou=testa deutschland, o=pki-1-verwaltung, c=DE
Nein
cn=CA-1-BYBN, cn=AIA, cn=Public Key Services, cn=Services, cn=Configuration, dc=PKI1, dc=Bayern, dc=de
cn=CA-1-BYBN, ou=Freistaat Bayern, o=PKI-1-Verwaltung, c=DE
Ja
cn=MFCA-1-BYBN, cn=AIA, cn=Public Key Services, cn=Services, cn=Configuration, dc=PKI1, dc=Bayern, dc=de
cn=MFCA-1-BYBN, ou=Freiststaat Bayern o=PKI-1-Verwaltung, c=DE
Ja
sK1: Stadt Köln
cn=CA Stadt Koeln, ou=Stadt Koeln, o=pki-1-verwaltung, c=DE
cn=CA Stadt Koeln, ou=Stadt Koeln, o=pki-1-verwaltung, c=DE
sK2: Stadt Frankfurt
cn=CA Stadt Frankfurt, ou=Hessen, o=pki-1-verwaltung, c=DE
cn=CA Stadt Frankfurt, ou=Hessen, o=pki-1-verwaltung, c=DE
sK3: Stadt München
6.2 DIT-DNs für CRL Distribution Points
6.2.1 DIT-Namensregeln für CDPs
CDPs dürfen in den Domänen im DIT nur unmittelbar unter den CAs
eingerichtet werden. Nur für Windows 2000-CAs gilt diese Regel nicht (vgl.
unten).
BSI Namensregeln und -formate Seite 36 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Aus dem CN des CDP muss hervorgehen, dass es sich um einen CDP handelt
und zu welcher CA er gehört. Es gilt folgende Namensregel:
„cn=CDP [Name der CA], cn=[Name der CA], ou=[Name der CA-Gruppe],
o=PKI-1-Verwaltung, c=DE“
c=DE c=DE
o=Bund o=Bund
o=PKI-1-Verwaltung o=PKI-1-Verwaltung
deutschland
deutschland
deutschland
ou=Stadt Köln
ou=Stadt Köln
Abbildung 3: Beispiele aus dem DIT für CDPs.
6.2.2 DIT-Namensregeln für CDPs für Windows 2000 CAs
Bei Windows2000-PKIs erfolgt eine Umsetzung der CDPs in die korrekte
Form,6 wenn der Windows 2000 Domänen-DIT die folgenden Bedingungen
erfüllt (Standard-DIT bei Windows2000):
• alle CDPs müssen im DIT unterhalb des Knotens „cn=CDP, cn=Public Key
Services, cn=Services, cn=Configuration, [Namensgebende DC-Kompo-
nenten]“ eingeordnet werden.
• Das unterste namensgebende Attribut des CDPs im D-DIT muss ein CN
sein, der dem CN der CA entspricht.
6 Vgl. zu den Umsetzungsregeln [PKI1V-VDK-Erg].
BSI Namensregeln und -formate Seite 37 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Damit ergibt sich folgende Regel für DIT-DNs in Windows 2000 Directories:
„cn=[Name der CA], [[cn=[xxx], [...]], cn=CDP, cn=Public Key Services,
cn=Services, cn=Configuration, [Namensgebende DC-Komponenten]“
Hinweis:
Der Name wird durch den Aktualisierungsprozess für den Verzeichnisdienst der
Verwaltung automatisch umgesetzt, wenn der CDP Entry zur Replikation ge-
kennzeichnet ist. Im Austausch-DIT der Dienste des Verzeichnisdienstkonzepts
folgt der Name dann der oben angegebenen Standard-Regel:
„cn=CDP [Name der CA], cn=[Name der CA], ou=[Name der CA-Gruppe],
o=PKI-1-Verwaltung, c=DE“.
Diese Umsetzung muss berücksichtigt werden, wenn die Adresse des CDPs im
Austausch-DIT in einem Zertifikat angegeben wird.
6.2.3 Beispiele für DIT-DNs von CDPs
DIT-DN Win2K PKI
cn=MFCA-1-BYBN, cn=pkinhstr212, cn=CDP, cn=Public Key Services, cn=Services, cn=Configuration, dc=pki1, dc=bayern, dc=de
Ja
cn=CDP MFCA-1-BYBN, cn=MFCA-1-BYBN, ou=Freistaat Bayern, o=PKI-1-Ver- waltung, c=DE
obiger CDP- Entry im Aus- tausch-DIT
cn=CDP CA Testa Deutschland, cn=CA Testa Deutschland, ou=Testa Deutschland, o=pki-1-verwaltung, c=DE
nein
sK1: Stadt Köln
cn=CDP CA Stadt Koeln, cn=CA Stadt Koeln, ou=Stadt Koeln, o=pki-1- verwaltung, c=DE
sK2: Stadt Frankfurt
cn=CDP CA Stadt Frankfurt, cn=CA Stadt Frankfurt, ou=Hessen, o=pki- 1-verwaltung, c=DE
sK3: Stadt München
6.3 DIT-DN für Teilnehmer
6.3.1 DIT-Namensregeln für Teilnehmer
Im Rahmen des Verzeichnisdienstkonzepts wurden Aktualisierungsprozesse
definiert, mit denen Entries aus einem lokalen Verzeichnisdienst in die Dienste
BSI Namensregeln und -formate Seite 38 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
des Verzeichnisdienstkonzepts übertragen werden. Diese Aktualisierungs-
prozesse bieten zwar eine Reihe von Konfigurationsmöglichkeiten, sind aber
doch auf einige Mindest-Voraussetzungen angewiesen. Sofern ein Entry die
Mindestvoraussetzungen erfüllt, kann er durch einen Umsetzungsmechanismus
auf den Entry abgebildet werden, der die Inhalte in den Diensten des Verzeich-
nisdienstkonzepts aufnimmt.7 Die folgenden Anforderungen beschreiben die
Mindestvoraussetzungen für die Umsetzung. Werden sie nicht erfüllt, kann
keine Übertragung der Entries nicht in die Dienste des
Verzeichnisdienstkonzepts erfolgen.
den DIT-DN eines Teilnehmer-Entries gestellt:
• commonName (cn) muss im DIT-DN jedes Teilnehmers enthalten sein. Ist
kein cn im DIT DN enthalten, muss im Entry ein Attribut "cn=" existieren, das
singlevalued belegt ist.
• organizationalUnitName (ou) muss mindestens einmal im DIT-DN enthalten
sein. Ist kein ou im DIT DN enthalten, muss im Entry ein Attribut "ou=" exis-
tieren, das singlevalued belegt ist.
• organizationName (o) muss mindestens einmal im DIT-DN enthalten sein.
Ist dies nicht der Fall, muss im Entry ein Attribut "o=" existieren, das single-
valued belegt ist.
• countryName (c): muss enthalten sein mit dem Wert "c=DE".
Sind die Anforderungen dieser Liste im lokalen DIT nicht erfüllt, muss die im
Umsetzungsprozess des Verzeichnisdienstkonzepts vorgesehene konfigurier-
bare Ersetzung der Namenswurzel verwendet werden, um die korrekte Struktur
7 Eine Aufnahme von Zertifikaten für SSL-Server und Endbenutzer-Zertifikaten ausschließlich
für SSL-Client-Authentifikation in das Verzeichnis ist nicht erforderlich. Um Verwechslungen
zu minimieren, wird empfohlen, diese Zertifikate weder in lokalen Verzeichnissen zu halten,
noch sie in die zentralen Verzeichnisdienste zu replizieren. Die Entscheidung darüber und
die Verantwortung für die Umsetzung liegt bei der jeweiligen CA.
BSI Namensregeln und -formate Seite 39 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
zu erreichen. Dies ist z. B. bei Verwendung von dc-Attributen in Windows 2000
Directories der Fall.
Es ergibt sich folgende Empfehlung für die Bildung von DIT-DNs von Teilneh-
mer-Entries:
„cn=[Name], [[optionales Attribut=[xxx], [...]], ou=[OU Name], o=[O Name],
c=DE“
Die einzelnen Namensbestandteile (bzw. Attribut-Werte im Entry) sind wie folgt
zu wählen:
• „c=DE“: Der Namensbestanteil ist festgelegt.
• „organizationName=“: Der Namensbestandteil des obersten „organiza-
tionName“ muss mit dem Wert aus dem Subject DN des Teilnehmer-Zertifi-
kats übereinstimmen (vgl. Kapitel 5.3.1). Entries, für die dies nicht der Fall
ist, werden nicht in die Dienste des Verzeichnisdienstkonzepts repliziert.
• „organizationalUnitName=“: Das für die Replikation relevante ou-Attribut
(oberster ou-Knoten im Subject DN) muss den Namen der Behörde
(rechtlich eigenständige Organisation) enthalten (vgl. Kapitel 5.3.1).
• „cn=Name“: Es wird empfohlen, den „commonName“ auch bei einer tiefe-
ren Strukturierung des lokalen DIT innerhalb des Namensraumes der
Organisation (in der Regel wird dies der oberste ou-Knoten sein) eindeutig
zu halten. Dazu sollte der cn gewählt werden, der auch im Subject DN des
Zertifikats des Teilnehmers enthalten ist (vgl. die Empfehlung zur
Eindeutigkeit oben in Kapitel 5.3.1).
• Als optionale Attribute können grundsätzlich beliebige Attribute gewählt
werden, auch solche, die nur innerhalb des lokalen Verzeichnisdienstes
spezifiziert sind. Unterstrukturierungen des lokalen Directory Information
Tree, wie sie z.B. mit „organizationalUnitName“ möglich sind, bleiben den
Institutionen überlassen.
BSI Namensregeln und -formate Seite 40 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Hinweis: Die Übereinstimmung von Subject DN und DIT DN ist nach diesen
Namensregeln für Teilnehmer nicht gefordert. Es ist Aufgabe der CA und des
lokalen Verzeichnisdienstes abzustimmen, wie Zertifikate in den Verzeichnis-
dienst eingestellt und daraus gelöscht werden können.
BSI Namensregeln und -formate Seite 41 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhänge: Format-Spezifikationen für Namen
Anhang B: Zertifikatserweiterung „subjectAltName“ 44
Anhang C: Alternative Namensformate 45
Anhang D: Zertifikatserweiterung „authorityKeyIdentifier“ 46
Anhang E: Zertifikatserweiterung „nameConstraints“ 47
Anhang F: Zertifikatserweiterung „cRLDistributionPoints“ 48
Anhang G:Basisformat einer CRL 49
Anhang H: Sperrlistenerweiterung „issuingDistributionPoint“ 50
Anhang I: X.500 Distinguished Name 51
Anhang J: Distinguished Name Attribut: „pseudonym“ 52
Anhang K: Distinguished Name: Länge von Attributtypen 53
Die Syntax von Distinguished Names ist aus der MailTrusT Spezifikation Ver-
sion 2 „Profile für Zertifikate und Sperrlisten“ [MTT PRO 99] übernommen. Die
Attribute selbst sind in [ITU-T X.520 97] definiert.
BSI Namensregeln und -formate Seite 42 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang A: Format eines X.509v3 Zertifikats
Certificate ::= SEQUENCE { tbsCertificate TBSCertificate, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }
TBSCertificate ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, issuerUniqueID [1] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,
-- If present, version shall be v2 or v3 extensions [3] EXPLICIT Extensions OPTIONAL
-- If present, version shall be v3 }
Version ::= INTEGER { v1(0), v2(1), v3(2) }
CertificateSerialNumber ::= INTEGER
Validity := SEQUENCE { notBefore Time, notAfter Time }
Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime }
UniqueIdentifier ::= BIT STRING
SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier, subjectPublicKey BIT STRING }
Extensions ::= SEQUENCE SIZE (1..MAX) OF Extension
Extension ::= SEQUENCE { extnID OBJECT IDENTIFIER, critical BOOLEAN DEFAULT FALSE, extnValue OCTET STRING }
BSI Namensregeln und -formate Seite 44 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang B: Zertifikatserweiterung „subjectAltName“
GeneralName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] ORAddress, directoryName 4] Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER }
OtherName ::= SEQUENCE { type-id OBJECT IDENTIFIER value [0] EXPLICIT ANY DEFINED BY type-id }
EDIPartyName ::= SEQUENCE { nameAssigner [0] DirectoryString OPTIONAL partyName [1] DirectoryString }
BSI Namensregeln und -formate Seite 45 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang C: Alternative Namensformate8
otherName beliebiges Format, z.B. für eigene Definitionen [ITU-T X.681 94]
rfc822Name Format für E-Mail-Adressen im Internet
[email protected]
sonne.darmstadt.gmd.de
[ITU-T X.411]
[ITU-T X.501 97]
uniformResource- Identifier
http://www.gmd.de oder ftp://.. oder ldap://..
[RFC 2396 98]
RegisteredId Format für Bezeichner von registrierten Objekten [ITU-T X.660 92]
8 Die Tabelle wurde der Spezifikation [ISIS 99] entnommen.
BSI Namensregeln und -formate Seite 46 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang D: Zertifikatserweiterung „authorityKeyIdentifier“
KeyIdentifier ::= OCTET STRING
Anhang E: Zertifikatserweiterung „nameConstraints“
GeneralSubtree ::= SEQUENCE { base GeneralName, minimum [0] BaseDistance DEFAULT 0, maximum [1] BaseDistance OPTIONAL }
BaseDistance ::= INTEGER (0..MAX)
Anhang F: Zertifikatserweiterung „cRLDistributionPoints“
DistributionPointName ::= CHOICE { fullName [0] GeneralNames, nameRelativeToCRLIssuer [1] RelativeDistinguishedName }
ReasonFlags ::= BIT STRING { unused (0), keyCompromise (1), cACompromise (2), affiliationChanged (3), superseded (4), cessationOfOperation (5), certificateHold (6) }
BSI Namensregeln und -formate Seite 49 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang G: Basisformat einer CRL
CertificateList ::= SEQUENCE { tbsCertList TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING }
TBSCertList ::= SEQUENCE { version Version OPTIONAL, signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificate SEQUENCE OF SEQUENCE {
userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL } OPTIONAL,
crlExtensions [0] EXPLICIT Extensions OPTIONAL
BSI Namensregeln und -formate Seite 50 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang H: Sperrlistenerweiterung „issuingDistributionPoint“
BSI Namensregeln und -formate Seite 51 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang I: X.500 Distinguished Name
Name ::= CHOICE { RDNSequence }
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY DEFINED BY AttributeType
Die möglichen Werte für ein Attribut werden durch die Typangabe bestimmt.
Die Werte für alle diese Attribute sind vom Typ „DirectoryString“9.
DirectoryString ::= CHOICE { teletexString TeletexString(SIZE (1..maxSize)), printableString PrintableString (SIZE (1.. maxSize)), universalString UniversalString (SIZE (1.. maxSize)), utf8String UTF8String (SIZE (1.. maxSize)), bmpString BMPString (SIZE (1.. maxSize)) }
9 Der MailTrusT Spezifikation 2 [MTT-PRO 99] entnommen.
BSI Namensregeln und -formate Seite 52 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang J: Distinguished Name Attribut: „pseudonym“
id-at OBJECT IDENTIFIER ::={ 2 5 4 }
id-at-pseudonym OBJECT IDENTIFIER ::= { id-at 65 }
-- pseudonym from the (forthcoming) X.520
pseudonym ATTRIBUTE ::= { WITH SYNTAX DirectoryString {ub_name } ID id-at-pseudonym }
Die Syntax des Attributs pseudonym ist im [PKIX QC 00] definiert, der sich auf
den Internet Draft PKCS #9 [PKCS#9 00] bezieht. In PKCS #9 ist das Attribut
pseudonym wie folgt definiert:
BSI Namensregeln und -formate Seite 53 von 53 BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002
Anhang K: Distinguished Name: Länge von Attributtypen10
Die Länge der AttributeValue-Stringtypen ist durch den Systemparameter
maxSize festgelegt, dessen Wert für die einzelnen Attribute gemäß der
folgenden Tabelle begrenzt ist. Hieraus ergeben sich die in der Längenspalte
angegebenen maximalen Längen der Attribute inklusive der ASN.1-
Kontrollinformationen, die eine Länge von 11 Bytes haben.
Objektbezeichner maxSize Länge
CommonName { 2 5 4 3 } 64 75
CountryName { 2 5 4 6 } 2 13
LocalityName { 2 5 4 7 } 32 43
OrganizationName { 2 5 4 10 } 64 75
organizationalUnit { 2 5 4 11 } 64 75
pseudonym12 { 2 5 4 65 } 64 75
email 128 139
11 Längenrestriktionen von Attribute der Syntax DirectoryString werden in X.500/LDAP in
Zeichen und nicht in Bytes angegeben. Die Angabe in Bytes stellt eine stärkere Restriktion
dar, die deshalb möglicherweise von den Produkten nicht gefordert wird. [ISIS-MTT Part 1]
spricht von "Maximal String Length".