La Crise de la Confiance : Du Web of Trust à Hagrid

I. Du pipeline cryptographique à la question : « à qui appartient cette clé ? »

Dans le premier article, on a vu qu’OpenPGP est avant tout une mécanique : les données sont chiffrées en symétrique avec une clé de session aléatoire, cette clé de session est elle‑même chiffrée en asymétrique avec la clé publique du destinataire, et la signature n’est rien d’autre que le hash du message signé avec la clé privée de l’émetteur. L’asymétrique ne sert donc pas à chiffrer les données brutes, mais à protéger la clé de session et à lier un message à une identité.

Dans le monde des certificats X.509 (HTTPS, VPN, etc.), c’est une Autorité de Certification (CA) qui lie une identité à une clé publique et signe ce lien. OpenPGP a choisi une autre voie : celle des certificats OpenPGP, enrichis de signatures d’autres utilisateurs, et d’un modèle social appelé Web of Trust où ce sont les humains qui s’attestent mutuellement plutôt qu’une autorité centrale.

Sur le papier, l’idée est élégante : pas de point central, pas de CA toute‑puissante, un réseau de confiance décentralisé où chacun construit sa propre vision de qui est fiable. Dans la pratique, à l’échelle d’Internet et avec des serveurs de clés comme SKS conçus pour ne jamais rien oublier, ce modèle a fini par se retourner contre lui‑même, jusqu’à rendre certaines clés inutilisables et pousser l’écosystème à inventer autre chose, comme Hagrid et keys.openpgp.org.

Dans ce deuxième article, on va quitter la pure cryptographie pour parler d’identité et d’infrastructure :

• ce qu’est réellement un certificat OpenPGP,
• comment fonctionne le Web of Trust,
• pourquoi SKS a explosé sous le poids de ce modèle,
• et pourquoi Hagrid a choisi de sacrifier une partie de l’idéologie du WoT global pour garder un système utilisable au quotidien.​

Ensuite, on pourra aller jusqu’à des cas concrets comme la vérification de commits signés sur GitHub/GitLab : comment une clé PGP proprement publiée, vérifiée et distribuée influence ce qu’on voit comme « Verified » dans notre historique Git.

II. Certificat et certificat OpenPGP

Avant de parler du Web of Trust, il faut clarifier ce qu’est un certificat électronique et pourquoi cette notion est centrale quand on manipule OpenPGP. Un certificat, c’est la carte d’identité cryptographique d’une entité : il lie une identité (personne, organisation, domaine) à une clé publique, d’une façon qui peut être vérifiée mathématiquement. Il peut en plus embarquer des métadonnées comme la période de validité, les usages autorisés de la clé, ou encore des noms de domaines alternatifs.

Certificat électronique client-serveur de opensuse.org

Sur la capture de certificat pour opensuse.org, le navigateur lit précisément ce lien identité ↔ clé publique : le sujet est « opensuse.org », le certificat mentionne plusieurs DNS (www.opensuse.org, doc.opensuse.org, etc.), la clé publique est une clé elliptique de 384 bits, et l’émetteur est l’autorité Let’s Encrypt, elle‑même rattachée à une racine de confiance (« ISRG Root X1 »). Quand le navigateur décide de faire confiance à ce certificat, ce n’est pas parce qu’il « aime bien » la clé du serveur, mais parce qu’il fait déjà confiance à la clé publique de Let’s Encrypt, qui a signé ce certificat

1. X.509 : identité garantie par une autorité

Le format X.509 est le standard utilisé pour les certificats TLS/HTTPS. L’idée est simple :​

• Le serveur génère un couple clé privée / clé publique.​
• Il envoie la clé publique et des informations d’identité (ex. opensuse.org) à une Autorité de Certification (CA).​
• La CA vérifie que le serveur contrôle réellement ce domaine (challenge DNS, HTTP, etc.).​
• Si tout est bon, la CA construit un certificat contenant :
• l’identité (domaine, organisation),
• la clé publique du serveur,
• des métadonnées (validité, usages, extensions),
• et calcule une signature cryptographique sur cet ensemble avec sa clé privée.​

Toute machine qui possède la clé publique de la CA peut alors vérifier cette signature et conclure :

Ce certificat dit que la clé publique K appartient à opensuse.org, et cette affirmation est signée par une CA en qui je fais déjà confiance.

C’est précisément ce qui évite que n’importe quel serveur se déclare « je suis opensuse.org » sans être détecté : sans CA, le phishing serait trivial à industrialiser.

Exemple de fonctionnement d’un certificat numérique

2. Certificat OpenPGP : identité garantie socialement

OpenPGP utilise aussi des certificats, mais dans un esprit très différent. Un certificat OpenPGP (ce qu’on appelle souvent « clé PGP » dans les outils) peut contenir :​

