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

<div class="about">
    <center><h2>
<a href="/about">Over</a> | <a href="/about/news">Nieuws</a> | <a href="/about/usage">Gebruik</a> | FAQ | <a href="/about/stats">Statistieken</a> | <a href="/about/privacy">Privacy</a>
</h2></center>

    <h3 id="sks-pool"><a href="#sks-pool">Maakt deze server deel uit van de "SKS" pool?</a></h3>

    <p>Nee. Het federatiemodel van de SKS pool heeft verschillende problemen 
op het gebied van betrouwbaarheid, weerstand tegen misbruik, privacy, en gebruiksvriendelijkheid. 
We kunnen misschien overwegen iets gelijkaardig te doen, 
maar <span class="brand">keys.openpgp.org</span> zal zelf nooit uitmaken van de SKS pool.</p>

    <h3 id="federation"><a href="#federation">Is keys.openpgp.org gefedereerd? Kan ik helpen door een instance te draaien?</a></h3>

    <p>Op het moment niet, nee.
We zijn uiteindelijk van plan om <span class="brand">keys.openpgp.org</span> te decentralizeren.
Met meerdere servers
Online bij onafhankelijke operatoren,
kunnen we hopelijk de betrouwbaarheid van deze service
nog meer verbeteren.</p>

    <p>Verschillende mensen hebben hun hulp aangeboden
door het "draaien van een Hagrid server instance".
We waarderen het aanbod zeer,
maar we zullen hoogstwarschijnlijk nooit een "open" federatie model hebben zoals SKS,
waar iedereen een instance kan draaien en deel uitmaken van een "pool".
Dit is voor twee redenen:</p>
    <ol>
<li>Federatie met open deelname vereist dat alle gegevens openbaar zijn.
Dit heeft een grote impact op de privacy van onze gebruikers, omdat
iedereen zo een lijst kan samenstellen van alle e-mailadressen.</li>
        <li>Servers die als hobby worden gerund door informele beheerders voldoen niet aan onze
normen voor betrouwbaarheid en prestaties.</li>
    </ol>
<h3 id="non-email-uids"><a href="#non-email-uids">Waarom is er geen ondersteuning
voor identiteiten welke geen e-mailadres zijn?</a></h3>

    <p>We hebben expliciete toestemming nodig om identiteitsgegevens te verspreiden.
Identiteiten die geen e-mailadressen zijn, zoals afbeeldingen of website
URL's, bieden ons geen eenvoudige manier om deze toestemming te verkrijgen.</p>

    <p>Opmerking: Sommige OpenPGP-software maakt sleutels met een onjuiste
e-mailadressen indeling. Deze adressen worden mogelijk niet correct herkend op
<span class="brand">keys.openpgp.org</span>.</p>

    <h3 id="verify-multiple"><a href="#verify-multiple">Kan ik meer dan
één sleutel valideren voor een e-mailadres?</a></h3>

    <p>Een e-mailadres kan slechts aan één sleutel worden gekoppeld.
Als een adres is geverifieerd voor een nieuwe sleutel,
zal deze in geen enkele sleutel meer verschijnen
waarvoor het eerder was geverifieerd.
<a href="/about">Niet-identiteitsgegevens</a> worden nog steeds verspreid
 voor alle sleutels.</p>

    <p>Dit betekent dat een zoekopdracht op e-mailadres
slechts één sleutel terug geeft ,
niet meerdere kandidaten.
Dit elimineert een onmogelijke keuze voor de gebruiker
("Welke sleutel is de juiste?"),
en maakt het vinden van sleutels via e-mail veel gemakkelijker.</p>

    <h3 id="email-protection"><a href="#email-protection">Wat doen jullie om
uitgaande verificatie-e-mails te beschermen?</a></h3>

    <p>We gebruiken een moderne standaard genaamd
<a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a>,
gecombineerd met
<a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a>
door de EFF,
om ervoor te zorgen dat verificatie-e-mails veilig worden verzonden.
Dit beschermt tegen afluisteren en onderscheppen tijdens het afleveren.</p>

    <p>Het MTA-STS mechanisme is afhankelijk van correct geconfigureerde e-mailservers.
U kunt <a href="https://www.hardenize.com/">deze test uitvoeren</a>
om te zien of uw e-mailprovider dit ondersteunt.
Als de vermelding "MTA-STS" aan de linkerkant geen groen vinkje is,
vraag uw provider dan om hun configuratie bij te werken.</p>

    <h3 id="third-party-signatures">
<a href="#third-party-signatures">
Distribueren jullie "derde partij handtekeningen"?</a> </h3>

    <p>In het kort: Nee.</p>

    <p>Een "handtekening van derden" is een handtekening op een sleutel
dat is gemaakt door een andere sleutel.
Meestal
dat zijn de handtekeningen die worden geproduceerd bij het "ondertekenen van iemands sleutel",
die de basis vormen voor
het "<a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">Web of Trust</a>".
Om een aantal redenen,
worden deze handtekeningen momenteel niet verspreid
via <span class="brand">keys.openpgp.org</span>.</p>

    <p>De belangrijkste reden is <strong>spam.</strong>.
Handtekeningen van derden maken het mogelijk willekeurige gegevens aan iemands sleutel toe te voegen,
en niets weerhoudt een kwaadwillende gebruiker ervan
vele megabytes 'ballast' aan een sleutel koppelen
zodat deze praktisch onbruikbaar wordt.
Erger nog,
ze kunnen aanstootgevende of illegale inhoud toevoegen.</p>

    <p>Er zijn ideeën om dit probleem op te lossen.
