15.02.2013 Aufrufe

Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

Teil I Aufbau und Betrieb einer Zertifizierungsinstanz - DFN-CERT

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

50 Kapitel 4. Konzept für eine Zertifizierungsstelle (“plan”)<br />

Jahr empfohlene Schlüssellänge<br />

1995 1280 bit<br />

2000 1280 bit<br />

2005 1536 bit<br />

2010 1536 bit<br />

2015 2048 bit<br />

Wenn man sich auch vor Geheimdiensten schützen will, sollten die Schlüssellängen nach SCHNEIER<br />

noch einmal um einiges größer (“substantially bigger”) gewählt werden.<br />

Angesichts dieser Angaben sollte die UNI-CA selber RSA-Schlüssel mit mindestens 1536 bit Länge<br />

verwenden <strong>und</strong> die Schlüssellänge gegebenenfalls in den nächsten Jahren beim Schlüsselwechsel<br />

erhöhen.<br />

Hier muß die weitere Entwicklung besonders aufmerksam verfolgt werden, um gegebenenfalls<br />

rechtzeitig die Policies <strong>und</strong> die Länge der eigenen Schlüssel an sich ändernde Anforderungen oder<br />

bei Bekanntwerden neuer Angriffsmöglichkeiten anpassen zu können. Es empfiehlt sich, z.B. die<br />

diesbezüglichen Vorgaben der RegTP bzw. des BSI für SigG-CAs zu beachten. LENSTRA <strong>und</strong><br />

VERHEULs Papier “Selecting Cryptographic Key Sizes” 8 kann dabei als Entscheidungshilfe mit<br />

einbezogen werden.<br />

Im Sinne der Interoperabilität verschiedener PGP-Versionen bzw. -Schlüssel kann es sinnvoll<br />

sein, auch eine Obergrenze für die Schlüssellänge vorzugeben. Es sind Probleme einzelner PGP-<br />

Implementierungen bzw. auf einzelnen <strong>Betrieb</strong>ssystem-Plattformen mit Schlüsseln größer als 2048<br />

bit bekannt. Daher wird für die UNI-CA-Policies vorgeschlagen, im Interesse der Interoperabilität<br />

bis auf weiteres neben der Mindest- auch eine Maximallänge für alle Schlüssel von 2048 bit<br />

vorzuschreiben.<br />

4.8.4 Zulässige Benutzerkennungen<br />

Bei der Low-Level-Zertifizierung ist eine Beschränkung der zulässigen Benutzerkennungen nicht<br />

sinnvoll möglich, da ja auch Universitätsfremde die Gelegenheit zur Zertifizierung wahrnehmen<br />

können <strong>und</strong> sollen. Deren Mailadressen ließen sich ja vom unvernetzten Zertifizierungsrechner aus<br />

gar nicht <strong>und</strong> auch sonst nicht unverzüglich prüfen – andernfalls wäre eine sofortige Zertifizierung<br />

nicht möglich (<strong>und</strong> damit die Gr<strong>und</strong>idee der Low-Level CA hinfällig). In diesem Fall kann daher<br />

bei der Benutzerkennung lediglich darauf geachtet werden, daß sie den Vornamen <strong>und</strong> Namen des<br />

Schlüsselinhabers enthält.<br />

Bei der Zertifizierung nach der Medium-Level-Policy sind die Abgabe des Antrags nebst Identitätsprüfung<br />

zeitlich von der eigentlichen Zertifizierung entkoppelt. Aufgr<strong>und</strong> der Prüfung der Mailadresse<br />

kommt es ja in jedem Fall zu <strong>einer</strong> gewissen Verzögerung. Da die Medium-Level UNI-CA<br />

nur UNI-Angehörige zertifizieren soll, ist eine Beschränkung auf solche Benutzerkennungen, die<br />

eine UNI-Mailadresse enthalten, sinnvoll <strong>und</strong> praktikabel.<br />

Abweichungen von der genauen Schreibweise von Vorname(n) <strong>und</strong> Zuname im vorgelegten Personaldokument<br />

sind nur bei Sonderzeichen (Umlauten, Accents) erlaubt; die deutschen Umlaute <strong>und</strong><br />

8 http://www.cryptosavvy.com/cryptosizes.pdf

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!