namensregeln und -formate

Zertifizierungs-infrastruktur

für diePKI-1-Verwaltung

Namensregeln und -formate

Bundesamt für Sicherheit in der Informationstechnik

Version 1.3 vom 25.11.2002

Dieses Dokument einschließlich aller Teile ist urheberrechtlich geschützt.

Die unveränderte Weitergabe (Vervielfältigung) des Dokuments ist ausdrücklicherlaubt.

Jede weitergehende Verwertung außerhalb der engen Grenzen desUrhebergesetzes ist ohne Zustimmung des Bundesamtes für Sicherheit in der

Informationstechnik unzulässig und strafbar.

© 2002 Bundesamt für Sicherheit in der Informationstechnik

Godesberger Allee 185-189, 53175 Bonn

Telefon: 0228/9582-0 - Telefax: 0228/9582-405

Dr. Volker Hammer,Dr. Dörte Neundorf

Jörg VölkerSecorvo Security Consulting GmbH

Albert-Nestler-Straße 9D-76131 Karlsruhe

[email protected]@[email protected]

Dr. Albrecht RosenhauerDr. Andreas Schmidt

Michael ThielBundesamt für Sicherheit in der Informationstechnik

Godesberger Allee 185-189D-53175 Bonn

[email protected]@bsi.bund.de

[email protected]

BSI Namensregeln und -formate Seite 3 von 53BSI-DNR_Namensregeln_V1.3.doc Stand 25. November 2002

Inhaltsübersicht

Änderungshistorie 4

Literaturverzeichnis 5

Glossar und Abkürzungen 6

1 Einleitung und Übersicht 9

1.1 Zweck des Dokuments 9

1.2 Anwendungsbereich 10

1.3 Struktur des Dokuments 10

2 Grundlagen der Namensvergabe 11

2.1 Namen in Verzeichnisdiensten 11

2.2 Namen in Public-Key-Infrastrukturen 13

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

4.3 Bund, Länder und Kommunen 17

5 Subject Distinguished Names (DNs) 18

5.1 Grundsätzliche Regeln für Subject DNs 18

5.2 Subject-DNs für Wurzelzertifizierungsinstanz undZertifizierungsinstanzen 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 vonPseudonymen 27

5.4.1 Namensregeln für Subject-DNs bei Verwendung vonPseudonymen 27

5.4.2 Beispiele für Subject-DNs bei Verwendung vonPseudonymen 30


5.5 Subject Distinguished Names für Personengruppen, Funktionenund 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

Version Datum Status, Änderungen Autoren

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 wiefolgt gekennzeichnet: <?? Klärungsbedarf BSI ??>

• Die Beispiele und Abbildungen müssen auf Eignunggeprü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 Verzeichnisdienstkonzeptvom 10.4.2001,

• Herr Klasen, Herr Gietz (DAASI),• Herr Thiel (PCA).

Volker Hammer

1.0 08.05.02 Anmerkungen eingearbeitet von:

• 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)


Version Datum Status, Änderungen Autoren

1.2 14.06.02 Einarbeitung von Korrekturen nach Vorstellung derNamensregeln 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

Andreas Schmidt

(Ref I 1.3, BSI)

Literaturverzeichnis

[ISIS 99] Arbeitsgemeinschaft Trust-Center für digitale Signaturen: Industrial Signature Inter-operability Specification ISIS, Version 1.2, 3.12.1999

[ISIS-MTT] ISIS-MTT - T7 & TeleTrusT (2001): ISIS-MTT – Common ISIS-MTT SpecificationFor PKI Applications, Version 1.0.2, September Juli 2002, http://www.teletrust.deoder 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]

BSI - Bundesamt für Sicherheit in der Informationstechnik (Hrsg.) (2001): Zertifizie-rungsinfrastruktur für die PKI-1-Verwaltung – Technische Grundlagen der Wurzel-zertifizierungsstelle - Namensformat nach MTTv2, aktuelle Version

[PKI1V-VDK-Erg] BSI (Hrsg.): Zertifizierungsinfrastruktur für die PKI-1-Verwaltung: Verzeichnis-dienstkonzept, 2001 – 2002 (Abschlussdokument)

[RegelungGrpZertifikate]

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 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 - LightweightDirectory 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.


