Cryptography Reference
In-Depth Information
Probleme für nichtenglischsprachige Autoren
Es liegt in der Natur der Sache, dass RFC 3647 für nichtenglischsprachige Auto-
ren einige Probleme aufwirft. Insbesondere gibt es bisher keine einheitliche Über-
setzung der RFC-3647-Bestimmungen ins Deutsche. Vielleicht setzen sich ja die
in Abschnitt 29.3.1 aufgeführten Übersetzungsvorschläge durch. Auch für die
Fachbegriffe in RFC 3647 gibt es keine offizielle Übersetzung. Es ist daher unter
anderem unklar, ob man »CA« mit »Zertifizierungsstelle« oder »Zertifizierungs-
instanz« oder anders übersetzen soll. Natürlich wäre es nicht sinnvoll, in einem
Dokument wie RFC 3647 Übersetzungsfragen zu berücksichtigen. Stattdessen
sind an dieser Stelle nationale Organisationen (in Deutschland etwa Teletrust
oder das BSI) gefordert. Diese könnten für eine Anpassung von RFC 3647 auf die
jeweiligen nationalen Gegebenheiten sorgen. Ein solche Anpassung könnte auch
nationale Besonderheiten wie das deutsche Signaturgesetz berücksichtigen - es
versteht sich von selbst, dass ein international gültiger Standard auf so etwas
nicht eingehen kann.
Fazit und Lösungsvorschläge
Kein Zweifel, RFC 3647 ist alles andere als ein Glanzlicht unter den PKIX-RFCs.
Und das, obwohl RFC 3647 im Gegensatz zu anderen PKIX-Bestandteilen nicht
durch Altlasten aus der PKI-Steinzeit betroffen ist. Was zu tun ist, um dieses Pro-
blem anzugehen, habe ich teilweise schon angesprochen. So sollte die nächste
RFC-Version einige zusätzliche Inhalte (z.B. Smartcards, Literaturverzeichnis)
enthalten. Auch eine andere Gliederung wäre von Vorteil. Zudem sollten natio-
nale Organisationen eine Anpassung und Übersetzung von RFC 3647 vorneh-
men. Unabhängig davon wäre es sinnvoll, statt eines RFC eine flexiblere Form
der Veröffentlichung zu wählen. Es sollte möglich sein, den Inhalt eines solchen
CPS-CP-Standards regelmäßig zu aktualisieren, was bei einem RFC nicht vorge-
sehen ist.
Interessant wäre es außerdem, einen alternativen CPS/CP-Standard ins Leben
zu rufen. Diesen könnte man
Simple CA Policy
(
SCAP
) nennen. Ein SCAP-Doku-
ment würde ein CPS und mehrere CPs durch ein Dokument ersetzen. Die Gliede-
rung eines SCAP-Dokuments sollte übersichtlicher und einfacher gestaltet wer-
den, als dies in RFC 3647 der Fall ist. Auch bei SCAP sollte es sich nicht um einen
RFC handeln, sondern um ein Rahmenwerk, dessen Inhalt laufend angepasst
werden kann. Da CPS/CP-Autoren jedoch weder auf die nächste RFC-Version
noch auf SCAP warten können, empfehle ich für das Schreiben eines CPS/CP-
Dokuments Folgendes:
■
In vielen Fällen reicht ein Dokument aus. Dieses sollte sowohl das CPS als
auch die relevanten CPs enthalten.
■
Die gesamte PKI-Architektur sollte in einem Betriebskonzept beschrieben
werden, das vom CPS/CP-Dokument unabhängig ist.
