GnuPG: Web Key Directory (WKD) einrichten

1. SchlüsselfälscherWeb Key Directory

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:

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.

Mitmachen ➡

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 Domain openpgpkey.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

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

27 Ergänzungen zu “GnuPG: Web Key Directory (WKD) einrichten”

  1. Comment Avatar Daniel sagt:

    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?

  2. Comment Avatar Martin sagt:

    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

  3. Comment Avatar Martin sagt:

    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…

  4. Comment Avatar ulif sagt:

    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

  5. Comment Avatar Rick sagt:

    Hallo,

    hat jemand vielleicht eine Konfiguration für lighttpd zur Hand?

    Vielen Dank schon mal!

  6. Comment Avatar Anonymous sagt:

    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.

  7. Comment Avatar Izzy sagt:

    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:

    We limit the number of keys _received_ from the WKD to 5. In fact there should be only one key but some sites want to store a few expired keys there also. gpg’s key selection will later figure out which key to use. Note that for WKD we always return the fingerprint of the first imported key.

    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.

  8. Comment Avatar Steven sagt:

    Funktioniert leider nicht mit einer Subdomain

  9. Comment Avatar Izzy sagt:

    Ü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:

    Beim Verfassen an die E-Mail-Adresse … wird Thunderbird/Enigmail automatisch versuchen, den öffentlichen Schlüssel via WKD zu beziehen.

    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?

    Using GnuPG’s WKD feature with versions before 2.2.12 can be a serious security risk, in particular in combination with Thunderbird/Enigmail. In a worst case scenario the attacker can …

  10. Comment Avatar Horscht sagt:

    Eine Frage; muss es wirklich über die www subdomain gehen oder könte es auch https://kuketz-blog.de/.well_known/… sein?

    • Comment Avatar Mike Kuketz sagt:

      Muss man nicht, das ist nur ein Beispiel. https://kuketz-blog.de/.well_known/* würde ebenfalls funktionieren.

    • Comment Avatar Izzy sagt:

      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.)

    • Comment Avatar dampfwalze sagt:

      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.

      • Comment Avatar Izzy sagt:

        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

        https://Domain/.well-known/openpgpkey/hu/Hash-Wert-Email-Prefix

        und als dazu (nicht) passendes Beispiel für webmaster@kuketz-blog.de

        https://www.kuketz-blog.de/.well-known/openpgpkey/hu/kd39y8fkyw5j8uubuicshffo9hhodk4j

        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 ;)

        • Comment Avatar Mike Kuketz sagt:

          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:

          Sites which do not use the advanced method but employ wildcard DNS for their sub-domains MUST make sure that the „openpgpkey“ sub-domain is not subject to the wildcarding. This can be done by inserting an empty TXT RR for this sub-domain.

          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.

          • Comment Avatar Izzy sagt:

            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.

          • Comment Avatar Mike Kuketz sagt:

            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.

          • Comment Avatar Izzy sagt:

            Da würde ich gar keine Antwort bekommen – außer ein NXNODOMAIN („Server not found“ im Firefox). Keine Auflösung – kein (ungültiges) Zertifikat :)

            Sites which do not use the advanced method but employ wildcard DNS
            for their sub-domains
            MUST make sure that the „openpgpkey“ sub-domain
            is not subject to the wildcarding. This can be done by inserting an
            empty TXT RR for this sub-domain.

            (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).

            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.

            (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).

            The direct method is kept for backward compatibility and to allow providing a Web Key Directory even with without DNS change requirements.

            („with without“ steht dort wirklich in Draft 8).

          • Comment Avatar Mike Kuketz sagt:

            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).

            So ist es nun korrekt – jetzt haben wir es.

            Ich habe den Abschnitt nochmal vollständig überarbeitet.

          • Comment Avatar Izzy sagt:

            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).

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle 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-Forum

Abschließ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.