1. Schlüsselfälscher
Gefälschte Schlüssel sind ein echtes Problem bei der Nutzung von E-Mail-Verschlüsselung via PGP bzw. GnuPG. Jeder kann Fake-Keys für beliebige E-Mail-Adressen erstellen und diese auf die Keyserver hochladen. Mit diesem Dilemma hatte ich mich bereits ausführlich beschäftigt. Eine mögliche Lösung für dieses Problem sind die neuen Keyserver wie keys.openpgp.org, die E-Mail-Adressen verifizieren und dem Eigentümer eine einfache Schlüsselverwaltung bietet.
Im vorliegenden Beitrag möchte ich euch noch eine weitere Alternative vorstellen, mit der sich öffentliche Schlüssel aus einer vertrauenswürdigen Quelle beziehen lassen. Mittels Web Key Directory (WKD) lassen sich öffentliche Schlüssel über einen Webserver bzw. E-Mail-Provider beziehen. WKD ist nach meiner Auffassung eine benutzerfreundliche Alternative für den Austausch von Schlüsseln, da Clients wie Thunderbird/Enigmail diesen Standard bereits verwenden, um beim Verfassen einer E-Mail automatisch den öffentlichen Schlüssel eines Benutzers abzurufen. Insgesamt wird der Schlüsseltausch mit WKD stark vereinfacht – das steigert insgesamt die Nutzerfreundlichkeit der E-Mail-Verschlüsselung.
2. Web Key Directory (WKD)
Angenommen ihr wollt an die E-Mail-Adresse webmaster@kuketz-blog.de
eine verschlüsselte E-Mail schreiben. Zunächst benötigt ihr dafür den aktuell gültigen öffentlichen Schlüssel. Auf den herkömmlichen Keyservern braucht ihr erst gar nicht zu suchen, da erhaltet ihr ganz viele Treffer – und die meisten davon sind Fakes. Aktuell könnt ihr meinen öffentlichen Schlüssel aus folgenden drei vertrauenswürdigen Quellen beziehen:
- Direkt als Download von der Webseite
- Vom keys.openpgp.org-Keyserver, der von mir autorisierte Schlüssel bereitstellt
- Via Web Key Directory (WKD) direkt über einen (PGP-)Client wie Thunderbird/Enigmail, KMail, Outlook (GpgOL) etc.
Beim Verfassen an die E-Mail-Adresse webmaster@kuketz-blog.de
wird Thunderbird/Enigmail automatisch versuchen, den öffentlichen Schlüssel via WKD zu beziehen. Als Quelle wird WKD an folgendem Ort bzw. URL nach dem Schlüssel suchen:
https://kuketz-blog.de/.well-known/openpgpkey/hu/kd39y8fkyw5j8uubuicshffo9hhodk4j
Wird WKD dort fündig, wird es den öffentlichen Schlüssel in den GnuPG-Keyring importieren und ihr könnt ohne Umwege direkt eine verschlüsselte E-Mail an meine Adresse versenden. Elegant und einfach.
Du kannst den Blog aktiv unterstützen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.1 Anforderung: Eigene Domain
Wenn ihr WKD für eure eigene Domain einrichten möchtet, benötigt ihr im Grunde lediglich die folgenden Komponenten:
- Einen Webserver wie nginx oder Apache, der eure Domain ausliefert
- Ein gültiges TLS-Zertifikat (bspw. von Let’s Encrypt)
- Einige Shell-Befehle
2.2 Alternative: E-Mail-Anbieter mit WKD-Support
All jene unter euch, die keinen eigenen Webserver bzw. eigene (E-Mail-)Domain betreiben, die finden unter der Ziffer »Mail Service Providers offering WKD« in dieser Liste E-Mail-Provider, die WKD bereits unterstützen. Sowohl mailbox.org als auch Posteo (beide in der Empfehlungsecke) bieten WKD bereits an.
3. Einrichtung
Nach der Einrichtung muss der öffentliche Schlüssel via TLS über eine spezielle URL erreichbar sein. Diese hat den folgenden Aufbau:
https://Domain
/.well-known/openpgpkey/hu/Hash-Wert-Email-Prefix
Als Beispiel verwende ich die URL bzw. meine E-Mail-Adresse »webmaster@kuketz-blog.de«:
https://kuketz-blog.de/.well-known/openpgpkey/hu/kd39y8fkyw5j8uubuicshffo9hhodk4j
Die nachfolgende Anleitung beschreibt die Einrichtung unter einem Debian-GNU/Linux-System mit nginx / Apache als Webserver. Mit minimalen Anpassungen lässt sich die Anleitung auf vergleichbare Linux- bzw. UNIX-Systeme übertragen.
3.1 Ordnerstruktur erstellen
Zunächst wird die Ordnerstruktur erstellt, unter der später der öffentliche Schlüssel abgelegt wird. Der Ordername hu
steht übrigens für hashed-userid:
mkdir -p /var/www/sites/kuketz-blog.de/.well-known/openpgpkey/hu
Anschließend muss noch eine Datei erstellt werden, die den WKD-Clients mitteilt, dass WKD grundsätzlich angeboten wird:
touch /var/www/sites/kuketz-blog.de/.well-known/openpgpkey/policy
3.2 Webserver einrichten
Für nginx könnt ihr folgendes Code-Snippet benutzen. Achtet darauf, dass ihr es unter dem Serverblock hinzufügt, der für die Auslieferung eurer Domain via TLS zuständig ist:
## WEB KEY DIRECTORY ## location ^~ /.well-known/openpgpkey { default_type application/octet-stream; add_header Access-Control-Allow-Origin * always; }
Für Apache eignet sich die folgende Konfiguration:
## WEB KEY DIRECTORY ## <Directory "/.well-known/openpgpkey"> <IfModule mod_mime.c> ForceType application/octet-stream Header always set Access-Control-Allow-Origin "*" </IfModule> </Directory>
Auch für den Caddy-Webserver gibt es einen Vorschlag:
your.domain { root * /var/www/your_web_folder file_server header /.well-known/openpgpkey/* Access-Control-Allow-Origin * header /.well-known/openpgpkey/* Content-Type application/octet-stream [...] }
3.3 Hashwert des E-Mail-Präfix auslesen
Nachdem die benötigten Verzeichnisse erstellt sind, wird der Prefix-WKD-Hash der E-Mail-Adresse ermittelt:
gpg --with-wkd-hash --fingerprint webmaster@kuketz-blog.de
Ausgabe:
pub rsa4096 2014-03-20 [SC] [verfällt: 2023-02-11]
144B E5B3 6734 7B82 60D6 D023 DB24 801D B9EF ECF5
uid [ ultimativ ] Mike Kuketz <mike@kuketz.de>
wf964j9kibbnokdn976bz8rd1stgio3y@kuketz.de
uid [ ultimativ ] Mike Kuketz <info@kuketz-security.de>
mg6owx9w8c3ejg3tu31f4tha5n17d4rj@kuketz-security.de
uid [ ultimativ ] Mike Kuketz <webmaster@kuketz-blog.de>
kd39y8fkyw5j8uubuicshffo9hhodk4j
@kuketz-blog.de sub rsa4096 2014-03-20 [E] [verfällt: 2023-02-11] sub rsa4096 2019-06-05 [A] [verfällt: 2023-02-11]
Der Prefix-WKD-Hash (grün markiert) besteht aus allen Zeichen einer E-Mail-Adresse bis zum @-Zeichen. Für die E-Mail-Adresse »webmaster@kuketz-blog.de« lautet der Prefix-WKD-Hash demnach: kd39y8fkyw5j8uubuicshffo9hhodk4j
= webmaster
3.4 WKD-Datei erstellen
Nachdem der Prefix-WKD-Hash bekannt ist, muss der öffentliche Schlüssel im Binärformat (nicht ASCII-armored) exportiert werden:
gpg --no-armor --export webmaster@kuketz-blog.de > kd39y8fkyw5j8uubuicshffo9hhodk4j
3.5 Upload des Schlüssels
Der exportierte Schlüssel mit der Bezeichnung kd39y8fkyw5j8uubuicshffo9hhodk4j
wird anschließend im Verzeichnis
https://kuketz-blog.de/.well-known/openpgpkey/hu
abgelegt. Insgesamt ergibt sich dann folgende Struktur:
.well-known/ └── openpgpkey ├── hu │ └── kd39y8fkyw5j8uubuicshffo9hhodk4j └── policy
3.6 TXT-Record im DNS hinterlegen
Hinweis
Der nachfolgende Schritt ist nur notwendig, wenn die Domainopenpgpkey.eureDomain.de
aufgelöst wird. Dann solltet ihr wie nachfolgend beschrieben einen (leeren) TXT-Record anlegen. Alternativ könnt ihr auch ein gültiges TLS-Zertifikat für die Subdomain openpgpkey.eureDomain.de
ausliefern und einen Redirect auf eure Schlüssel-URI vornehmen. Das Anlegen eines TXT-Records ist etwas einfacher.Die Implementierung von WKD unterscheidet zwischen einer Advanced- und Direct-Methode zur Abfrage der Schlüssel-URI. Bei der Advanced-Methode wird der öffentliche Schlüssel unter der Subdomain
https://openpgpkey.kuketz-blog.de
gesucht. Diese Subdomain habe ich allerdings nicht eingerichtet, sondern verwende die Direct-Methode. Da die Domain openpgpkey.kuketz-blog.de
bei mir jedoch aufgelöst wird bzw. erreichbar ist, muss zusätzlich ein TXT-Record im DNS hinterlegt werden, damit Clients den öffentlichen Schlüssel von der URL
https://kuketz-blog.de/.well-known/openpgpkey/hu/kd39y8fkyw5j8uubuicshffo9hhodk4j
beziehen können bzw. überhaupt dort danach suchen. Standardmäßig werden Clients zunächst versuchen, den öffentlichen Schlüssel über die Advanced-Methode zu beziehen, also von openpgpkey.eureDomain.de
. Durch das Anlegen des TXT-Records unterbindet man praktisch, dass der DNS-Server einen A-Record oder CNAME zurückliefert und unser Webserver die Anfrage anschließend entgegennimmt – das möchten wir vermeiden.
Begebt euch daher in die DNS-Einstellungen eures Hosting-Anbieters und legt dort einen DNS-Eintrag an. Beim Anbieter netcup.de würde dies für die Domain kuketz-blog.de so aussehen:
- Host: openpgpkey
- Type: TXT
- Destination: empty
Beim Feld »Destination« muss ein beliebiger Eintrag erfolgen – es ist nicht möglich einen leeren TXT-Record anzulegen. Ich verwende daher einfach die Bezeichnung bzw. Eintrag empty
.
Anschließend könnt ihr den TXT-Record ausgeben lassen – je nach DNS-Server wird dies etwas dauern:
host -t txt openpgpkey.kuketz-blog.de
Ausgabe:
openpgpkey.kuketz-blog.de descriptive text "empty"
3.7 Testen der WKD-Schlüsselerkennung
Mit dem folgenden Befehl wird GnuPG angewiesen, den öffentlichen Schlüssel via WKD zu beziehen – sogar dann, wenn er lokal bereits im GnuPG-Keyring vorhanden ist:
gpg -v --auto-key-locate clear,wkd,nodefault --locate-key webmaster@kuketz-blog.de
Ausgabe:
gpg: verwende Vertrauensmodell pgp
gpg: pub rsa4096/DB24801DB9EFECF5 2014-03-20 Mike Kuketz <mike@kuketz.de>
gpg: Schlüssel DB24801DB9EFECF5: "Mike Kuketz <mike@kuketz.de>" nicht geändert
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg: unverändert: 1
gpg: auto-key-locate found fingerprint 144BE5B367347B8260D6D023DB24801DB9EFECF5
gpg: `webmaster@kuketz-blog.de' automatisch via WKD geholt
pub rsa4096 2014-03-20 [SC] [verfällt: 2023-02-11] 144BE5B367347B8260D6D023DB24801DB9EFECF5 uid [ ultimativ ] Mike Kuketz <mike@kuketz.de> uid [ ultimativ ] Mike Kuketz <info@kuketz-security.de> uid [ ultimativ ] Mike Kuketz <webmaster@kuketz-blog.de> sub rsa4096 2014-03-20 [E] [verfällt: 2023-02-11] sub rsa4096 2019-06-05 [A] [verfällt: 2023-02-11]
Prima. Der Import via WKD funktioniert!
Alternativ könnt ihr ebenfalls den WKD-Checker benutzen, um zu prüfen, ob euer öffentlicher Schlüssel via WKD beziehbar ist.
4. Fazit
Das Auffinden von Schlüsseln via WKD ist einfach, elegant und praktisch gelöst – die Einrichtung ist fix erledigt. Jeder, der verschlüsselte E-Mails via PGP bzw. GnuPG austauscht und eine eigene Domain besitzt, sollte WKD einrichten. Damit macht ihr es eurem Gegenüber so einfach wie möglich, mit euch eine sichere Kommunikation aufzubauen. Clients wie Thunderbird/Enigmail prüfen noch während des Verfassens der E-Mail, ob ein Schlüssel via WKD beziehbar ist. Sofern dies zutrifft, wird die E-Mail auf Wunsch bzw. je nach Einstellung ohne manuellen Eingriff direkt mit dem korrekten Schlüssel verschlüsselt. Fake-Keys gehören damit der Vergangenheit an.
Einrichten. Jetzt!
Bildquellen:
Cloud: Eucalyp from www.flaticon.com is licensed by CC 3.0 BY
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
27 Ergänzungen zu “GnuPG: Web Key Directory (WKD) einrichten”
Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
Habe ich gleich mal bei mir umgesetzt, nur finde ich es komisch wenn ich über Windows (gpg4win) den Key abrufen will, erhalte ich nur einen Fehler.
gpg: Fehler beim automatischen holen von `webmaster@kuketz-blog.de' über `WKD': Fatale "Alert" Nachricht erhalten
gpg: error reading key: Fatale "Alert" Nachricht erhalten
und es über mein Linuxserver problemlos funktioniert.
Weißt du vilt. woran dies liegen kann?
Nein. Habe auch kein gpg4win zum Testen da. Eventuell gibt es einen Debug-Modus, der mehr Infos ausspuckt?
Habe nun geschaut und beim dirmngr im debug-log gefunden dass der TLS handshake fehlschlägt, scheint seit 2016/17 ein Problem zu sein.
Hallo Mike,
bei meinem Hoster wurde beim Apache die Direktive
Header set Access-Control-Allow-Origin „*“
bei den 404er Seiten nicht gesetzt. Dadurch wurde der Test Not found keys also generate CORS headers nicht bestanden.
Die Lösung war ein always einzufügen:
Header always set Access-Control-Allow-Origin „*“
Tschüss,
Martin
Braucht man .well-known/openpgpkey/policy wirklich? Ich meine, daß es bei meinem Firmenserver nicht vorhanden ist, aber WKD trotzdem funktioniert.
Übrigens bieten die Provider mailbox.org und posteo auch WKD an. Man muß natürlich dann dem Anbieter vertrauen, daß sie den korrekten public key publizieren und nicht einzelnen oder allen Kontakten andere Keys unterschieben.
Jetzt fehlt eigentlich nur noch ein XMPP-Client, der WKD unterstützt…
Ja, die Policy-Datei braucht man wirklich. Ursprünglich nicht, aber nach der Überarbeitung des Protokolls schon.
Hallo Mike et al.,
vielen Dank für die gute Anleitung! Die oben angegebene Apache-Config kann evtl. noch zwei Änderungen vertragen:
1. Sollte ggf. im -Block der absolute (Dateisystem-)Pfad angegeben werden, also z.B. „/var/www/sites/www.kuketz-blog/…“. Relative (URL-)Pfade werden im Apache, wie ihr wisst, mit -Blöcken definiert.
2. Der Hinweis von Martin ist korrekt. Ohne always erhalten nur gefundene Schlüssel den CORS-Header. Nicht gefundene (404) kommen ohne an. Meine Config sieht jetzt so aus:
# Web Key Directory
# See: https://www.kuketz-blog.de/gnupg-web-key-directory-wkd-einrichten/
Header always set Access-Control-Allow-Origin „*“
ForceType application/octet-stream
OK danke. Ich passe es später an.
Hallo,
hat jemand vielleicht eine Konfiguration für lighttpd zur Hand?
Vielen Dank schon mal!
Scheinbar bin ich blind (oder das Redesign von mailbox.org nicht ganz so gelungen…): kann mir jemand erklären, wie ich diese Funktion mit einem normalen Account bei mailbox.org nutze. Ich habe keine eigene Domain hinterlegt.
Danke im Voraus.
Soweit ich mich erinnere wollte mailbox.org WKD in 2019/Q2 implementieren. Kann auch sein, dass es noch gar nicht verfügbar ist.
Da der Hash nur über den „username“ der Email-Adresse gebildet wird, ist er für mehrere Identitäten gleich (in meinem Fall erfasst der identische Hash meine Mail-Adresse für qumran.org und izzysoft.de im gleichen Schlüssel). Er ist aber auch gleich, wenn man mehrere Schlüsselpaare für die gleiche Mail-Adresse erstellt hat (z. B. durch „Upgrade“ von 1024bit auf 4096bit, oder weil man einen Schlüssel „revoken“ musste). Für diesen Fall sollte man im Auge behalten, dass „WKD Retrieval“ nur die ersten 5 Treffer mitnimmt:
Auch wenn es unwahrscheinlich ist, dass jemand mehr als 5 Schlüssel auf die gleiche Mail-Adresse ausgestellt hat, ist es nicht unmöglich. Man sollte in diesem Fall beim Export zumindest „deprecated keys“ ausschließen („expired and revoked keys“ werden, wenn ich das richtig verstanden habe, standardmäßig ausgeblendet – sofern man nicht –list-options show-unusable-uids,show-unusable-subkeys verwendet). Einen Parameter dafür konnte ich nicht finden; sollte es wirklich jemand brauchen: Alle exportieren, in einen temporären Keyring importieren, die nicht gewünschten daraus löschen, und dann von dort exportieren sollte funktionieren.
Funktioniert leider nicht mit einer Subdomain
Wenn die Subdomain dir gehört, dann ja auch die Domain selbst. Warum nimmst du nicht einfach deine Domain?
Auf dem Server, auf dem die Domain gehostet wird kann ich dies leider nicht machen
Übrigens: Wer noch GPG < 2.1.12 einsetzt (welches noch kein WKD beherrscht – betroffen sind u.a. xUbuntu 16.04, Linux Mint 18.x), findet im GnuPG Wiki Hilfestellung in Form eines Python-Skriptes, das die benötigte Funktionalität „nachrüstet“. Das Skript dort ist für Python 2; für Python 3 findet sich das äquivalente Skript bei GitLab. Dank des im Artikel ebenfalls angehängten Makefile lässt sich der Prozess gut automatisieren:
* IDs der gewünschten Schlüssel in replacekeys.txt speichern (1 pro Zeile)
* Im Makefile die Variablen anpassen
* Mit make hu die Schlüssel-Exporte erzeugen
* Mit make dry-run schauen, was passiert
* Oder gleich mit make all Exporte erzeugen und zum Server synchronisieren
—-
Mike: Was meinst Du zu Attacks on GnuPG’s Web Key Directory? Du schreibst ja u. a. selbst im Artikel:
Das passiert generell, ohne dass der User informiert wird. Und zwar nicht nur, wenn er Dir schreibt. Es erfolgt also für jede Mail-Adresse ein „Ping“ an den entsprechenden Server, der somit die IP des Verfassers mitgeteilt bekommt – unabhängig davon, ob die Mail letztendlich verschickt wird oder nicht. Der Enigmail-Autor will das auch nicht ändern (z. B. Lookup erst bei Betätigung des „Senden“ Buttons). Und das war jetzt der harmlose Punkt.
Einige der Risiken wurden mittlerweise „eingeschränkt“; so bezieht sich mein obiges We limit the number of keys _received_ from the WKD to 5. beispielsweise auf die Denial-of-Service attack on keyring (flooding mit hunderten von Schlüsseln). Magst Du vielleicht die „Conclusion“ des verlinkten Artikels noch grob in den Deinigen übernehmen?
Eine Frage; muss es wirklich über die www subdomain gehen oder könte es auch https://kuketz-blog.de/.well_known/… sein?
Muss man nicht, das ist nur ein Beispiel. https://kuketz-blog.de/.well_known/* würde ebenfalls funktionieren.
De facto ist das auch, wo der GPG Client zuerst nachschaut (zumindest nach meiner Beobachtung). Ich bin eigentlich sogar davon ausgegangen, dass die Auflösung über die „Haupt-Domain” auf jeden Fall funktionieren muss (und ggf. auf etwas anderes, wie die „www.“ Subdomain) umleiten kann. Habe allerdings die Specs nicht studiert ;)
Nachdem ich einen Draft der Specs gefunden habe, bestätigt sich dies. Abschnitt 3.1 Key Discovery beschreibt die Bildung der URL so: „https://“ + Domain-Part der Mail-Adresse + „/.well-known/openpgpkey/hu/“ + $hash – am Beispiel user@example.com: „https://example.com/.well-known/openpgpkey/hu/{user-hash}“. Eine „www“ Subdomain wird nicht genannt. Also muss die Haupt-Domain per „https://“ erreichbar sein und kann weiterleiten.
(PS: Sollte der Draft-Link nicht mehr funktionieren, einfach mal die Nummer am Ende hochzählen. Hatte zuvor die „01“ per Searx gefunden und einen 404 bekommen – die „06“ tat zumindest gerade eben.)
Nach der neusten Version des Drafts darf es nicht die „www“ Subdomain sein, sondern der Key muss entweder unter der „openpgpkey“ Subdomain oder ganz ohne Subdomain zu finden sein.
Es kann natürlich sein, dass du deine Domain ohne Subdomain auf die „www“ Subdomain umleitest dann würde das auch funktionieren.
Mike, könntest Du bitte den Text im Artikel noch entsprechend ergänzen? Die „openpgpkey” Subdomain (openpgpkey.example.com) ist nicht zwingend notwendig. Es genügt auch, wenn im DNS ein Eintrag (A Record oder C Name) für die „Basis-Domain“ (example.com) existiert, und die entsprechende Domain auf den passenden Webserver verweist, welcher korrekt mit Zertifikat versehen antwortet (ggf. mit Redirect, aber auch das ist optional). Im Artikel benennst Du zwar beide Methoden (Direct, Advanced) – es liest sich aber so, als müsse man den Advanced Mode zwingend konfigurieren.
Die „Einleitung” in Punkt 3 ist auch unstimmig: Als Muster nennst Du
und als dazu (nicht) passendes Beispiel für webmaster@kuketz-blog.de
Das Beispiel ist falsch (das „www.“ muss laut Spec raus – es funktioniert bei Dir nur aufgrund eines Redirects, den Du nicht erwähnt hast).
Punkt 3.6 würde ich einleitend ergänzen mit dem Hinweis, dass „bisheriges“ (vor Punkt 3.6) bereits ausreicht und den Direct Modus umsetzt – während man im Punkt 3.6 selbst beschriebenes nur optional benötigt, wenn man den Advanced Modus umsetzen möchte. Welches von beiden Du ggf. empfehlen möchtest, könnte da natürlich ebenfalls stehen ;)
Das „www“ habe ich jetzt überall rausgenommen, das war verwirrend.
Den TXT DNS-Record würde ich aber genau so drinlassen, gerade wenn man die Direct-Methode verwendet. Sonst läuft man eventuell in diesen Fehler hier rein:
Quelle: OpenPGP Web Key Directory – draft-koch-openpgp-webkey-service-08 Unterpunkt 3.1 Key Discovery
Weil sonst fragt ein Client zunächst mit der Advanced-Methode an und findet allerdings nichts unter https://openpgpkey.kuketz-blog.de/*. Diese Domain ist weder angelegt, noch ein TLS-Cert dafür ausgestellt. Der Webserver antwortet in meinem Fall dann mit einem Self-Signed-Cert, dass auf „webserver.kuketz.de“ ausgestellt ist. Anders mit dem zusätzlichen TXT-Record: Dann wird der Fallback auf die Direct-Methode ausgelöst.
Danke, Mike!
Dennoch: Nach Deiner Formulierung („Bei der Verwendung der Direct-Methode muss allerdings zusätzlich ein TXT-Record im DNS hinterlegt werden…”) dürftest Du meinen Key via WKD nicht abrufen können, da ich die Subdomain „openpgpkeys“ nicht im DNS hinterlegt habe. Es funktioniert jedoch (zumindest mit GPG 2.2.13) – da ich eben kein Wildcard-DNS für meine Subdomains betreibe. Magst Du diese Einschränkung im Text nicht auch machen? Wie verbreitet ist denn „Wildcard DNS“? Ich muss ehrlich gestehen, davon bislang nicht einmal etwas gewusst zu haben (ganz zu schweigen, wie man so etwas einrichten würde).
Für eine kleine Domain mit einem einzelnen GPG Key fände ich die zusätzliche Subdomain ein wenig „Over-Engineering” – insbesondere, wenn man sie nicht zwingend benötigt.
Ich kenne deine Domain nicht wo du hinterlegt hast, aber einige Implementierungen haben Probleme, wenn die Direct-Methode verwendet wird und kein TXT-Eintrag hinterlegt ist, der dies kenntlich macht.
Kannst du ja selbst mal testen: Was für ein Zertifikat erhälst du, wenn du https://openpgpkey.deineDomain.de aufrufst? Ist es ein gültiges Zertifikat? Wenn nicht, dann wird die Prüfung bei einigen Clients fehlschlagen und der TXT-Eintrag wird benötigt, damit der Fallback auf den Direct-Mode passiert – soweit ich das korrekt verstanden habe.
Da würde ich gar keine Antwort bekommen – außer ein NXNODOMAIN („Server not found“ im Firefox). Keine Auflösung – kein (ungültiges) Zertifikat :)
(emphasis mine) Der TXT Eintrag dient nur dazu sicherzustellen, dass vom DNS Server kein A Record oder CNAME zurückgeliefert wird.. Ich nutze kein Wildcard DNS – daher passiert das bei mir ohnehin nicht (sofern ich nicht explizit einen Eintrag für „openpgpkey“ hinzufüge).
Ergo: Löst „openpgpkey.{Domain}“ im DNS nicht auf, kann man sich das sparen. Löst es auf, braucht man diesen (leeren) TXT Eintrag – oder der Webserver hört auf den Namen und handelt entsprechend (gültiges Zertifikat plus WKD oder Redirect).
(Hervorhebung wieder von mir). Dürfte auf die wenigsten von uns zutreffen. Die Flexibilität wird hier dadurch erreicht, dass die URL leicht anders aufgebaut ist – und ein einziger (virtual) Server mehrere Domains bedienen kann:
https://openpgpkey.{Domain}/.well-known/openpgpkey/{lowercase-domain}/hu/{hash}?l={user-local-part}
https://openpgpkey.kuketz-blog.de/.well-known/openpgpkey/kuketz-blog.de/hu/{hash}?l=webmaster
Bei allen anderen Domans, für die Du unter kuketz-blog.de ein WKD bereitstellen willst, ist „openpgpkey“ dann ein CNAME für „openpgpkey.kuketz-blog.de“ – mit korrespondierendem Verzeichnis /.well-known/openpgpkey/{andere.domain}/hu/ bei „openpgpkey.kuketz-blog.de“ – wenn ich das jetzt richtig verstanden habe. Was ich nicht verstanden habe ist, wofür das „l={user-local-part}“ an die URL angehängt wird (und ob der Webserver das irgendwie auswerten soll – außer fürs Logging).
(„with without“ steht dort wirklich in Draft 8).
So ist es nun korrekt – jetzt haben wir es.
Ich habe den Abschnitt nochmal vollständig überarbeitet.
Danke Mike – jetzt ist es definitiv klarer :)
PS: würde ein Client bei gültigem Zertifikat auf openpgpkey.{domain} automatisch vom Advanced Mode ausgehen? In dem Fall müsste man für Direct Mode definitiv den TXT Eintrag erstellen, da die Keys sonst nicht gefunden werden – oder die Verzeichnis-Sturktur um die zusätzliche Ebene für {domain} im Advanced Mode ergänzen (siehe meinen vorigen Kommentar).