hagrid-keyserver--hagrid/templates-translated/fr/about/faq.html.hbs

<div class="about">
    <center><h2>
<a href="/about">À propos</a> | <a href="/about/news">Nouvelles</a> | <a href="/about/usage">Utilisation</a> | FAQ | <a href="/about/stats">Statistiques</a> | <a href="/about/privacy">Protection des données</a>
</h2></center>

    <p><strong>Des instructions se trouvent dans notre <a href="/about/usage">guide d’utilisation</a>.</strong></p>

    <h3 id="sks-pool"><a href="#sks-pool">Ce serveur fait-il partie de la réserve « SKS » ? </a></h3>

    <p>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 <span class="brand">keys.openpgp.org</span> ne fera jamais partie de la réserve SKS même.</p>

    <h3 id="federation"><a href="#federation">keys.openpgp.org est-il fédéré ? Puis-je participer en faisant tourner une instance du site ?</a></h3>

    <p>Pas pour le moment. Nous prévoyons de décentraliser <span class="brand">keys.openpgp.org</span> 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.</p>

    <p>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 :</p>
    <ol>
<li>La fédération à participation ouverte exige que toutes les données soient publiques. Cela a une incidence considérable sur la vie privée de nos utilisateurs, car cela permet à n’importe qui de récupérer une liste de toutes les adresses courriel.</li>
        <li>Les serveurs exploités comme passe-temps par des administrateurs occasionnels ne répondent pas à nos normes de fiabilité et de performances.</li>
    </ol>
<h3 id="non-email-uids"><a href="#non-email-uids">Pourquoi les identités qui ne sont pas des adresses courriel ne sont-elles pas prises en charge ?</a></h3>

    <p>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.</p>

    <p>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 <span class="brand">keys.openpgp.org</span>.</p>

    <h3 id="verify-multiple"><a href="#verify-multiple">Puis-je confirmer plus d’une clé avec la même adresse courriel ?</a></h3>

    <p>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 <a href="/about">renseignements qui ne permettent pas de vous identifier</a> seront encore distribués pour toutes les clés.</p>

    <p>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.</p>

    <h3 id="email-protection"><a href="#email-protection">Que faites-vous pour protéger les courriels de confirmation sortants ?</a></h3>

    <p>Nous utilisons une norme moderne appelée <a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a> combinée à <a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a> 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.</p>

    <p>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 <a href="https://www.hardenize.com/">exécuter ce test</a> 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.</p>

    <h3 id="third-party-signatures"><a href="#third-party-signatures">Distribuez-vous les « signatures par des tiers » ?</a></h3>

    <p>Tout simplement, non.</p>

    <p>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 « <a href="https://fr.wikipedia.org/wiki/Toile_de_confiance" target="_blank">toile de confiance</a> ». Pour plusieurs raisons, ces signatures ne sont actuellement pas distribuées par <span class="brand">keys.openpgp.org</span>.</p>

    <p>La raison principale est <strong>les contenus indésirables</strong>. 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.</p>

    <p>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 <a href="https://wiki.debian.org/caff" target="_blank">genre « caff »</a> (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.</p>

    <h3 id="no-sign-verified"><a href="#no-sign-verified">Pourquoi ne pas signer les clés après confirmation ?</a></h3>

    <p>Le service <span class="brand">keys.openpgp.org</span> 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.</p>

    <h3 id="revoked-uids"><a href="#revoked-uids">Pourquoi les identités révoquées ne sont-elles pas distribuées comme telles ?</a></h3>

    <p>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.</p>
    <p>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.</p>
    <p>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 <span class="brand">keys.openpgp.org</span> dès que nous le pourrons.</p>

    <h3 id="search-substring"><a href="#search-substring">Pourquoi n’est-il pas possible d’effectuer une recherche avec une partie de l’adresse courriel, par exemple, seulement le domaine ?</a></h3>

    <p>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.</p>

    <p>Sur <span class="brand">keys.openpgp.org</span>, 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.</p>

    <p>Nous avons mis cette restriction en place dans le cadre de notre <a href="/about/privacy">politique de confidentialité</a>, ce qui signifie que nous ne pouvons pas la changer sans demander le consentement des utilisateurs.</p>

    <h3 id="tor"><a href="#tor">Prenez-vous Tor en charge ?</a></h3>

    <p>Bien sûr ! Si vous avez installé Tor, vous pouvez accéder anonymement à <span class="brand">keys.openpgp.org</span> en tant que <a href="https://support.torproject.org/fr/onionservices/#onionservices-2" target="_blank">service onion</a> : <br><a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>

    <h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">Pourquoi ne pas chiffrer les courriels de confirmation ?</a></h3>

    Il existe plusieurs raisons :
    <ol>
<li>C’est plus compliqué, à la fois pour les utilisateurs et pour nous.</li>
        <li>Cela ne prévient pas les attaques. Un assaillant ne gagne rien à téléverser une clé à laquelle il n’a pas accès.</li>
        <li>La suppression devrait quand même être possible même si une clé est perdue.</li>
        <li>Un mécanisme différent (et plus compliqué) serait nécessaire pour téléverser des clés qui peuvent seulement signer.</li>
    </ol>
<h3 id="older-gnupg"><a href="#older-gnupg">J’éprouve des difficultés à mettre à jour certaines clés avec GnuPG. Y a-t-il un bogue ? </a></h3>

    <p>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 <a href="/about">pas d’adresse courriel confirmée</a> 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.</p>
    <p>En juin 2019, l’équipe de <span class="brand">keys.openpgp.org</span> 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.</p>
    <p>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 <strong> les versions non corrigées de GnuPG ne peuvent pas recevoir de mises à jour de <span class="brand">keys.openpgp.org</span> pour les clés qui n’ont pas d’adresse courriel confirmée</strong>. Vous trouverez plus de précisions au sujet de cette décision dans le problème <a href="https://dev.gnupg.org/T4393#133689">T4393</a> du système de suivi des bogues de GnuPG (page en anglais).</p>
    <p>Les instructions qui suivent vous permettront de vérifier si votre version de GnuPG est affectée.</p>
    <blockquote>
<span style="font-size: larger;">Importez la clé de test :</span><br><br>
      $ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import<br>
      gpg: clef F231550C4F47E38E: « Alice Lovelace &lt;alice@openpgp.example&gt; » importée<br>
      gpg: Quantité totale traitée : 1<br>
      gpg:               importées  1<br><br>
</blockquote>
    <blockquote>
<span style="font-size: larger;">Avec le correctif, la clé sera mise à jour si elle est connue localement :</span><br><br>
      $ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: clef F231550C4F47E38E : « Alice Lovelace &lt;alice@openpgp.example&gt; » inchangée<br>
      gpg: Quantité totale traitée : 1<br>
      gpg:              inchangées : 1<br><br>
</blockquote>
    <blockquote>
<span style="font-size: larger;">Sans le correctif, une clé dépourvue d’identité est toujours rejetée :</span><br><br>
      $ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E : n'est pas un identifiant de clef <br>
</blockquote>
</div>