Déployer un service d’annuaire de clefs OpenPGP

Quand Bob veut obtenir la clef d’Alice à partir de son adresse e-mail (alice@example), il construit une URL avec la forme suivante :

https://openpgpkey.example.org/.well-known/openpgpkey/example.org/hu/↪
kei1q4tipxxu1yj79k9kfukdhfy631xe?l=alice

La chaîne kei1q4tipxxu1yj79k9kfukdhfy631xe est le condensat SHA-1^[1] de la partie locale de l’adresse d’Alice (alice donc, dans notre exemple), encodé en Z-Base32.

	Note
	Vous pouvez utiliser la commande suivante pour calculer le condensat : $ echo -n alice | openssl dgst -sha1 -binary | zbase32 kei1q4tipxxu1yj79k9kfukdhfy631xe (bien sûr, en « situation réelle » vous n’avez jamais à le faire, c’est votre client de messagerie qui s’en charge.)

Le serveur openpgpkey.example.org doit répondre à une requête HTTP sur cette URL en renvoyant une copie de la clef d’Alice, sous la forme d’une clef publique transférable (Transferable Public Key ou TPK) conforme au standard OpenPGP. La clef reçue est directement importable dans le trousseau public de Bob.

Notez la répétition du nom de domaine example.org dans l’URL ci-dessus (une fois dans le nom d’hôte, une fois dans le chemin de la ressource). L’URL est construite ainsi afin de faciliter le déploiement d’un annuaire WKD qui gérerait plusieurs domaines. Dans le même ordre d’idée, le composant openpgpkey du nom d’hôte, qui semble redondant avec la ressource « bien connue » .well-known/openpgpkey, offre un niveau d’indirection qui permet d’héberger l’annuaire sur une autre machine que celle située derrière le nom example.org.

	Note
	Les premières versions du brouillon WKD utilisaient, pour fournir ce niveau d’indirection, un enregistrement SRV plutôt qu’un nom d’hôte avec un composant fixé. Malheureusement, cela posait trop de problèmes aux développeurs Javascript, ce langage (ou plutôt son environnement d’exécution, dans les navigateurs) n’offrant pas de fonctionnalités de résolution DNS digne de ce nom.

Si une indirection n’est pas nécessaire, l’opérateur de example.org peut diffuser la clef d’Alice sous une URL légèrement plus simple, qu’on appelle la méthode directe (par opposition à l’URL précédente, qui représente la méthode avancée) :

https://example.org/.well-known/openpgpkey/hu/↪
kei1q4tipxxu1yj79k9kfukdhfy631xe?l=alice

Les opérateurs déployant WKD sont libres de choisir de supporter la méthode directe ou la méthode avancée, selon qu’ils ont besoin du niveau d’indirection offert par la méthode avancée ou non. Les clients eux doivent essayer en premier lieu la méthode avancée, puis se rabattre sur la méthode directe si le sous-domaine openpgpkey n’existe pas.

Pour déposer sa clef publique dans l’annuaire WKD de son fournisseur de messagerie, Alice doit suivre les étapes suivantes.

Premièrement, elle doit demander à son fournisseur l’adresse de soumission, par une requête HTTP sur

https://openpgpkey.example.org/.well-known/openpgpkey/example.org/↪
submission-address

(méthode « avancée ») ou bien (si openpgpkey.example.org n’existe pas) sur

https://example.org/.well-known/openpgpkey/submission-address

(méthode « directe »). Le serveur répond par une seule ligne contenant l’adresse e-mail à laquelle Alice devra envoyer sa clef.

Deuxièmement, Alice doit obtenir la clef publique de l’annuaire WKD, qu’elle devra utiliser pour chiffrer son message. Elle utilise pour ça le protocole Web Key Directory décrit en section précédente, sur l’adresse de soumission qu’elle vient de recevoir.

Troisièmement, Alice envoie un message à l’adresse de soumission indiqué, chiffré avec la clef publique qu’elle vient d’obtenir et contenant une copie de sa propre clef publique. Elle reçoit alors une demande de confirmation, envoyé à l’adresse alice@example.org et chiffré avec la clef publique qu’elle vient d’envoyer.

Quatrièmement, Alice déchiffre la demande de confirmation, dans laquelle elle trouve un nonce. Elle répond à la demande de confirmation en renvoyant le nonce. Ce faisant, elle prouve à l’opérateur de l’annuaire i) qu’elle contrôle l’adresse e-mail (puisqu’elle a reçu la demande de confirmation) et ii) qu’elle possède la clef privée correspondant à la clef publique qu’elle a soumise à l’annuaire (puisqu’elle a pu déchiffrer la demande de confirmation et en extraire le nonce). Conséquemment, l’opérateur accepte de publier sa clef.

Commencez par installer GnuPG et gpg-wks-server sur votre serveur, puis créez un compte utilisateur pour le service d’avitaillement, qu’on appelera ici wks :