Als voorbeeld kunnen handtekeningen worden gedistribueerd met een ondertekenaar,
in plaats van de iemand die ondertekend.
Als alternatief kunnen we ondertekening eisendoor de ondertekenaar vóór distributie
ter ondersteuning van een
<a href="https://wiki.debian.org/caff" target="_blank">caff-stijl</a>
workflow. 
Als er voldoende interesse is,
staan we open voor samenwerking met andere OpenPGP-projecten
voor een oplossing.</p>

    <h3 id="no-sign-verified"><a href="#no-sign-verified">Waarom geen sleutels ondertekenen?
na verificatie?</a></h3>

    <p>De service <span class="brand">keys.openpgp.org</span> is bedoeld voor sleutel
distributie en vindbaarheid, niet als een certificeringsinstantie.
Clientimplementaties die geverifieerde communicatie willen aanbieden, zouden dat moeten
vertrouwen op hun eigen vertrouwensmodel.</p>

    <h3 id="revoked-uids"><a href="#revoked-uids">Waarom worden ingetrokken identiteiten niet
als zodanig verdeeld?</a></h3>

    <p>Wanneer een OpenPGP-sleutel een van zijn identiteiten als ingetrokken markeert
moet deze identiteit niet langer als geldig worden beschouwd voor de sleutel, en deze
informatie zou idealiter verspreid moeten worden onder alle OpenPGP-clients
weet al van de nieuw ingetrokken identiteit.</p>
    <p>Helaas is er momenteel geen goede manier om intrekkingen te verspreiden,
die niet de ingetrokken identiteit zelf onthult. We willen
ingetrokken identiteiten niet verspreid, daarom kunnen we de identiteit helemaal niet verspreiden.</p>
    <p>Er zijn voorgestelde oplossingen voor dit probleem, die de distributie mogelijk maken
van intrekkingen zonder ook de identiteit zelf te onthullen. Maar tot nu toe
zijn er geen definitieve specificatie of ondersteuning in enige OpenPGP-software. Wij
hoop dat er in de nabije toekomst een oplossing zal komen en hiervoor
ondersteuning kunnen toevoegen op <span class="brand">keys.openpgp.org</span> zodra
we kunnen.</p>

    <h3 id="search-substring"><a href="#search-substring">Waarom is het niet mogelijk om te zoeken op een deel van een e-mailadres, zoals alleen het domein?</a></h3>

    <p>Sommige sleutelservers ondersteunen het zoeken naar sleutels via een deel van een e-mailadres.
Hierdoor kunnen niet alleen sleutels worden gevonden, maar ook adressen, met een vraag als "sleutels voor adressen op gmail dot com".
Hierdoor worden de adressen van alle sleutels op die sleutelservers effectief in een openbare lijst geplaatst.</p>

    <p>Een zoekopdracht op e-mailadres op <span class="brand">keys.openpgp.org</span> levert alleen een sleutel op als deze exact overeenkomt met het e-mailadres.
Op deze manier kan een normale gebruiker de sleutel ontdekken die is gekoppeld aan elk adres dat hij al kent, maar hij kan geen nieuwe e-mailadressen ontdekken.
Dit voorkomt dat een kwaadwillende gebruiker of spammer gemakkelijk een lijst met alle e-mailadressen van de server krijgt.</p>

    <p>We hebben deze beperking opgenomen in ons <a href="/about/privacy">privacybeleid</a>,
wat betekent dat we dit niet kunnen wijzigen zonder toestemming van de gebruiker te vragen.</p>

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

    <p>Als u Tor hebt geïnstalleerd,
kunt u <span class="brand">keys.openpgp.org</span> anoniem bereiken
als
<a href="https://support.torproject.org/onionservices/#onionservices-2" target="_blank">onion service</a>:
<br><a href="http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion">zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion</a></p>

    <h3 id="encrypt-verification-emails"><a href="#encrypt-verification-emails">
Waarom worden verificatie-e-mails niet versleuteld?</a></h3>

    Verschillende redenen:
    <ol>
<li>Het is ingewikkelder, zowel voor onze gebruikers als voor ons.</li>
        <li>Het voorkomt aanvallen niet - een aanvaller heeft geen voordeel bij
het uploaden van een sleutel waar men geen toegang tot heeft.</li>
        <li>Verwijderen zou nog steeds mogelijk moeten zijn, zelfs als er een sleutel is
verloren.</li>
        <li>Het zou een ander (en ingewikkelder) mechanisme vereisen voor
het uploaden sleutels die alleen kunnen ondertekenen.</li>
    </ol>
<h3 id="older-gnupg"><a href="#older-gnupg">
Ik heb problemen met het updaten van sommige sleutels met GnuPG. Is er een bug?
</a></h3>

    <p>Dit is een probleem met de huidige versies van GnuPG. Als je het probeert
een sleutel te update op <span class="brand">keys.openpgp.org</span> die
geen <a href="/about">identiteitsgegevens</a> bevat, zal GnuPG weigeren
om de sleutel te verwerken:</p>
    <blockquote>$ gpg --receive-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E1<br>
gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: geen gebruikers-ID</blockquote>
    <p>We werken met het GnuPG team samen om dit probleem op te lossen.</p>
</div>