IKS Service GmbH: High Certification Policy

Kurzfassung dessen, was eigentlich zertifiziert wird.

Inhalt

  1. Einleitung
  2. Gültigkeit dieses Dokumentes
  3. Zuständigkeitsbereich
  4. Rechtliche Bedeutung
  5. Die Zertifizierungshierarchie (CH)
    1. Regionale Zertifizierungsinstanzen (CA)
    2. Regionale Registrierungsinstanzen (RA)
  6. Sicherheit der CA-Ausstattung
    1. Sicherheitsanforderungen an die Root-CA
    2. Sicherheitsanforderungen an Regionale CAs
    3. Sicherheitsanforderungen an RAs
    4. Sicherheitsanforderungen an Benutzer
  7. Zertifizierungsregeln
    1. Regeln für die Zertifizierung von CAs
    2. Regeln für die Zertifizierung von RAs
    3. Regeln für die Zertifizierung von Benutzern
    4. Regeln für die Cross-Zertifizierung zweier CAs
  8. Management von Zertifikaten
  9. Widerruf von Zertifikaten
  10. Regeln für die Namensgebung
    1. Wahl eines Namens für CAs
    2. Wahl eines Namens für RAs und Benutzer
    3. Wahl eines Gruppennamens
  11. Verschiedenes
    1. Erklärungen der Teilnehmer
    2. Vereinbarungen zwischen Root-CA und CA
    3. Vereinbarungen zwischen CA und RA
    4. Gebühren
    5. Eingesetzte Software

1 Einleitung

Dieses Dokument enthält die Zertifizierungsrichtlinien (die sog. "Policy") der obersten Zertifizierungsinstanz der IKS Service GmbH.

Der Sinn dieses Dokumentes ist es, Benutzern im Netzwerk eine Einschätzung der durch diese CAs ausgestellten Zertifikate zu ermöglichen sowie die Mindestanforderungen an den Betrieb der regionalen Zertifizierungsinstanzen (CAs) zu geben, die durch die Root-CA zertifiziert werden.

Die in diesem Dokument getroffenen Aussagen sind für die Arbeit der Root-CA und der durch die Root-CA zertifizierten CAs bindend, soweit sie nicht gesetzlichen Regelungen widersprechen. Jede CA zertifiziert ausschließlich nach den Richtlinien dieser Policy. Um die internationale Zusammenarbeit mit anderen CAs zu ermöglichen, wird ferner eine englische Übersetzung dieses Dokumentes veröffentlicht werden; maßgeblich ist diese deutsche Fassung der Policy.

Die Benennungsrichtlinien der regionalen CAs gemäß dieser Policy als CAs soll Einschränkungen ähnlicher Entwicklungen in diesen Regionen vermeiden. Die trifft gleichermaßen auf die Benennung der RAs zu.

2 Gültigkeit dieses Dokumentes

Dieses Dokument ist vom 26. März 1997 bis 31. Dezember 2008, sowie im Rahmen einer Überleitung auf den Nachfolger dieses Dokumentes bis zum 30. März 2009 gültig. Die Regeln für den Ablauf der Überleitung sind Bestandteil des neuen Nachfolgedokumentes und können die Überleitungsfrist nicht verkürzen.

3 Zuständigkeitsbereich der CH

Zuständigkeitsschema

Der Zuständigkeitsbereich der CH (Zertifikationshierararchie) umfaßt alle vertraglich zertifizierten CAs und RAs und alle interessierten Nutzer.

Das vorrangige Ziel der CH besteht in dem Aufbau einer kommerziellen Public-Key-Zertifizierungs-Infrastruktur. Eine solche Infrastruktur ist die Voraussetzung für vertrauenswürdige Kommunikation.

Eine Erzeugung privater Schlüssel darf nur dann durch eine CA erfolgen, wenn dies zur Erzeugung des Zertifikates protokollbedingt unvermeidlich ist. Die CA behält nach der Aushändigung eines Schlüsselpaares an den Benutzer keine Kopie des entsprechenden privaten Schlüssels oder der zur Konstruktion notwendigen Zwischenwerte.

Unterstützt werden im Rahmen der technischen Möglichkeiten:

4 Rechtliche Bedeutung