[X.500 ff 1997] ITU-T X.500 – International Telecommunication Union - Telecommunication Sector(1997): ITU-T Recommendation X.500 Ff – Information Technology - OpenSystems 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. Surnameoder OrganizationalUnitName. Attribute treten in zwei Rollen auf:

• als Bestandteile eines eindeutigen Namens (Distinguished Name). DerDistinguished Name besteht aus einer Reihe von Attributen, derenReihenfolge festgelegt ist. In der Reihenfolge können an unterschiedlichenStellen Attribute gleichen Typs auftreten.

• als Speicherplatz für Werte in einem ÕEntry. Ein Entry kann verschiedeneAttribute enthalten. Ein Attribut kann so definiert werden, dass es nur eineneinzelnen Wert (singlevalued) oder mehrere Werte des Typs aufnehmen kann(multi-valued).

Attribut-Typ Attribut-Typen dienen der Spezifikation von Attributen für das ÕDirectorySchema. Mit ihnen wird die Semantik und die Codierung von Werten bestimmt.Sie werden benutzt, um ÕObjektklassen zu definieren. Ein ÕAttribut ist dieInstanz 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. Unterbestimmten Umständen kann dies die Verwaltung der Sperrlisten oder denZugriff darauf erleichtern.

2) Im Zertifikat kann ein CDP angegeben sein, der direkt auf den Speicherortder Sperrliste (nämlich den CDP im Verzeichnis) verweist. Dies kannClients 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

Zusammenfassend für die drei Dienste, die im Verzeichnisdienstkonzept spezi-fiziert werden: zentraler Verzeichnisdienst der Verwaltung, Austauschdienst undVeröffentlichungsdienst.


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 vonNamen aufgespannt, die jeweils relativ zum übergeordneten Knoten eindeutigsein müssen. Jeder Entry im DIT wird durch seinen DIT-Distinguished Nameeindeutig 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, eindeutigerName (und Identifier) eines ÕEntries im Directory. Siehe auch ÕDIT undÕLDAP-Schreibweise von DIT-DNs. Zur Unterscheidung siehe ÕSubject-DNund Õ Issuer-DN. Der DIT-DN eines Teilnehmer-Entries und sein Subject-DN imZertifikat 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 einesZertifikates der PKI ist.

Entry Die Informationen zu einem Objekt (Teilnehmer oder Zertifizierungsinstanz)werden in einem sogenannten Entry im Verzeichnisdienst gespeichert. DerEntry 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 einenautomatischen E-Mail-Dienst, ausgestellt. Der Zugriff auf den geheimenSchlüssel kann, anders als für persönliche Schlüsselpaare, mehreren Personeneingeräumt werden.

gn Abkürzung für Given Name (Attribut-Typ).

Gruppenzertifikat Das Zertifikat wird auf den Namen einer Gruppe ausgestellt. Der Zugriff auf dengeheimen Schlüssel wird, anders als für persönliche Schlüsselpaare, mehrerenPersonen 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 - TelecommunicationSector, 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. DieSzenarien 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 abgefragtoder geändert werden kann, macht aber keine Aussagen über die Ablage derDaten. Auch "echte" X.500 Server oder Standard-Datenbanken können LDAP"sprechen".

LDAP-Schreibweisevon DIT-DNs

Die LDAP-Schreibweise von ÕDIT-DNs beginnt beim Blatt-Entry und folgt denKnoten aufsteigend zur Wurzel des DIT, also bspw. "cn=Mustermann Peter,o=Muster GmbH, c=DE".


MTT MailTrusT, Standard für Formate und Dienste von ÕPKIs und fürAnwendungen, die PKI-Leistungen nutzen, z. B. zur Verschlüsselung von E-Mails.

NamensgebendesAttribut

Das "unterste" ÕAttribut des DIT-DN, das den Namen des ÕEntries von denanderen Entries auf der gleichen Ebene unterscheidet, wird alsnamensgebendes 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 öffentlichenSchlüsseln, Zertifikaten und Sperrinformationen.

PKI-1-Verwaltung PKI der öffentlichen Verwaltung der Bundesrepublik Deutschland. Sie umfasstalle ÕPKIs, die durch die ÕPCA-1-Verwaltung für die öffentliche Verwaltungzertifiziert werden.

PKI-Informationen Oberbegriff für Teilnehmer-Zertifikate, CA-Zertifikate und Sperrlisten

Relative DistinguishedName

