hagrid-keyserver--hagrid/dist/templates/about/news.html.hbs

{{#> 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="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 mails
        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/hagrid-keyserver/hagrid/merge_requests?scope=all&utf8=%E2%9C%93&state=merged" target="_blank">here</a>.

    <h4>Secure mail 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 mails are still delivered without encryption.

    <p>
        With MTA-STS, domain operators can indicate
        (via HTTPS)
        that their mail 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 mails 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}}