Digitale Zertifikate - Kryptografie - page 537

■ Subject Unique ID : Diese eindeutige Kennung des Zertifikatsinhabers ermög-

licht eine Unterscheidung, wenn mehrere Zertifikatsinhaber denselben Namen
haben.

Die meisten X.509-Implementierungen verwenden die beiden X.509v2-Felder
nicht. Auch in den X.509-Profilen von PKIX und Common PKI wird empfohlen,
diese Felder einfach leer zu lassen. Stattdessen sollte eine CA dafür sorgen, dass
Namensgleichheiten nicht vorkommen. X.509v2 erwies sich somit als überflüs-
sige Erweiterung des X.509-Standards.

27.1.2 Nachteile von X.509v1 und v2

Im Laufe der Jahre zeigte sich, dass X.509v1-Zertifikate einige Nachteile haben,
die durch die zweite X.509-Version nicht behoben wurden:

■ X.509v1 sieht als Inhaber- und CA-Namen jeweils X.500-Namen vor, die

einem bestimmten Format entsprechen müssen. Da X.509-Zertifikate meist
unabhängig von X.500 eingesetzt werden, ist diese Einschränkung aus heuti-
ger Sicht unsinnig. X.509v1 erlaubt es beispielsweise nicht, als Name ledig-
lich eine E-Mail-Adresse zu verwenden, obwohl dies oftmals sinnvoll wäre.

■ X.509v1-Zertifikate lassen keine Rückschlüsse auf den Verwendungszweck

des zertifizierten öffentlichen Schlüssels zu. Es gibt kein Feld, das eine ent-
sprechende Aussage machen könnte. Es ist jedoch sinnvoll, beispielsweise
zwischen Schlüsseln zum Verschlüsseln und zur Verifikation von Signaturen
zu unterscheiden.

■ X.509v1-Zertifikate machen keine Aussage über die Policy, die ihnen zugrunde

liegt. Alices Zertifikat ist daher zum Beispiel nicht anzusehen, ob Alice es
ohne nennenswerte Authentifizierung per E-Mail bei der CA bestellt oder
nach Vorlage ihres Ausweises persönlich abgeholt hat.

Um diese Mängel zu beheben, entwickelten einige Unternehmen den Standard
PKCS#6 , der das X.509-Format erweitert [PKCS#6]. PKCS#6 erwies sich jedoch
schnell als überflüssig, da mit der dritten X.509-Version eine leistungsfähigere
Alternative entstand.

27.2 X.509v3-Zertifikate

1996 erschien die dritte Version des X.509-Standards. X.509v3 sah zunächst
keine neuen Felder für X.509-Zertifikate vor, sondern spezifizierte eine Syntax,
mit der neue Felder ( Erweiterungen ) definiert werden können. Jede Erweiterung
enthält dabei ein Teilfeld, das angibt, ob die Erweiterung kritisch oder unkritisch
ist. Wenn eine Software eine kritische X.509v3-Erweiterung entdeckt, die sie
nicht kennt, dann wird das Zertifikat als ungültig betrachtet. Eine der Software
nicht bekannte unkritische Erweiterung wird dagegen übergangen.