Eine Zertifizierung durch die CH zieht keinerlei rechtliche Bedeutung nach sich; ein gesetzlicher Anspruch auf die Erteilung eines Zertifikates durch die CAs besteht nicht.

Insbesondere ist die allgemeine rechtliche Relevanz digitaler Signaturen derzeit unklar. Der Sinn einer weiten Public-Key-Infrastruktur liegt in der Schaffung der technischen Voraussetzungen für eine gesicherte elektronische Kommunikation. Insbesondere die Firma IKS Service GmbH, die beauftragten Personen und Firmen sowie die regionalen Mitarbeiter der CAs übernehmen keine Form der Gewährleistung. Alle Aufgaben werden von den Projektmitarbeitern nach bestem Wissen und Gewissen durchgeführt.

5 Die Zertifizierungshierarchie (CH)

Die dem X.509-Modell folgende Zertifizierungshierarchie unterhalb der Root-CA besteht aus drei verschiedenen Einheiten (Zertifikatnehmern):

Die externe Anbindung der kompletten CH an andere Hierarchien kann durch eine wechselseitige Zertifizierung (Cross-Zertifizierung) der CAs mit anderen CAs erfolgen. Die Eingliederung der CH in eine Internet-weite Infrastruktur kann erfolgen, sobald eine entsprechende Instanz verfügbar ist. In jedem Fall werden die Teilnehmer der CH über internationale Anbindungen und Cross-Zertifizierungen informiert.

5.1 Regionale Zertifizierungsinstanzen (CA)

Es kann regionale CAs geben, welche direkt von der Root-CA zertifiziert werden. Diese regionalen CAs haben die Möglichkeit, ihrerseits Zertifikate für Benutzer und ihnen untergeordnete Regionale RAs zu erzeugen. Weitere, den regionalen CAs untergeordnete CAs sind zu vermeiden.

Es kann ebenso firmeninterne CAs geben, die in ihren Substrukturen nicht weiter beschränkt sind.

Unterhalb der Root-CA operierende regionale CAs haben weiterhin die Möglichkeit, durch den Vorgang der Cross-Zertifizierung mit anderen CAs eigene Verbindungen zu Zertifizierungsinstanzen bzw. -infrastrukturen herzustellen.

Der öffentliche Schlüssel der Root-CA ist in einem selbst-signierten Zertifikat (Wurzel-Zertifikat), ausgestellt durch die Root-CA, enthalten. Alle Teilnehmer der Infrastruktur erhalten dieses Wurzel-Zertifikat im Zuge der eigenen Zertifizierung und können somit die Authentizität und Gültigkeit aller unterhalb der Root-CA erteilten Zertifikate überprüfen. Die Root-CA ist verpflichtet, direkte Abrufmöglichkeiten des Wurzel-Zertifikates über verschiedene Medien und Internet-Dienste bereitzustellen.

5.2 Regionale Registrierungsinstanzen (RA)

Innerhalb größerer Regionen kann es vorkommen, daß die zuständige CA weit entfernt von den zu zertifizierenden Benutzern lokalisiert ist. In diesem Fall besteht die Möglichkeit, vertrauenswürdige Registrierungsinstanzen (RAs) für die lokale Überprüfung von Identität und Authentizität der einzelnen Benutzer einzusetzen. RAs dürfen lediglich zur Entgegennahme von Zertifizierungswünschen von Benutzern und zur Überprüfung ihrer Identität eingerichtet werden.

Bei einer Registrierungsinstanz handelt es sich um einen in der üblichen Weise durch eine CA zertifizierten Teilnehmer, der im Auftrag seiner CA die Identitätsprüfung anderer Benutzer vor deren Zertifizierung durch die CA übernimmt. Benutzer, die zertifiziert werden möchten, übermitteln ihren selbst-signierten Public Key und den entsprechenden Zertifizierungswunsch an die entsprechende RA, welche sich anschließend in geeigneter Weise von der Identität des Benutzers überzeugen muß, um unzulässige Zertifizierungswünsche auszuschließen.

