67. pepsi-keydisc

Den öffentlichen Schlüssel oder das Zertifikat eines Korrespondenten finden und festhalten, wie viel seine Quelle wert ist.

67.1. Rolle

pepsi-keydisc ist die Schlüssel-Entdeckungs-Schicht: Zu einer E-Mail-Adresse findet es den OpenPGP-Schlüssel oder das S/MIME-Zertifikat des Korrespondenten, hält fest, woher es stammt und ob die Abfrage DNSSEC-validiert war, und speichert es in pepsi.peer_key zwischen. Es ist keine Stage. Es verbindet sich über [pepsi-postgres] und wird vollständig durch [pepsi-keydiscovery] konfiguriert.

Die Entdeckung ist asynchron und außerhalb der Stages. Eine Stage, die einen Schlüssel braucht, den sie nicht im Cache hat, betreibt keine Netzwerk-E/A: Sie committet die bereits geleistete Arbeit, pausiert die Nachricht und reiht eine Anfrage in pepsi.key_request ein; eine Entdeckungsinstanz beantwortet die Anfrage und gibt im selben Round-Trip, in dem sie den Schlüssel speichert, jede an dieser Adresse geparkte Nachricht frei. So wartet nie ein Stage-Worker auf einen Keyserver, hundert Nachrichten an einen Korrespondenten kosten eine Abfrage, und eine Anfrage, die sich ohne Schlüssel erledigt, gibt ihre Wartenden ebenso frei — die Dienste finden Schlüssel, die Stages entscheiden über Mail. Referenz: pepsi-keydisc(1).

Das Kapitel Schlüsselverwaltung erklärt die Vertrauensrangfolge, nach der diese Ergebnisse beurteilt werden, und wie sich die Entdeckungsschicht zum Schlüsselspeicher als Ganzem verhält.

67.2. Funktionen

  • Ein Prozess je Methode (pepsi-keydisc serve <method>), aus der systemd-Vorlage pepsi-keydisc@.service: @dane, @wkd-advanced, @wkd-direct, @vks und (in einem Build mit dem Cargo-Feature ldap) @ldap. SOURCES verwendet standardmäßig die ersten vier. Ein hängendes LDAP-Bind kann WKD nicht aufhalten, und eine Methode abzuschalten ist systemctl disable pepsi-keydisc@ldap. Eine Instanz, deren Methode in [pepsi-keydiscovery] SOURCES fehlt, verweigert den Start, weil die Stopp-Regel nur auf die von SOURCES benannten Methoden wartet.

  • Die beiden WKD-Methoden sind getrennte Ränge und laufen daher als getrennte Instanzen gleichzeitig statt als Rückfallkette — „direct“ nur „falls advanced fehlschlägt“ auszuführen, würde die schwächere Antwort immer dann annehmen, wenn die stärkere bloß langsam war.

  • DANE ist an das AD-Bit gebunden. OPENPGPKEY (RFC 7929) und SMIMEA (RFC 8162) werden ohne das DNSSEC-AD-Bit des Resolvers rundweg abgelehnt: Eine unvalidierte DNS-Antwort ist keine schwächere Antwort, sie ist keine Antwort.

  • Ein gehärteter Abruf für WKD und VKS: nur HTTPS, Zertifikatsvalidierung ohne unsicheren Modus, höchstens eine HTTPS-zu-HTTPS-Umleitung zum selben Host, Verweigerung von Verbindungen zu Loopback-/privaten/Link-Local-Adressen, eine während des Streamens durchgesetzte Byte-Obergrenze, eine Frist für jeden Schritt und IDNA-A-Label-Umwandlung. Ein zurückgegebener Schlüssel, dessen User-ID die abgefragte Adresse nicht benennt, wird verworfen.

  • probe ADDRESS — führt den ganzen Fan-out für eine Adresse aus und gibt aus, was jede Methode gefunden hat, ohne etwas zu speichern (nicht einmal einen Negativ-Cache-Eintrag), als Diagnose.

  • Die engste Datenbankrolle der Installation, eingerichtet von pepsi-setup: peer_key, key_request, die keydisc_*-Funktionen und auf pepsi.workqueue nur SELECT plus ein UPDATE (status, timeout) auf Spaltenebene — genug, um eine geparkte Nachricht zu wecken, und nicht mehr. Es läuft unter seinem eigenen Konto pepsi-keydisc ohne setuid- oder setgid-Bit.

67.3. Siehe auch

pepsi-keys, pepsi-setup, Schlüsselverwaltung, RFC-Index, pepsi-keydisc(1), pepsi-keys(1), pepsi.conf(5).