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

<div class="about">
    <center><h2>
<a href="/about">Sobre</a> | <a href="/about/news">Novetats</a> | <a href="/about/usage">Ús</a> | FAQ | <a href="/about/stats">Estadístiques</a> | <a href="/about/privacy">Privacitat</a>
</h2></center>

    <h3 id="sks-pool"><a href="#sks-pool">Aquest servidor forma part del pool "SKS" ?</a></h3>

    <p>No. El model federat del pool SKS té diversos problemes en termes de fiabilitat, possibilitat d'abús, privacitat i usabilitat. Podem realitzar alguna cosa semblant, però <span class="brand">keys.openpgp.org</span> mai no formarà part del pool SKS.</p>

    <h3 id="federation"><a href="#federation">Està keys.openpgp.org federat? Puc ajudar aportant una instància ?</a></h3>

    <p>De moment no. Tenim previst descentralitzar <span class="brand">keys.openpgp.org</span> en algún moment. Amb diferents servidors d'operadors independents esperem millorar la fiabilitat d'aquest servei encara més.</p>

    <p>Diverses persones s'han ofert a ajudar fent córrer una instància de servidor Hagrid. Apreciem realment aquestes ofertes, però probablement mai hi haurà una federació 'oberta' com SKS, on tothom pot fer córrer una instància i formar part del pool. Això és per dues raons:</p>
    <ol>
<li>Una federació amb participació oberta requereix que totes les dades siguin públiques. Això afecta significativament la privacitat dels usuaris perquè permet a qualsevol obtenir una llista de totes les adreces de correu electrònic.</li>
        <li>Els servidors gestionats com a passatemps per administradors casuals no encaixen amb els nostres estàndards de fiabilitat i rendiment. </li>
    </ol>