Eine RA darf weder einen Schlüssel für Benutzer erzeugen, noch darf sie Benutzer-Zertifikate erteilen. Die RA leitet lediglich einen vom Benutzer selbst-signierten Public Key in einer durch die RA signierten Nachricht an die CA weiter, wenn die Identität des Benutzers in geeigneter Weise durch die RA überprüft wurde. Empfängt eine CA den Zertifizierungswunsch eines Benutzers von einer vertrauenswürdigen RA, wird nach Überprüfung der Gültigkeit der RA-Signatur das von der CA neu ausgestellte Zertifikat sowohl an die RA als auch an den Benutzer übermittelt.

Jede CA kann beliebig viele Benutzer zu Registrierungsinstanzen ernennen. Eine RA wird sich üblicherweise an bestimmte Prozeduren, festgelegt durch die CA, halten müssen. Diese Prozeduren umfassen mindestend die in dieser Policy aufgeführten Handlungsweisen. Jede CA veröffentlicht diese Prozeduren, zusammen mit einer Liste aller von ihr betrauten RAs.

6 Sicherheit der CA-Ausstattung

Durch die Teilnahme an einer Public-Key-Infrastruktur entstehen für alle Teilnehmer bestimmte Anforderungen hinsichtlich der Sicherheit der eingesetzten Hard- und Software einerseits sowie des verantwortungsvollen Umgangs mit kryptographischen Schlüsseln andererseits. Die Anforderungen an die CAs und die RAs sind dabei naturgemäß höher als die an die Benutzer, da der Mißbrauch eines CA-/RA-Schlüssels allen untergeordneten Zertifikaten die Vertrauenswürdigkeit entziehen würde.

6.1 Sicherheitsanforderungen an die Root-CA

Folgende Anforderungen werden an die Root-CA gestellt:

6.2 Sicherheitsanforderungen an Regionale CAs

Folgende Anforderungen werden an die von der Root-CA zertifizierten regionalen CAs gestellt:

6.3 Sicherheitsanforderungen an RAs

Folgende Anforderungen werden an die von einer CA eingesetzten RAs gestellt:

6.4 Sicherheitsanforderungen an Benutzer

Benutzer im Sinne dieser Policy sind einzelne Personen. Folgende Anforderungen werden an die von einer CA zertifizierten Benutzer gestellt:

7 Zertifizierungsregeln

Dieser Abschnitt beschreibt technische und organisatorische Richtlinien und Prozeduren, die vor einer Zertifizierung von CAs oder Benutzern zu beachten sind.

Sowohl Zertifizierungsinstanzen als auch Benutzer werden mit eindeutigen Namen bezeichnet. Die Wahl dieser Namen wird später beschrieben.

Vor jeder Zertifizierung hat sich die CA in geeigneter Weise durch technische und organisatorische Maßnahmen von der Identität desjenigen Schlüsselinhabers zu überzeugen, welcher eine Zertifizierung wünscht, um unerlaubte Zertifizierungswünsche zu erkennen. Dieser Vorgang kann nur durch persönlichen Kontakt oder telefonischen Rückruf zu persönlich bereits länger und gut Bekannten vor der Zertifizierung erfolgen. Für kurzfristige Testzertifikate kann die Überprüfung etwas laxer ausfallen.

Setzt eine CA Registrierungsinstanzen ein, kann die Verantwortung der Identitätsprüfung an die RAs delegiert werden. Diese Delegierung ist mit der Einrichtung der RA ausgesprochen und bedarf keiner Einzelfallzustimmung. Zur Identitätsprüfung sollte die CA oder RA benutzt werden, die der Aufgabe am geeignetsten nachkommen kann.

Das selbst-signierte Zertifikat eines Zertifikatnehmers im Sinne dieser Policy muß mindestens den Namen des Teilnehmers sowie dessen Public Key enthalten. Wahlweise kann dieses Zertifikat auch eine Gültigkeitsdauer enthalten. Nur derartige selbst-signierte Zertifikate sind im Rahmen dieser Policy zertifizierbar.

Zertifikate werden ausschließlich dann erteilt, wenn der zu zertifizierende Public Key über die festgelegten Mindestlängen verfügt und sich die zertifizierende Instanz in geeigneter Weise von der Identität des Schlüsselinhabers und dem Besitz des korrekten Schlüsselpaares überzeugt hat. In jedem Fall ist die Personalausweisnummer oder Reisepaßnummer des Schlüsselinhabers als Nachweis für den erfolgten Identitätsnachweis zu notieren. Diese Angaben sind vertraulich zu behandeln.