Der Relative Distinguished Name ist ein Namensteil des DIT DistinguishedName, der auf einer Ebene des DIT Eindeutigkeit sicherstellt. Für den Werteines Relative Distinguished Names eines Entries ist gefordert, dass er sich vonallen anderen Relative Distinguished Names auf der gleichen Ebene seinesTeilbaums 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.

Steuerungsgremiumder PKI-1-Verwaltung

Gegenwärtig wird geklärt, wie die an der PKI-1-Verwaltung beteiligten Domänenund CAs gemeinsam die Weiterentwicklung dieser PKI und des Verzeichnis-dienstkonzepts steuern. Das künftig zuständige Gremium wirdzusammenfassend 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 imRahmen der PKI-1-Verwaltung Schlüssel und Zertifikate erhalten oder aus demVerzeichnisdienst 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 weitereSonderzeichen.

UTF8 Codierungsvorschrift zur Codierung von ÕUNICODE-Zeichen in Texten undNachrichten

X.500 ff. Serie von Standards der Õ ITU-T für Verzeichnisdienste.


1 Einleitung und Übersicht

1.1 Zweck des Dokuments

Die in der PKI-1-Verwaltung ausgestellten Zertifikate und Sperrlisten (PKI-In-

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.


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,

• alle nachgeordneten Zertifizierungsinstanzen,

• natürliche Personen,

• juristische Personen mit einem personenbezogenen Zertifikat,

• Gruppenzertifikate (z.B. für Personengruppen, Funktionen oder automati-

sierte 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 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.

• 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 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.

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


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=DEc=DE

o=Bundo=Bund

ou=BMIou=BMI

l=Berlinl=Berlin

cn=Peter Müllercn=Müller Peter

ou=BSIou=BSI

ou=BMWIou=BMWI

o=Thüringeno=Thüringen

o=Stadt Kölno=Stadt Köln

Abbildung 1: Beispiel für einen Directory Information Tree. Der Teilnehmer-Entry liegt imTeilbaum 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.


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

• 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:


• 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.

• Es soll ein Austausch von PKI-Informationen zwischen verschiedenen Ver-

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.

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


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,

• 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 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.


• 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 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-


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.


• 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,

• 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.


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.

„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.


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

PCA cn=pca-1-verwaltung, o=pki-1-verwaltung, c=DE

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 2000PKI

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: StadtKöln

cn=CA Stadt Koeln, ou=Stadt Koeln, o=pki-1-verwaltung, c=DE

sK2: StadtFrankfurt

cn=CA Stadt Frankfurt, ou=Hessen, o=pki-1-verwaltung, c=DE

sK3: StadtMünchen

entfällt (keine eigene CA)

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=DEc=DE

o=Bundo=Bund

o=PKI-1-Verwaltungo=PKI-1-Verwaltung

cn=PCA-1-Verwaltung

cn=PCA-1-Verwaltung ou=Freistaat

Bayern

ou=FreistaatBayern ou=testa

deutschland

ou=testadeutschland

cn=CA-1-BYBN

cn=CA-1-BYBN cn=MFCA-1-

BYBN

cn=MFCA-1-BYBN cn=ca testa

deutschland

cn=ca testadeutschland

ou=StadtKöln

ou=StadtKöln

cn= CAStadt Köln

cn= CAStadt Köln

Abbildung 2: Beispiele aus dem Namensbaum von Subject-DNs für CAsJede 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):

• 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


(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):

• eMailAddress (email); 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 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.

„[email=[E-Mail-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 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).


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.

• „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).


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.


gewählte Reihenfolge der Bestandteile des CN dient der einfachen Suche in

Verzeichnissen.

• „email=[E-Mail-Adresse]“: Die E-Mail 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

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.

Mitarbeiter von Firmen müssen eindeutig als externe Mitarbeiter gekenn-

zeichnet 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.


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

[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: StadtKö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: StadtFrankfurt

cn=Frick Frider, ou=Einwohnermeldeamt Stadt Frankfurt, o=Hessen, c=DE

sK3: StadtMü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

5.4.1 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


(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:

• „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 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.

• 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.


• 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:

• 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.

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: StadtFrankfurt

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.


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:

„cn=[GRP: Gruppenname]|[DNS-Name des SSL-Servers], [[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 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“

Für SSL-Server-Zertifikate gilt diese Ausnahme nicht; Namen von SSL-Servern

dürfen keine E-Mail-Adresse enthalten.

Die einzelnen Namensbestandteile sind wie folgt zu wählen:

• „ 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.


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.

Die Namensregeln für die weiteren Namensbestandteile für Gruppen und

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):

Subject-DN von Gruppen

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: StadtKöln

cn=GRP: Versicherungsamt, ou=Versicherungsamt, o=Stadt Koeln, c=DE

sK2: StadtFrankfurt

cn=GRP: Versicherungsamt, ou=Versicherungsamt Stadt Frankfurt, o=Hessen, c=DE

sK3: StadtMü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: StadtKöln

cn=www.koeln.de, ou=Presestelle, o=Stadt Koeln, c=DE

sK2: StadtFrankfurt

cn=www.frankfurt.de, ou=Pressestelle, o=Hessen, c=DE

sK3: StadtMü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:

Der DIT-DN der PCA-1-Verwaltung enthält keinen Namensbestandteil vom Typ

„organizationalUnitName“ (ou):

„cn=[Name der CA], o=PKI-1-Verwaltung, c=DE“

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.

5 Vgl. zu den Umsetzungsregeln [PKI1V-VDK-Erg].


Es ergibt sich die folgende Namensregel:

„cn=[Name der CA], [[cn=[xxx], [...]], cn=Public Key Services, cn=Services,

cn=Configuration, [Namensgebende DC-Komponenten]“

6.1.3 Beispiele für DIT-DNs von Zertifizierungsinstanzen

Beispiele für DIT-DNs von Zertifizierungsinstanzen und dazugehörigem Sub-

ject-DN.

DIT-DN Subject-DN Win2KPKI

cn=PCA-1-Verwaltung, o=PKI-1-Verwaltung,c=DE

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=testadeutschland, 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=FreistaatBayern, o=PKI-1-Verwaltung, c=DE

Ja

cn=MFCA-1-BYBN, cn=AIA, cn=Public KeyServices, cn=Services, cn=Configuration,dc=PKI1, dc=Bayern, dc=de

cn=MFCA-1-BYBN, ou=FreiststaatBayern o=PKI-1-Verwaltung, c=DE

Ja

sK1: StadtKöln

cn=CA Stadt Koeln, ou=StadtKoeln, o=pki-1-verwaltung, c=DE

cn=CA Stadt Koeln, ou=StadtKoeln, o=pki-1-verwaltung, c=DE

sK2: StadtFrankfurt

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: StadtMünchen

entfällt (keine eigene CA) entfällt (keine eigene CA)

Tabelle 7: Beispiele für DIT-DN und korrespondierenden Subject-DN

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).


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=DEc=DE

o=Bundo=Bund

o=PKI-1-Verwaltungo=PKI-1-Verwaltung

ou=FreistaatBayern

ou=FreistaatBayern ou=testa

deutschland

ou=testadeutschland

cn=CA-1-BYBN

cn=CA-1-BYBN cn=ca testa

deutschland

cn=ca testadeutschland

cn=CDPCA-1-BYBN

cn=CDPCA-1-BYBN cn=CDP ca testa

deutschland

cn=CDP ca testadeutschland

ou=StadtKöln

ou=StadtKöln

cn=CA StadtKöln

cn=CA StadtKöln

cn=CDP CAStadt Köln

cn=CDP CAStadt 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].


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: StadtKöln

cn=CDP CA Stadt Koeln, cn=CA Stadt Koeln, ou=Stadt Koeln, o=pki-1-verwaltung, c=DE

sK2: StadtFrankfurt

cn=CDP CA Stadt Frankfurt, cn=CA Stadt Frankfurt, ou=Hessen, o=pki-1-verwaltung, c=DE

sK3: StadtMünchen

entfällt (keine eigene CA)

Tabelle 8: Beispiele für DIT-DN von CDPs

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


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.

Die folgenden Anforderungen werden aus dem Verzeichnisdienstkonzept an

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.


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:


• „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.


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.


Anhänge: Format-Spezifikationen für Namen

Anhang A: Format eines X.509v3 Zertifikats 42

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.


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 v3subjectUniqueID [2] IMPLICIT UniqueIdentifier OPTIONAL,

-- If present, version shall be v2 or v3extensions [3] EXPLICIT Extensions OPTIONAL

-- If present, version shall be v3 }

Version ::= INTEGER { v1(0), v2(1), v3(2) }

CertificateSerialNumber ::= INTEGER

AlgorithmIdentifier ::= SEQUENCE {Algorithm OBJECT IDENTIFIER,parameters ANY DEFINED BY algorithm OPTIONAL }

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 }


Anhang B: Zertifikatserweiterung „subjectAltName“

SubjectAltName ::= GeneralNames

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

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 IDENTIFIERvalue [0] EXPLICIT ANY DEFINED BY type-id }