• une clé principale et éventuellement plusieurs sous‑clés (chiffrement, signature, auth),
• une ou plusieurs identités déclarées (User IDs : nom, email, parfois commentaire),
• des signatures d’autres utilisateurs qui disent « j’ai vérifié que cette clé appartient bien à cette identité »,
• des métadonnées (algorithmes, dates de création/expiration, préférences, etc.).​

Contrairement à X.509, il n’y a pas une hiérarchie de CA au centre. N’importe qui peut générer sa paire de clés et créer un certificat avec ses propres identités, puis demander à d’autres personnes de le signer après vérification au travers des *key signing party.* C’est la défintion de la toile de confiance (Web Of Trust) : chaque individu peut choisir lui-même les tiers en qui il veut faire confiance, de façon directe ou indirecte.

3. Web of Trust (WoT) : la confiance comme graph social

Une fois la notion de certificat OpenPGP posée, la question centrale devient :

« Peut‑on raisonnablement croire que ce certificat appartient bien à la personne ou à l’organisation qu’il revendique ? »

Le Web of Trust est la réponse historique d’OpenPGP à cette question, dans un modèle sans autorité centrale. L’idée est que chaque utilisateur construit sa propre vision de la confiance :

• il peut décider de signer le certificat d’une autre personne après l’avoir vérifié (par exemple en contrôlant l’identité et l’empreinte de la clé lors d’une rencontre ou via un canal fiable) ;
• ces signatures créent des liens de confiance entre certificats ;
• la confiance est locale (chacun choisit ses propres critères) et transitive (un certificat peut être jugé suffisamment fiable parce qu’il est signé par plusieurs entités déjà jugées fiables).

Par exemple, si Bob reçoit un certificat, il peut le considérer valide si :

• il l’a lui-même signé
• ou le certificat est signé par une personne à laquelle Jean a donné sa confiance totale
• ou si le certificat est signé par trois personnes auxquelles Jean a donné une confiance partielle. (peut varier en fonction des critères de Jean !)

Le Web of Trust ne sert donc ni à chiffrer ni à signer les messages ; il sert uniquement à évaluer l’identité derrière une clé publique, c’est‑à‑dire à décider si l’on va utiliser ce certificat pour chiffrer ou pour accepter une signature.

Ce graphe illustre l’idée clé qu’on a expliqué plus haut : la confiance n’est ni globale ni automatique, elle est dérivée de la structure de ce réseau de signatures et des choix individuels de chaque utilisateur. C’est un modèle très puissant en théorie, mais qui devient difficile à gérer à grande échelle, ce qui conduira directement aux problèmes de scalabilité et, plus tard, aux limites de SKS.

4. Le problème de scalabilité du Web of Trust

Dans le modèle OpenPGP, n’importe quel utilisateur peut signer n’importe quelle clé. Chaque signature est stockée dans le certificat correspondant, au même titre que les identités et les métadonnées. Il n’existe pas, dans le format lui‑même, de limite stricte au nombre de signatures pouvant être attachées à un même certificat.​

À l’échelle d’Internet, cela signifie que les données « sociales » (qui a signé quelle clé, à quel moment, avec quel niveau de confiance) sont potentiellement non bornées. Plus une clé est connue, plus elle est susceptible d’accumuler des signatures : au fil du temps, son certificat grossit, parfois de façon spectaculaire. Le problème n’est alors pas cryptographique (les algorithmes de hash et de signature restent robustes), mais structurel et social : un format conçu pour être durable et append‑only se retrouve à encoder des relations humaines qui, elles, peuvent croître sans limite.

Cette croissance non contrôlée pose plusieurs difficultés pratiques :

• certificats volumineux à télécharger, stocker et traiter,
• vérifications de signatures plus lentes,
• outils qui doivent parser et interpréter des graphes de confiance complexes avant de prendre une décision. (Car oui le graphe peut devenir grandement complexe)

5. SKS : l’infrastructure qui a amplifié le problème

Pour distribuer ces certificats OpenPGP, la communauté a longtemps utilisé une famille de serveurs appelée SKS (Synchronizing Key Server). L’idée était simple : former un réseau de serveurs qui répliquent entre eux l’ensemble des certificats et de leurs signatures, de manière décentralisée. Ce réseau pouvait être interrogé par n’importe quel client OpenPGP pour rechercher une clé par identifiant ou par adresse email.

Le principe fondateur de SKS était radical : append‑only, never delete. Une fois qu’une clé ou une signature était publiée, elle était acceptée, recopiée sur les autres serveurs et pratiquement impossible à retirer proprement. Ce choix visait la résilience (ne pas perdre de clés), la résistance à la censure (ne pas permettre à un acteur central d’effacer discrètement des certificats) et la simplicité de synchronisation entre nœuds.