Bietet ein Protokoll keine Möglichkeit, ein Zertifikat zu widerrufen, so ist zusätzlich bei der Zertifizierung ein "Key Revocation Certificate" zu erzeugen und dieses bei der Zertifizierung mit zu Übergeben. Die CA wird dieses "Key Revocation Certificate" ausschließlich im Falle des Zertifikatwiderrufs verwenden.

Für anonyme, pseudonyme oder andere experimentelle Zertifikate sind die Nachweise gemäß des zugehörigen protokollspezifischen Anhangs durchzuführen.

7.1 Regeln für die Zertifizierung von CAs

CAs, die von der Root-CA zertifiziert werden möchten, unterzeichnen vor der Zertifizierung eine Vereinbarung mit der Root-CA. Diese Vereinbarung enthält eine Erklärung darüber, daß die Richtlinien dieser Policy akzeptiert werden und deren Einhaltung beim Betrieb der eigenen CA zugestimmt wird. Berechtigt zu der Unterzeichnung dieser Vereinbarung ist eine für den Betrieb der CA verantwortliche Person (CA-Administrator).

Die jeweilige CA hat der Root-CA ein schriftliches Konzept vorzulegen, aus dem die Soft- und Hardware, die eingesetzt werden sollen, ebenso hervorgehen wie die technischen und organisatorischen Maßnahmen, die die Betreiber der zukünftigen CA zur Gewährleistung der Sicherheitsanforderungen zu treffen gedenken.

Die Root-CA behält sich vor, CAs auf deren Eignung sowie das Vorhandensein der technischen Voraussetzungen vor Ort zu überprüfen.

Die Zertifizierung von CAs erfordert den persönlichen Kontakt zwischen dem Administrator der CA und der Root-CA.

Zertifikate für CAs haben eine Gültigkeitsdauer von maximal 2 Jahren.

Die Einrichtung organisationsweiter Sub-Hierarchien obliegt der Verantwortung der CA der jeweiligen Organisation. Über diese Policy hinausgehende Richtlinien können bei Bedarf von jeder Sub-CA in einer eigenen Policy festgelegt werden.

7.2 Regeln für die Zertifizierung von RAs

Jede CA kann Benutzer bestimmen, welche im Auftrag der CA als Registrierungsinstanz (RA) fungieren. Die CA kann die Unterzeichnung einer Vereinbarung verlangen, welche die RA an bestimmte Richtlinien bindet. Insbesondere sollen von der RA die Sicherheitsanforderungen eingehalten werden.

Ein RA-Zertifikat unterscheidet sich nicht von einem üblichen Benutzer-Zertifikat. Für die Zertifizierung von RAs siehe daher den nächsten Abschnitt.

7.3 Regeln für die Zertifizierung von Benutzern

Ein Benutzer, welcher zertifiziert werden möchte, generiert zunächst ein persönliches asymmetrisches Schlüsselpaar und übermittelt anschließend ein selbst-signiertes Zertifikat oder eine Zertifikatsaufforderung per E-Mail oder mittels eines Datenträgers an die zuständige RA bzw. CA.

Vor der Zertifizierung vergewissert sich die CA von der Identität des Benutzers und der korrekten Zuordnung der E-Mailadresse zu diesem Benutzer. Erfolgt die Verifikation durch eine RA, leitet diese das vom Benutzer vorgelegte selbst-unterschriebene Zertifikat oder die vorgelegte Zertifikatsaufforderung in einer signierten und verschlüsselten (wegen der Ausweisnummer) Nachricht an die zuständige CA weiter.

Sollen Gruppenschlüssel zertifiziert werden, hat ein Mitglied der Gruppe den Public Key an die zertifizierende Instanz zu übermitteln. Diese hat vor der Zertifizierung in geeigneter Weise die Existenz der entsprechenden Gruppe sowie die Zugehörigkeit des Benutzers zu der Gruppe zu verifizieren. Die Nachweise sind festzuhalten.

Es findet keine Zertifizierung statt, wenn nicht eindeutig auf die Gruppenzugehörigkeit des Benutzers geschlossen werden kann. Gruppenschlüssel dürfen nur von CAs (nicht von RAs) angenommen werden.