EDIPartyName ::= SEQUENCE {nameAssigner [0] DirectoryString OPTIONALpartyName [1] DirectoryString }


Anhang C: Alternative Namensformate8

GENERALNAMETypnamen

Bedeutung der Formate und Beispiele RELEVANTENormen

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]

[RFC 822 82]

dNSName Format für Domänennamen in Internet

sonne.darmstadt.gmd.de

[RFC 1035 87]

x400Address Format für X.400-Adressen

S=user; P=darmstadt; A=gmd; c=de

[ITU-T X.411]

directoryName Format für Verzeichnisdienstnamen

cn=vorname name, L=darmstadt, o=gmd, c=DE

[ITU-T X.501 97]

ediPartyName Format für elektronischen Dokumentenaustausch

uniformResource-Identifier

Format für Uniform Resource Identifier (URI) im World-Wide-Web

http://www.gmd.de oder ftp://.. oder ldap://..

[RFC 2396 98]

IPAddress Format für Internet-Protokoll-Adressen

141.12.63.6

[RFC 791 81]

RegisteredId Format für Bezeichner von registrierten Objekten [ITU-T X.660 92]

8 Die Tabelle wurde der Spezifikation [ISIS 99] entnommen.


Anhang D: Zertifikatserweiterung „authorityKeyIdentifier“

