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

<div class="about">
    <center><h2>
<a href="/about">About</a> | <a href="/about/news">Novità</a> | <a href="/about/usage">Guida all'uso</a> | FAQ | <a href="/about/stats">Statistiche</a> | <a href="/about/privacy">Privacy</a>
</h2></center>

    <h3 id="sks-pool"><a href="#sks-pool">Questo server è parte del pool "SKS"?</a></h3>

    <p>No. Il modello di federazione del pool SKS ha diversi problemi in termini
di affidabilità, resistenza all'abuso, privacy, ed usabilità. Potremmmo fare
qualcosa di simile, ma <span class="brand">keys.openpgp.org</span>
non sarà mai parte del pool SKS.</p>

    <h3 id="federation"><a href="#federation">keys.openpgp.org è federato? Posso contribuire mantenendo un'istanza?</a></h3>

    <p>Per il momento, no.
Vogliamo decentralizzare <span class="brand">keys.openpgp.org</span>
prima o poi.
Con più server
gestiti da più agenti indipendenti,
possiamo auspicabilmente migliorare ulteriormente
l'affidabilità di questo servizio.</p>

    <p>Diverse persone si sono offerte di aiutare
"facendo girare un'istanza del server Hagrid".
Appreziamo molto l'offerta,
ma probabilmente non avremo mai un modello di federazione "aperta" come SKS,
dove chiunque può gestire un'istanza e divenire parte del "pool".
Questo per due ragioni:</p>
    <ol>
<li>La federazione a partecipazione aperta richiede che tutti i dati siano pubblici.
Questo impatta significativamente la privacy dei nostri utenti, perché
consente a chiunque di estrarre una lista di tutti gli indirizzi email.</li>
        <li>I server mantenuti per hobby dagli amministratori amatoriali non raggiungono i nostri standard di performance e affidabilità.</li>
    </ol>
<h3 id="non-email-uids"><a href="#non-email-uids">Perché non c'è supporto
per le identità che non sono indirizzi email?</a></h3>

    <p>Richiediamo il consenso esplicito per distribuire le informazioni identificative.
Le identità che non sono indirizzi email, come immagini o URL di siti web, non offrono alcun modo pratico per chiedere questo consenso.</p>

    <p>Nota: Alcuni software OpenPGP creano chiavi con email formattati incorrettamente. Questi indirizzi potrebbero non essere riconosciuti correttamente su <span class="brand">keys.openpgp.org</span>.</p>

    <h3 id="verify-multiple"><a href="#verify-multiple">Posso verificare più
di una chiave per alcuni indirizzi email?</a></h3>

    <p>Un indirizzo email può essere associato solo con una singola chiave.
Quando un indirizzo è verificato per una nuova chiave,
non appare più in nessuna chiave per cui era stato precedentemente verificato.
Le<a href="/about">informazioni non identificative</a> vengono comunque distribuite per tutte le chiavi.</p>

    <p>Questo significa che una ricerca per indirizzo email
restituirà una sola chiave,
non diversi candidati.
Questo elimina una scelta impossibile per l'utente
("Quale chiave è quella giusta?"),
e rende la ricerca delle chiavi per email molto più semplice.</p>

    <h3 id="email-protection"><a href="#email-protection">Cosa fare per
proteggere le email di verifica in uscita?</a></h3>

    <p>Usiamo uno standard moderno chiamato
<a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a>,
oltre a 
<a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a>
della EFF,
per essere sicuri che le mail di verifica siano inviate in maniera sicura.
Questo protegge dalle intercettazioni durante la consegna.</p>

    <p>Il meccanismo MTA-STS dipende dalla corretta configurazione dei server email.
Puoi <a href="https://www.hardenize.com/">eseguire questo test</a>
per vedere se il tuo provider email lo supporta.
Se la voce "MTA-STS" sulla sinistra non è una spunta verde,
chiedi al tuo provider di aggiornare la sua configurazione.</p>

    <h3 id="third-party-signatures"><a href="#third-party-signatures">
Distribuite "firme di terze parti"?</a></h3>

    <p>In sintesi: No.</p>

    <p>Una "firma di terza parte" è una firma su una chiave
che è stata fatta con una qualche altra chiave.
Più comunemente,
queste sono firme prodotte quando si "firma la chiave di qualcuno",
che è la base per
la "<a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">Rete della Fiducia</a>".
Per svariate ragioni,
queste firme non vengono attualmente distribuite
da <span class="brand">keys.openpgp.org</span>.</p>

    <p>La ragione principale è lo <strong>spam</strong>.
Le firme di terze parti consentono di allegare dati a piacere alla chiave di chiunque,
e niente impedisce a un utente malintenzionato di
allegare così tanti megabyte di ciarpame a una chiave
da renderla praticamente inutilizzabile.
Anche peggio,
potrebbero allegare contenuto offensivo o illegale.</p>

    <p>Ci sono delle idee per risolvere questo problema.