Réseau SKS (vue mesh)

Principe de propagation dans un réseau SKS

Combiné au Web of Trust non borné, ce modèle append‑only avait une conséquence directe : chaque nouvelle signature ajoutée sur une clé s’accumulait dans son certificat, puis était répliquée sur l’ensemble du réseau. À long terme, certaines clés très populaires devenaient de véritables « aimants à signatures », avec des certificats de plus en plus volumineux et coûteux à traiter, sans possibilité réaliste de nettoyage ou de modération.

6. L’attaque SKS (2019) : quand le design se retourne contre lui

L’épisode de 2019 n’était pas une faille cryptographique classique, mais une exploitation du design social de l’écosystème SKS. Des attaquants ont publié des quantités massives de signatures supplémentaires, syntaxiquement valides, sur des certificats très connus (par exemple ceux de développeurs de projets open source majeurs).​

En vertu du modèle SKS, ces signatures ont été acceptées, répliquées et conservées par l’ensemble du réseau : les certificats ciblés ont gonflé jusqu’à atteindre des dizaines de mégaoctets. De nombreux clients OpenPGP se sont alors retrouvés incapables de charger ou de traiter ces clés de manière raisonnable, ce qui a ralenti ou bloqué des opérations courantes comme la vérification de signatures de logiciels ou de commits Git signés.​

Cet épisode illustre un déni de service sémantique : du point de vue mathématique, tout fonctionne correctement (les signatures restent valides, les algorithmes sont sûrs), mais l’écosystème devient pratiquement inutilisable à cause de la taille et de la prolifération incontrôlée des données de confiance.

7. La chute progressive de SKS

Face à l’impossibilité de nettoyer les certificats empoisonnés ou de retirer proprement les signatures malveillantes du réseau, la communauté a progressivement abandonné SKS. Des projets et distributions majeurs ont désactivé ou remplacé leurs serveurs SKS, et les opérateurs restants ont fermé les uns après les autres, faute de solution de modération compatible avec le design append‑only initial.​

Cet abandon est, en creux, la reconnaissance que un Web of Trust global, stocké dans des certificats append‑only répliqués partout, ne passe pas à l’échelle d’Internet. C’est ce constat qui ouvre la voie à une nouvelle génération de serveurs de clés, dont Hagrid et keys.openpgp.org sont aujourd’hui les représentants les plus visibles.

8. Hagrid / keys.openpgp.org : changer d’objectif

Après l’épisode SKS, une nouvelle génération de serveurs de clés est apparue avec une philosophie différente. Hagrid est le logiciel qui alimente keys.openpgp.org, un « Verifying Key Server » dont le but n’est plus de stocker tout le Web of Trust mondial, mais de fournir une distribution fiable et maîtrisée des clés publiques.​

La rupture avec SKS est nette :

• pas de réseau de serveurs qui se répliquent aveuglément entre eux ;
• pas de stockage des signatures tierces (les certifications d’autres utilisateurs ne sont pas publiées) ;
• possibilité de supprimer ou de restreindre les données associées à une clé, notamment pour respecter le RGPD.

Principe : vérifier le contrôle de l’email

Hagrid se concentre sur un point vérifiable de manière automatisable : la preuve que le propriétaire d’une clé contrôle bien l’adresse email associée. Le flux simplifié est le suivant :

Lorsqu’un certificat est envoyé à un serveur OpenPGP moderne, celui-ci commence par extraire les identités associées à la clé, généralement des adresses email. Pour chaque adresse, le serveur envoie un message de confirmation contenant un lien unique. L’adresse n’est considérée comme vérifiée que si le détenteur de la clé clique sur ce lien, ce qui prouve qu’il contrôle réellement cette identité.

Une fois ce processus terminé, le serveur publie la clé publique accompagnée des identités email vérifiées. Cependant, les signatures tierces qui composent le Web of Trust ne sont pas publiées par le serveur.

Ce modèle recentre le rôle du serveur sur une fonction limitée mais robuste : il distribue des clés propres et associées à des emails contrôlés par leurs propriétaires, tout en laissant la gestion fine de la confiance — les signatures, les politiques locales et l’établissement de relations de confiance — au client ou à des outils séparés. Cela simplifie l’infrastructure côté serveur tout en préservant la sécurité et la flexibilité pour les utilisateurs.

9. Git, GitHub et les clés OpenPGP

Dans l’écosystème Git, la part cryptographique la plus visible d’OpenPGP est la signature de commits et de tags. Git calcule déjà un hash pour chaque commit ; ajouter une signature OpenPGP revient à signer ce hash avec la clé privée du développeur.​