AuthorityKeyIdentifier ::= SEQUENCE {keyIdentifier [0] KeyIdentifier OPTIONAL,authorityCertIssuer [1] GeneralNames OPTIONAL,authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL}

( WITH COMPONENTS {..., authorityCertIssuer PRESENT, authorityCertSerialNumber PRESENT } |

WITH COMPONENTS {..., authorityCertIssuer ABSENT, authorityCertSerialNumber ABSENT } )

KeyIdentifier ::= OCTET STRING


Anhang E: Zertifikatserweiterung „nameConstraints“

NameConstraints ::= SEQUENCE {permittedSubtrees [0] GeneralSubtrees OPTIONAL,excludedSubtrees [1] GeneralSubtrees OPTIONAL }

GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

GeneralSubtree ::= SEQUENCE {base GeneralName,minimum [0] BaseDistance DEFAULT 0,maximum [1] BaseDistance OPTIONAL }

BaseDistance ::= INTEGER (0..MAX)


Anhang F: Zertifikatserweiterung „cRLDistributionPoints“

CRLDistPointsSyntax ::= SEQUENCE SIZE (1..MAX) OF DistributionPoint

DistributionPoint ::= SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL,reasons [1] ReasonFlags OPTIONAL,cRLIssuer [2] GeneralNames OPTIONAL }

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) }


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


Anhang H: Sperrlistenerweiterung „issuingDistributionPoint“

IssuingDistributionPoint ::= SEQUENCE {distributionPoint [0] DistributionPointName OPTIONAL,onlyContainsUserCerts [1] BOOLEAN DEFAULT FALSE,onlyContainsCACerts [2] BOOLEAN DEFAULT FALSE,onlySomeReasons [3] ReasonFlags OPTIONAL,indirectCRL [4] BOOLEAN DEFAULT FALSE


Anhang I: X.500 Distinguished Name

Name ::= CHOICE { RDNSequence }

RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

RelativeDistinguishedName ::= SET OF AttributeTypeAndValue

AttributeTypeAndValue ::= SEQUENCE {type AttributeType,value AttributeValue }

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.


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:

pseudonym ATTRIBUTE ::= {WITH SYNTAX DirectoryString {pkcs-9-ub-pseudonym}EQUALITY MATCHING RULE caseExactMatchID id-at-pseudonym }


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

Name nummer [Bytes]11 [Bytes]

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

10 Die Längenangaben entstammen der Spezifikation [ISIS 99].

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".

12 Das Attribut pseudonym wird im kommenden X.520 definiert [siehe PKIX QC 00].

namensregeln und -formate

Documents