Per esempio, le firme potrebbero essere distribuite con la chiave del firmatario,
invece che del firmato.
In alternativa, potremmo richiedere
una firma incrociata dal firmatario prima della distribuzione
per supportare un
flusso <a href="https://wiki.debian.org/caff" target="_blank">a-la-caff</a>.
Se c'è abbastanza interesse,
siamo aperti a lavorare con gli altri progetti OpenPGP
ad una soluzione.</p>

    <h3 id="no-sign-verified"><a href="#no-sign-verified">Perché non firmare le chiavi
dopo la verifica?</a></h3>

    <p>Il servizio <span class="brand">keys.openpgp.org</span>è mirato a distribuire
e far reperire le chiavi, non ad essere una Certification Authority de facto. 
Le implementazioni dei client che vogliono offrire una comunicazione verificata dovrebbero
fare affidamento sul loro modello di fiducia.</p>

    <h3 id="revoked-uids"><a href="#revoked-uids">Perché le identità revocate non sono distribuite come tali?</a></h3>

    <p>Quando una chiave OpenPGP segnala una delle sue identità come revocata, questa
identità non dovrebbe essere più ritenuta valida per la chiave, e questa
informazione dovrebbe essere idealmente distribuita a tutti i client OpenPGP che
conoscono già l'identità appena revocata.</p>
    <p>Sfortunatamente, attualmente non c'è un buon modo di distribuire le revoche
che non riveli anche l'identità revocata stessa. Non vogliamo
distribuire le identità revocate, quindi non possiamo distribuire l'identità affatto.</p>
    <p>Ci sono delle soluzioni proposte per questo problema, che consentono la distribuzione
delle revoche senza rivelare anche l'identità stessa. Ma finora
non c'è stata nessuna specifica finale, o supporto in alcun software OpenPGP. 
Speriamo che una soluzione sia individuata nell'immediato futuro, e
aggiungeremo il supporto su <span class="brand">keys.openpgp.org</span> appena possibile.</p>

    <h3 id="search-substring"><a href="#search-substring">Perché non è possibile cercare per solo una parte di indirizzo email, per esempio solo il dominio?</a></h3>

    <p>Alcuni keyserver supportano la ricerca di chiavi per parte di indirizzo email.
Questo consente di reperire non solo le chiavi, ma anche gli indirizzi, con una query del tipo "chiavi per indirizzi chiocciola gmail punto com".
Questo pone a tutti gli effetti gl iindirizzi di tutte le chiavi su quei keyserver in una lista pubblica.</p>

    <p>Una ricerca per indirizzo email su <span class="brand">keys.openpgp.org</span> restituisce una chiave solo se corrisponde esattamente all'indirizzo inserito.
In questo modo, un utente normale può reperire le chiavi associate con qualsiasi indirizzo conoscano già, ma non possono scoprire alcun nuovo indirizzo email.
Questo previene agli utenti malintenzionati o agli spammer di ottenere facilmente una lista di tutti gli indirizzi email presenti nel server.</p>

    <p>Abbiamo resto questa restrizione parte della nostra <a href="/about/privacy">privacy policy</a>,
il che vuol dire che non la cambieremo senza chiedere esplicito consenso agli utenti.</p>

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

    <p>Certo!
Se hai Tor installato,
puoi raggiungere <span class="brand">keys.openpgp.org</span> anonimamente come un <a href="https://support.torproject.org/onionservices/#onionservices-2" target="_blank">servizio onion</a>:
<br><a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>

    <h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">Perché non cifrare le mail di verifica?</a></h3>

    Diversi motivi:
    <ol>
<li>È più complicato, sia per i nostri utenti che per noi.</li>
        <li>Non previene gli attacchi - un attaccante non ha alcun beneficio dal
caricare una chiave a cui non hanno accesso.</li>
        <li>La cancellazione dovrebbe restare possibile anche quando una chaive è
persa.</li>
        <li>Richiederebbe un meccanismo diverso (e più complesso) per
caricare chiavi abilitate solo alla firma.</li>
    </ol>
<h3 id="older-gnupg"><a href="#older-gnupg">
Sto avendo dei problemi ad aggiornare alcune chiavi con GnuPG. C'è un bug?
</a></h3>

    <p>È un problema con le attuali versioni di GnuPG. Se provi a 
aggiornare una chiave da <span class="brand">keys.openpgp.org</span> che
non contiene <a href="/about">informazioni identificative</a>, GnupG si rifiuterà
di gestire la chiave:</p>
    <blockquote>$ gpg --receive-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID</blockquote>
    <p>Stiamo lavorando con il team GnuPG per risolvere questo problema.</p>
</div>