2025-10-06 00:23:08 +02:00 · 2025-09-28 23:58:59 +02:00
parent f272c7147e
commit de2ab333a5
74 changed files with 0 additions and 7516 deletions
							
							
							
						
@@ -1,85 +0,0 @@
{{#> layout }}
<div class="about">
    <center><h2>About | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | <a href="/about/faq">FAQ</a> | <a href="/about/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>
    <p>
        The <span class="brand">keys.openpgp.org</span> server is a public service for the
        distribution and discovery of OpenPGP-compatible keys, commonly
        referred to as a "keyserver".
    </p>
    <p>
        <strong>For instructions, see our <a href="/about/usage">usage guide</a>.</strong>
    </p>
    <h3>How it works</h3>
    <p>
        An OpenPGP key contains two types of information:
    </p>
    <ul>
        <li><strong>Identity information</strong> describes the parts of
            a key that identify its owner, also known as "User IDs".
            A User ID typically includes a name and an email address.
        </li>
        <li><strong>Non-identity information</strong> is all the technical
            information about the key itself. This includes the large numbers
            used for verifying signatures and encrypting messages.
            It also includes metadata like date of creation, some expiration
            dates, and revocation status.
        </li>
    </ul>
    <p>
        Traditionally, these pieces of information have always been distributed
        together. On <span class="brand">keys.openpgp.org</span>, they are
        treated differently.  While anyone can upload all parts of any OpenPGP key
        to <span class="brand">keys.openpgp.org</span>, our keyserver
        will only retain and publish certain parts under certain
        conditions:
    </p>
    <p>
        Any <strong>non-identity information</strong> will be stored and freely
        redistributed, if it passes a cryptographic integrity check.
        Anyone can download these parts at any time as they contain only
        technical data that can't be used to directly identify a person.
        Good OpenPGP software can use <span class="brand">keys.openpgp.org</span>
        to keep this information up to date for any key that it knows about.
        This helps OpenPGP users maintain secure and reliable communication.
    </p>
    <p>
        The <strong>identity information</strong> in an OpenPGP key
        is only distributed with consent.
        It contains personal data, and is not strictly necessary for
        a key to be used for encryption or signature verification.
        Once the owner gives consent by verifying their email address,
        the key can be found via search by address.
    </p>
    <h3 id="community">Community and platform</h3>
    <p>
        This service is run as a community effort.
        You can talk to us in
        #hagrid on OFTC IRC,
        also reachable as #hagrid:stratum0.org on Matrix.
        Of course you can also reach us via email,
        at <tt>support at keys dot openpgp dot org</tt>.
        The folks who are running this come
        from various projects in the OpenPGP ecosystem,
        including Sequoia-PGP, OpenKeychain, and Enigmail.
    </p>
    <p>
        Technically,
        <span class="brand">keys.openpgp.org</span> runs on the <a href="https://gitlab.com/keys.openpgp.org/hagrid" target="_blank">Hagrid</a> keyserver software,
        which is based on <a href="https://sequoia-pgp.org">Sequoia-PGP</a>.
        We are running on <a href="https://eclips.is" target="_blank">eclips.is</a>,
        a hosting platform focused on Internet Freedom projects,
        which is managed by <a href="https://greenhost.net/" target="_blank">Greenhost</a>.
    </p>
</div>
{{/layout}}
							
							
							
						
@@ -1,284 +0,0 @@
{{#> layout }}
<div class="about">
    <center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | <a href="/about/faq">FAQ</a> | <a href="/about/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>
  <p>
    Hagrid implements both the legacy HKP interface, as well as our
    native interface, VKS.
  </p>
  <h2>Verifying Keyserver (VKS) Interface</h2>
  <p>Hagrid has its own URL scheme to fetch, submit, and verify keys.</p>
  <ul>
    <li>
      <tt>GET /vks/v1/by-fingerprint/&lt;FINGERPRINT&gt;</tt>
      <p>
        Retrieves the key with the given <tt>Fingerprint</tt>.
        The <tt>Fingerprint</tt> may refer to the primary key, or any subkey.
        Hexadecimal digits MUST be uppercase,
        and MUST NOT be prefixed with <code>0x</code>.
        The returned key is ASCII Armored, and has a content-type of <code>application/pgp-keys</code>.
      </p>
    </li>
    <li>
      <tt>GET /vks/v1/by-keyid/&lt;KEY-ID&gt;</tt>
      <p>
        Retrieves the key with the given long <tt>KeyID</tt>.
        The <tt>KeyID</tt> may refer to the primary key, or any subkey.
        Hexadecimal digits MUST be uppercase,
        and MUST NOT be prefixed with <code>0x</code>.
        The returned key is ASCII Armored, and has a content-type of <code>application/pgp-keys</code>.
      </p>
    </li>
    <li>
      <tt>GET /vks/v1/by-email/&lt;URI-ENCODED EMAIL-ADDRESS&gt;</tt>
      <p>
        Retrieves the key with the given <tt>Email Address</tt>.
        Only exact matches are accepted.
        Lookup by email address requires opt-in by the owner of the email address.
        The returned key is ASCII Armored, and has a content-type of <code>application/pgp-keys</code>.
      </p>
    </li>
    <li>
      <tt>POST /vks/v1/upload</tt>
      <p>
        A single key may be submitted using a POST request to <tt>/vks/v1/upload</tt>.
        The body of the request must be <code>application/json</code>.
        The JSON data must contain a single field <code>keytext</code>,
        which must contain the keys to submit.
        The value of <code>keytext</code> can be formatted in standard OpenPGP ASCII Armor, or base64.
      </p>
      <p>
        The returned JSON data
        contains the fields <code>token</code>, <code>key_fpr</code>,
        and <code>status</code>.
        The <code>token</code> field contains an opaque value,
        which can be used to perform <tt>request-verify</tt> requests
        (see below).
        The <code>key_fpr</code> field contains the fingerprint of the uploaded primary key.
        The <code>status</code> token contains a map of email addresses
        contained in the key, with one of the values
        <code>unpublished</code>,
        <code>published</code>,
        <code>revoked</code>, or
        <code>pending</code>,
        indicating the status of this email address.
      </p>
      <div class="example">
        <div>
          Example request:
          <pre>
{
  "keytext": "&lt;ASCII ARMORED KEY&gt;"
}
          </pre>
        </div>
        <div>
          Example response:
          <pre>
{
  "key_fpr": "&lt;FINGERPRINT&gt;",
  "status": {
    "address@example.org": "unpublished"
  },
  "token": "..."
}
          </pre>
        </div>
      </div>
    </li>
    <li>
      <tt>POST /vks/v1/request-verify</tt>
      <p>
        A key that has been uploaded
        can be made discoverable by one or more of its email addresses
        by proving ownership of the address
        via a verification email.
        This endpoint requests verification
        for one or more email addresses.
      </p>
      <p>
        The body of the request must be <code>application/json</code>.
        The JSON data must include the opaque <code>token</code> value
        (obtained via <tt>/vks/v1/upload</tt>)
        and an <code>addresses</code> field,
        which is a list of email addresses (not full User IDs)
        to request verification mails for.
        It can optionally include a <code>locale</code> field,
        which is list of locales,
        ordered by preference,
        which to use for the verification email.
        The reply will be the same as for the <tt>/vks/v1/upload</tt> endpoint,
        with addresses marked as <code>pending</code> where a verification email
        has been sent.
      </p>
      <div class="example">
        <div>
          Example request:
          <pre>
{
  "token": "...",
  "addresses": [
    "address@example.org"
  ],
  "locale": [ "de_CH", "de_DE" ]
}
          </pre>
        </div>
        <div>
          Example response:
          <pre>
{
  "key_fpr": "&lt;FINGERPRINT&gt;",
  "status": {
    "address@example.org": "pending"
  },
  "token": "..."
}
          </pre>
        </div>
      </div>
    </li>
  </ul>
  <h3>Error handling</h3>
  <p>
    If a GET request fails for any reason,
    a suitable HTTP status code will be returned.
    The response will be a plaintext error message.
    If a key is not found,
    the HTTP status code will be <tt>404</tt>.
  </p>
  <p>
    If a POST request fails for any reason,
    a suitable HTTP status code will be returned.
    The response body will be
    a JSON object
    with a single <code>error</code> attribute.
    A POST request may fail
    with a HTTP 503 error
    at any time
    if the server is undergoing
    database maintenance.
    <strong>Clients should handle errors gracefully for POST requests.</strong>
  </p>
  <div class="example">
    <div>
      Example response:
      <pre>
{
  "error": "We are currently undergoing scheduled database maintenance!"
}
      </pre>
    </div>
  </div>
  <h3 id="rate-limiting"><a href="#rate-limiting">Rate Limiting</a></h3>
  <p>
    Requests to the <span class="brand">keys.openpgp.org</span> API are rate
    limited:
  </p>
  <ul>
    <li>
      Requests by fingerprint or key id are limited to five requests per second.
      Excessive requests will fail with <tt>error 429</tt>.
      There is a burst window of 1000.
    </li>
    <li>
      Requests by email address are limited to one request per minute.
      Excessive requests will fail with <tt>error 429</tt>.
      There is a burst window of 50.
    </li>
  </ul>
  <h2>HTTP Keyserver Protocol (HKP) Interface</h2>
  <p>
    Hagrid implements a subset of
    the <a href="https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00">HKP</a>
    protocol so that tools like GnuPG and OpenKeychain can use it
    without modification.
  </p>
  <ul>
    <li>
      <tt>GET /pks/lookup?op=get&amp;options=mr&amp;search=&lt;QUERY&gt;</tt>
      <p>Returns an ASCII Armored key matching the query.  Query may be:</p>
      <ul>
        <li>An exact email address query of the form <code>localpart@example.org</code>.</li>
        <li>
          A hexadecimal representation of a long <tt>KeyID</tt>
          (e.g., <code>069C0C348DD82C19</code>, optionally prefixed by <code>0x</code>).
          This may be a <tt>KeyID</tt> of either a primary key or a subkey.
        </li>
        <li>
          A hexadecimal representation of a <tt>Fingerprint</tt>
          (e.g., <code>8E8C33FA4626337976D97978069C0C348DD82C19</code>, optionally prefixed by <code>0x</code>).
          This may be a <tt>Fingerprint</tt> of either a primary key or a subkey.
        </li>
      </ul>
    </li>
    <li>
      <tt>GET /pks/lookup?op=index&amp;options=mr&amp;search=&lt;QUERY&gt;</tt>
      <p>
        Returns
        a <a href="https://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-5.2">machine-readable
        list</a> of keys matching the query.  Query may have the forms
        detailed above.  Hagrid always returns either one or no keys at
        all.
      </p>
    </li>
    <li>
      <tt>POST /pks/add</tt>
      <p>
        Keys may be submitted using a POST request to <tt>/pks/add</tt>,
        the body of the request being
        a <code>application/x-www-form-urlencoded</code> query.
        <code>keytext</code> must be the keys to submit,
        which must be ASCII Armored.
        More than one key may be submitted in one request.
        For verification of email addresses,
        the <tt>/vks/v1/upload</tt> endpoint
        must be used instead.
      </p>
    </li>
  </ul>
  <a href="#rate-limiting">Rate limiting</a> applies as for the VKS interface
  above.
  <h4>Limitations</h4>
  <p>
    By design, Hagrid does not implement the full HKP protocol.  The specific
    limitations are:
  </p>
  <ul>
    <li>No support for <code>op=vindex</code>.</li>
    <li>Only exact matches by email address, fingerprint or long key id are returned.</li>
    <li>All requests return either one or no keys.</li>
    <li>The expiration date field in <code>op=index</code> is left blank (discussion <a target="_blank" href="https://gitlab.com/keys.openpgp.org/hagrid/issues/134">here</a>).</li>
    <li>All parameters and options other than <code>op</code> and <code>search</code> are ignored.</li>
    <li>Output is always machine readable (i.e. <code>options=mr</code> is always assumed).</li>
    <li>Uploads are restricted to 1 MiB.</li>
    <li>All packets that aren't public keys, user IDs or signatures are filtered out.</li>
  </ul>
</div>
{{/layout}}
							
							
							
						
@@ -1,276 +0,0 @@
{{#> 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/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>
    <p>
        <strong>For instructions, see our <a href="/about/usage">usage guide</a>.</strong>
    </p>
    <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>
{{/layout}}
							
							
							
						
@@ -1,410 +0,0 @@
{{#> layout }}
<div class="about">
    <center><h2><a href="/about">About</a> | News | <a href="/about/usage">Usage</a> | <a href="/about/faq">FAQ</a> | <a href="/about/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>
    <h2 id="2023-04-28-governance">
      <div style="float: right; font-size: small; line-height: 2em;">2023-04-28 📅</div>
      <a style="color: black;" href="/about/news#2023-04-28-governance">keys.openpgp.org governance 📜</a>
    </h2>
    <p>
        It's been quite a while since the last update.
        Not a lot happened around <span class="brand">keys.openpgp.org</span> during this time, operationally. 😴
    <p>
        But no news is good news in this case:
        A few bugs were fixed, some software maintenance was perfomed to keep up with the ecosystem.
        There were no significant outages, we've had some steady growth of users, things are generally working as expected.
        Hurray!
    <p>
        There is, however, an important bit of news:
        <span class="brand">keys.openpgp.org</span> has a governance process now.
        In particular, there is now a written constitution for the service,
        which you can find <a href="https://gitlab.com/keys.openpgp.org/governance/-/blob/main/constitution.md">here</a>.
    <p>
        Most importantly, there is now a board, who were elected by a community of contributors to the OpenPGP ecosystem.
        This board currently consists of:
    <ul>
        <li>Daniel Huigens, from Proton</li>
        <li>Lukas Pitschl, from GPGTools</li>
        <li>Neal Walfield, from Sequoia-PGP</li>
        <li>Ola Bini</li>
        <li>Vincent Breitmoser</li>
    </ul>
    <p>
        The primary responsibility of the board is to make decisions on the future of <span class="brand">keys.openpgp.org</span>.
        Which features should go in, which not?
        We are having regular meetings at the moment, and progress is slow but steady.
        We'll be sure to let you know (via this news blog) when anything exciting happens!
    <p>
        You can find more info about governance in the <a href="https://gitlab.com/keys.openpgp.org/governance/">repository</a>.
        You can also reach the board via email at <tt>board</tt> <tt>at</tt> <tt>keys.openpgp.org</tt>.
    <p>
        That's all for now!
        <span style="font-size: x-large;">🙇</span>
    <hr style="margin-top: 2em; margin-bottom: 2em;" />
    <h2 id="2019-11-12-celebrating-100k">
      <div style="float: right; font-size: small; line-height: 2em;">2019-11-12 📅</div>
      <a style="color: black;" href="/about/news#2019-11-12-celebrating-100k">Celebrating 100.000 verified addresses! 📈</a>
    </h2>
    <p>
        Five months ago, we launched this service.
        And just today, we have reached a remarkable milestone:
    <center style="margin-top: 2em; margin-bottom: 2em;">
        <img src="/assets/img/stats-addresses-2019-11-12.png" style="padding: 1px; border: 1px solid gray;" /><br />
        <strong>One hundred thousand verified email addresses!</strong>
    </center>
    <p>
        Thanks to everyone using this service!
        And thanks especially to those who have provided us with feedback,
        translations, or even code contributions!
    <p>
        A few updates on things we've been working on:
    <ul>
        <li>
            This news page is now available as an <strong><a target="_blank" href="/atom.xml">atom feed <img src="/assets/img/atom.svg" style="height: 0.8em;" /></a></strong>.
        </li>
        <li>
            We have been working on
            a <strong><a target="_blank" href="https://gitlab.com/keys.openpgp.org/hagrid/issues/131">new mechanism to refresh keys</a></strong>
            that better protects the user's privacy.
        </li>
        <li>
            Work on <strong>localization</strong> is in full swing!
            we hope to have some languages ready for deployment soon.
        </li>
    </ul>
    <p>
        If you would like to see <span class="brand">keys.openpgp.org</span>
        translated into your native language,
        please <a target="_blank" href="https://www.transifex.com/otf/hagrid/">join the translation team</a>
        over on Transifex.
        We would appreciate help especially for <strong>Russian</strong>, <strong>Italian</strong>, <strong>Polish</strong> and <strong>Dutch</strong>.
    <p>
        That's all, keeping this one short!
        <span style="font-size: x-large;">👍️</span>
    <hr style="margin-top: 2em; margin-bottom: 2em;" />
    <h2 id="2019-09-12-three-months-later">
      <div style="float: right; font-size: small; line-height: 2em;">2019-09-12 📅</div>
      <a style="color: black;" href="/about/news#2019-09-12-three-months-later">Three months after launch ✨</a>
    </h2>
    <p>
        It has been three months now
        <a href="/about/news#2019-06-12-launch">since we launched</a>
        <span class="brand">keys.openpgp.org</span>.
        We are happy to report:
        It has been a resounding success!
        🥳
    <h4>Adoption in clients</h4>
    <p>
        The
        <span class="brand">keys.openpgp.org</span>
        keyserver has been received very well by users,
        and clients are adopting it rapidly.
        It is now used by default in
        <a href="https://gpgtools.org/" target="_blank">GPGTools</a>,
        <a href="https://enigmail.net/" target="_blank">Enigmail</a>,
        <a href="https://www.openkeychain.org/" target="_blank">OpenKeychain</a>,
        <a href="https://github.com/firstlookmedia/gpgsync" target="_blank">GPGSync</a>,
        Debian,
        NixOS,
        and others.
        Many tutorials have also been updated,
        pointing users our way.
    <p>
        At the time of writing,
        more than 70.000 email addresses
        have been verified.
    <center style="margin-top: 2em; margin-bottom: 2em;">
        <img src="/assets/img/stats-addresses-2019-09-12.png" style="padding: 1px; border: 1px solid gray;" /><br />
        <span style="font-size: smaller;">If that isn't a promising curve, I don't know what is :)</span>
    </center>
    <p>
        A special shout-out here goes to GPGTools for macOS.
        They implemented the update process so smoothly,
        the number of verified addresses completely exploded
        when they released their update.
    <h4>All's good in operations</h4>
    <p>
        There is not a lot to report operationally,
        and no news is good news in this case!
        Since launch,
        there was nearly zero downtime,
        only a single bug came up
        that briefly caused issues during upload,
        and support volume has been comfortably low.
    <p>
        Our traffic is currently
        at about ten requests per second
        (more during the day, less on the weekend),
        and we delivered roughly 100.000 emails
        in the last month.
        No sweat.
    <p>
        We made several small operational improvements
        including deployment of
        <a href="http://dnsviz.net/d/keys.openpgp.org/dnssec/" target="_blank">DNSSEC</a>,
        implementing some
        <a href="/about/api#rate-limiting" target="_blank">rate-limiting</a>,
        nailing down our
        <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP">content security policy</a>
        headers,
        and enabling
        <a href="https://blog.torproject.org/whats-new-tor-0298" target="_blank">single-hop</a>
        mode on our Tor Onion Service.
        You can find a more complete list
        <a href="https://gitlab.com/keys.openpgp.org/hagrid/merge_requests?scope=all&utf8=%E2%9C%93&state=merged" target="_blank">here</a>.
    <h4>Secure email delivery with MTA-STS</h4>
    <p>
        One improvement that deserves special mention is
        <a href="https://www.hardenize.com/blog/mta-sts">MTA-STS</a>,
        which improves the security of outgoing emails.
    <p>
        While HTTPS is deployed fairly universally these days,
        that sadly isn't the case for email.
        Many servers don't do encryption at all,
        or use a self-signed certificate
        instead of a proper one (e.g. from Let's Encrypt).
        But delivery failures upset customers more
        than reduced security,
        and many emails are still delivered without encryption.
    <p>
        With MTA-STS, domain operators can indicate
        (via HTTPS)
        that their email server <em>does</em> support encryption.
        When a secure connection can't be established
        to such a server,
        message delivery will be postponed
        or eventually bounce,
        instead of proceeding insecurely.
    <p>
        This is extremely useful for service like
        <span class="brand">keys.openpgp.org</span>.
        If encryption isn't reliable,
        attackers can intercept verification emails relatively easily.
        But for providers who have MTA-STS deployed,
        we can be sure that
        every message is delivered securely,
        and to the right server.
    <p>
        You can <a href="https://aykevl.nl/apps/mta-sts/" target="_blank">run a check</a>
        to find out whether your email provider
        supports MTA-STS.
        If they don't,
        please drop them a message and tell them
        to step up their security game!
    <h4>Work in progress</h4>
    <p>
        We are working on two features:
    <p>
        The first is <strong>localization</strong>.
        Most people do not speak English,
        but so far that is the only language we support.
        To make this service more accessible,
        we are working with the OTF's
        <a href="https://www.opentech.fund/labs/localization-lab/" target="_blank">Localization Lab</a>
        to make the website and outgoing emails
        available in several more languages.
    <p>
        The second is to bring back
        <strong>third-party signatures</strong>.
        As <a href="/about/faq#third-party-signatures">mentioned in our FAQ</a>,
        we currently don't support these due to spam and potential for abuse.
        The idea is to require
        <a href="https://gitlab.com/openpgp-wg/rfc4880bis/merge_requests/20/diffs" target="_blank">cross-signatures</a>,
        which allow each key to choose for itself
        which signatures from other people it wants to distribute.
        Despite this extra step,
        this is fairly compatible with existing software.
        It also nicely stays out of the way of users
        who don't care about signatures.
    <p>
        Although work is in progress for both of those features,
        neither have a planned time of release yet.
    <p>
        Regarding the "<tt>no user ID</tt>" issue with GnuPG
        (mentioned in our
        <a href="/about/news#2019-06-12-launch-challenges">last news post</a>
        and our
        <a href="/about/faq#older-gnupg" target="_blank">FAQ</a>),
        a patch that fixes this problem is now carried by Debian,
        as well as GPGTools for macOS.
        GnuPG upstream has not merged the patch so far.
    <p>
        That's it!
        Thanks for your interest!
        <span style="font-size: x-large;">👋</span>
    <hr style="margin-top: 2em; margin-bottom: 2em;" />
    <h2 id="2019-06-12-launch">
      <div style="float: right; font-size: small; line-height: 2em;">2019-06-12 📅</div>
      <a href="/about/news#2019-06-12-launch" style="color: black;">Launching a new keyserver! 🚀</a>
    </h2>
    <p>
    From a community effort by
    <a href="https://enigmail.net" target="_blank">Enigmail</a>,
    <a href="https://openkeychain.org" target="_blank">OpenKeychain</a>,
    and <a href="https://sequoia-pgp.org">Sequoia PGP</a>,
    we are pleased to announce
    the launch of the new public OpenPGP keyserver
    <span class="brand">keys.openpgp.org</span>!
    Hurray! 🎉
    <h4>Give me the short story!</h4>
    <ul>
      <li>Fast and reliable. No wait times, no downtimes, no inconsistencies.</li>
      <li>Precise. Searches return only a single key, which allows for easy key discovery.</li>
      <li>Validating. Identities are only published with consent,
        while non-identity information is freely distributed.</li>
      <li>Deletable. Users can delete personal information with a simple email confirmation.</li>
      <li>Built on Rust, powered by <a href="https://sequoia-pgp.org" target="_blank">Sequoia PGP</a> - free and open source, running AGPLv3.</li>
    </ul>
    Get started right now by <a href="/upload">uploading your key</a>!
    <h4>Why a new keyserver?</h4>
    <p>
      We created <span class="brand">keys.openpgp.org</span>
      to provide an alternative to the SKS Keyserver pool,
      which is the default in many applications today.
      This distributed network of keyservers has been struggling with
      <a target="_blank" href="https://medium.com/@mdrahony/are-sks-keyservers-safe-do-we-need-them-7056b495101c">abuse</a>,
      <a target="_blank" href="https://en.wikipedia.org/wiki/Key_server_(cryptographic)#Problems_with_keyservers">performance</a>,
      as well as <a href="http://www.openwall.com/lists/oss-security/2017/12/10/1">privacy issues</a>,
      and more recently also
      <a target="_blank" href="http://nongnu.13855.n7.nabble.com/SKS-apocalypse-mitigation-td228252.html">GDPR</a>
      compliance questions.
      Kristian Fiskerstrand has done a stellar job maintaining the pool for
      <a target="_blank" href="https://blog.sumptuouscapital.com/2016/12/10-year-anniversary-for-sks-keyservers-net/">more than ten years</a>,
      but at this point development activity seems to have
      <a target="_blank" href="https://bitbucket.org/skskeyserver/sks-keyserver/pull-requests/60/clean-build-with-405">mostly ceased</a>.
    <p>
    We thought it time to consider a fresh approach to solve these problems.
    <h4>Identity and non-identity information</h4>
    <p>
    The <span class="brand">keys.openpgp.org</span> keyserver splits up
    identity and non-identity information in keys.
    You can find more details on our <a href="/about" target="_blank">about page</a>:
    The gist is that non-identity information (keys, revocations, and so on)
    is freely distributed,
    while identity information
    is only distributed with consent
    that can also be revoked at any time.
    <p>
    If a new key is verified for some email address,
    it will replace the previous one.
    This way,
    every email address is only associated with a single key at most.
    It can also be removed from the listing
    at any time by the owner of the address.
    This is very useful for key discovery:
    if a search by email address returns a key,
    it means this is the single key
    that is currently valid for the searched email address.
    <h4>Support in Enigmail and OpenKeychain</h4>
    <p>
    The <span class="brand">keys.openpgp.org</span> keysever
    will receive first-party support in upcoming releases of
    <a href="https://enigmail.net" target="_blank">Enigmail</a> for Thunderbird,
    as well as
    <a href="https://play.google.com/store/apps/details?id=org.sufficientlysecure.keychain&hl=en">OpenKeychain</a> on Android.
    This means users of those implementations will
    benefit from the faster response times,
    and improved key discovery by email address.
    We hope that this will also give us some momentum
    to build this project into a bigger community effort.
    <h4 id="2019-06-12-launch-challenges">Current challenges</h4>
    <p>
    Privacy-preserving techniques in keyservers are still new,
    and sadly there are still a few compatibility issues
    caused by splitting out identity information.
    <p>
    In particular, when GnuPG (as of this writing, version 2.2.16) encounters
    an OpenPGP key without identities,
    it throws an error "no user ID"
    and does not process new non-identity information
    (like revocation certificates)
    even if it is cryptographically valid.
    We are actively engaged in
    providing fixes for these issues.
    <h4>The future</h4>
    <p>
    Privacy-preserving techniques in keyservers are still new,
    and we have more ideas for reducing the metadata.
    But for now, our plan is only to
    keep <span class="brand">keys.openpgp.org</span> reliable and fast 🐇,
    fix any upcoming bugs 🐞,
    and <a href="/about#community">listen to feedback</a> from the community. 👂
    <p>
    For more info, head on over to
    our <a target="_blank" href="/about">about page</a>
    and <a target="_blank" href="/about/faq">FAQ</a> pages.
    You can get started right away
    by <a href="/upload" target="_blank">uploading your your key</a>!
    Beyond that there is more cool stuff to discover,
    like our <a target="_blank" href="/about/api">API</a>,
    and an <a target="_blank" href="/about/faq#tor">Onion Service</a>!
    <p>
    Cheers!
    <span style="font-size: x-large;">🍻</span>
</div>
{{/layout}}
							
							
							
						
@@ -1,104 +0,0 @@
{{#> layout }}
<div class="about">
    <center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | <a href="/about/faq">FAQ</a> | <a href="/about/stats">Stats</a> | Privacy</h2></center>
    <h3>Name and contact details</h3>
    <p>
        <span class="brand">keys.openpgp.org</span> is a community effort.
        You can find more information about us, and our contact, details <a href="https://keys.openpgp.org/about">here</a>.
    </p>
    <h3>How we process data</h3>
    <p>
        The public keyserver running on <span class="brand">keys.openpgp.org</span> processes, stores, and distributes OpenPGP certificate data.
        The specific way in which data is processed differs by type as follows:
    </p>
    <ul>
        <li>
            <h4>Email Addresses</h4>
            <p>
                Email addresses of individuals contained in <abbr title="Packet Tag 13">User IDs</abbr> are personal data.
                Special care is taken to make sure they are used only with consent, which you can withdraw at any time:
            </p>
            <ul>
                <li>Publishing requires double opt-in validation, to prove ownership of the email address in question.</li>
                <li>Addresses are searchable by exact email address, but not by associated name.</li>
                <li>Enumeration of addresses is not possible.</li>
                <li>Deletion of addresses is possible via simple proof of ownership in an automated fashion, similar to publication, using the <a href="https://keys.openpgp.org/manage">“manage“ tool</a>. To unlist an address where this isn't possible, write to support at keys dot openpgp dot org.</li>
            </ul>
            <p>
                This data is never handed collectively (“as a dump“) to third parties.
            </p>
        </li>
        <li>
            <h4>Public Key Data</h4>
            <p>
                We process the cryptographic content of OpenPGP certificates - such as public key material, self-signatures, and revocation signatures – for the legitimate interest of providing the service.
            </p>
            <p>
                This data is not usually collectively available (“as a dump“), but may be handed upon request to third parties for purposes of development or research.
            </p>
            <p>
                If you upload your OpenPGP certificates to the service, you are the source of this data.
                It is also possible for anyone who has your public OpenPGP certificate to upload them to this service – for example, if you have published them somewhere else, or sent them to someone. This does not include publication of Email Addresses, which are only used with explicit consent as described above.
            </p>
        </li>
        <li>
            <h4>Other User ID data</h4>
            <p>
                An OpenPGP certificate may contain personal data other than email addresses, such as User IDs that do not contain email addresses, or image attributes.
                This data is stripped during upload and never stored, processed, or distributed in any way.
            </p>
            <p>
                OpenPGP packet types that were not specifically mentioned above are stripped during upload and never stored, processed or distributed in any way.
            </p>
        </li>
    </ul>
    <p>
        Data is never relayed to third parties outside of what is available from the public API interfaces, and what is described in this policy and on our <a href="https://keys.openpgp.org/about">about page</a>.
    </p>
    <p>
        This service is available on the Internet, so anyone, anywhere in the world, can access it and retrieve data from it.
    </p>
    <h3>Retention periods</h3>
    <p>
        We will retain your email address linked with your OpenPGP certificates until you remove it.
        We will remove your Public Key Data if you wish, but note that anyone can re-upload it to the service, in keeping with the “public” nature of this key material.
    </p>
    <p>
        All incoming requests are logged for a period of 30 days, and only used as necessary for operation of the service.
        IP addresses are anonymized for storage.
    </p>
    <h3>Your rights</h3>
    <p>
        You can withdraw consent to the processing of your email address at any time, or erase your email addresses, using the <a href="https://keys.openpgp.org/manage">“manage“ tool</a>.
    </p>
    <p>
        You can obtain access to the personal data we process about you by viewing your OpenPGP certificates, or searching for your certificates using your email addresses, using this service.
    </p>
    <p>
        You can delete your OpenPGP certificates by emailing support at keys dot openpgp dot org, but note that anyone can upload them again. If you object to having your certificate re-uploaded, email support at keys dot openpgp dot org and we will banlist your keys.
    </p>
    <p>
        To exercise the right of portability, you can download your OpenPGP certificate using this service.
    </p>
    <p>
        If you are in the EEA or UK, you also have the right to lodge a complaint with a supervisory authority, such as your local data protection authority.
    </p>
</div>
{{/layout}}
							
							
							
						
@@ -1,33 +0,0 @@
{{#> layout }}
<div class="about">
    <center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | <a href="/about/usage">Usage</a> | <a href="/about/faq">FAQ</a> | Stats | <a href="/about/privacy">Privacy</a></h2></center>
    <h3>Verified email addresses</h3>
    <p>
      A simple statistic of the total number of email addresses that are currently verified. 📈
    </p>
    <p>
      <center><img src="/about/stats/month.png" /></center>
    </p>
    <p>
      <center><img src="/about/stats/year.png" /></center>
    </p>
    <h3>Load Average</h3>
    <p>
      The "load average" of a server is a statistic of how busy it is. Simply put:
      <ul>
        <li>0.0 means the <span class="brand">keys.openpgp.org</span> host is completely idle</li>
        <li>1.0 is fairly busy</li>
        <li>4.0 and above means it's on fire 🔥</li>
      </ul>
    </p>
    <p>
      <center><img src="/about/stats/load_week.png" /></center>
    </p>
</div>
{{/layout}}
							
							
							
						
@@ -1,223 +0,0 @@
{{#> layout }}
<div class="about usage">
    <center><h2><a href="/about">About</a> | <a href="/about/news">News</a> | Usage | <a href="/about/faq">FAQ</a> | <a href="/about/stats">Stats</a> | <a href="/about/privacy">Privacy</a></h2></center>
    <p>
        On this page, we collect information on how to use
        <span class="brand">keys.openpgp.org</span> with different OpenPGP
        software products.<br />
        We are still in the process of adding more. If you are missing some, please
        write to us and we'll try to add it.
    </p>
    <h2 id="web" style="padding-left: 3%;">
        <a href="#web">Web Interface</a>
    </h2>
    <p>
        The web interface on <span class="brand">keys.openpgp.org</span> allows you to:
    </p>
    <p>
        <ul>
            <li><a href="/">Search</a> for keys manually, by fingerprint or email address.</li>
            <li><a href="/upload">Upload</a> keys manually, and verify them after upload.</li>
            <li><a href="/manage">Manage</a> your keys, and remove published identities.</li>
        </ul>
    </p>
    <h2 id="enigmail">
        <div><img src="/assets/img/enigmail.svg"></div>
        <a href="#enigmail">Enigmail</a>
    </h2>
    <p>
        <a href="https://enigmail.net" target="_blank">Enigmail</a> for Thunderbird
        uses <span class="brand">keys.openpgp.org</span> by default since
        version 2.0.12.
    </p>
    <p>Full support is available since Enigmail 2.1
        (for <a href="https://www.thunderbird.net/en-US/thunderbird/68.0beta/releasenotes/" target="_blank">Thunderbird 68</a> or newer):
        <ul>
            <li>Keys will be kept up to date automatically.</li>
            <li>During key creation, you can upload and verify your key.</li>
            <li>Keys can be discovered by email address.</li>
        </ul>
    </p>
    <h2 id="gpg-suite">
        <div><img src="/assets/img/gpgtools.png"></div>
        <a href="#gpg-suite">GPG Suite</a>
    </h2>
    <p>
        <a href="https://gpgtools.org/">GPG Suite</a> for macOS
        uses <span class="brand">keys.openpgp.org</span> by default
        since August 2019.
    </p>
    <h2 id="openkeychain">
        <div><img src="/assets/img/openkeychain.svg"></div>
        <a href="#openkeychain">OpenKeychain</a>
    </h2>
    <p>
        <a href="https://www.openkeychain.org/">OpenKeychain</a> for Android
        uses <span class="brand">keys.openpgp.org</span> by default
        since July 2019.
        <ul>
            <li>Keys will be kept up to date automatically.</li>
            <li>Keys can be discovered by email address.</li>
        </ul>
    </p>
    <p>
        Note that there is no built-in support for upload and email address verification so far.
    </p>
    <h2 id="pignus">
        <div><img src="/assets/img/pignus.png"></div>
        <a href="#pignus">Pignus</a>
    </h2>
    <p>
        <a href="https://www.frobese.de/pignus/">Pignus</a> for iOS
        uses <span class="brand">keys.openpgp.org</span> by default
        since November 2019.
        <ul>
            <li>Your keys can be uploaded at any time.</li>
            <li>Keys can be discovered by email address.</li>
        </ul>
    </p>
    <h2 id="gnupg">
        <div><img src="/assets/img/gnupg.svg" /></div>
        <a href="#gnupg">GnuPG</a>
    </h2>
    <p>
        To configure <a href="https://gnupg.org">GnuPG</a>
        to use <span class="brand">keys.openpgp.org</span> as keyserver,
        add this line to your <tt>gpg.conf</tt> file:
        <blockquote>
            keyserver hkps://keys.openpgp.org
        </blockquote>
    </p>
    <h4 id="gnupg-retrieve"><a href="#gnupg-retrieve">Retrieving keys</a></h4>
    <ul>
        <li>
            To locate the key of a user, by email address:
            <blockquote>gpg --auto-key-locate keyserver --locate-keys user@example.net</blockquote>
        </li>
        <li>To refresh all your keys (e.g. new revocation certificates and subkeys):
            <blockquote>gpg --refresh-keys</blockquote>
        </li>
    </ul>
    <h4 id="gnupg-upload"><a href="#gnupg-upload">Uploading your key</a></h4>
    <p>
        Keys can be uploaded with GnuPG's <tt>--send-keys</tt> command, but
        identity information can't be verified that way to make the key
        searchable by email address (<a href="/about">what does this mean?</a>).
    </p>
    <ul>
        <li>
            You can try this shortcut for uploading your key, which outputs
            a direct link to the verification page:
            <blockquote>
                gpg --export your_address@example.net | curl -T - {{ base_uri }}
            </blockquote>
        </li>
        <li>
            Alternatively, you can export them to a file
            and select that file in the <a href="/upload" target="_blank">upload</a> page:
            <blockquote>
                gpg --export your_address@example.net &gt; my_key.pub
            </blockquote>
        </li>
    </ul>
    <h4 id="gnupg-troubleshooting"><a href="#gnupg-troubleshooting">Troubleshooting</a></h4>
    <ul>
        <li>
            Some old <tt>~/gnupg/dirmngr.conf</tt> files contain a line like this:
            <blockquote>
                hkp-cacert ~/.gnupg/sks-keyservers.netCA.pem
            </blockquote>
            <p>
                This configuration is no longer necessary,
                but prevents regular certificates from working.
                It is recommended to simply remove this line from the configuration.
            </p>
        </li>
        <li>
            While refreshing keys, you may see errors like the following:
            <blockquote>gpg: key A2604867523C7ED8: no user ID</blockquote>
            This is a <a href="https://dev.gnupg.org/T4393" target="_blank">known problem in GnuPG</a>.
            We are working with the GnuPG team to resolve this issue.
        </li>
    </ul>
    <h4 id="gnupg-tor"><a href="#gnupg-tor">Usage via Tor</a></h4>
    <p>
        For users who want to be extra careful,
        <span class="brand">keys.openpgp.org</span> can be reached anonymously as an
        <a href="https://support.torproject.org/onionservices/#onionservices-2" target="_blank">onion service</a>.
        If you have
        <a href="https://www.torproject.org/" target="_blank">Tor</a>
        installed, use the following configuration:
        <blockquote>
            keyserver hkp://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion
        </blockquote>
    </p>
    <h2 style="padding-left: 3%;" id="wkd-as-a-service">
        <a href="#wkd-as-a-service">WKD as a Service</a>
    </h2>
    <p> The Web Key Directory (WKD) is a standard for discovery of OpenPGP keys by email address, via the domain of its email provider.
        It is used to discover unknown keys in some email clients, such as <a href="https://www.gpg4win.de/about.html" target="_blank">GpgOL</a>.
    <p> <span class="brand">keys.openpgp.org</span> can be used as a managed WKD service for any domain.
        To do so, the domain simply needs a <tt>CNAME</tt> record that delegates its <tt>openpgpkey</tt> subdomain to <tt>wkd.keys.openpgp.org</tt>.
        It should be possible to do this in the web interface of any DNS hoster.
    <p> Once enabled for a domain, its verified addresses will automatically be available for lookup via WKD.
    <p> The <tt>CNAME</tt> record should look like this:
    <blockquote>
        $ drill openpgpkey.example.org<br>
        ...<br>
        openpgpkey.example.org.       300     IN      CNAME   wkd.keys.openpgp.org.
    </blockquote>
    <p> There is a simple status checker for testing the service:
    <blockquote>
        $ curl 'https://wkd.keys.openpgp.org/status/?domain=openpgpkey.example.org'<br>
        CNAME lookup ok: openpgpkey.example.org resolves to wkd.keys.openpgp.org<br>
    </blockquote>
    <p> For testing key retrieval:
    <blockquote>
        $ gpg  --locate-keys --auto-key-locate clear,nodefault,wkd address@example.org<br>
    </blockquote>
    <h2 style="padding-left: 3%;">API</h2>
    <p>
        We offer an API for integrated support in OpenPGP applications. Check
        out our <a href="/about/api">API documentation</a>.
    </p>
    <h2 style="padding-left: 3%;">Others</h2>
    <p>
        Missing a guide for your favorite implementation?  This site is
        a work-in-progress, and we are looking to improve it. Drop us a line at
        <span class="email">support at keys dot openpgp dot org</span> if you
        want to help out!
    </p>
</div>
{{/layout}}
							
							
							
						
@@ -1,31 +0,0 @@
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>keys.openpgp.org</title>
  <link href="{{ base_uri }}/atom.xml" rel="self"/>
  <id>urn:uuid:8e783366-73b1-460e-83d3-42f01046646d</id>
  <updated>2023-04-28T12:00:00Z</updated>
  <entry>
    <title>k.o.o governance 📜</title>
    <link href="{{ base_uri }}/about/news#2023-04-28-governance" />
    <updated>2023-04-28T12:00:00Z</updated>
    <id>urn:uuid:75dfcd1e-ac6a-4d1b-9d0f-0e1821322f87</id>
  </entry>
  <entry>
    <title>Celebrating 100.000 verified addresses! 📈</title>
    <link href="{{ base_uri }}/about/news#2019-11-12-celebrating-100k" />
    <updated>2019-11-12T12:00:00Z</updated>
    <id>urn:uuid:5b69781f-5aa4-4276-8d9e-6a71c896cb65</id>
  </entry>
  <entry>
    <title>Launching a new keyserver! 🚀</title>
    <link href="{{ base_uri }}/about/news#2019-06-12-launch" />
    <updated>2019-06-12T12:00:00Z</updated>
    <id>urn:uuid:a071a6dc-f8ea-43de-b853-bd6d8bbe063f</id>
  </entry>
  <entry>
    <title>Three months after launch ✨</title>
    <link href="{{ base_uri }}/about/news#2019-09-12-three-months-later" />
    <updated>2019-09-12T12:00:00Z</updated>
    <id>urn:uuid:1bd5412a-f480-4c3f-a72d-c9b7a849f544</id>
  </entry>
</feed>