Zertifikate für Benutzer haben eine Gültigkeitsdauer von maximal anderthalb Jahren. Eine Nachzertifizierung ist möglich.

7.4 Regeln für die Cross-Zertifizierung zweier CAs

Um die Anbindung an andere Zertifizierungshierarchien zu erlauben, besteht sowohl für CAs als auch für die Root-CA die Möglichkeit der Cross-Zertifizierung mit anderen Zertifizierungsinstanzen. Die Cross-Zertifizierung bietet einen Mechanismus, einen direkten Vertrauenspfad zwischen zwei Instanzen herzustellen, welcher von der strikten Zertifizierungshierarchie abweicht und so eine größere Flexibilität bietet. Dadurch wird auch den Teilnehmern zweier verschiedener Hierarchien die sichere Kommunikation untereinander ermöglicht. Der Vorgang unterscheidet sich dabei für Root-CA und die CAs nicht.

Vor einer Cross-Zertifizierung haben sich die verantwortlichen CA-Administratoren mit den Zertifizierungsrichtlinien der jeweils anderen CA vertraut zu machen. Der Vorgang der Cross-Zertifizierung besagt, daß die Policy der anderen CA bei der Zertifizierung bekannt war und deren aktuelle Richtlinien akzeptiert werden, nicht jedoch, daß diese Richtlinien mit der eigenen Policy übereinstimmen müssen.

Die Cross-Zertifizierung einer CA unterscheidet sich grundsätzlich nicht von der Zertifizierung eines Benutzers gemäß der jeweiligen Policy der Zertifikaterstellers. Die Verfahren können also durchaus verschieden sein. Der Public Key einer CA wird in einem selbst-signierten Zertifikat per E-Mail oder durch den Austausch eines Datenträgers an die andere CA übermittelt. Daran anschließend hat eine gegenseitige Verifikation der Identitäten zu erfolgen, um unerlaubte Zertifizierungswünsche auszuschließen.

Ein Cross-Zertifikat sollte keine längere Gültigkeitsdauer als das reguläre Zertifikat der cross-zertifizierten CA besitzen.

Es sei darauf hingewiesen, daß der Prozeß der Cross-Zertifizierung nicht notwendigerweise die gegenseitige Zertifizierung zweier Instanzen bedeuten muß. Denkbar ist eine Zertifizierung in lediglich eine Richtung beispielsweise dann, wenn eine CA ihren Benutzern die Zertifikate einer kommerziellen CA verfügbar machen möchte, diese CA jedoch aus Policy-Gründen kein Zertifikat für die CA erteilen kann.

8 Management von Zertifikaten

Jede zertifizierende Instanz der CH ist für die Bereitstellung der von ihr ausgestellen Zertifikate zuständig. Die Zertifikate einer CA werden dabei zunächst in einer lokalen Datenbank gespeichert und gepflegt.

Alle Zertifikate der CH sollen veröffentlicht werden. Die Root-CA wird hierfür die von ihr erteilten Zertifikate an einen entsprechenden Server zur Verteilung weiterleiten. Auch alle untergeordneten CAs sind aufgefordert, Zertifikate in diesem Verzeichnis zur Verfügung zu stellen. Nur in solchen Fällen, in denen eine CA keine Möglichkeit hat, Zertifikate im Verzeichnis abzulegen, muß sie sämtliche ausgestellten Zertifikate per E-Mail an die Root-CA senden, welche die entsprechenden Einträge vornehmen wird. Zu diesem Zweck wird von der Root-CA eine E-Mail-Adresse eingerichtet.

Als alternative, zusätzliche Verteilungsformen werden von der Root-CA diverse Informationsdienste eingerichtet, deren Aufgabe die Verteilung von Zertifikaten und CRLs ist. Zu diesen Diensten gehören vorrangig ein E-Mail-basierter Server, FTP- und WWW-Server sowie bei Bedarf die Einrichtung von Mailinglisten oder UNIX-basierten ``finger''-Servern. Diese Dienste können auch von den einzelnen CAs angeboten werden, um ihren Benutzern das Auffinden von Zertifikaten zu erleichtern.

