FAQ: Die Policy der Individual Network Zertifikationshierarchie

Letzte Änderung: 15.09.1996
Diese FAQ wird von Lutz Donnerhacke gepflegt. Kommentare sind willkommen.

Motivation

Sinn dieser FAQ ist es, die vielen Fragen und Unklarheiten im Zusammenhang mit Zertifikaten und Zertifikationsinstanzen ansatzweise zu klären.

Nichts ist zeitraubender, als die notwendigen Fragen von Neulingen auf diesem Gebiet zu beantworten. Es macht viel Freude, diese Antworten zu geben, jedoch beschränkt der tägliche Zeitrahmen diese stets auf ein unzureichendes Minimum.

Im Interesse derjenigen, die nach Antworten suchen, wird hier der Versuch gemacht, diese ausführlich und umfassend zu geben. Das wird nicht immer auf Anhieb gelingen, deswegen keine Scheu: Rückfragen deuten auf Schwächen der Autoren, sie zu stellen verbessert nur diese FAQ.

Die Fragen und Antworten

  1. Was sind Zertifikate?
  2. Wie benutzte ich Zertifikate?
  3. Wer vergibt wie welche Zertifikate?
  4. Wie speichern Zertifikationsinstanzen ihre privaten Schlüssel?
  5. Wie sind Zertifikationsinstanzen angreifbar?
  6. Was passiert, wenn ein privater Schlüssel einer Zertifikationsinstanz verlorengeht oder kompromittiert wird?
  7. Was sind Certificate Revocation Lists?
  8. Warum wird nicht gesagt, welche Software beim Nutzer eingesetzt werden soll?
  9. Warum behandelt Ihr PEM, wenn Nutzersoftware so schwer zu bekommen ist?
  10. Wen zertifiziert die IN-Root-CA?
  11. Wird sich die Arbeitsgruppe IN-CA an politischen Gremien beteiligen?
  12. Wie erreiche ich die Arbeitsgruppe, die den Aufbau der IN-CA koordiniert?
  13. Warum gibt es mehrere IN-CAs?
  14. Warum hat diese Policy eine Mindestlaufzeit bis ins nächste Jahr?
  15. Was sind 'experimentelle Zertifikate'? Ist das zuverlässig?
  16. Sind weitere, den IN-CAs untergeordnete CAs zulässig?
  17. Kann ein Zertifikat denn 'anonym', also ohne Namen, sein?
  18. Warum steht in den Sicherheitsanforderungen der Passus: 'Zugriffe auf andere Software im Terminalbetrieb ist zu verhindern.'
  19. Wo kommt die Zahl 1535 in den Sicherheitsanforderungen her?
  20. Kann auch jemand einen PGP Schlüssel zertifizieren, ohne eine eMailadresse zu haben?
  21. Warum schreibt die Policy von Mindestlängen, wo doch RSA nur eine Schlüssellänge kennt?
  22. Was unterscheidet ein selbst-signiertes Zertifikat von einem PGP Schlüssel?
  23. Ist die Angabe der Option "IN-CA:[regionaldomain]" nicht redundant? Die zugehörige IN-CA erkennt mensch doch am Zertifikat!
  24. Sollen diese ganzen Namensrestriktionen auch bei Verfahren gelten, wo diese Informationen bereits im Zertifikat selbst stehen?
  25. Warum stehen die Ortsangaben zur IN-Root-CA nicht in der Policy?
  26. Welche Personen können fremdzertifiziert werden?
  27. Kann eine IN-CA meinen privaten Schlüssel mißbrauchen?
  28. Welche Verfahren werden unterstützt?
  29. Muß ich mich an den nächsten IN-RA wenden?
  30. Kann ich auch zur IN-Root-CA fahren?
  31. Kann ich verhindern, daß mein Zertifikat öffentlich wird?
  32. Was heißt das ENCR oder SIGN in den Namensregeln?
  33. Was passiert, wenn mein Zertifikat verfällt?
  34. Was passiert, wenn ein Schlüssel den angebenen Expiretag überschreitet?
  35. Was passiert, wenn ein Name doppelt vergeben wird?
  36. Wie weit ist das Projekt fortgeschritten?
  37. Soll diese Zertifizierungshierarchie einmal Zertifizierungsstelle nach SiG werden?
  38. Warum sind elektronische Unterscnriften trotz SiG fraglich?
  39. Es gibt deutschlandweit in letzter Zeit Gründungen von CAs, u.a. bietet seit letzter Woche die c't sowas an und in Hamburg ist gerade eine Schlüsselinstanz beim DFN-Cert im Aufbau. Gibts da eigentlich einen Zusammenhang, Hierarchien, Cross-Zertifizierungen oder ähnliches oder kocht da jede(r) seine eigene Suppe?