Obwohl die PGP-Gemeinde eine gesunde Paranoia auszeichnet, wird PGP weiterhin regelmäßig für unsicher oder sogar obsolet erklärt, nicht zuletzt nach der Entdeckung der EFail-Schwachstelle. Interessanterweise setzt auch Apples Produktsicherheitsteam auf PGP für eine sichere Kommunikation, kann aber die für Apple Mail zuständigen Entwicklerinnen offensichtlich nicht bewegen, PGP nativ zu unterstützen.
Da mein MUA nicht (oder kaum) von EFail betroffen ist, vervollständige ich meinen überkomplexen Mailstack dennoch mit einer jahrelang vernachlässigten Komponente und richte trotz der fehlgeschlagenen Schlüsseldistributionsinitiativen der vergangenen Jahre ein OpenPGP Web Key Directory ein, denn:
Im Unterschied zu den bisher genutzten öffentlichen Key Servern werden beim integrierten Web Key Directory nur authentifizierte E-Mail Adressen inklusive des öffentlichen Schlüssels veröffentlicht. Über das integrierte WKD wird der E-Mail-Server des jeweiligen Anbieters zum maßgeblichen und zuverlässigen Bezugspunkt für den richtigen öffentlichen Schlüssel der jeweiligen E-Mail-Adresse. Denn durch ein Verifizierungsverfahren, idealerweise über die explizite Bestätigung des E-Mail-Nutzers selbst, werden öffentlicher Schlüssel und E-Mail-Adresse fest verknüpft. Eine Verwechselung kann somit weitestgehend ausgeschlossen werden.
Die WKD-Anleitung von Mike Kuketz ist sehr hilfreich, verführt mich aber an einer entscheidenden Stelle dazu, sämtliche Schlüssel zu einer E-Mail-Adresse zu exportieren/veröffentlichen (gpg --no-armor --export user@eden.one > ke39y8fkyw5j8uubuicshffo9hhudk4j), was zu verwirrenden Effekten führt. Andererseits kann ich diese Situation dazu nutzen, sauber signierte Nachrichten an gnugpg-users@gnupg.org zu senden (und sofort Hilfe zu bekommen). Werner Koch selbst nimmt meine Anfrage sogar zum Anlass, das Zusammenspiel von GnuPG und WKD zu überdenken. Ich fühle mich sehr geehrt.
Dank Homebrew verfüge ich bereits über ein aktuelles GnuPG und ein entsprechend kompiliertes mutt, gpgme funktioniert mittlerweile reibungslos, die Generierung modern gekurvter-Schlüssel ist rasch erledigt (gpg --full-gen-key), und da meine Domain zertifikatsbewehrt ist, gestaltet sich auch die WKD-Konfiguration denkbar einfach. Zunächst wird ein Verzeichnis im Webroot-Verzeichnis auf dem Webserver angelegt und innerhalb des neuen Verzeichnisbaums eine (leere) Policy-Datei erzeugt:
mkdir -p /var/www/html/mysite/.well-known/openpgpkey/hu touch /var/www/html/mysite/.well-known/openpgpkey/policy
Anschließend werden der WKD-Hash und der Fingerabdruck des PGP-Schlüssels ausgelesen –
gpg --with-wkd-hash --fingerprint user@eden.one
– um den öffentlichen Schlüssel dann im Binärformat in eine Datei zu schreiben, die den Namen des WKD-Hashes trägt:
gpg --no-armor --export $fingerprint > /var/www/html/mysite/.well-known/openpgpkey/hu/$wkd_hash
Zum Schluss benötigt nginx.conf eine Ergänzung –
location ^~ /.well-known/openpgpkey { default_type application/octet-stream; add_header Access-Control-Allow-Origin * always; }
– für die WKD-konforme Auslieferung des Schlüssels. Und schon:
snafu ~ % gpg -v --locate-external-key user@eden.one gpg: Note: RFC4880bis features are enabled. gpg: using pgp trust model gpg: pub ed25519/7CD6651792B3D1F8 2022-06-06 Snafu <user@eden.one> gpg: key 7CD6651792B3D1F8: "Snafu <user@eden.one>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: auto-key-locate found fingerprint xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx gpg: automatically retrieved 'user@eden.one' via WKD pub ed25519 2022-06-06 [SC] [expires: 2024-06-05] xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx uid [ultimate] Snafu <user@eden.one> sub cv25519 2022-06-06 [E] [expires: 2024-06-05]
Die WKD-Spezifikation unterscheidet zwischen einer direkten und einer fortgeschrittenen Methode –
The benefit of the advanced method is its greater flexibility in setting up the Web Key Directory in environments where more than one mail domain is hosted.
– und obwohl ich nur eine Domain abdecken muss, möchte ich mich nicht auf eine lediglich rückwärtskompatible Variante stützen, sondern den Fortschritt implementieren. Zu diesem Zweck werden ein DNS-Eintrag (A) für die Subdomain openpgpkey.eden.one und ein Zertifikat für die Subdomain benötigt:
certbot certonly -d openpgpkey.eden.one --nginx
Um die Pflege separater Verzeichnisstrukturen für advanced und direct zu vermeiden, ergänze ich nginx.conf so, dass Anfragen an https://openpgpkey.eden.one/.well-known/openpgpkey/eden.one/hu auf das bestehende Verzeichnis abgebildet werden (alle anderen Anfragen an die Subdomain werden auf die reguläre Website umgeleitet):
server { listen 443 ssl http2; server_name openpgpkey.eden.one; ssl_certificate /etc/letsencrypt/live/openpgpkey.eden.one/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/openpgpkey.eden.one/privkey.pem; location / { return 301 https://eden.one; } location ^~ /.well-known/openpgpkey/eden.one { alias /var/www/html/mysite/.well-known/openpgpkey; default_type application/octet-stream; add_header Access-Control-Allow-Origin * always; } }
Ab sofort können die vielen Menschen, die statt eines sicheren Messengers lieber einen WKD-fähigen MUA nutzen, mir mit etwas geringerem Aufwand verschlüsselte E-Mails senden und bei fehlerfreier Konfiguration und Anwendung etwas sicherer sein, den richtigen Schlüssel zu verwenden.