Date: Fri, 09 Nov 2018 23:50:00 +0000
To: Bart Butler <bartbutler@protonmail.com>
From: Bart Butler <bartbutler@protonmail.com>
Cc: Werner Koch <wk@gnupg.org>, Paul Fawkesley <paul@fluidkeys.com>,
 "openpgp@ietf.org" <openpgp@ietf.org>
Reply-To: Bart Butler <bartbutler@protonmail.com>
Message-ID: <oV88O2XtRI1RpDaxMI6Yy1ivZX1-3T5iiQmVRBDdalhHgb_vlrcq5OXBc0EiyOL3_QDqnaZ0rcKcLQfzj0q8JQ==@protonmail.com>
In-Reply-To: <e8YBN6CQZpY7QiCOtFMY7IDhHVT5-gymd9AW-BgtUrGMFTQPppr_qdhcoPAYDNYXv5IXAjZi3wPakOju_5CzUg==@protonmail.com>
References: <23523.16831.292658.490356@chiark.greenend.org.uk>
 <874lcsyr3p.fsf@wheatstone.g10code.de>
 <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com>
 <87ftwbye1s.fsf@wheatstone.g10code.de>
 <e8YBN6CQZpY7QiCOtFMY7IDhHVT5-gymd9AW-BgtUrGMFTQPppr_qdhcoPAYDNYXv5IXAjZi3wPakOju_5CzUg==@protonmail.com>
Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="---------------------70162d41f57adbcaf333f3159e6b259c";
 charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Dw4-zR09MozV39JQCVgAFyOpq0s>
Subject: Re: [openpgp] OpenPGP Web Key Directory I-D
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
-----------------------70162d41f57adbcaf333f3159e6b259c
Content-Type: multipart/mixed; boundary="---------------------d5eb70f1375939dbfaf4b45c105b7524"

-----------------------d5eb70f1375939dbfaf4b45c105b7524
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

I also wanted to clarify in the WKD I-D that requests should follow HTTP r=
edirects (301, 302). As I provider we would like this so that a client usi=
ng us to host their email could just set up a redirect to our WKD server. =
It needs to be at the HTTP level rather than using a CNAME record because =
we do not want to have to host our clients' TLS certificates.

-Bart Butler

Sent from ProtonMail, encrypted email based in Switzerland.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M=
essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
On Friday, November 9, 2018 3:18 PM, Bart Butler <bartbutler=3D40protonmai=
l.com@dmarc.ietf.org> wrote:

> Hi all,
> =


> Based on discussions in Brussels, our current plan at ProtonMail is to i=
mplement, on the 'serving' side:
> =


> ..well-known/openpgpkey/hu/<hash>?l=3DJoe.Doe@example.org
> =


> accepting everything including and empty string for the hash and using t=
he 'l' query string parameter exclusively for lookup for all the reasons p=
reviously mentioned in this thread and discussed in Brussels (case sensiti=
vity, +aliases/subaddresses, Unicode, catch-all addresses). The hash would=
 be ignored.
> =


> I think that long-term, two parameters that do the same thing and could =
conflict is bad and that while compatibility is a good short-term goal, we=
 should try drop the hash and to migrate to this final form as soon as pos=
sible:
> =


> ..well-known/openpgpkey/hu/?l=3DJoe.Doe@example.org
> =


> While this doesn't allow a filesystem to serve WKD directly, I'm fairly =
certain that one could do it reasonably easily with, say mod_rewrite and s=
ome minimal transformations or use RewriteMap with a script which does whi=
chever transformation you'd like (lowercase, remove subaddresses, etc).
> =


> As for the SRV record discussion, I agree that JS support is a problem a=
nd unfortunately that means supporting HTTPS. I'm wondering if we should s=
implify this and simply mandate the 'wkd' subdomain, full stop, rather tha=
n having a fallback mechanism to the main domain. The reason for this is t=
hat a client could determine whether the HTTP lookup is worth doing from w=
hether the WKD subdomain resolves rather than making an experimental HTTP =
request for every domain periodically and contributing to the internet's 4=
04 rate.
> =


