Kurzfassung dessen, was eigentlich zertifiziert wird.
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.
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:
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.
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.
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.
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.
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.
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.
Ein RA-Zertifikat unterscheidet sich nicht von einem üblichen Benutzer-Zertifikat. Für die Zertifizierung von RAs siehe daher den nächsten Abschnitt.
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.
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.
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.
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.
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.
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.
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:
Rolf Michael Babbel <babel@babilon.babbel.de>
Rolf M. Babbel <babel@babilon.babbel.de> (SIGN)
Rolf M. Babbel <babel@babilon.babbel.de> (EXPIRE:1998-10-13)
Rolf M. Babbel <babel@babilon.babbel.de> (ENCR EXPIRE:1996-10-13)
Rolf Babbel <babel@babilon.org> (EXPIRE:1996-10-13 ENCR)
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.
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.
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.
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.
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.