Existieren bereits für das entsprechende Kryptosystem internationale Suchverzeichnisse, so sind diese in Anspruch zu nehmen. Nach Möglichkeit kann auch ein eigener Suchserver eingerichtet werden. Einträge in derartige Verzeichnisse können selbstverständlich auch von den einzelnen Benutzern vorgenommen werden.

Details zu den Informationsdiensten, die die Root-CA zur Verteilung von Zertifikaten und CRLs anbietet, werden in einem separaten Dokument veröffentlicht. Diese Hinweise finden sich außerdem auf dem Informationsserver der Root-CA.

Alle Teilnehmer der CH erklären sich grundsätzlich mit der Veröffentlichung ihres Zertifikates einverstanden. Es besteht jedoch die Möglichkeit, bei der Beantragung eines Zertifikates einer Veröffentlichung zu widersprechen.

9 Widerruf von Zertifikaten

Die Root-CA behält sich vor, von ihr erteilte Zertifikate jederzeit vor Ablauf der Gültigkeitsdauer ohne Angabe expliziter Gründe zu widerrufen. Ursachen für den Widerruf eines Zertifikates können beispielsweise das Bekanntwerden mißbräuchlicher Handlungen eines CA-Administrators oder das Nichtbefolgen auch einzelner Richtlinien dieser Policy sein. Andere Gründe sind beispielsweise das Ausscheiden eines Mitarbeiters aus einer Einrichtung oder die Änderung des Namens.

Jede CA kann von ihr erteilte Zertifikate für CAs oder Benutzer jederzeit vor Ablauf der Gültigkeitsdauer ohne Angabe expliziter Gründe widerrufen.

Jeder Teilnehmer der CH kann von der Instanz, die seinen Schlüssel zertifiziert hat, ohne Angabe von Gründen verlangen, daß diese das entsprechende Zertifikat widerruft. Die betreffende CA hat diesem Verlangen nachzukommen, sobald sie sich durch geeignete Schritte davon überzeugt hat, daß der Antrag vom Zertifikatnehmer selbst stammt bzw. von ihm autorisiert ist.

Zertifikate können nur von der ausstellenden Instanz widerrufen werden. Alle widerrufenen Zertifikate werden von der zuständigen CA auf einer sog. Certificate Revocation List (CRL) veröffentlicht, welche allen Teilnehmern zur Verfügung gestellt werden muß, damit widerrufene Zertifikate nicht aus Unwissenheit weiter benutzt werden. Widerrufene Zertifikate bleiben solange auf der CRL, bis die ursprüngliche Gültigkeitsdauer überschritten wurde.

Einmal widerrufene Zertifikate können nicht erneuert werden. Jedoch hat jeder Teilnehmer der CH die Möglichkeit, ein neues Zertifikat zu beantragen.

Unmittelbar nach der Zertifizierung durch eine übergeordnete Instanz hat jede CA eine CRL herauszugeben. Daran anschließend müssen in höchstens wöchentlichen Abständen CRLs herausgeben werden, auch wenn in der Zwischenzeit keine weiteren Zertifikate durch die CA widerrufen wurden. CRLs sind stets zusammen mit einem Zeitstempel vor Veröffentlichung zu signieren.

Für die Veröffentlichung der CRLs gelten die Absätze zur Veröffentlichung von Zertifikaten in gleicher Weise. Werden Zertifikate veröffentlicht, so sind die CRLs in jedem Fall an gleicher oder benachbarter Stelle zu veröffentlichen. Die Veröffentlichung der CRLs hat Vorrang vor der Zertifikatveröffentlichung.

Jeder zertifizierenden Instanz steht es frei, die CRLs von cross-zertifizierten Instanzen zu veröffentlichen.

10 Regeln für die Namensgebung

Alle Zertifikatnehmer einer Zertifizierungshierarchie werden durch einen eindeutigen Namen identifiziert. Ein solcher Name enthält eine Folge von eindeutig kennzeichnenden Namensattributen, durch die alle Teilnehmer einer Hierarchie referenziert werden können. Die korrekte Wahl von eindeutigen Namen ermöglicht daher die effiziente Speicherung und Suche von Zertifikaten innerhalb eines Verzeichnisses.

