Cryptography Reference
In-Depth Information
■
Meines Erachtens ist es sinnvoll, die Beschreibung eines IT-Systems (ein
CPS/CP ist eine solche) in drei Teile zu gliedern: Komponenten, Rollen und
Prozesse. Oft bietet es sich an, als weiteren Bestandteil eine Einführung oder
ein Kapitel über vertragliche Details vorzusehen. RFC 3647 folgt diesem
bewährten Vorgehen jedoch nicht, sondern beschreibt eine neunteilige Kapi-
telstruktur, die unnötig kompliziert wirkt.
■
Die Inhalte eines CPS/CP gemäß RFC 3647 sind sehr ungleichmäßig auf die
neun Kapitel verteilt. Kapitel 2 (
Veröffentlichung und Aufbewahrung
) und
Kapitel 8 (
Evaluierung und Überprüfung
) haben keine Unterkapitel und fal-
len daher meist recht kurz aus. Kapitel 9 (
Sonstige gesetzliche und geschäftli-
che Aspekte
) ist in den meisten mir bekannten CPS/CP-Dokumenten sogar
leer, während Kapitel 5 (
Bauliche und organisatorische Bestimmungen
) und
Kapitel 6 (
Technische Sicherheitsbestimmungen
) wenig Inhalt haben. Der
eigentliche CPS/CP-Inhalt konzentriert sich auf die verbleibenden Kapitel 1, 3
und 7, die dadurch vergleichsweise umfangreich werden.
■
Die RFC-3647-Kapitelstruktur sieht kein dediziertes Kapitel zum Thema Pro-
zesse vor. Stattdessen muss der CPS/CP-Autor Prozessbeschreibungen über
die Kapitel 4, 5 und 6 verstreuen, was wahrlich nicht übersichtlich ist.
■
Der wichtigste Prozess in einer PKI ist das Anwender-Enrollment. Die Bedeu-
tung dieses Vorgangs sollte sich auch in einem CPS oder CP widerspiegeln. RFC
3647 kennt leider kein Enrollment als kompletten Prozess. Stattdessen wird der
entsprechende Vorgang in vier Teile zerlegt (
Zertifizierungsanträge
,
Verarbei-
tung der Zertifizierungsanträge
,
Ausstellen der Zertifikate
,
Entgegennahme von
Zertifikaten
). Diese Vierteilung erscheint unnötig und unübersichtlich.
■
RFC 3647 fordert eine Trennung zwischen CPS und CP. In der Praxis
wünscht ein PKI-Betreiber jedoch meist, alle Informationen in einem Doku-
ment zu haben. Aus Sicht eines Beraters ist es ohnehin schwierig, einen Kun-
den von der Notwendigkeit mehrerer Policy-Dokumente zu überzeugen. Bes-
ser ist es in den meisten Fällen, ein CPS und mehrere CPs in ein Dokument zu
packen. Dabei ist es natürlich trotzdem möglich, verschiedene Zertifikats-
typen zu unterscheiden und dazu jeweils eigene Policy-Inhalte zu definieren.
Die genannten Probleme machen es zu einem schwierigen Unterfangen, ein gutes
CPS/CP-Dokument zu schreiben, das RFC-3647-konform ist. Viele CPS/CP-
Autoren halten sich daher erst gar nicht an die RFC-3647-Struktur.
Unverständliche Mängel
Neben der ungünstigen Struktur weist RFC 3647 weitere Mängel auf. Hier die
wichtigsten:
■
Die Begriffe »CPS« und »CP« sind unvorteilhaft gewählt. Die beiden Abkür-
zungen sehen sich recht ähnlich, zumal der Plural von »CP« »CPs« lautet,
was wiederum leicht mit »CPS« zu verwechseln ist. Es wäre sicherlich besser
