hagrid-keyserver--hagrid/templates-untranslated/about/faq.html.hbs

<div class="about">
    <center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | FAQ | <a href="/about/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>

    <h3 id="sks-pool"><a href="#sks-pool">Is this server part of the "SKS" pool?</a></h3>

    <p>
        No. The federation model of the SKS pool has various problems in terms
        of reliability, abuse-resistance, privacy, and usability. We might do
        something similar to it, but <span class="brand">keys.openpgp.org</span>
        will never be part of the SKS pool itself.
    </p>

    <h3 id="federation"><a href="#federation">Is keys.openpgp.org federated? Can I help by running an instance?</a></h3>

    <p>
        For the moment, no.
        We do plan to decentralize <span class="brand">keys.openpgp.org</span>
        at some point.
        With multiple servers
        run by independent operators,
        we can hopefully improve the reliability
        of this service even further.
    </p>

    <p>
        Several folks offered to help out
        by "running a Hagrid server instance".
        We very much appreciate the offer,
        but we will probably never have an "open" federation model like SKS,
        where everyone can run an instance and become part of a "pool".
        This is for two reasons:
    </p>
    <ol>
        <li>
            Federation with open participation requires all data to be public.
            This significantly impacts the privacy of our users, because it
            allows anyone to scrape a list of all email addresses.
        </li>
        <li>
            Servers run as a hobby by casual administrators do not meet our
            standards for reliability and performance.
        </li>
    </ol>

    <h3 id="non-email-uids"><a href="#non-email-uids">Why is there no support
            for identities that aren't email addresses?</a></h3>

    <p>
        We require explicit consent to distribute identity information.
        Identities that aren't email addresses, such as pictures or website
        URLs, offer no simple way for us to acquire this consent.
    </p>

    <p>
        Note: Some OpenPGP software creates keys with incorrectly formatted
        email addresses.  These addresses might not be recognized correctly on
        <span class="brand">keys.openpgp.org</span>.
    </p>

    <h3 id="verify-multiple"><a href="#verify-multiple">Can I verify more than
            one key for some email address?</a></h3>

    <p>
        An email address can only be associated with a single key.
        When an address is verified for a new key,
        it will no longer appear in any key
        for which it was previously verified.
        <a href="/about">Non-identity information</a> will still be distributed
        for all keys.
    </p>

    <p>
        This means a search by email address
        will only return a single key,
        not multiple candidates.
        This eliminates an impossible choice for the user
        ("Which key is the right one?"),
        and makes key discovery by email much more convenient.
    </p>

    <h3 id="email-protection"><a href="#email-protection">What do you do to
            protect outgoing verification emails?</a></h3>

    <p>
        We use a modern standard called
        <a href="https://www.hardenize.com/blog/mta-sts" target="_blank">MTA-STS</a>,
        combined with
        <a href="https://starttls-everywhere.org/" target="_blank">STARTTLS Everywhere</a>
        by the EFF,
        to make sure verification emails are sent out securely.
        This protects against eavesdropping and interception during delivery.
    </p>

    <p>
        The MTA-STS mechanism only works if supported by the recipient's email
        provider. Otherwise, emails will be delivered as usual.
        You can <a href="https://www.hardenize.com/">run this test</a>
        to see if your email provider supports it.
        If the "MTA-STS" entry on the left isn't a green checkmark,
        please ask your provider to update their configuration.
    </p>

    <h3 id="third-party-signatures"><a href="#third-party-signatures">
            Do you distribute "third party signatures"?</a></h3>

    <p>
        Short answer: No.
    </p>

    <p>
        A "third party signature" is a signature on a key
        that was made by some other key.
        Most commonly,
        those are the signatures produced when "signing someone's key",
        which are the basis for
        the "<a href="https://en.wikipedia.org/wiki/Web_of_trust" target="_blank">Web of Trust</a>".
        For a number of reasons,
        those signatures are not currently distributed
        via <span class="brand">keys.openpgp.org</span>.
    </p>

    <p>
        The killer reason is <strong>spam</strong>.
        Third party signatures allow attaching arbitrary data to anyone's key,
        and nothing stops a malicious user from
        attaching so many megabytes of bloat to a key
        that it becomes practically unusable.
        Even worse,
        they could attach offensive or illegal content.
    </p>

    <p>
        There are ideas to resolve this issue.
        For example, signatures could be distributed with the signer,
        rather than the signee.
        Alternatively, we could require
        cross-signing by the signee before distribution
        to support a
        <a href="https://wiki.debian.org/caff" target="_blank">caff-style</a>
        workflow.
        If there is enough interest,
        we are open to working with other OpenPGP projects
        on a solution.
    </p>

    <h3 id="no-sign-verified"><a href="#no-sign-verified">Why not sign keys
            after verification?</a></h3>

    <p>
        The <span class="brand">keys.openpgp.org</span> service is meant for key
        distribution and discovery, not as a de facto certification authority.
        Client implementations that want to offer verified communication should
        rely on their own trust model.
    </p>

    <h3 id="revoked-uids"><a href="#revoked-uids">Why are revoked identities not
            distributed as such?</a></h3>

    <p>
        When an OpenPGP key marks one of its identities as revoked, this
        identity should no longer be considered valid for the key, and this
        information should ideally be distributed to all OpenPGP clients that
        already know about the newly revoked identity.
    </p>
    <p>
        Unfortunately, there is currently no good way to distribute revocations,
        that doesn't also reveal the revoked identity itself.  We don't want to
        distribute revoked identities, so we can't distribute the identity at
        all.
    </p>
    <p>
        There are proposed solutions to this issue, that allow the distribution
        of revocations without also revealing the identity itself.  But so far
        there is no final specification, or support in any OpenPGP software.  We
        hope that a solution will be established in the near future, and will
        add support on <span class="brand">keys.openpgp.org</span> as soon as
        we can.
    </p>

    <h3 id="search-substring"><a href="#search-substring">Why isn't it possible to search by part of an email address, like just the domain?</a></h3>

    <p>
        Some keyservers support search for keys by part of an email address.
        This allows discovery not only of keys, but also of addresses, with a query like "keys for addresses at gmail dot com".
        This effectively puts the addresses of all keys on those keyservers into a public listing.
    </p>

    <p>
        A search by email address on <span class="brand">keys.openpgp.org</span> returns a key only if it exactly matches the email address.
        That way, a normal user can discover the key associated with any address they already know, but they cannot discover any new email addresses.
        This prevents a malicious user or spammer from easily obtaining a list of all email addresses on the server.
    </p>

    <p>
        We made this restriction a part of our <a href="/about/privacy">privacy policy</a>,
        which means we can't change it without asking for user consent.
    </p>

    <h3 id="tor"><a href="#tor">Do you support Tor?</a></h3>

    <p>
        Of course!
        If you have Tor installed,
        you can reach <span class="brand">keys.openpgp.org</span> anonymously
        as an
        <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">
            Why not encrypt verification emails?</a></h3>

    Various reasons:
    <ol>
        <li>It is more complicated, both for our users and for us.</li>
        <li>It doesn't prevent attacks - an attacker gains nothing from
            uploading a key they don't have access to.</li>
        <li>Deletion would still have to be possible even when a key is
            lost.</li>
        <li>It would require a different (and more complicated) mechanism to
            upload keys that can only sign.</li>
    </ol>

    <h3 id="older-gnupg"><a href="#older-gnupg">
      I have trouble updating some keys with GnuPG.  Is there a bug?
    </a></h3>

    <p>
      GnuPG considers keys that contain no identity information to be invalid, and refuses to import them.
      However, a key that has no <a href="/about">verified email addresses</a> may still contain useful information.
      In particular, it's still possible to check whether the key is revoked or not.
    </p>
    <p>
      In June 2019, the <span class="brand">keys.openpgp.org</span> team created a patch that allows GnuPG to process updates from keys without identity information.
      This patch was quickly included in several downstream distributions of GnuPG, including Debian, Fedora, NixOS, and GPG Suite for macOS.
    </p>
    <p>
      In March 2020 the GnuPG team rejected the patch, and updated the issue status to "Wontfix".
      This means that <strong>unpatched versions of GnuPG cannot receive updates from <span class="brand">keys.openpgp.org</span> for keys that don't have any verified email address</strong>.
      You can read about this decision in issue <a href="https://dev.gnupg.org/T4393#133689">T4393</a> on the GnuPG bug tracker.
    </p>
    <p>
      You can check if your version of GnuPG is affected with the following instructions.
    </p>
    <blockquote>
      <span style="font-size: larger;">Import test key:</span><br>
      <br>
      $ curl https://keys.openpgp.org/assets/uid-test.pub.asc | gpg --import<br>
      gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" imported<br>
      gpg: Total number processed: 1<br>
      gpg:               imported: 1<br>
      <br>
    </blockquote>
    <blockquote>
      <span style="font-size: larger;">With patch, key will be updated if locally known:</span><br>
      <br>
      $ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: key F231550C4F47E38E: "Alice Lovelace &lt;alice@openpgp.example&gt;" not changed<br>
      gpg: Total number processed: 1<br>
      gpg:              unchanged: 1<br>
      <br>
    </blockquote>
    <blockquote>
      <span style="font-size: larger;">Without patch, a key without identity is always rejected:</span><br>
      <br>
      $ gpg --recv-keys EB85BB5FA33A75E15E944E63F231550C4F47E38E<br>
      gpg: key EB85BB5FA33A75E15E944E63F231550C4F47E38E: no user ID<br>
    </blockquote>
</div>