Re: [openpgp] OpenPGP Web Key Directory I-D

Bjarni Runar Einarsson <> Mon, 12 November 2018 16:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD1E2130DF2 for <>; Mon, 12 Nov 2018 08:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.305
X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lNhNKhS6tHHg for <>; Mon, 12 Nov 2018 08:37:18 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::341]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 22CF012F1AC for <>; Mon, 12 Nov 2018 08:37:17 -0800 (PST)
Received: by with SMTP id u3so3437024ota.5 for <>; Mon, 12 Nov 2018 08:37:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=sender:mime-version:subject:from:cc:in-reply-to:references :user-agent:message-id:date:openpgp:to; bh=l7i531LcDFtVU9krjsrj4FlrWVDg7oyLyb4PESlrblI=; b=AMK6I8wfIon3CuQiCEvaKQJ4+HDrnGndwFYCCwaw2tEu/k9rfdKz/44OE/YMTYJGJr 5DMT6jsHnnPRQxxjk9bS5Bp/Xr0V8eW5naUt9jF/8Papu6MbyD1weZRlWE8rhldP/E61 vFMiCdVWqxjrX3qaPhsVeEJ120v8XGrwfOxYwa3YjJdwn9f1Ad0y+KsEoj2z2f5uxLc6 VBTFtmBNL4YXY7xGo4k5uOS/1BvOUH+igMBaVCexiYi2H7/p/sfFgcx29RfPyjmBdbJB xKrTrhOzaU1Ina80CkU1A6yviwUfCRQSTjCElT557A5u89jZO98VMObALHhyQv3TdNBc x6OQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:cc:in-reply-to :references:user-agent:message-id:date:openpgp:to; bh=l7i531LcDFtVU9krjsrj4FlrWVDg7oyLyb4PESlrblI=; b=cFaMEPpVWebGSfBHBW46sDH+xvLyAejGMPCP1p7MYwiMwPxOFzravb4CAcCHs/FMP/ SkdEoNlVKhTmsxt/7Prr1Pd7OZ7YSph2saUXZm0uDMRYPMoor2nDHhRTgLDAFMuMvtWG rwSledbXdtmC81Lix7OQd4BP9H1rrsC2zuZB7Gi+MDrcKHpqISGOv3U+rsmLDg9TmiSE lsr+O36HaM1D05KCdK/NcfQ0IHJBFq0ItYrQ0Yx/xM8O35b9lJ/6Cg/vTvBcdekrOwHV ninFlpQUFMcqm24u/Bi3aBFUyzP8PWS7UFNxsIpOplPLg3ZiF/oLjbiQ7ivZXHjcIlDc HI7A==
X-Gm-Message-State: AGRZ1gJp3ea9mTMWDtaT65WcssKC6u2WaMVqlfBhmPRPFheWhdAjUlVp Ug3IAJEEvSS4+JmceAhC1rsM3956Azs=
X-Google-Smtp-Source: AJdET5eJhs2mUyh8WFmqWOtChRjv+0QQzv/mUFJiqPKT9mpr2wGoYa1xyuaC3cbhMvhTbXUw+CATng==
X-Received: by 2002:a9d:118a:: with SMTP id v10mr913341otf.281.1542040636850; Mon, 12 Nov 2018 08:37:16 -0800 (PST)
Received: from mailpile.local ([]) by with ESMTPSA id f9sm6873511oth.17.2018. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 08:37:16 -0800 (PST)
Sender: =?UTF-8?Q?Bjarni_R=C3=BAnar_Einarsson?= <>
Content-Type: multipart/mixed; boundary="==g5yJGnbfeNsHkeFwujIbKv4cvvFpYY=="
MIME-Version: 1.0
From: Bjarni Runar Einarsson <>
Cc: "Paul Fawkesley" <>, "" <>
In-Reply-To: <>
References: <>
User-Agent: Mailpile
Message-Id: <DiIWPgMENERRi7akurqzJbz8IyvtxcuHX2bdNqRr22db@mailpile>
Date: Mon, 12 Nov 2018 16:33:33 -0000
OpenPGP: id=61A015763D28D410A87B197328191D9B3B4199B4; preference=signencrypt
To: "Werner Koch" <>
Archived-At: <>
Subject: Re: [openpgp] OpenPGP Web Key Directory I-D
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Nov 2018 17:15:08 -0000

Hash: SHA512

Hello all!

Werner Koch <>; wrote:
> > Given that SRV records can't be accessed by Javascript implementations,
> > I don't think we can point to that as a solution
> It is a pity that solid network techniques need to be dropped
> in favor of large but uncooperative browser vendors. Adding an
> interface for SRV records would be really easy and helps to
> support flexible network administration. Note that I don't
> wan't them to use SRV records for generic http requests but
> extensions should be able to use it instead of resorting to
> external DNS lookup providers.

On behalf of Mailpile, I'd just like to speak up and say I am
very glad to hear we are moving away from SRV records.

Mailpile tries very hard to protect the privacy of its users;
when fetching things from the public Internet (usually the web),
the easiest way to do that is to route the requests over Tor.

This is very easy for HTTPS - so looking up keys at predictable,
stable HTTPS URLs (exactly what the format of the URL is, doesn't
matter much) is something we are very comfortable and happy to
do. This means WKD (w/o SRV records) is currently our preferred
mechanism for discovering keys that we haven't already received
over AutoCrypt or imported by hand.

If I were to implement support for SRV records, that would mean I
can no longer rely on Tor to do that for us, but need to start
thinking about DNS-over-HTTPS or other emerging standards (or,
hacks ;-) in order to maintain the same security/privacy
guarantees. It's just more complicated to do in a
privacy-preserving fashion, which means in any resource-starved
project (aren't we all?) it might not happen at all.

I'm very happy not to have to deal with that.

> First try
> if that host can't be resolved (or accessed?), fallback to
> be a practical replacement for SRV records here?

This works well for Mailpile.

I might be tempted to suggest trying the bare domain first, and as a fallback, simply because from a
privacy point of view that leaks less information about what the
client is doing.

But I understand this would probably waste more bytes/CPU cycles
and it requires more complicated logic to determine when to fall
back, and when to treat the server's 404 as final. So it may not
be worth it.

I am also quite happy with the ?l=... solution to expose the
original e-mail address to servers who want to be smarter than
can be accommodated with a fixed hash in the filesystem.

In general, I applaud the fact that this appears to be converging
on something that is dead-simple to implement both on the client
and the server, even if the "fixed subdomain" is a hack from a
protocol-purity point of view. It's pragmatic and it works, which
is (IMO) exactly what we need in this space.

All the best,
 - Bjarni

- -- lets your personal computer be part of the web