15.02.2013 Aufrufe

Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

110 Kapitel 5. Praktische Umsetzung des CA-Konzeptes<br />

um sie ihnen aushändigen zu können. Diese Informationen bilden die Gr<strong>und</strong>lage für die spätere<br />

Nutzung der von der CA ausgestellten Zertifikate. Ihre Authentizität ist daher von höchster Wichtigkeit;<br />

es muß unter allen Umständen vermieden werden, daß hier ein Angreifer seinen Schlüssel<br />

oder seine Schlüsselinformationen gegen die der UNI-CA austauscht!<br />

Die Zettel oder Datenträger mit den Schlüsseln oder Schlüsselinformationen müssen daher vor unbefugtem<br />

Zugriff sicher verwahrt werden. Andererseits müssen sie zugänglich sein, wenn ein Zertifizierungswilliger<br />

erscheint <strong>und</strong> einen Zertifizierungsantrag stellt, damit sie ihm dann ausgehändigt<br />

werden können.<br />

5.2.12 Interne Probeläufe<br />

Zur Einübung, zur Optimierung der Abläufe <strong>und</strong> damit eventuelle Fehler noch keine dramatischen<br />

Folgen für das Ansehen der CA haben, sollten die Arbeitsabläufe bei allen Phasen der Zertifizierung<br />

<strong>und</strong> der sonstigen CA-Arbeit realitätsnah durchgespielt werden.<br />

Hierzu könnten die Schlüssel der RZ-Mitarbeiter bzw. die Schlüssel einiger PGP-Interessierter probezertifiziert<br />

werden, mit einem ausdrücklich als „Test-Key“ gekennzeichneten CA-Schlüssel (oder<br />

einem Schlüssel mit einem Decknamen) <strong>und</strong> <strong>einer</strong> kurzen Gültigkeitsdauer. Die Gültigkeitsdauer<br />

sollte so bemessen sein, daß auch Aspekte wie ein Schlüsselwechsel der CA im Rahmen dieser<br />

Tests simuliert werden können.<br />

Erprobt werden muß auch die Vorgehensweise bei der Sperrung eines Zertifikates, damit hier später<br />

im Ernstfall keine Fehler unterlaufen. Ebenfalls sollte auch die Re-Zertifizierung von Keys durchexerziert<br />

werden.<br />

Eventuell in dieser Phase zutage getretene Schwächen oder Fehler in der Policy können zu dieser<br />

Zeit noch relativ leicht durch Korrektur derselben behoben werden.<br />

5.2.13 Policy-Verabschiedung <strong>und</strong> -Bekanntgabe<br />

Es ist eine eindeutige Regelung zu treffen, wer die UNI-CA-Policy letztlich abzusegnen hat oder zu<br />

Änderungen befugt ist. Diese Regelung sollte, eventuell auch als Information in der Policy selbst,<br />

bekanntgemacht werden.<br />

Die Policy sollte vor ihrer Verabschiedung unbedingt auch mit der <strong>DFN</strong>-PCA abgestimmt sein,<br />

damit es nicht im Nachhinein zu Problemen mit der Einbindung der UNI-CA in die <strong>DFN</strong>-<br />

Zertifizierungshierarchie kommt! Auch bei Änderungen bzw. vor der Verabschiedung <strong>einer</strong> geänderten<br />

Fassung der Policy sollte vorsorglich immer die <strong>DFN</strong>-PCA beteiligt werden.<br />

Zu Beginn der Zertifizierungstätigkeit der UNI-CA könnte die Policy erst einmal als „vorläufig“<br />

<strong>und</strong> in der Erprobung deklariert <strong>und</strong> relativ kurz befristet werden. Wenn sich dann nach den ersten<br />

Wochen oder Monaten der Arbeit nach dieser Policy gezeigt hat, ob sie noch Schwachpunkte enthält,<br />

die korrigiert werden müßten, oder ob sie so als endgültige Policy verwendet werden kann,<br />

dann kann die endgültige Fassung in Kraft gesetzt werden.

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!