Existieren strukturierte Namensinformationen im Protokoll, so sind diese so weit wie möglich zu benutzen. Für den Freiform-Teil (Common Name, ...) gelten die folgenden Regeln ebenso, wie für die Protokolle, die außer einem Freiform-Teil keine weiteren Strukturelemente kennen.

Um die Bindung eines Public Keys an einen Benutzer zu erreichen, gibt es bestimmte Richtlinien für die Wahl der Benutzer-ID, welche bei der Zertifizierung zu beachten sind.

10.1 Wahl eines Namens für CAs

Jede von der Root-CA direkt zertifizierte CA erhält einen Namen der Form: " CA der [Organisation] <[e-mail]> ([SIGN/ENCR] EXPIRE:[yyyy-mm-dd])". Werden andere Adressierungsarten verwendet, so ist der Name mit der Root-CA abzustimmen.

Die angegebene E-Mailadresse der CA muß erreichbar sein und dort auflaufende E-Mail von den Mitarbeitern der CA gelesen werden. Sie ist immer dann einzufügen, wenn die zugehörige Protokolle keine E-Mailadresse kennt. Automatische Mailroboter sind unter dieser Adresse nur zulässig, wenn mindestens ein Verantwortlicher mitliest.

Das Verwendungszweckfeld des Namenseintrages enthält entweder die Zeichenfolge "SIGN" für den Zertifikationsschlüssel oder "ENCR" für den Verschlüsselungsschlüssel. Es ist immer dann einzufügen, wenn die zugehörige Protokolle Verwendungszweckeinträge kennen. Der zugehörige Signier- und Entschlüsselungsschlüssel sind stets unter Verschluß zu halten.

Das letzte Feld gibt das Ende der Gültigkeit des Schlüssels klarschriftlich an. Es ist immer dann einzufügen, wenn die zugehörige Protokolle keine zeitlichen Begrenzungen für Schlüssel oder Zertifikate kennt. Werden diese zeitlichen Begrenzungen an anderer Stelle im Zertifikat vermerkt, kann dieser Eintrag entfallen. Das Datumsformat ist "YYYY-MM-DD" und inklusive dieses Tages.

10.2 Wahl eines Namens für RAs und Benutzer

Da Registrierungsinstanzen innerhalb der Zertifizierungshierarchie den gleichen Status besitzen wie Benutzer, unterscheidet sich auch die Wahl des zugehörigen Namens nicht.

Die Wahl des Benutzernamens wird in erster Linie durch die Richtlinien der CAs bestimmt, es gilt jedoch auch für Benutzer die Regel der Namensunterordnung. Aus dem Namen muß unmittelbar auf dessen zertifizierende Instanz geschlossen werden können.

Der Name eines Benutzers soll folgendem Schema folgen: "Realname <[e-mail]>". Ausführlichere Formen haben die prinzipielle Gestalt: "Realname (Kommentar) <[e-mail]> (Optionen)". Alle Klammern müssen in diesem Fall paarweise auftreten und können geschachtelt sein. Der Eintrag muß mit und ohne Optionen nach RfC 822 (oder Nachfolger) direkt als E-Mailadresse verwendet werden können.

Die angegebene E-Mailadresse sollte die bestmögliche Erreichbarkeit des Nutzers sicherstellen. Die Felder "SIGN/ENCR und "EXPIRE:YYYY-MM-DD" sind optional, aber wenn vorhanden, dann müssen sie direkt nach der E-Mail Adresse folgen und in einfachen runden Klammern stehen.

Die Reihenfolge der Optionsfelder ist egal.

Der Realname geht dem formalen Eintrag voraus. Er darf keine Klammern oder andere Unregelmäßigkeiten enthalten. Über den US-ASCII Zeichensatz hinausgehende Kodierungungen sind nach RFC 1522 (oder Nachfolger) vorzunehmen.

Zumindest der Rufname ist auszuschreiben und wird von weiteren (ausgeschriebenen oder abgekürzten) Vornamen sowie dem ausgeschriebenen Nachnamen gefolgt. Die über den Rufnamen hinausgehenden Vornamen können ganz entfallen, wenn die Identität des Nutzers dadurch nicht verfälscht werden kann.

Im Anschluß an den Realnamen können in runden Klammern Kommentare eingefügt werden.

Beispiele für gültige Benutzernamen sind:

