Des instructions se trouvent dans notre guide d’utilisation.
Non. Le modèle fédéré de la réserve SKS présente divers problèmes en matière de fiabilité, de résistance aux abus, de confidentialité et d’utilisabilité. Nous réaliserons peut-être quelque chose de semblable, mais keys.openpgp.org ne fera jamais partie de la réserve SKS même.
Pas pour le moment. Nous prévoyons de décentraliser keys.openpgp.org ultérieurement. Avec plusieurs serveurs exploités par des opérateurs indépendants, nous pouvons espérer améliorer encore plus la fiabilité de ce service.
Plusieurs personnes ont offert de nous aider en « faisant tourner une instance du serveur Hagrid ». Nous sommes très reconnaissants de ces offres, mais nous n’aurons probablement jamais de modèle fédéré « ouvert » tel que SKS, où tout le monde peut exécuter une instance et faire partie d’une réserve. Il y a deux raisons :
Pour distribuer des renseignements d’identité, nous exigeons un consentement explicite. Les identités qui ne sont pas des adresses courriel, telles que les images ou les URL de site Web ne nous permettent pas d’obtenir facilement ce consentement.
Note : Certains logiciels OpenPGP créent des clés avec des adresses courriel mal formatées. Ces adresses pourraient ne pas être reconnues correctement sur keys.openpgp.org.
Une adresse courriel ne peut être associée qu’avec une seule clé. Si une adresse est confirmée pour une nouvelle clé, elle n’apparaîtra plus avec aucune clé pour laquelle elle était confirmée précédemment. Les renseignements qui ne permettent pas de vous identifier seront encore distribués pour toutes les clés.
Cela signifie qu’une recherche par adresse courriel ne retournera qu’une seule clé et non plusieurs candidates. Cela élimine un choix impossible pour l’utilisateur (« Quelle clé est la bonne ? ») et rend plus pratique la recherche de clés par adresse courriel.
Nous utilisons une norme moderne appelée MTA-STS combinée à STARTTLS Everywhere de la FFÉ (sites en anglais), afin de nous assurer que les courriels de confirmation sont envoyés en toute sécurité. Ces mesures protègent contre l’écoute et l’interception en cours de livraison.
Le mécanisme MTA-STS ne fonctionne que s’il est pris en charge par le service de courriel des destinataires. Les courriels seront autrement remis comme d’habitude. Vous pouvez exécuter ce test pour voir si votre service de courriel le prend en charge. Si l’entrée « MTA-STS » située sur la gauche ne présente pas de coche verte, veuillez demander à votre fournisseur de mettre à jour sa configuration.
Tout simplement, non.
Une « signature par un tiers » est la signature d’une clé effectuée par quelque autre clé. Généralement, ce sont les signatures produites en signant la clé de quelqu’un, qui constituent la fondation de la « toile de confiance ». Pour plusieurs raisons, ces signatures ne sont actuellement pas distribuées par keys.openpgp.org.
La raison principale est les contenus indésirables. Les signatures par des tiers permettent de joindre des données arbitraires à la clé de n’importe qui, et rien n’empêche un utilisateur malveillant de joindre tant de méga-octets de données obèses à une clé qu’elle devient pratiquement inutilisable. Pis encore, il pourrait joindre du contenu offensif ou illégal.
Des idées de solution existent pour résoudre ce problème. Par exemple, les signatures pourraient être distribuées avec le signataire plutôt qu’avec la personne à qui la signature est destinée. Nous pourrions aussi exiger, avant distribution, une signature croisée de la personne à qui la signature est destinée, afin de prendre en charge un déroulement genre « caff » (page en anglais). Si cela suscite suffisamment d’intérêt, nous sommes prêts à collaborer avec d’autres projets OpenPGP pour concevoir une solution.
Le service keys.openpgp.org est conçu pour la distribution et la recherche de clés, pas comme une autorité de certification de facto. Les mises en œuvre par des clients qui souhaitent offrir des communications vérifiées devraient reposer sur leur propre modèle de confiance.
Si une clé OpenPGP marque l’une de ses identités comme révoquée, cette identité ne devrait plus être considérée comme valide pour la clé. Ce renseignement devrait idéalement aussi être distribué à tous les clients OpenPGP qui connaissent déjà la nouvelle identité révoquée.
Malheureusement, il n’existe actuellement aucune bonne façon de distribuer des révocations qui ne divulguerait pas aussi l’identité révoquée même.
Des solutions à ce problème ont été proposées, qui permettent la distribution de révocations sans aussi divulguer l’identité même. Cependant, il n’existe jusqu’à présent aucune spécification finale ni prise charge par des logiciels OpenPGP. Nous espérons qu’une solution sera mise en place dans un avenir proche et nous la déploierons sur keys.openpgp.org dès que nous le pourrons.
Certains serveurs de clés prennent en charge la recherche de clés avec une partie de l’adresse courriel. Cela permet de découvrir non seulement des clés, mais aussi des adresses, avec une requête telle que « clés pour adresses à gmail point com ». Ainsi, une liste publique des adresses de toutes les clés sur ces serveurs est en fait créée.
Sur keys.openpgp.org, une recherche par adresse courriel ne retourne une clé que si elle correspond exactement à l’adresse courriel. De cette façon, un utilisateur normal peut découvrir la clé associée avec n’importe quelle adresse courriel qu’il connaît déjà, mais il ne peut pas découvrir de nouvelles adresses courriel. Cela empêche un utilisateur malveillant ou un arroseur (pourrielleur) d’obtenir une liste de toutes les adresses courriel sur ce serveur.
Nous avons mis cette restriction en place dans le cadre de notre Politique de confidentialité, ce qui signifie que nous ne pouvons pas la changer sans demander le consentement des utilisateurs.
Bien sûr ! Si vous avez installé Tor, vous pouvez accéder anonymement à keys.openpgp.org en tant que service onion :
zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion
GnuPG considère que les clés qui ne comprennent pas de renseignements d’identité sont invalides et refuse de les importer. Cependant, une clé qui n’a pas d’adresse courriel confirmée peut quand même comprendre des renseignements utiles. Plus précisément, il est possible de vérifier si la clé est révoquée ou non.
En juin 2019, l’équipe de keys.openpgp.org a créé un correctif qui permet à GnuPG de traiter les mises à jour des clés sans renseignements d’identité. Ce correctif a rapidement été intégré à plusieurs versions en aval de GnuPG, dont Debian, Fedora, NixOS, et GPG Suite pour macOS.
En mars 2020, l’équipe de GnuPG a rejeté le correctif et a changé l’état du problème à « Wontfix » (ne sera pas corrigé). Cela signifie que les versions non corrigées de GnuPG ne peuvent pas recevoir de mises à jour de keys.openpgp.org pour les clés qui n’ont pas d’adresse courriel confirmée. Vous trouverez plus de précisions au sujet de cette décision dans le problème T4393 du système de suivi des bogues de GnuPG (page en anglais).
Les instructions qui suivent vous permettront de vérifier si votre version de GnuPG est affectée.
Importez la clé de test :
$ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import
gpg: clef F231550C4F47E38E: « Alice Lovelace <alice@openpgp.example> » importée
gpg: Quantité totale traitée : 1
gpg: importées 1
Avec le correctif, la clé sera mise à jour si elle est connue localement :
$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E
gpg: clef F231550C4F47E38E : « Alice Lovelace <alice@openpgp.example> » inchangée
gpg: Quantité totale traitée : 1
gpg: inchangées : 1
Sans le correctif, une clé dépourvue d’identité est toujours rejetée :
$ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E
gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E : n'est pas un identifiant de clef