# groupadd --system wks
# useradd --comment "Web Key Service" --home-dir "/var/lib/gnupg/wks ↪
  -g wks --no-user-group --system --shell /bin/bash

Créez ensuite le dossier qui abritera l’annuaire, /var/lib/gnupg/wks. Notez qu’il s’agit là du dossier par défaut utilisé par gpg-wks-server ; vous êtes libres de choisir un autre dossier, mais dans ce cas vous devrez rajouter l’option -C DOSSIER à toutes les invocations de gpg-wks-server ci-dessous. Où que vous décidiez de créer le dossier, donnez-le à l’utilisateur wks et assurez-vous que le « reste du monde » n’y a pas accès en lecture.

# mkdir -p /var/lib/gnupg/wks
# chown wks:wks /var/lib/gnupg/wks
# chmod 0751 /var/lib/gnupg/wks

Les commandes suivantes sont à faire sous le compte wks. Créez dans le dossier /var/lib/gnupg/wks un sous-dossier pour chacun de vos domaines dont vous voulez publier les clefs et initialisez l’annuaire :

$ mkdir example.org
$ gpg-wks-server --list-domains
gpg-wks-server: domain example.org: subdir 'pending' created
gpg-wks-server: domain example.org: subdir 'hu' created
gpg-wks-server: domain example.org: submission address not configured
example.org

Décidez de ce que sera l’adresse de soumission. Ici, nous choisirons wks-submission@example.org. Si vous hébergez plusieurs domaines, chaque domaine peut avoir sa propre adresse de soumission, mais vous pouvez aussi utiliser une seule et même adresse pour tous les domaines de votre annuaire.

Créez la clef associée à l’adresse de soumission :

$ gpg --batch --passphrase '' --quick-gen-key wks-submission@example.org

Notez que la clef privée n’a pas de phrase de passe, puisqu’elle doit pouvoir être utilisée de manière autonome. Notez aussi qu’elle expirera deux ans après sa création, il vous appartiendra de penser à repousser sa date d’expiration avant l’échéance. Pour demander dès le départ que la clef n’expire jamais, vous pouvez ajouter les mots-clefs default default never à la fin de la commande ci-dessus (les deux premiers mots-clefs demandent à GnuPG d’utiliser les algorithmes et le profil d’utilisation par défaut, le dernier demande que la clef générée n’expire jamais).

Finalement, publiez la clef du compte de soumission dans l’annuaire puis publiez l’adresse de soumission elle-même :

$ gpg -k wks-submission@example.org
pub   rsa2048 2020-05-29 [SC] [expires: 2022-05-29]
      0D2652F979E05D919B64C808AAB89C4C439B2F67
uid           [ultimate] wks-submission@example.org
sub   rsa2048 2020-05-29 [E]

$ gpg-wks-server --install-key 0D2652F979E05D919B64C808AAB89C4C439B2F67 wks-submission@example.org
gpg-wks-server: key 0D2652F979E05D919B64C808AAB89C4C439B2F67 published for ↪
wks-submission@example.org

$ echo wks-submission@example.org > example.org/submission-address

L’annuaire étant en place, il faut maintenant configurer le serveur de messagerie afin que les messages envoyés à l’adresse de soumission choisie dans la section précédente (wks-submission@example.org) soit passés au programme gpg-wks-server, appelé sous le compte utilisateur responsable de l’annuaire (wks).

Il y a bien sûr plusieurs façons de procéder, qui vont dépendre de votre serveur de messagerie et de sa configuration déjà existante. Il n’est pas possible de couvrir toutes les configurations possibles et en fin de compte je vous renvoie vers la documentation de votre logiciel serveur. Ce qui suit est à titre illustratif.

L’approche probablement la plus simple est de rediriger les messages envoyés à wks-submission@example.org vers le compte local wks, puis d’installer la règle Procmail suivante dans le fichier ~/.procmailrc du compte wks :

:0
|gpg-wks-server --receive --from wks-submission@example.org --send

La commande --receive instruit gpg-wks-server de lire le message qu’il reçoit sur son entrée standard et d’agir en fonction du contenu du message (si c’est une nouvelle soumission, envoyer une demande de confirmation ; si c’est une confirmation, vérifier qu’elle correspond à une soumission en cours et que le nonce est correct). L’option --send demande à ce que la réponse soit directement renvoyée au système de messagerie, via la commande /usr/sbin/sendmail.

Une autre configuration possible avec Postfix est d’avoir les lignes suivantes dans le main.cf :

virtual_alias_maps = hash:/etc/postfix/virtual
mailbox_command_maps = hash:/etc/postfix/local_commands

