Version 0.6, 20.02.2015
Dieser Text ist noch nicht fertig.
Ein wichtiger Aspekt praktischer Kryptografie ist die Verteilung öffentlicher Schlüssel (Zertifikate). Dies beinhaltet
Auffinden
den ersten Zugriff auf ein Zertifikat
Updates des Zertifikats (neue, verlängerte und widerrufene Komponenten)
die Bekanntmachung, dass ein Zertifikat insgesamt widerrufen wurde
Das wird heute durch Keyserver erreicht. Problematische Aspekte der heutigen Situation sind:
verbindliche Quelle
Es gibt eine Reihe öffentlicher, kostenlos nutzbarer Keyserver. Viele, aber nicht alle von ihnen synchronisieren ihre Daten. Es ist also nicht klar, wo man ein Zertifikat suchen muss. Das erleichtert MitM-Angriffe: Wenn der Angegriffene zuerst auf einem Keyserver(pool) sucht, den der Schlüsselbesitzer nicht nutzt (und auch sonst niemand den legitimen Schlüssel dort hochgeladen hat), dann kann der Angreifer dort ein Fake-Zertifikat hochladen, das keinen Verdacht erregt, weil es das einzige ist, das bei einer Suche nach der E-Mail-Adresse angezeigt wird.
Für die Lösung dieses Problems bietet es sich an, den Keyserver oder das Zertifikat an die Domain der E-Mail-Adresse zu binden. Es gibt einen Entwurf für einen solchen Standard, der allerdings nur die Zertifikate selber ans DNS bindet, aber keine Indirektion über den Verweis auf einen Keyserver bietet: Using DANE to Associate OpenPGP public keys with email addresses. Das heißt, dass ein Mailprovider, der seinen Nutzern diesen Vorteil bieten will, dafür erheblichen Aufwand treiben muss. Für den Provider, aber auch für manche Kunden wäre es nützlich, wenn Kommunikationspartner übers DNS an den zuständigen Keyserver verwiesen würden.
Datenschutz
Man kann direkt nach Namen und E-Mail-Adressen suchen und findet (wenn auch nicht eindeutig) eine zuvor unbekannte E-Mail-Adresse zu einem Namen oder einer bekannten E-Mail-Adresse oder den unbekannten Namen zu einer bekannten E-Mail-Adresse. Hinzu kommen eventuell Kommentare in den User-IDs.
Dieses Problem ist nicht leicht zu lösen. Insbesondere ist diese Problematik mit dem folgenden Punkt unerwünschte Daten von Dritten verbunden, aber auch wenn man diesen erschwerenden Aspekt ausblendet, kann der Anwender heute keine Unterscheidung treffen zwischen
einerseits denjenigen Zertifikatsdaten, die ihm und seinen legitimen Kontakten zur Verfügung stehen
und andererseits denjenigen Zertifikatsdaten, die jeder auf den Keyservern suchen und abrufen kann (wobei man diese beiden Aspekte getrennt behandeln könnte)
Das Problem hat viel damit zu tun, dass das bisherige Keyserver-Modell davon ausgeht, dass man keinen Einfluss mehr auf die Daten seines Zertifikats hat, sobald sie in der Welt sind. Das ergibt sich schon daraus, dass viele Keyserver synchronisiert werden.
Offenlegung der Kontakte
Wenn man regelmäßig die Zertifikate in seinem Keyring auf Updates prüft – was man auf jeden Fall machen sollte –, dann weiß der Keyserver, welche Zertifikate man (also normalerweise nur eine IP-Adresse) (ge)nutzt (hat) – wenn man beim Abruf keine Tricks anwendet (Abruf einzelner Keys auf jeweils anderen Wegen durch Anonymisierungsnetze).
Dieses Problem ist mit dem der Serverlast verbunden. Man kann die von einem Keyserver erhaltenen Daten nicht so weitergeben, dass der Empfänger die Sicherheit hat, dass sie wirklich so (und zum fraglichen Zeitpunkt) von dem Keyserver stammen. Gäbe es eine Möglichkeit dafür, könnte man dem Keyserver viel Traffic ersparen und durch die Zusammenfassung vieler abzufragender Zertifikate verschleiern, wer sich für welches interessiert.
(rechtssichere) Verbindlichkeit der Auskunft
Für aus juristischer Perspektive ernsthafte Anwendungen wird OpenPGP derzeit kaum genutzt. Das liegt nicht nur daran, dass man derzeit keine qualifizierten Zertifikate (Signaturgesetz) im OpenPGP-Format bekommt (was auch technische Gründe hat, die schwer zu überwinden sind), sondern auch daran, dass es für OpenPGP keine rechtssichere Dokumentation gibt, wann ein Zertifikat noch gültig war und wann nicht mehr. Das könnte ein Keyserverbetreiber ändern. Das ist weniger ein technisches Problem als ein ökonomisches: Mit dieser Verbindlichkeit geht ein Haftungsrisiko einher. Deswegen und wegen des damit einhergehenden technischen und organisatorischen Aufwands kann man so etwas im allgemeinen nicht kostenlos anbieten.
unerwünschte Daten von Dritten
Ein erhebliches, zu Missbrauch geradezu einladendes Problem stellt der Umstand dar, dass heute jeder in der Lage ist, beliebige Daten auf Keyserver hochzuladen oder dort zu ergänzen. Dieses Feature senkt nicht nur den Aufwand für die Keyserver dramatisch, es war auch gut gemeint: Je mehr Signaturen ein Zertifikat hat, desto besser. Allerdings führt das auch dazu, dass man sein Zertifikat nicht verlässlich von Keyservern fernhalten kann. Jeder kann es hochladen (das passiert meist ohne bösen Willen). Es gibt zwar ein Flag im Zertifikat, das für Änderungen die Autorisierung des Schlüsselbesitzers verlangt, aber das wird ignoriert (die (meisten) Keyserver nehmen sowieso keine Signaturprüfungen vor).
keine qualitativen Aussagen (Prüfung der E-Mail-Adresse)
Es macht die Entwicklung eines Keyservers natürlich einfacher, wenn der sich um nichts kümmern muss, das nicht absolut essentiell ist: Speicherung & Indizierung / Abfrage. Es gibt aber keinen guten Grund dafür, einem Keyserver nicht einmal die Möglichkeit zu geben, mehr zu leisten. Das muss natürlich entsprechend kenntlich gemacht sein.
Eine Funktion, die sich aufdrängt, weil viele Anwender sie von einem Keyserver erwarten dürften, ist die Prüfung der E-Mail-Adresse. Es gibt Keyserver, die das machen. Die haben dann aber auch nur solche Zertifikate, weswegen man sich nicht auf die Nutzung solcher Keyserver beschränken kann. Erstrebenswert ist, dass ein Keyserver für jedes gelieferte Zertifikat mitteilt, ob er die E-Mail-Adresse geprüft hat. Oder – die Server müssen ihre Zertifikate sinnvoll untereinander abgleichen können – ob ein Keyserver, dem er vertraut, das getan hat. Der Anwender könnte seine Software dann beispielsweise anweisen, nur solche Zertifikate (ohne weitere Bestätigung) zu importieren, die als geprüft gekennzeichnet sind. Das würde trivialen Zertifikatsspam erheblich erschweren.
fehlende Filterfunktionen
Es ist eine groteske Fehlleistung, dass eine Keyserver-Software es den Admins nicht erlaubt, einzelne Zertifikate zu löschen und dauerhaft zu blockieren. Der dagegen ins Feld geführte Einwand der Synchronisation ist von er schreckender Einfältigkeit.
Es wäre derzeit mit wenig Aufwand (aber etwas krimineller Energie) möglich, auf juristischem Weg den Großteil des OpenPGP-Keyserversystems in die Knie zu zwingen. Man muss nur illegalen Inhalt (und da ist weitaus Schlimmeres denkbar als Beleidigungen und Copyrightverstöße, denn OpenPGP-Zertifikate können auch Fotos enthalten...) hochladen. Ein ausreichend dummer Staatsanwalt ist in Deutschland schnell gefunden. Richter mit Internet-Amoklauftendenz gibt es in Hamburg und Köln auch zur Genüge.
Aber auch unabhängig von rechtlichen Problemen muss ein Serverbetreiber sich entscheiden können, z.B. aus Platzgründen keine Fotos oder keine Signaturen von ihm unbekannten Schlüsseln zu speichern.
Serverlast
Version 1.0, xx.xx.2015 (diese Version, Permanentlink)