Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

5.5. Stolpersteine 123
Es können PGP-Keys mit einem Erstellungsdatum in der Zukunft auftreten:
pub 2048/FEECC7A5 2018/06/14 Michael [...]
Es können Tippfehler in den UserIDs vorliegen:
Type Bits/KeyID Date User ID
pub 1024/0XXXXXXX 2000/02/xx xxxxxxxxxxxxxx
=
Wie verfährt man bei ungewöhnlichen Darstellungen von Sonderzeichen im Namen in der
UserID, z.B. bei Umlauten, die als 8bit-ISO-Latin1-Zeichen in der UserID vorkommen und
auf Rechner mit anderer Zeichensatz-Codierung als Sonderzeichen dargestellt werden?
Sind Schlüssel zertifizierbar, bei denen der Name des Inhabers einen Umlaut enthält, dieser in
der UserID aber mit dem nicht-umgelauteten Vokal geschrieben ist (also z.B. Name ‘Müller’,
UserID ‘... Muller ...’ )?
Sollen Schlüssel zertifiziert werden, die den Namen in der UserID nicht in der Standardform
‘Vorname Nachname E-Mailadresse’ enthalten, sondern nur als Bestandteil der Mailadresse,
etwa hans.mustermann@UNI.de ?
Probleme bei der X.509-Zertifizierung bereitet vor allem die eindeutige Zuordnung zwischen Zertifizierungsantrag
und einem Zertifizierungs-Request (Certificate Signing Request, CSR), wenn dieser
nur per E-Mail übermittelt wird. Viele Programme, die X.509-Zertifikate verarbeiten, bieten
keinerlei Möglichkeit, sich den erzeugten CSR oder eine kryptographische Prüfsumme (Hash-Wert,
Message Digest) davon anzeigen zu lassen, so daß – anders als bei PGP – auch kein „Fingerprint“
o.ä. im Zertifizierungsantrag angegeben werden kann. Es fehlt dann an der Verknüpfung zwischen
schriftlichem Zertifizierungsantrag und dem elektronischen CSR, was z.B. Verwechslungen begünstigt.
(Möglicher workaround: siehe Anhang H.1.1)