La première ligne installe une « table d’alias virtuels », permettant entre autres choses de rediriger une adresse virtuelle vers un compte local. La seconde ligne installe une table permettant de spécifier la commande de livraison à exécuter pour un compte local donné. On ajoutera la ligne suivante à la table /etc/postfix/virtual :

wks-submission@example.org  wks

et la ligne suivante à la table /etc/postfix/local_commands :

wks  gpg-wks-server --receive --from wks-submission@example.org --send

On n’oubliera pas bien sûr d’exécuter postmap sur les tables après édition.

La dernière chose à faire est d’installer une tâche cron pour purger régulièrement les soumissions non confirmées :

42 3 * * * gpg-wks-server --cron

Ajoutez cette tâche à la crontab de l’utilisateur wks. Modifiez la périodicité comme bon vous semble. À chaque invocation, gpg-wks-server --cron supprimera les soumissions non-confirmées vieilles de plus de trois jours.

L’annuaire est maintenant prêt et connecté au système de messagerie pour recevoir les soumissions de clefs, il ne reste plus qu’à le rendre accessible via le web.

En supposant i) que votre serveur web est sur la même machine que votre serveur mail, ii) que votre serveur est Apache httpd, et iii) que vous avez opté pour le format d’URL dit direct, alors il devrait vous suffire d’ajouter les lignes suivantes dans la configuration du virtual host servant le domaine example.org :

Alias /.well-known/openpgpkey /var/lib/gnupg/wks/example.org
        <Directory /var/lib/gnupg/wks/example.org>
  Require all granted
  </Directory>

Si vous avez plusieurs domaines, vous pouvez soit ajouter les lignes ci-dessus dans la configuration du virtual host de chaque domaine, soit opter pour le format d’URL avancé. Dans ce dernier cas, créez un nouveau virtual host qui sera dédié à l’annuaire et qui répondra au sous-domaine openpgpkey de chacun de vos domaine :

ServerName openpgpkey.example.org
ServerAlias openpgpkey.example.com
ServerAlias openpgpkey.example.net

Alias /.well-known/openpgpkey /var/lib/gnupg/wks
<Directory /var/lib/gnupg/wks>
  Require all granted
</Directory>

Notez que les requêtes WKD se font systématiquement via HTTPS, donc votre nouvel hôte doit avoir une configuration TLS correcte et un certificat valable pour tous vos domaines openpgpkey.*.

Si vous utilisez Thunderbird et Enigmail, vous pouvez tester la publication de votre clef dans votre annuaire en ouvrant le « gestionnaire de clefs » (Key Management). Sélectionnez votre clef, puis lancez la commande Upload to your provider’s Web Key Directory dans le menu Keyserver.

Enigmail se chargera alors d’envoyer le message de soumission de clef et vous devriez rapidement recevoir sur votre adresse un message provenant de wks-submission@example.org. Ouvrez ce message, et Enigmail reconnaîtra qu’il s’agit d’une demande de confirmation et vous demandera si vous souhaitez confirmer ou non la publication de votre clef. Acceptez et vous recevrez un nouveau message vous annonçant que votre clef a bien été publiée dans l’annuaire.

Si vous utilisez un client de messagerie sans support natif pour le protocole WKD Update Protocol, vous pouvez utiliser l’outil gpg-wks-client fourni par GnuPG. Notez que cet outil n’est pas forcément dans le PATH de votre interpréteur de commandes, il est par défaut installé dans /usr/libexec (parce qu’il n’est pas vraiment conçu pour être appelé directement par l’utilisateur, mais plutôt par les clients de messagerie).

La commande suivante permet de tester que le service d’annuaire pour example.org est bel et bien disponible :

$ /usr/libexec/gpg-wks-client --supported alice@example.org

Si la commande renvoie une valeur différente de zéro, inutile d’aller plus loin, il y a un problème avec votre annuaire, probablement dans la configuration du serveur web.

Créez ensuite le message de soumission :

$ /usr/libexec/gpg-wks-client 7685DC4214D727BB011BD6B754B4CC7749CAE7C3 ↪
          alice@example.org > submit-msg

Le fichier submit-msg contient le message de soumission prêt à être envoyé via votre client de messagerie habituel.

	Note
	Si vous avez un programme /usr/sbin/sendmail fonctionnel sur votre machine (qu’il s’agisse réellement de Sendmail ou d’un programme utilisant la même interface, comme msmtp par exemple), vous pouvez demander à gpg-wks-client d’envoyer le message lui-même avec l’option --send.

Lorsque vous recevrez la demande de confirmation dans votre client de messagerie, déchiffrez-là et sauvez-là dans un fichier, puis passez ce fichier à gpg-wks-client pour créer le message de confirmation :

$ /usr/libexec/gpg-wks-client --read < confirm-request > confirm-msg

Comme à l’étape précédente, envoyez le fichier confirm-msg via votre client habituel, ou utilisez l’option --send pour laisser gpg-wks-client s’en charger.