{{#> layout }}
<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/privacy">Privacy Policy</a></h2></center>

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

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

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

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

    <p>
        Note: Some OpenPGP software creates keys with incorrectly formatted
        e-mail addresses.  These addresses might not be recognized correctly on
        <span class="brand">keys.openpgp.org</span>.
    </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="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://en.wikipedia.org/wiki/Tor_(anonymity_network)#Onion_services" 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 e-mails?</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="sks-pool"><a href="#sks-pool">Is this server part of the "SKS" pool?</a>
    </h3>

    <p>No. The "append-only" federation model of the SKS pool leads to various
        problems, that make both operation and use of those servers very
        difficult.  There is also no simple way to store information about
        e-mail verification in a federated way.
    </p>
    <p>We do plan to explore options for a distributed service in the future, so
        users can choose between different service operators again.
    </p>

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

    <p>
      This is a problem with current versions of GnuPG.  If you are
      trying to update a key whose owner has not opted-in to having
      their userid(s) published, GnuPG will complain complain about
      the key having no userid:
    </p>
    <blockquote>
      $ gpg --receive-keys FB3751F1587DAEF<br>
      gpg: key FB3751F1587DAEF1: no user ID
    </blockquote>
    <p>
      We are working with the GnuPG team to resolve this problem.
    </p>
</div>
{{/layout}}