Spezielle Fragen beim Betrieb einer PKI - Kryptografie - page 586

■ Ich empfehle, trotz aller Mängel die in RFC 3647 vorgegebene Struktur bei-

zubehalten. Dadurch werden CPS/CP-Dokumente untereinander vergleich-
bar. Dabei muss man jedoch in Kauf nehmen, dass ein CPS bzw. CP zahlrei-
che leere Unterkapitel enthält.

Auf die beschriebene Weise sollte es möglich sein, brauchbare CPS/CP-Doku-
mente zu schreiben, die RFC 3647 entsprechen.

29.4 Policy-Hierarchien

Das Hantieren mit Certificate Policys kann schnell kompliziert werden, wenn wir
es mit einer CA-Hierarchie zu tun haben. Nehmen wir beispielsweise an, CA 1
stelle ein Zertifikat für CA 2 aus. Wenn sich CA 1 an eine bestimmte Certificate
Policy hält, CA 2 aber nicht, dann steht CA 1 am Ende für Zertifikate gerade, die
nicht nach ihren Richtlinien generiert worden sind. Damit dies nicht passiert,
muss CA 1 CA 2 dazu verpflichten, die eigene Certificate Policy zu beachten oder
zumindest eine gleichwertige Certificate Policy einzuhalten. In einer CA-Hierar-
chie gibt es daher zwangsläufig auch eine Policy-Hierarchie , zu der sich die Betei-
ligten ihre Gedanken machen müssen.

29.4.1 Hierarchietiefe

Um Certificate Policys über die Ebenen einer CA-Hierarchie hinweg durchsetzen
zu können, stellt der X.509v3-Standard eine Reihe von Zertifikatsfeldern zur
Verfügung. Es handelt sich dabei um mehrere X.509v3-Standarderweiterungen
sowie um eine PKIX-spezifische X.509v3-Erweiterung. Alle relevanten Felder
wurden bereits in Abschnitt 27.2.1 erwähnt. Zunächst ist das Zertifikatsfeld
Certificate Policies von Bedeutung. Dieses kann beispielsweise in Alices Zertifikat
stehen und dort die Kennung der Certificate Policy aufnehmen, die für das Zerti-
fikat gültig ist (es können auch mehrere Policy-Kennungen in einem Zertifikat
enthalten sein). Allerdings sagt dieses Feld nichts darüber aus, ob und wie eine
Certificate Policy in einer CA-Hierarchie vererbt werden kann.
Ein weiteres wichtiges Zertifikatsfeld ist Basic Constraints . Dieses kommt
nur in CA-Zertifikaten zum Einsatz. Darin wird festgelegt, wie viele Hierarchie-
ebenen unterhalb der jeweiligen CA vorkommen dürfen. Wenn CA 1 ein Zertifikat
für CA 2 ausstellt und dieses Feld dabei auf 0 setzt, dann darf CA 2 nur Endanwen-
der-Zertifikate, aber keine CA-Zertifikate ausstellen. Tut CA 2 dies doch (z.B. für
CA 3 ), dann sollte Bobs X.509v3-konforme Anwendung diese Policy-Verletzung
erkennen und alle von CA 3 ausgestellten Zertifikate als ungültig ablehnen. Setzt
CA 1 den Basic-Constraints-Wert dagegen auf 1, dann darf CA 2 zwar CA-Zertifi-
kate (z.B. für CA 3 ) ausstellen, CA 3 darf dies jedoch nicht tun. Mit anderen Wor-
ten: Mit dem Feld Basic Constraints kann CA 1 verhindern, dass die CA-Hierar-
chie unter ihr beliebig viele Ebenen enthält.