<h3 id="non-email-uids"><a href="#non-email-uids">Per què no hi ha suport per identitats que no són adreces de correu electrònic ?</a></h3>

    <p>Requerim consentiment explícit per a distribuir informació sobre identitats. Les identitats que no són correus electrònics, com imatges o adreces de correu, no tenen una forma fàcil d'obtenir aquests consentiments.</p>

    <p>Nota: algun programari OpenPGP crea claus amb adreces de correu electrònic formatejades incorrectament. Aquestes adreces podrien no ser reconegudes a <span class="brand">keys.openpgp.org</span>.</p>

    <h3 id="verify-multiple"><a href="#verify-multiple">Puc verificar més d'una clau per alguna adreça de correu electrònic ?</a></h3>

    <p>Una adreça de correu electrònic pot estar associada només a una sola clau. Quan una adreça és verifica per a una nova clau, no torna a apareixer a les altres claus per a les estava associada previament. <a href="/about">La informació impersonal</a> sí que es manté distribuida per a totes les claus.</p>

    <p>Això significa que la cerca per adreça de correu electrònic només torna una única clau, no múltiples candidates. Això elimina l'elecció impossible per a l'usuari ("Quina és la clau correcta ?"), i fa la cerca per adreça de correu electrònic molt més convenient.</p>

    <h3 id="email-protection"><a href="#email-protection">Què feu per a protegir els correus de verificació ?</a></h3>

    <p>Utilitzem un estàndard actual anomenat <a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a>, combinat amb <a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a> de la EFF, per estar segurs que els correus de validació són enviats de forma segura. Això protegeig contra l'espionatge i la interceptació durant l'enviament.</p>

    <p>El mecanisme MTA-STS depén de la correcta configuració dels servidors de correu electrònic. Podeu <a href="https://www.hardenize.com/">provar aquest test</a> per a veure si el vostre proveïdor d'internet el suporta. Si el símbol "MTA-STS" a l'esquerra no és una marca verda, si us plau demaneu al vostre proveïdor que actualitzi la seva configuració.</p>

    <h3 id="third-party-signatures"><a href="#third-party-signatures">Distribuiu signatures de terceres parts ?</a></h3>

    <p>Resposta curta: No.</p>

    <p>Una signatura de tercera part és una signatura d'una clau feta per una altra clau. El més habitual és que aquestes signatures siguin fetes quan se signa la clau d'una altra persona, el que és la base de la <a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">xarxa de confiança</a>. Per unes quantes raon aquestes signatures no són distribuides actualment per <span class="brand">keys.openpgp.org</span>.</p>

    <p>La raó principal és <strong>spam</strong>. Les signatures de terceres parts permeten adjuntar qualsevol mena d'información a la clau de qualsevol, i res atura a un usuari maliciós d'adjuntar tanta informació a una clau que la converteix en pràcticament inusable. Encara pitjor, l'usuari maliciós pot adjuntar contingut ofensiu o il·legal.</p>

    <p>Hi ha idees per a resoldre aquest problema. Per exemple, les signatures podrien ser distribuides amb el signador, enlloc del signat. Alternativament, podriem requerir signatures creuades 'cross-signin' amb el signat abans de la distribució i així suportar el procediment <a href="https://wiki.debian.org/caff" target="_blank">caff-style</a>. Si hi ha prou interès, estem oberts a treballar amb altres projectes OpenPGP en una solució.</p>

    <h3 id="no-sign-verified"><a href="#no-sign-verified">Per què no signar les claus després de verificar-les ?</a></h3>

    <p>El servei de <span class="brand">keys.openpgp.org</span> està dirigit a la distribució i descobriment de claus, no com una autoritat de certificació. Les implementacions de clients que volen oferir comunicacions verificades han de suportar-se en els seus propis models de confiança.</p>

    <h3 id="revoked-uids"><a href="#revoked-uids">Per què les identitats revocades no es distribueixen com a tals ?</a></h3>

    <p>Cuan una clau OpenPGP marca una de les seves identitats com a revocada, aquesta identitat no hauria de considerar-se mai més vàlida per a la clau, i idealment, aquesta informació hauria de distribuir-se a tots els clients OpenPGP que encara coneixen la identitat ara revocada.</p>
    <p>Per desgràcia no hi ha una manera de distribuir revocacions que alhora no revelin la pròpia identitat revocada. No volem distribuir identitats revocades, de manera que no podem distribuir identitats.</p>
    <p>Hi ha proposades solucions a aquest problema, que permeten la distribució de revocacions sense revelar les identitats. Però encara no hi ha una especificació final, o el suport de cap programari OpenPGP. Esperem que s'estabeixi una solució en un futur, y aleshores afegirem el suport a <span class="brand">keys.openpgp.org</span> tan ràpid com puguem.</p>

    <h3 id="search-substring"><a href="#search-substring">Per què no és possible cercar per parts d'adreces de correu electròric, com per exemple el domini ?</a></h3>

    <p>Alguns servidors de claus donen suport a la cerca de claus per parts d'adreces de correu elctrònic. Això permet el descobriment no només de claus, sino també d'adreces, amb una cerca per exemple com "claus d'adreces a gmail punt com". Això exposa efectivament les adreces d'aquests servidors a llistats publics.</p>

    <p>Una cerca per adreça de correu electrònic a <span class="brand">keys.openpgp.org</span> retorna una clau només si coindixeix exactament amb aquesta adreça. D'aquesta manera un usuari normal pot trobar la clau associada a qualsevol adreça que coneix, però no pot descobrir cap nova adreça de correu electrònic. Això evita que un usuari maliciós o spammer pugui obtenir fàcilment la llista de totes les adreces del servidor.</p>

    <p>Hem fet aquesta restricció part de la nostra <a href="/about/privacy">política de privacitat</a>, el que significa que no podem canviar-la sense demanar el consentiment dels usuaris.</p>

    <h3 id="tor"><a href="#tor">Suporteu Tor ?</a></h3>

    <p>Per suposat ! Si teniu Tor instal·lat podreu arribar a <span class="brand">keys.openpgp.org</span> de forma anònima com un <a href="https://support.torproject.org/onionservices/#onionservices-2" target="_blank">servei onion</a>: 
<a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>

    <h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">Per què no encripteu els correus de verificació ?</a></h3>

    Hi ha diverses raons:
    <ol>
<li>És més complicat, tant pels nostres usuaris com per a nosaltres.</li>
        <li>No evita els atacs - un atacant no guanya res de pujar una clau a la que no té accés.</li>
        <li>L'esborrat hauria de ser possible encara que la clau s'hagués perdut.</li>
        <li>Requeriria un mecanisme diferent (i encara més complicat) per pujar claus només de signatura.</li>
    </ol>
<h3 id="older-gnupg"><a href="#older-gnupg">Tinc algún problema pujant algunes claus amb GnuPG. Hi ha algun error ?</a></h3>

    <p>Hi ha un problema amb la versió actual de GnuPG. Si intenteu pujar una clau des de <span class="brand">keys.openpgp.org</span> que no conté <a href="/about">informació d'identitat</a>, GnuPG rebutjarà processar aquesta clau.</p>
    <blockquote>$ gpg --receive-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID</blockquote>
    <p>Estem treballant amb l'equip de GnuPG per resoldre aquest problema.</p>
</div>