Letzte Änderung: 15.09.1996Diese FAQ wird von Lutz Donnerhacke gepflegt. Kommentare sind willkommen.
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.
ENCR oder SIGN in den Namensregeln?
Zertifikate sind elektronische Unterschriften von vertrauenwürdigen Dritten, die bestimmte Zuordnungen bestätigen. Der häufigste Fall wird die Zuordnung einer Person zu einem öffentlichen Schlüssel sein.
Hast Du den Verifikationsschlüssel der des Unterzeichners, so kannst Du das Zertifikat überprüfen. Wenn diese Unterschrift stimmt, ist es faktisch genausoviel wert, wie wenn der Unterzeichner persönlich dies bestätigen würde. Traust Du dem Unterzeichner, so kannst Du nun dem wildfremden Menschen vor Dir glauben, daß die Behauptung, die er mit diesem Zertifikat belegt hat, stimmt. Insbesondere kannst Du Dich darauf verlassen, daß die öffentlichen Schlüssel von Leuten, die Du nie gesehen hast, wirklich zu den richtigen Leuten gehören.
Um dem Verifiaktionsschlüssel des Unterzeichners trauen zu können, überprüfst Du die Zertifikate dieses Schlüssels. In der hier verwendeten Hierarchie bis Du in wenigen Schritten bei der IN-Root-CA, die ihren öffentlichen Verifikationsschlüssel auf anderen Wegen Dir bekannt machen kann (Zeitschriften, Faxpolling, ...)
Ein Unterzeichner, der Zertifikate vergibt, wird Zertifikationsinstanz oder CA (certification authority) genannt. Im Rahmen der vorliegenen Policy vergeben die regionalen IN-CAs Zertifikate an die Nutzer. Was zertifiziert werden kann, hängt von den Fähigkeiten der regionalen IN-CA ab. Einfach mal fragen.
Ein heikles Problem. In dieser Policy wird verlangt, daß die geheimen Schlüssel nur auf wechselbaren Datenträgern vorliegen und nicht auf Rechnern mit Netzanschluß verarbeitet werden. Diese Datenträger müssen sicher weggeschlossen werden. Darüberhinaus sind die geheimen Schlüssel alle passwortgeschützt.
Am brutalsten ist ein bewaffneter Überfall zur Hauptgeschäftszeit.
Alle Mittel, die den Angreifer in Besitz der geheimen Schlüssel bringen, sind anwendbar. Das können brutale wie auch sehr feinsinnige Methoden (wie Messung der kompromittierenden Abstrahlung des Verifikationsgerätes) oder Bestechung sein. In der Regel kosten diese Angriffe viel Geld. Dies ist jedoch aufgrund der strikten Nichtkommerzialität der Zertifikatsnutzer unwahrscheinlich.
Andere Angriffe bestehen in einer ausgiebigen Kryptoanalyse der öffentlichen Daten der CA. Da einer CA Unterschrift viel getraut wird, wäre dies ein gangbarer Weg, sich eine neue Identität zu verschaffen oder schlicht massiv zu betrügen. Diese Angriffe sind jedoch sehr teuer und sehr schwer oder bekannt. In der Regel lohnt ein solcher Angriff auf eine IN-CA den Aufwand nicht.
Bei experimentellen Protokollen kann es jedoch leicht passieren, daß die Protokolle gebrochen werden. Derartigen Zertifikaten solltest Du also nicht trauen. Eine IN-CA wird in der Regel auch protokollübergreifende Zertifikate mit sichereren Verfahren durchführen.
Um langfristigen Attacken aus dem Weg zu gehen, wechseln die IN-CAs ihre Schlüssel regelmäßig. Der noch wertvollere Schlüssel der IN-Root-CA wird darüberhinaus nur selten eingesetzt, um die Kryptoanalyse zu erschweren.
Um einfachen Falschidentifikationen vorzubeugen, muß die Identität des Nutzers oft sehr genau bestimmt werden. Das ist keine Schikane sondern Notwendigkeit. Der Einsatz von IN-RAs vor Ort gestattet eine Identitätsprüfung über persönliche Bekanntschaft.
Wenn der private Schlüssel einer CA verlorengeht (Passwort vergessen), bleiben alle ausgestellten Zertifikate gültig. Es kann nur kein neues Zertifikat erstellt werden.
Ein kompromittierter CA Schlüssel ist gefährlicher. Der Angreifer, der den Schlüssel sich beschafft hat, kann im Namen der CA auftreten. Damit könnten unentdeckbare Fälschungen erzeugt werden. Wenn eine derartige Kompromittierung entdeckt wird, muß die CA sofort ihren Schlüssel zurückrufen und für ungültig erklären. Gleichzeitig sollten alle Zertifikate anhand eines neuen Schlüssels und der Protokolle erneut erstellt werden. Mit einem ewigen Logfile oder ähnlichen Mechanismen kann dies öffentlich überprüft werden. Gleichzeitig gestattet es dieser Mechanismus, auch ältere Zertifikate zu prüfen. Zertifikate, die vor der Kompromittierung ausgestellt wurden, sind gültig.
Beachte, daß dies alles nicht die Nutzerschlüssel ungültig macht. In diesem Falle sind nur die Zertifikate, die die Zuordnung des Schlüssels an eine Person betreffen, gefährdet.
Eine Kompromittierung der privaten Schlüssels der IN-Root-CA ist eine Katastrophe, da nicht ausgeschlossen werden kann, daß dieser Schlüssel für automatische Überprüfungen verwendet wird. (Was eigentlich nicht passieren sollte...)
Wird ein Zertifikat vor Ablauf seiner Gültigkeit zurückgezogen, so muß dies bekannt gemacht werden, da es unmöglich ist, die Kopien des Zertifikates überall zu löschen.
Vor Benutzung eines Zertifikates solltest Du kontrollieren, ob dieses nicht bereits zurückgerufen wurde. Verdächtig ist immer, wenn Dein Gegenüber auf Eile drängt. Vielleicht hofft er so, daß Du nicht nachschaust und dem kompromittieren Schlüssel einfach so traust.
Die Listen der zurückgerufenen Zertifikate findest Du bei der ausstellenden IN-CA und bei der IN-Root-CA.
Diese Policy befaßt sich ausschließlich mit den Anforderungen an die zertifiziernden Einrichtungen. Der Endnutzer kann sich sicher dort informieren, die Software die er benutzt, liegt jedoch in seiner eigenen Verantwortung.
Im Rahmen dieser Policy wird ausschließlich über die Zertifizierung von PEM Schlüsseln gesprochen. Ihre Existenz und Benutzung wird als gottgegeben vorausgesetzt. Vielleicht findet sich etwas auf den künftigen Server der IN-Root-CA.
Die Root-CA ist nur für die direkten Organe des IN e.V. und die regionalen IN-CAs da. Übergangsweise kann sie bei noch nicht funktionsfähigen regionalen IN-CAs deren Aufgaben nur unvollständig übernehmen.
Problem: Notwendige persönliche Kontakte.
Nein. Dafür sind andere Organisationen besser geeignet. Besonders zur Frage der Kryptopolitik ist krypto@rhein-main.de empfehlenswert.
Per eMail an in-ak-ca@individual.net. Wenn Du in die Mailingliste aufgenommen werden willst, so wende Dich an in-ak-ca-request@individual.net.
Würde mensch die regionalen CAs, die dieser Policy gehorchen, nicht als IN-CAs bezeichnen, so wäre dies ein schweres Handicap für andere Entwickungen auf dem gleichen Gebiet. Wir sind nicht perfekt, die Policy kann fehlerhaft sein oder irgendwelche politischen Reglungen schlagen plötzlich dazwischen... dann behindert diese Policy die weitere Arbeit möglicherweise erheblich. Mit der speziellen Benennung bleibt den Regionaldomains immer die Möglichkeit weitere CAs zu errichten, ohne in Namesstreitigkeiten zu kommen.
Nach jeweils einem Jahr gibt es neue Erkenntnisse im akademischen, wie auch im politischen und menschlichen Bereich. Diese wirken sich in der Regel auch auf die Konstrukte der Zertifikationsstrukturen aus. Deshalb muß die Policy regelmäßig angepaßt werden. Das erklärt ihre Laufzeit von genau einem Jahr.
Andererseits muß ein ausgestelltes Zertifikat eine Mindestsicherheit haben, die auf der Policy basiert. Ebenso sind Übergangsreglungen von endlicher Länge. Die Überlappung garantiert, wie lange Du noch auf die vorjährigen Ansprüche an die IN-CA vertrauen kannst. Diese Mindestfrist des Überganges und der Unveränderlichkeit bildet eine Kontinuität im Betrieb der IN-CAs.
Es geht um experimentelle Protokolle, die durch eine Zertifikationsinstanz aufgewertet werden können. Experimente tatkräftig zu unterstützen ist im Sinne des Individual Network e.V. und entspricht dem experimentellen Charakter der IN-CA. Die Sicherheit anderer Zertifikate leidet nicht unter der Verwendung verschiedener Protokolle, ebensowenig, wie die Unterschriften unter Verträgen von Unterschriften unter Geburtstagskarten beeinflußt werden.
Im Prinzip nein. In begründeten Ausnahmefällen kann das jedoch Sinn machen. Da diese weder vorhersehbar sind noch erwartet werden, wurde die vorsichtige Formulierung 'sollten nicht existieren' verwendet.
Ja. Siehe Chaums Theorien auf http://www.digicash.nl/. Ein Zertifikat bestätigt nur eine bestimmte Eigenschaft des Inhabers.
Bspw. ein Zertifikat, daß bestätigt via IN e.V. versorgt zu sein, kann völlig anonym ausgestellt werden und dann Zugriff auf bestimmte Ressourcen im Netz eröffnen.
Ist es einem Mitarbeiter möglich, auf der Maschine per Terminalzugriff mehr als Zertifikationen auszuüben, so kann das auch ein Angreifer. Dieses Risiko soll vermieden werden.
(2048+1024) / 2 = 3072 / 2 = 1536
1535 liegt genau in der Mitte zwischen den Minimalanforderungen an die Schlüssellängen einer IN-RA und der IN-Root-CA. Es hat nichts weiter zu bedeuten.
Die IN-CA ist für Teilnehmer an den Regionaldomains des Individual Network e.V. da. Alle diese Menschen haben eine eMail.
Es gibt mehr als RSA. Im DSA des DSS tauchen drei Mindestlängen der verwendeten Schlüsselpaare auf. (Zwei für den öffentlichen und eine für den privaten Schlüssel)
Ein selbst-signierter öffentlicher PGP Schlüssel ist ein selbst-signiertes Zertifikat, wenn die Namensregeln eingehalten wurden.
Nach der dritten Crosszertifizierung?
Die Felder ... sind optional ...
Zum einen existieren sie noch nicht.
Zum anderen gehören sie nicht in dieses Dokument, da die IN-Root-CA nur eine spezielle Anwendung des Dokumentes darstellt.
Es wird immer wieder Leute geben, die nicht Mitglied einer IN Regionaldomain sind und trotzdem an bestimmten Zertifikaten privates Interesse haben. Diese können, aber müssen nicht, von einer IN-CA ein Zertifikat bekommen. besonders interessant ist dies für experimentelle Protokolle, da für diese i.d.R. keine Zertifikationsstrukturen existiern, bevor nicht irgendein Gutachten dieses einfordert.
Für kommerzielle Anwendungen werden keine Zertifikate ausgestellt. Es wird jedoch eine Crosszertifizierung mit kommerziellen Zertifikationsstrukturen begrüßt.
Nein, weil sie ihn nicht hat. Du bringst nur Deinen öffentlichen Schlüssel und (unter Umständen) ein Widerrufszertifikat mit. Daraus kann die IN-CA Deinen privaten Schlüssel nicht wiederherstellen.
Bei verschiedenen experimentellen Protokollen, insbesondere im Zusammenhang mit Chipkarten, werden jedoch die privaten Schlüssel bei der CA erzeugt. Werden derartige Protokolle verwendet, so ist die IN-CA nach Maßgabe dieser Policy zur sofortigen Vernichtung der Daten zur Wiederherstellung Deines privaten Schlüssels verpflichtet.
Bei anderen Protokollen gestatteten es neuere Erkenntnisse, den privaten Schlüssel aus den öffentlichen Schlüsseldaten zu berechnen. Die IN-CAs sind jedoch kaum in der Lage die dafür notwendigen Geldmengen in Rechentechnik zu stopfen noch haben sie ein Interesse an Deinem Schlüssel.
Der Umgang mit Trustcentern, wie sie die IN-CAs darstellen basiert auf Vertrauen. Fragen sind immer gestattet und wenn Dir die Antworten nicht genügen, dann such Dir lieber andere Wege des Schlüsseltausches. Die IN-CAs sind nicht lebensnotwendig, nur praktisch.
PGP-Unterschriften in erster Linie, PEMs (X.509) Zertifikate und weitere Zertifikate, je nach Bedarf und Ausbaustufe. Schon die Unterstützung von PEM kann regional verschieden sein. Frage Deine nächste IN-CA.
Nein. Innerhalb der Region solltest Du Dir den Ansprechpartner suchen, der am sichersten Deine Identität bestätigen kann. Das kann natürlich die IN-CA selbst sein. Die IN-RAs sind dafür da, Dir Fahrtwege zu ersparen.
Nein. Die IN-Root-CA ist ausschließlich für die Zertifizierung und Überprüfung der IN-CAs da. Außerdem erledigt sie die Zertifikatansprüche der überregionalen Einrichtungen des Individual Network e.V.
Ja, Du kannst ohne Angabe von Gründen (im Zweifel hast Du einfach Angst von Bulk-eMail) bei der Zertifikation Deines Schlüssels einer Veröffentlichung widersprechen. Einer Veröffentlichung eines Zertifikatwiderrufs kannst Du jedoch nicht widersprechen. Diese Veröffentlichung des Widerrufs ist ja in Deinem Interesse, da irgendetwas mit Deinem Schlüssel schiefgegangen ist, das Deine Netzidentität beeinträchtigen kann.
ENCR oder SIGN in den Namensregeln?
ENCR ist die Angabe, daß es sich um einen
Chiffrierschlüssel handelt. Mit diesem Schlüssel kannst Du Nachrichten
an die zugehörige Person verschlüsseln. Empfängst Du jedoch
Unterschriften, die zu diesem Schlüssel passen sollen, so liegt sehr
wahrscheinlich ein Betrugsversuch vor.
SIGN ist die Angabe, daß es sich um einen
Verifikationsschlüssel für Unterschriften handelt. Mit diesem Schlüssel
kannst Du prüfen, ob eine Unterschrift stimmt. Du solltest NIE mit diesem
Schlüssel Nachrichten an die zugehörige Person chiffrieren. Empfängst
Du Nachrichten, die mit diesem Schlüssel chiffriert sind, so traue ihnen
nicht. Sie sind vermutlich gefälscht.
Dein Schlüssel ist nicht mehr durch dieses Zertifikat bestätigt. Es kann nun sein, daß verschiedene Leute Deinen Schlüsseln nicht mehr trauen. Du kannst einfach Deinen Schlüssel neu zertifizieren lassen.
Dieser Schlüssel ist ungültig und sollte nicht mehr verwendet werden. Du kannst ihn löschen. Ist es Dein Schlüssel, so mußt Du einen neuen Schlüssel im Umlauf haben oder in Umlauf bringen.
Dann hat die IN-CA geschlampt. Melde Dich bei der IN-Root-CA. Hat die IN-Root-CA geschlampt, mache ein Faß auf.
Momentan ist die Policy und eine FAQ veröffentlicht und wird gepflegt. Die Policy steht fest. In ihrer jetzigen Form wurde sie von der IN MV am 9.3.1997 in Ilsenburg angenommen. Die IN-Root-CA und die überregionale CA sind aktiv. Die Schlüssel findest Du auf dem Webserver oder bei einem PGP-Net Server. Andere Regionaldomains sind im Aufbau.
Wie Du richtig bemerkt hast, ist es ein Entwurf. Mit dem betreffenden Referenten stehen wir auch in Kontakt, da er sich an der Mailingliste krypto@rhein-main.de beteiligt. Sobald dieses Gesetz kommt, wird entschieden werden müssen, ob die Anforderungen von uns erfüllbar sind oder nicht.
Mit dem momentanen Wortlaut ist unsere Regelung dahingehend vereinbar, daß wir davon ausgehen, die notwendige Sachkunde und Zuverlässigkeit zu besitzen. Dies zu prüfen gelingt momentan nicht, da der Entwurf des SiG eine massive Schwachstelle in seinem Paragraphen 16 hat, der alle Prüfungen aus den Händen des Gesetzgebers in die eines Ministerialbeamten übergibt. Dessen Entscheidungen sind unvorhersehbar. Die Angaben in unserer Policy bieten diesen Spielraum nicht. So können Kollisionen auftreten, die eine Anerkennung der IN-CA Struktur als Zertifizierungsstelle im Sinne des SiG unmöglich machen.
Von unserer Seite aus streben wir momentan keine Prüfung durch das BSI oder eine andere Behörde im Sinne des Paragraphen 16 an.
Darüberhinaus gibt es im Absatz 5 des Paragraphen 4 ein Problem mit der Veröffentlichung. Unsere Zertifikate sind zwar per default öffentlich, einer Veröffentlichung kann jedoch ohne Angabe von Gründen widersprochen werden (Abschnitt 8). In diesem Falle verbietet es unsere Policy in Abschnitt 9 nicht, die Widerrufszertifikate ebenfalls nicht zu veröffentlichen, so der Nutzer das wünscht.
Ja, das SiG regelt die Gültigkeit von bestimmten Zertifikaten, aber nicht völlig allgemein, sondern nur für digitale Unterschriften, Zertifizierungsstellen usw., die die im Gesetz beschriebenen Eigenschaften aufweisen.
Die aktuelle Formulierung "...die allgemeine rechtliche Relevanz..." - will sagen, die rechtliche Bedeutung oder Beweiskraft z.B. einer PGP-Unterschrift ist nach wie vor (auch nach Inkrafttreten des Signaturgesetzes) unklar.
Das ganze ist im größeren Zusammenhang der zunehmenden Internet-Nutzung und des daraus resultierenden Bedarfs nach gesicherter, (rechts-)verbindlicher elektronischer Kommunikation zu sehen. Insbesondere die zunehmende kommerzielle Nutzung des Internet "schreit" geradezu nach verbindlicheren elektronischen Dokumenten als es z.B. normale e-mails sind.
Zusammenhang
Die DFN-PCA, die Du ansprichst, ist schon am längsten in Vorbereitung und gab letztlich auch den Anstoß für das Projekt im Individual Network (IN) e.V.. Das CA-Projekt des Individual Network war dann aber etwas eher "operational" als die DFN-PCA. Die muß aber auch noch umfangreichere Aufgaben wahrnehmen, muß man fairerweise hinzufügen: die DFN-PCA ist die deutsche "Root-CA" innerhalb des europäischen ICE-TEL-Projektes und eben auch die Toplevel-Zertifizierungsstelle für alle DFN-Teilnehmer.
Hierarchie
Da das IN auch DFN-Teilnehmer ist, ist die DFN-PCA sozusagen hierarchisch "über" der IN-Root-CA anzusiedeln. Das würde aber eine Zertifizierung für die IN-Root-CA durch die DFN-PCA voraussetzen. Ob die möglich sein wird, hängt noch an ein, zwei Knackpunkten, die von der endgültigen Fassung der DFN-PCA-Policy abhängen. Falls eine Zertifizierung für das IN möglich ist, sind wir unterhalb der DFN-PCA angesiedelt, ansonsten wird es aller Voraussicht nach eine Cross-Zertifizierung mit der DFN-PCA geben.
c't-Krypto-Kampagne
Die c't hat eine "Krypto-Kampagne" gestartet, um mehr Netznutzer für die Wichtigkeit von Verschlüsselung zu sensibilisieren. Das geschah auch vor dem Hintergrund, daß immer wieder von Überlegungen zu hören ist, Verschlüsselung unter einen Gesetzesvorbehalt zu stellen bzw. genehmigungspflichtig zu machen.
Die ct-Zertifizierungsstelle (CA) will nach eigenen Angaben von der DFN-PCA zertifiziert werden oder zumindest nach deren Richtlinien arbeiten; von daher wäre dann auch die c't-CA in der Zertifizierungshierarchie unterhalb der DFN-PCA anzusiedeln.