67. pepsi-keydisc

Trouver la clé publique ou le certificat d’un correspondant, et noter ce que vaut sa source.

67.1. Rôle

pepsi-keydisc est la couche de découverte de clés : à partir d’une adresse e-mail, il trouve la clé OpenPGP ou le certificat S/MIME du correspondant, note sa provenance et si la résolution a été validée par DNSSEC, et le met en cache dans pepsi.peer_key. Ce n’est pas une étape. Il se connecte via [pepsi-postgres] et se configure entièrement par [pepsi-keydiscovery].

La découverte est asynchrone et hors des étapes. Une étape qui a besoin d’une clé absente du cache ne fait aucune E/S réseau : elle valide le travail déjà accompli, met le message en pause et met une demande en file dans pepsi.key_request ; une instance de découverte répond à la demande et, dans le même aller-retour qui stocke la clé, libère chaque message garé sur cette adresse. Ainsi aucun worker d’étape n’attend jamais un serveur de clés, cent messages vers un même correspondant coûtent une seule résolution, et une demande qui se conclut sans clé libère ses messages en attente tout autant — les services trouvent les clés, les étapes décident du courrier. Référence : pepsi-keydisc(1).

Le chapitre Gestion des clés explique le classement de confiance selon lequel ces résultats sont jugés, et comment la couche de découverte se rapporte au magasin de clés dans son ensemble.

67.2. Fonctionnalités

  • Un processus par méthode (pepsi-keydisc serve <method>), depuis le modèle systemd pepsi-keydisc@.service : @dane, @wkd-advanced, @wkd-direct, @vks et (dans un build avec la fonctionnalité Cargo ldap) @ldap. SOURCES prend par défaut les quatre premières. Un bind LDAP bloqué ne peut pas paralyser WKD, et désactiver une méthode se fait par systemctl disable pepsi-keydisc@ldap. Une instance dont la méthode est absente de [pepsi-keydiscovery] SOURCES refuse de démarrer, car la règle d’arrêt n’attend que les méthodes nommées par SOURCES.

  • Les deux méthodes WKD sont des rangs distincts, et donc des instances distinctes s’exécutent simultanément plutôt qu’en chaîne de repli — n’exécuter direct que « si advanced échoue » accepterait la réponse la plus faible chaque fois que la plus forte serait simplement lente.

  • DANE est conditionné par le bit AD. OPENPGPKEY (RFC 7929) et SMIMEA (RFC 8162) sont refusés d’emblée sans le bit AD DNSSEC du résolveur : une réponse DNS non validée n’est pas une réponse plus faible, c’est une absence de réponse.

  • Une récupération durcie pour WKD et VKS : HTTPS uniquement, validation de certificat sans mode non sécurisé, au plus une redirection HTTPS vers HTTPS et vers le même hôte, refus de se connecter aux adresses de boucle locale, privées ou lien-local, un plafond d’octets appliqué pendant le flux, une échéance à chaque étape, et conversion IDNA en A-label. Une clé renvoyée dont l’identifiant utilisateur ne nomme pas l’adresse interrogée est écartée.

  • probe ADDRESS — exécuter tout l’éventail pour une adresse et afficher ce que chaque méthode a trouvé, sans rien stocker (pas même une entrée de cache négatif), à titre de diagnostic.

  • Le rôle de base de données le plus étroit du déploiement, provisionné par pepsi-setup : peer_key, key_request, les fonctions keydisc_*, et sur pepsi.workqueue seulement SELECT plus un UPDATE (status, timeout) au niveau colonne — de quoi réveiller un message garé, et rien de plus. Il tourne sous son propre compte pepsi-keydisc, sans bit setuid ni setgid.

67.3. Voir aussi

pepsi-keys, pepsi-setup, Gestion des clés, Index des RFC, pepsi-keydisc(1), pepsi-keys(1), pepsi.conf(5).