> With the current scheme, relatively high-volume clients like us would pr=
obably need to do requests for the policy document periodically for each d=
omain we send to and cache the result to avoid getting banned for generati=
ng too many 404s. The TTL for that caching would be decided by the us, the=
 client. With the 'wkd' subdomain all clients would get that kind of cachi=
ng for free via DNS, with a TTL controlled by the WKD server, which is bot=
h simpler and more logical I think.
> =


> -Bart Butler
> =


> Sent from ProtonMail, encrypted email based in Switzerland.
> =


> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original=
 Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Thursday, November 8, 2018 4:00 AM, Werner Koch wk@gnupg.org wrote:
> =


> > On Thu, 8 Nov 2018 12:08, paul@fluidkeys.com said:
> =


> > > The requirement for the client to filter the return key for matching
> > > user IDs is a fairly big blocker for us.
> =


> > We can't request a certain address and then work with any address
> > returned from the server. I am pretty sure that there will be server's
> > which store the entire key and not used the key stripped off all other
> > user-ids. Thus the filtering on the client site is important.
> =


> > > We (and previous large organisations I've worked in) use + aliases
> > > feature extensively to distinguish different services, for example:
> =


> > Yes, I know. We discussed this withe protonmail folks. One idea was to
> > ask the server for the rules it uses to canonicalize the address. That
> > will be quite complex and needs additional roundtrips. So the other
> > idea is to simply go with the '+' separator and have a special case fo=
r
> > it. Implementation wise it this requires changes at several palce to
> > have a consistent user experience.
> =


> > > To stay compatible, keep supporting static files and resolve the cas=
e
> > > and aliasing issues, I'd support:
> =


> > > 1.  keep supporting sha1-z-base-32 identifier
> =


> > Already doing that.
> =


> > > 2.  additionally start supporting z-base-32 identifier with no SHA1
> > >     2.a maybe put them at different path
> > >     2.b don't lowercase anything before searching for these
> > >     =


> =


> > =


> =


> > GnuPG 2.2.11 does this as descipned in my last mail.
> > For example the URI to lookup the key for Joe.Doe@Example.ORG is now
> =


> > https://example.org/.well-known/openpgpkey/
> > hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=3DJoe.Doe@example.org
> =


> > No hashing is required, the case is not changed; the parameters underg=
o
> > the usual percent-quoting.
> =


> > > 2.c in the client, don't filter on the user id for these
> =


> > That is the harder part. The matching in gpg is anyway case-insensitiv=
e
> > and I would like to implement '+' style sub-addresses; that is ignorin=
g
> > everything from '+' to '@'.
> =


> > > Given that SRV records can't be accessed by Javascript implementatio=
ns,
> > > 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 SR=
V
> > 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. [Arggh, it is the whole
> > everything must be http thing - I bet we will sooner or later see a ne=
w
> > IP protocol number for HTTP-ng].
> =


> > > > This is an open question but for a different reason: Current web
> > > > browsers have no way to lookup SRV records.
> =


> > > I'd support this.
> > > I'd also support dropping the whole SRV records part to simplify the=
 spec.
> =


> > I recently looked into a protocol *forgot which one) which didn't used
> > SRV but a domain name prefix. So, do you think that a strategy of:
> =


> > First try
> =


> > https://openpgpkey.example.org/.well-known/openpgpkey/...
> =


> > if that host can't be resolved (or accessed?), fallback to
> =


> > https://example.org/.well-known/openpgpkey/...
> =


> > be a practical replacement for SRV records here?
> =


> > Shalom-Salam,
> =


> > Werner
> =


> > =


> =


> > Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.


-----------------------d5eb70f1375939dbfaf4b45c105b7524--

-----------------------70162d41f57adbcaf333f3159e6b259c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail
Comment: https://protonmail.com

wl4EARYKABAFAlvmHSUJEJkFRGXvMx5EAAD0egEAuWU/Bhuw3q+aHk4eo8UD
O6tLvnxCLekoUWVcBCEOZPwA/2TD6B+im2kLSfj1TmwLtrrt+f4B/0/mzfS0
YS/J9SUE
=6BUo
-----END PGP SIGNATURE-----


-----------------------70162d41f57adbcaf333f3159e6b259c--