Cryptography Reference
In-Depth Information
■
requireExplicitPolicy
=
0: Für
CA
1
,
CA
2
,
CA
3
und
CA
4
ist keine Policy-Kennung gefordert.
■
requireExplicitPolicy
=
1: Für
CA
2
,
CA
3
und
CA
4
ist keine Policy-Kennung gefordert.
■
requireExplicitPolicy
=
2: Für
CA
3
und
CA
4
ist keine Policy-Kennung gefordert.
■
3: Für
CA
4
ist keine Policy-Kennung gefordert.
Es gibt noch ein weiteres X.509v3-Zertifikatsfeld, das an dieser Stelle von Belang
ist:
Inhibit Any-Policy
. Dieses bezieht sich auf die
Any-Policy
, eine leere Certifi-
cate Policy, die eine eigene OID hat. Steht in einem Policy-Constraints-Feld, dass
eine Policy gleichwertig mit der Any-Policy ist, dann bedeutet dies, dass jede Cer-
tificate Policy als gleichwertig akzeptiert wird. Der Zweck des Felds
Inhibit Any-
Policy
ist es, die Verwendung der Any-Policy zu unterbinden. In unserem Beispiel
hat dies folgende Konsequenzen:
requireExplicitPolicy
=
■
inhibitAny-Policy
= 0: Any-Policy nicht anerkannt.
■
inhibitAny-Policy
= 1: Any-Policy wird nur in
CA
1
anerkannt.
■
inhibitAny-Policy
= 2: Any-Policy wird in
CA
1
und
CA
2
anerkannt.
■
inhibitAny-Policy
= 3: Any-Policy wird in CA
1
, CA
2
und CA
3
anerkannt.
29.4.3
Policy-Hierarchien in der Praxis
Möglicherweise werden Sie angesichts dieser komplexen Mapping-Arithmetik
vermuten, dass Policy-Hierarchien kaum mehr als eine Spielerei sind. In der Tat
spielt dieses Thema in der Praxis bisher keine große Rolle. Policy-Hierarchien
fehlt einfach die Pragmatik, die für eine erfolgreiche Karriere im PKI-Sektor
erforderlich ist. Da jedoch derzeit ein zaghaftes Zusammenwachsen von bisher
isolierten PKIs zu verzeichnen ist und der Umgang mit Policys dadurch an Bedeu-
tung gewinnt, könnte das Policy Mapping in den nächsten Jahren ebenfalls popu-
lärer werden.