Les plateformes comme GitHub ou GitLab associent ensuite une clé PGP à un compte utilisateur. Lorsqu’un commit signé est poussé, elles vérifient que la signature correspond à une clé enregistrée pour ce compte et marquent le commit comme « Verified » si c’est le cas. Derrière ce badge, on retrouve exactement les mécanismes décrits dans l’article : certificat OpenPGP, clé publique, signature du hash du commit et décision de confiance sur l’identité liée à la clé.​

10. Synthèse et lien avec le TP Hagrid

Les deux articles convergent vers un même constat : OpenPGP est cryptographiquement solide, mais l’histoire montre que la partie la plus fragile n’est pas le chiffrement lui‑même, c’est la gestion de l’identité distribuée et des relations de confiance à grande échelle. Le modèle Web of Trust + SKS a tenté de résoudre ce problème de manière radicalement décentralisée, au prix d’une complexité sociale et d’un manque de contrôle qui l’ont rendu vulnérable au spam et au déni de service sémantique.

Dans un prochain article, nous présenterons l’implémentation de notre projet qui n’a pas pour vocation de « réinventer Hagrid », mais à l’utiliser comme terrain d’expérimentation :

• déployer une instance Hagrid en environnement contrôlé, observer concrètement le flux d’une clé (soumission, vérification par email, publication partielle) et les API HKP/VKS exposées ;
• analyser ses choix technologiques (Rust, Sequoia-PGP, base locale, refus de la fédération) et ce qu’ils impliquent en termes de sécurité, de robustesse et de gouvernance ;
• concevoir, à plus long terme, des pistes d’extensions ou de nouvelles fonctionnalités : scénarios de test plus poussés, métriques d’usage, intégration avec des workflows Git signés, ou outils autour de la vérification par fingerprint plutôt que par simple recherche email

L’objectif du projet est donc double : comprendre Hagrid de l’intérieur (architecture, contraintes, compromis) et ouvrir la porte à des améliorations concrètes, plutôt que de rester sur une critique abstraite de SKS ou du Web of Trust. C’est une manière d’ancrer la réflexion théorique sur la confiance dans des choix d’implémentation réels, auditables et modifiables.

SOURCES

Web of Trust, certificats, identité

• Web of Trust — Wikipedia https://en.wikipedia.org/wiki/Web_of_trust
• Toile de confiance — Wikipédia (FR) https://fr.wikipedia.org/wiki/Toile_de_confiance
• PGP Web of Trust: core concepts https://www.linux.com/training-tutorials/pgp-web-trust-core-concepts-behind-trusted-communication/
• PGP Web of Trust: delegated trust and keyservers — Linux Foundation https://www.linuxfoundation.org/blog/blog/pgp-web-of-trust-delegated-trust-and-keyservers
• Web of Trust: decentralized trust model https://negg.blog/en/web-of-trust-decentralized-trust-model/
• Cryptography with OpenPGP — Apache Infrastructure https://infra.apache.org/openpgp.html

SKS, effondrement des keyservers

• SKS keyserver (logiciel) — GitHub https://github.com/SKS-Keyserver/sks-keyserver
• SKS — Synchronizing Key Server (fiche paquet) https://www.freshports.org/security/sks/
• SKS Key Servers Gone — Technology Stir Fry https://iay.org.uk/blog/2021/07/05/sks-key-servers-gone/
• Migrating the Launchpad Keyservers from SKS to Hockeypuck — Ubuntu https://ubuntu.com/blog/migrating-the-launchpad-keyservers-from-sks-to-hockeypuck

Hagrid et keys.openpgp.org

• Hagrid: A New Verifying Key Server Built on Sequoia https://sequoia-pgp.org/blog/2019/06/14/20190614-hagrid/
• Projet Hagrid / keys.openpgp.org (code) https://gitlab.com/keys.openpgp.org/hagrid
• keys.openpgp.org — FAQ https://keys.openpgp.org/about/faq/
• Verifying Keyserver (VKS) Interface — keys.openpgp.org https://keys.openpgp.org/about/api/

Git, commits signés et Web of Trust

• GitHub Docs — Signing commits https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits
• GitHub Docs — About commit signature verification https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification
• GitLab Docs — Sign commits with GPG https://docs.gitlab.com/user/project/repository/signed_commits/gpg/
• Sign Like a Pro: Simple Guide to GPG and Web of Trust for commits https://www.neteye-blog.com/2025/01/sign-like-a-pro-simple-guide-to-gpg-and-web-of-trust-for-commits/

Contexte OpenPGP / RFC (si besoin)

• RFC 4880 — OpenPGP Message Format https://datatracker.ietf.org/doc/html/rfc4880
• OpenPGP — Site officiel https://www.openpgp.org/