Auf Zertifikate, die andere Namensformate aufweisen, sind die Regeln analog anzuwenden.

Eine CA darf keinesfalls einen Benutzernamen zertifizieren, für den es bereits ein Zertifikat für einen andere Person gibt. Dies vor der Zertifizierung zu prüfen, obliegt der jeweiligen CA.

10.3 Wahl eines Gruppennamens

Die IDs von Gruppenschlüsseln müssen in eindeutiger Weise auf den Namen der Gruppe schließen lassen. Die angegebene E-Mailadresse muß die gesamte Gruppe erreichen (Mailingliste). Der Realname wird durch einen ausführlichen Gruppennamen ersetzt. Ansonsten gelten die Regeln für die Wahl eines Benutzernamen.

11 Verschiedenes

Dieses Dokument basiert auf analogen Dokumenten des oben genannten Individual Network e.V. Projektes.

Es wird keine Haftung für die Korrektheit, Vollständigkeit oder Anwendbarkeit der enthaltenen Informationen und der vorgeschlagenen Maßnahmen übernommen. Ferner kann keine Haftung für eventuelle Schäden, entstanden durch die Inanspruchnahme der Dienste der Root-CA, CA oder daraus resultierender Dienste übernommen werden. Die Verantwortung für die Verwendung der oben beschriebenen Verfahren und Programme liegt allein bei den die Installation durchführenden Administratoren und Benutzern.

Die Root-CA behält sich vor, Zertifizierungswünschen nicht nachzukommen. Ferner kann keine Garantie für die Verfügbarkeit der Root-CA-Dienste übernommen werden. Eine Erreichbarkeit der Root-CA auf den nächsten Arbeitstag wird angestrebt.

Sämtliche Arbeiten der Root-CA, der regionalen CAs und von deren RAs sind zu protokollieren.

11.1 Erklärungen der Teilnehmer

Alle Teilnehmer der CH haben vor ihrer Zertifizierung handschriftlich eine Erklärung zu unterzeichnen, in der sie über ihre Rechte und Pflichten sowie über die Risiken und Gefahren beim Einsatz von Public-Key-Systemen aufgeklärt wurden. Diese Erklärung wird von der zertifizierenden Instanz verwahrt und beinhaltet in erster Linie die Kenntnisnahme von und Zustimmung zu den Richtlinien dieser Policy.

Werden Schlüssel zertifiziert, die aufgrund von staatlichen Beschränkungen unter der hier geforderten Mindestschlüssellänge liegen, so hat ist der Benutzer auf dieses Problem und die damit verbundenen Gefahren hinzuweisen.

11.2 Vereinbarungen zwischen Root-CA und CA

Ein CA-Administrator, welcher eine Zertifizierung durch die Root-CA wünscht, hat eine Vereinbarung mit der Root-CA zu unterzeichnen. Diese Vereinbarung enthält in erster Linie eine Erklärung über die Einhaltung der Richtlinien dieser Policy und kann bei der Root-CA angefordert werden.

11.3 Vereinbarungen zwischen CA und RA

Ein Benutzer, welcher für eine CA als RA fungieren will, hat eine Vereinbarung mit der CA zu unterzeichnen, in welcher die Einhaltung dieser Policy sowie eventuell weiterer, durch die CA festgelegte Richtlinien, erklärt wird. Diese Vereinbarung kann bei der zuständigen CA angefordert werden.

11.4 Gebühren

Jede CA hat das Recht, für bestimmte Leistungen Gebühren zu erheben. Genaueres regeln die Gebührentabellen der entsprechenden CAs.

11.5 Eingesetzte Software

Die eingesetzten Implementationen sind im Rahmen der technischen und organisatorischen Möglichkeiten auf Sicherheitslücken und Funktionsfähigkeit zu überprüfen.

Die Root-CA stellt mindestens eine stets aktuelle Version der einsetzbaren Software zum Abruf bereit. Zu jeder Software legt die Root-CA eine Datei zu den lizenzrechtlichen Bestimmungen bei. Diese sind zu beachten.

Anwendungsabhängige Richtlinien, die bestimmte Eigenheiten bei der Arbeit mit bestimmten Protokollen und Implementationen nutzen, werden in seperaten Dokumenten veröffentlicht.