Situation
Wie neulich dargestellt ist das Web of Trust in der alten Form nicht praktikabel (und auch nicht konform zur DSGVO) und die Ersatzmethode mit zentralistischen Keyservern nicht wünschenswert. Das Vertrauensprinzip bei letzterer Methode ist die direkte Überprüfung per E-Mail, also des Zugriffs des hochladenden Schlüsselinhabers auf den E-Mail-Account. Diese Idee kann verfeinert werden, um einen dezentraleren Lösungsansatz zu erreichen.
Web Key Directory - WKD
Der Ansatz, der einen Kompromiss zwischen den dezentralen (föderalen) Keyservern des Web of Trust und den zentralen moderneren Keyservern darstellt, ist das Web Key Directory (WKD). Dabei kann der Domänenteil der E-Mail-Adresse als Domäne für einen Web-Zugriff verwendet werden, der lokale Teil wird gehasht und für den abzurufenden Dateinamen verwendet. Als Domain-Inhaber mit Webspace kann man seinen Schlüssel selber ohne zusätzliche Hilfe Dritter veröffentlichen. Auch einige E-Mail-Anbieter bieten eine entsprechende Möglichkeit an.
Vorteile
Man könnte als Domain-Inhaber seinen Schlüssel einfach zum Download anbieten und auf seiner Webseite verlinken. Allerdings wären dann weder der Ablageort noch das Namensschema einheitlich definiert und eine Automatisierbarkeit kaum möglich. Mit WKD kann man E-Mail-Programme so erweitern, dass der Import fehlender Schlüssel aus Sicht des Benutzers sehr einfach ist. Eine Reihe von bekannten E-Mail-Programmen haben das bereits implementiert. Thunderbird hatte es, als Enigmail noch aktiv benutzt wurde, und weitere Beispiele sind KMail und Outlook. Diese Liste erhebt keinen Anspruch auf Vollständigkeit. GnuPG kann mit dieser Methode Schlüssel via Kommandozeile importieren.
Beispiel
Der angezeigte Hash-Wert ist frei erfunden und dient nur der Illustration.
Schlüsseldatei für WKD erzeugen (Schlüsselinhaber)
$ gpg --with-wkd-hash --fingerprint john.doe@example.net | grep @ | grep -v john 7p53u1sqwxrgerffd6ip3jieqcqzea43@example.net $ gpg --no-armor --export john.doe@example.net > 7p53u1sqwxrgerffd6ip3jieqcqzea43
Ablage Webserver (Schlüsselinhaber)
https://openpgp.example.net/.well-known/openpgpkey/hu/7p53u1sqwxrgerffd6ip3jieqcqzea43
Schlüsseldatei importieren (Leute im Internet)
$ gpg --locate-external-keys john.doe@example.net
Eine weiterführende und deutschsprachige Anleitung gibt es im Kuketz-Blog (s.u.) seit 2019-09-11. Einige erforderliche Details sind hier nicht aufgeführt. Das betrifft die Existenz einer ggf. leeren Datei policy und die Konfiguration des DNS. Für einen Domain-Inhaber ist das keine ernsthafte Schwierigkeit.
Vertrauensmodell
Als Domain-Inhaber oder Inhaber der E-Mail-Adresse muss man dem Provider für Webspace oder E-Mail vertrauen, den korrekten Schlüssel auszuliefern. Als Benutzer sind fremdsignierte Schlüssel wünschenswert, aber auch über die Kombination E-Mail/Web/DNS-Validierung begründet sich ein Erstvertrauen, das etwas stärker ist als einen Schlüssel aus einer beliebigen Quelle nach dem Prinzip Trust on first use (TOFU) (s.u.) zu verwenden. Ein Angreifer müsste die Kommunikationskanäle E-Mail und Web gleichzeitig unbemerkt kompromittieren.
WKD (en)
GnuPG: Web Key Directory (WKD) einrichten
WP: Trust on first use (en) - TOFU