66. pepsi-keys

Gérer le magasin de clés de bout en bout.

66.1. Rôle

pepsi-keys est l’outil de l’opérateur pour le magasin de clés de la cryptographie de bout en bout de Pepsi : pepsi.crypto_identity (les paires de clés des adresses que nous servons, moitié privée comprise et enveloppée au repos), pepsi.peer_key (les clés publiques et certificats mis en cache des correspondants distants) et pepsi.ca_trust (les certificats d’AC contre lesquels les chaînes S/MIME entrantes sont validées). Il se connecte via la section partagée [pepsi-postgres] et lit les options CRYPTO_* de [pepsi] ainsi que la section [pepsi-crypto]. Ce n’est pas une étape. Référence : pepsi-keys(1) ; la conception est expliquée dans Gestion des clés.

C’est l’un des binaires autonomes, hors de l’exécutable pepsi unifié, pour deux raisons : c’est le seul programme qui engendre du matériel de clé (le plier dedans lierait la génération de clés et la délivrance de certificats dans chaque worker d’étape), et un site peut l’installer setuid pour que les utilisateurs gèrent leurs propres identités — un bit qu’un binaire multi-appel partagé ne peut pas porter.

66.2. Fonctionnalités

  • identity list / show — quel matériel existe pour une adresse : protocole, usage, statut, s’il est le principal pour sa capacité, s’il est publié, si la moitié privée est présente, purgée ou n’a jamais été détenue (client pour la propre clé MUA de l’utilisateur, dont la moitié privée réside dans son client de messagerie), et — dans show — la garde, s’il s’agit de la face publique de l’adresse et son état sur le serveur de clés.

  • identity generate — créer du matériel de clé et le stocker. OpenPGP produit une clé transférable (Ed25519 par défaut, RSA en option) ; S/MIME produit un certificat de signature et un certificat de chiffrement, chacun auto-signé pour un usage immédiat, ou un seul certificat portant les deux usages de clé sous CRYPTO_SMIME_SHARED_KEY. --csr émet en outre une demande PKCS#10 sur chaque clé, de sorte qu’une véritable AC puisse délivrer un remplacement sans changer de clé.

  • identity import / export / csr — stocker du matériel engendré ailleurs (une clé publique OpenPGP importée sans --private est enregistrée comme la propre clé MUA de l’utilisateur), réécrire du matériel dans sa forme binaire propre (--pem pour X.509), ou construire une demande de certificat sur la clé existante d’une identité.

  • identity revoke / retire / forget-private — le cycle de vie. La révocation et le balayage périodique retire détruisent le matériel privé de signature et conservent le matériel de déchiffrement ; revoke --upload publie d’abord un certificat de révocation vers le serveur de clés, car cela doit se produire tant que la clé de signature existe encore. forget-private est la manière explicite et confirmée (-y pour sauter la question) de détruire une clé de déchiffrement.

  • identity set-primary / publish / unpublish / delete — choisir le matériel utilisé pour les nouveaux messages, inscrire ou retirer une adresse de la publication (publish peut aussi téléverser vers un serveur de clés), ou supprimer purement et simplement une ligne.

  • peer list / show / import / pin / unpin / refresh / prune / remove — les clés de pairs mises en cache. refresh revalide les clés qui existent déjà et n’en découvre jamais une pour une adresse qui n’en a aucune ; prune supprime les clés expirées et les demandes de découverte périmées (--dry-run pour regarder d’abord). show applique la règle de correspondance (une adresse exacte l’emporte toujours sur un repli *@domain saisi à la main) ; import stocke une clé avec la source manual, la seule source autorisée à nommer un domaine entier.

  • ca list / add / enable / disable / remove — les ancres de confiance S/MIME. Un certificat sans basicConstraints CA:TRUE est refusé, puisqu’aucune chaîne ne pourrait jamais s’y terminer. Être accepté ici n’est pas la même chose qu’être utilisable : les nameConstraints, pathLenConstraint et contraintes de politique propres à une ancre lient toute chaîne qui passe par elle (RFC 5937), et une AC portant une extension critique que Pepsi ne sait pas traiter est ignorée lors de la construction du chemin (RFC 5280 §4.2).

  • wrap rotate — ré-envelopper chaque clé privée stockée sous une nouvelle clé de chiffrement de clés, de façon incrémentale et avec --dry-run pour regarder d’abord.

  • dns — imprimer les enregistrements OPENPGPKEY (RFC 7929) et SMIMEA (RFC 8162) qui publient une adresse, sous les noms de propriétaire hachés que définissent ces normes. Cela ne vaut la peine d’être publié que dans une zone signée par DNSSEC, ce que la sortie indique.

66.3. Modèle de privilèges

Atteindre une clé privée exige deux choses gardées indépendamment : le rôle de base de données pepsi-crypto — le seul à qui la colonne crypto_identity.private_wrapped est accordée, tout autre rôle de service détenant un droit au niveau colonne qui l’omet — et la clé de chiffrement de clés, qui ne réside que dans secrets.d/pepsi-crypto.secret. Une base de données volée ne livre que du chiffré ; le secret seul ne livre rien.

pepsi-keys n’endosse ce rôle que pour la durée de chaque appel à la base : lancé en tant que root, il devient le compte (root n’a pas de rôle de base propre) et revient ensuite. L’authentification par pair de PostgreSQL se fonde sur l”uid effectif, non sur le gid, de sorte qu’un bit setgid accorderait le groupe qui garde le fragment de secret mais pas l’identité en base.

Le binaire est livré sans bit setuid, contrairement à pepsi-whitelist : un programme capable d’ouvrir chaque clé privée d’un déploiement est une prise bien plus grosse qu’une simple table de liste blanche. Un site qui veut que ses utilisateurs gèrent leurs propres identités l’installe setuid pepsi-crypto ; les identités appartiennent au login passwd auquel leur adresse se résout, et un appelant non privilégié du binaire setuid ne peut voir et modifier que les siennes. Sans le bit, chaque appelant se connecte sous sa propre identité et seuls les droits de la base de données décident, de sorte que le rendre setuid est une décision de site plutôt qu’un changement de code. Les clés de pairs et les ancres de confiance valent pour tout le déploiement et sont réservées à l’opérateur, listage compris.

66.4. Voir aussi

Gestion des clés, pepsi-setup, pepsi-whitelist, pepsi-settings, Architecture, pepsi-keys(1), pepsi.conf(5).