Version: 2.01 , Stand: 14. Juni 2004
Dieses Dokument ist gültig bis zum 31. Januar 2010 oder bis eine neue
Version dieser Policy veröffentlicht wird.
Diese Policy ist angelehnt an die World Wide Web Policy der
DFN-PCA Version
1.41,
weicht jedoch in einigen wesentlichen Punkten davon ab.
Dieses Dokument löst Version 1.0 ab, und beinhaltet Änderungen in folgenden Punkten: Rechtliche Bedeutung, Minimale Schlüssellänge, Zertifizierungsregeln und Zertifikats-Erweiterungen, sowie bei der Namensgebung.
Fakultät für Informatik der Technischen Universität München
Rechnerbetriebsgruppe
Boltzmannstraße 3
85748 Garching
Deutschland
Telefon: 089-289-18534
Fax: 089-289-18507
E-Mail: ca@in.tum.de
WWW: http://ca.in.tum.de/
Die RBG-Server-CA ist Teil der
RBG-CA2-Hierarchie.
Der Zuständigkeitsbereich der RBG-Server-CA umfasst die Angehörigen der Fakultät für Informatik der Technischen Universität München.
Die RBG-Server-CA erteilt nur X.509v3 SSL/TLS-ServerZertifikate.
Eine Zertifizierung durch die RBG-CA oder untergeordnete CAs
zieht keinerlei rechtliche Bedeutung nach sich.
Ein gesetzlicher Anspruch auf die Erteilung eines Zertifikates besteht
grundsätzlich nicht.
Insbesondere ist die allgemeine rechtliche Relevanz einfacher digitaler
Signaturen derzeit unklar.
Der Sinn der durch die RBG-CA bereitgestellten Public Key
Infrastructure (PKI) liegt in der Schaffung der technischen
Voraussetzungen für eine gesicherte elektronische Kommunikation.
Alle Aufgaben werden von den Mitarbeitern der RBG-CA nach bestem
Wissen und Gewissen durchgeführt, die Abwicklung erfolgt jedoch ohne
Gewährleistung.
Die dieser Policy zugrundeliegenden Anforderungen an technische Komponenten und Verfahren zur Zertifizierung genügen derzeit nur den Kriterien der ,,einfachen digitalen Signatur`` nach § 2 Nr. 1 SigG 2001. Sie sind also weder ,,fortgeschritten`` noch ,,qualifiziert`` oder gar ,,akkreditiert`` nach § 2 Nr. 2 u. 3 SigG 2001 bzw. § 15 Abs. 1 SigG 2001. Die gesetzliche Anscheinsvermutung für eine Beweiserleichterung nach ZPO greift hier also nicht. Vielmehr müssen Gerichte und Gutachter im Streitfall den rechtlichen Wert der eingesetzten Schlüssel, Zertifikate und Signaturen im Einzelfall prüfen.
Folgende Sicherheitsanforderungen werden von der RBG-Server-CA erfüllt:
Der geheime Schlüssel des Endteilnehmers muss ausreichend vor
Missbrauch durch Unbefugte geschützt und darf nicht weitergegeben
werden; hierfür ist jeder Endteilnehmer selbst verantwortlich.
Das Verzeichnis bzw. die Dateien, in denen die kryptographischen
Schlüssel von Anwendungen3gespeichert werden, sind vom Server-Verwalter
nach Maßgabe der Möglichkeiten vor unbefugtem Missbrauch zu schützen.
Dies kann z. B. durch das Setzen bestimmter Zugriffsrechte geschehen,
sofern das eingesetzte Betriebssystem dies unterstützt. Die Speicherung
der kryptographischen Schlüssel auf externen Datenträgern
(z. B. Diskette) wird dringend empfohlen.
Wird keine externe Peripherie (z. B. Diskette) zum Speichern des
geheimen Schlüssels eingesetzt, sollte der Zugriff auf den geheimen
Schlüssel des Endteilnehmers durch das Setzen eines nicht-trivialen
Passworts (Mindestlänge: 8 Zeichen) bzw. einer PIN geschützt
werden.
Weder die optionale Peripherie noch Passwort bzw. PIN dürfen an andere
Personen weitergegeben werden. Passwort bzw. PIN dürfen niemals im
Klartext abgelegt bzw. über ungeschützte Netzwerkverbindungen gesendet
werden.
Das asymmetrische Schlüsselpaar des Endteilnehmers muss eine minimale Länge von 2048 Bit RSA (oder vergleichbares Niveau) aufweisen. Die Wahl größerer Schlüssellängen wird dringend empfohlen und richtet sich nach der technischen Verfügbarkeit. In besonderen Ausnahmefällen können Schlüssel bis zu einer minimalen Schlüssellänge von 1024 Bit RSA (oder vergleichbares Niveau) verwendet werden.
Die RBG-Server-CA generiert für registrierte SSL-Server ein
asymmetrisches Schlüsselpaar und erstellt die
entsprechenden Zertifikate.
Das Schlüsselpaar sowie das Zertifikat werden in einem geeigneten
Austauschformat (PKCS12) verschlüsselt gespeichert.
Der Server-Verantwortliche muss persönlich im Servicebüro RBG erscheinen, um
sein Passwort für die PKCS12-Datei entgegenzunehmen, wobei die
Vorlage eines Personalausweises/Reisepasses oder eines vergleichbaren
Dokuments erforderlich ist.
Zusätzlich sollte der Studentenausweis bzw. der Mitarbeiterausweis
vorgelegt werden.
Falls der Endteilnehmer aus technischen Gründen sein persönliches asymmetrisches Schlüsselpaar selber erzeugen muss, so muss der entsprechende Zertifizierungsantrag diesen Richtlinien in allen Punkten genügen, vor allen was die Namensgebung und die Schlüssellänge betrifft, sonst wird er von der CA nicht angenommen.
Der Endteilnehmer schickt seinen Zertifizierungswunsch
über den vorgegebenen Übertragungsweg zur CA.
Zertifikate für Endteilnehmer haben eine Gültigkeitsdauer von maximal
einem Jahr. Stichtag ist jeweils der 31. Mai.
Jedes Zertifikat muß eine Seriennummer beinhalten, die von der
zertifizierenden CA vergeben wird. Dabei hat jede CA bei der
Zertifizierung zu gewährleisten, daß von ihr keine Seriennummer
mehrfach vergeben wird.
Zertifikate werden in der Regel nicht automatisch durch die ausstellende CA erneuert; Anträge auf Rezertifizierung sind gegebenenfalls bei der entsprechenden CA zu stellen.
Folgende Zertifikats-Erweiterungen werden von der RBG-Server-CA unterstützt:
Alle Teilnehmer der RBG-CA-Hierarchie haben 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 werden. Diese Erklärung, die im Einzelfall auch vom Teilnehmer an die zertifizierende CA gefaxt, bzw. per Mail mit einer durch die RBG-Server-CA zertifizierten Signatur geschickt werden kann, wird von der zertifizierenden Instanz verwahrt und beinhaltet in erster Linie die Zustimmung zu den Richtlinien dieser Policy, sowie gegebenenfalls eine Erklärung darüber, von welcher Instanz das zu zertifizierende asymmetrische Schlüsselpaar erzeugt wurde.
Alle Teilnehmer erklären sich grundsätzlich mit der Veröffentlichung
ihres Zertifikates einverstanden.
Der Teilnehmer kann die Veröffentlichung auf den Bereich der Fakultät
beschränken, andernfalls gilt sie weltweit.
Für die Überprüfung der Zertifikate hat die RBG-CA ein Verzeichnis eingerichtet, dessen Aufgabe die Überprüfung und Verteilung von Zertifikaten und CRLs ist.
Die RBG-Server-CA kann erteilte Zertifikate jederzeit vor Ablauf der
Gültigkeitsdauer ohne Angabe von Gründen widerrufen.
Jeder Zertifikatnehmer kann von der Instanz, die seinen Public Key
zertifiziert hat, ohne Angabe von Gründen verlangen, dass diese ein
für ihn ausgestelltes Zertifikat widerruft.
Alle widerrufenen Zertifikate werden auf einer Widerrufsliste
veröffentlicht, welche allen Teilnehmern zur Verfügung gestellt wird.
Einmal widerrufene Zertifikate können nicht erneuert oder verlängert
werden. Jedoch hat jeder Teilnehmer die Möglichkeit, ein neues
Zertifikat zu beantragen.
Unmittelbar nach der Aufnahme des Betriebs hat jede CA eine
Certification Revocation List (CRL) herauszugeben. Diese CRL
wird mindestens im monatlichen Abstand erneuert.
Für die Bereitstellung von CRLs hat die RBG-Server-CA ein Verzeichnis eingerichtet.
Allen Zertifikatsnehmern wird ein eindeutiger Name (Distinguished Name,
DN) zugeordnet, welcher bei der Ausstellung eines Zertifikates für
einen Teilnehmer als dessen X.509-Subjektname verwendet wird.
Ein DN enthält eine Folge von eindeutig kennzeichnenden
Namensattributen, durch die alle Teilnehmer einer Hierarchie
referenziert werden können.
Aus Gründen der Interoperabilität wird auf unübliche Sonderzeichen
(z. B. Umlaute) innerhalb des DNs verzichtet.
Für Teilnehmer der RBG-Server-CA wird ein DN mit folgendem
Aufbau erzeugt:
| C | DE |
| L | Muenchen |
| O | TUM |
| OU | IN |
| CN | <hostname bzw servicename> |
| <Verwalter >@in.tum.de |