Cryptography Reference
In-Depth Information
28.1.5
Zertifizierungsanträge
In einigen Enrollment-Varianten spielen
Zertifizierungsanträge
eine Rolle. Ein
Zertifizierungsantrag ist ein Datensatz, der Alices Namen, ihren öffentlichen
Schlüssel sowie gegebenenfalls weitere Angaben enthält und in der Regel digital
signiert ist. Für Zertifizierungsanträge gibt es zwei gängige Standards: PKCS#10
und CRMF. Letzterer ist der deutlich jüngere Standard. Beide sind ausschließlich
für X.509-Zertifikate gedacht und lassen offen, wer den Antrag entgegennimmt
(CA oder RA). PKCS#10 und CRMF sind nicht miteinander kompatibel.
PKCS#10
PKCS#10
ist ein weiterer Standard aus der PKCS-Reihe [PKCS#10]. Er spezifiziert
ein Format für Zertifizierungsanträge. Im Vergleich zu einigen anderen PKCS-
Standards ist PKCS#10 recht simpel aufgebaut. Ein PKCS#10-Datensatz enthält
den Namen des Antragsstellers (in diesem Fall Alice), die gewünschte X.509-Ver-
sionsnummer sowie den öffentlichen Schlüssel. Weitere mögliche Inhalte (Attri-
bute) eines PKCS#10-Antrags sind Angaben über gewünschte X.509v3-Erweite-
rungsfelder und ein Sperrpasswort. Diese Attribute werden jedoch nicht im
PKCS#10-Standard selbst, sondern in PKCS#9 beschrieben (PKCS#9 spezifiziert
zudem Attribute für verschiedene andere Standards der PKCS-Familie).
Ein PKCS#10-Antrag muss von Alice selbst signiert sein (mit demjenigen pri-
vaten Schlüssel, dessen öffentliches Gegenstück im Antrag enthalten ist). Durch
eine Verifizierung der Signatur kann die RA bzw. CA zum einen die Korrektheit
des Zertifizierungsantrags überprüfen und zum anderen sicherstellen, dass Alice
auch tatsächlich den zum Antrag passenden privaten Schlüssel besitzt (
Proof of
Possession
). PKCS#10 ist nicht dazu vorgesehen, dass ein Registrator einen von
Alice gestellten Zertifikatsantrag signiert, obwohl dies eine durchaus sinnvolle
Einsatzmöglichkeit wäre.
Bei einem PKCS#10-Antrag ist eines zu beachten: Falls das von Alice gene-
rierte Schlüsselpaar ein RSA-Schlüsselpaar ist, bereitet das Erstellen einer Signa-
tur keine Probleme, da sich RSA für digitale Signaturen nutzen lässt. Handelt es
sich dagegen um ein Diffie-Hellman-Schlüsselpaar, dann ist die Sache nicht ganz
so einfach, da Diffie-Hellman kein Signaturverfahren ist. Diesem Problem wid-
met sich der PKIX-Standard RFC 2875, der die zwei folgenden Proof-of-Posses-
sion-Verfahren (PoP) für Diffie-Hellman-Schlüssel spezifiziert [RFC2875]:
■
Statischer PoP
: Bei dieser Variante kommt keine digitale Signatur zum Ein-
satz, sondern lediglich eine kryptografische Hashfunktion (SHA-1). Der Stan-
dard sieht vor, dass Alice und die CA bzw. RA einen Diffie-Hellman-Schlüs-
selaustausch durchführen. Aus dem resultierenden gemeinsamen geheimen
Schlüssel sowie aus dem Zertifizierungsantrag generiert Alice einen Hash-
wert, den sie anstelle der digitalen Signatur in den Antrag einfügt. Die CA
bzw. RA berechnet nach Erhalt des Antrags auf dieselbe Weise wie Alice einen
