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

Werner Koch <> Thu, 08 November 2018 12:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B4E9130E6A for <>; Thu, 8 Nov 2018 04:05:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aeA0IvAKgsxc for <>; Thu, 8 Nov 2018 04:05:11 -0800 (PST)
Received: from ( [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D75B130E46 for <>; Thu, 8 Nov 2018 04:05:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=C1KU56KzMnIHgcbGhrvPhIh4KdkkYWMPvbXqDAbrUMY=; b=VMIJuerEv5S/1KrA0ydJ6yqWYk Lc+jlBqMTt5webptbZt+rqcg9fkM6vY2sjyB2B7MdM0XHunIPYaWe/Xi/V7Q9SrQRK+fRe3Ut1z/e 2OVbo8HZMBneUx1T1g7XPkC4Ro2Yj/nWjF46EeMhuBJ/JTrTyp8a/7ESE2bMMQwOgJC8=;
Received: from uucp by with local-rmail (Exim 4.89 #1 (Debian)) id 1gKj3d-0002Qv-0S for <>; Thu, 08 Nov 2018 13:05:09 +0100
Received: from wk by with local (Exim 4.84 #3 (Debian)) id 1gKizA-0005Fo-6m; Thu, 08 Nov 2018 13:00:32 +0100
From: Werner Koch <>
To: Paul Fawkesley <>
References: <> <> <>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Paul Fawkesley <>,
Date: Thu, 08 Nov 2018 13:00:31 +0100
In-Reply-To: <> (Paul Fawkesley's message of "Thu, 8 Nov 2018 11:08:23 +0000")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=Fortezza_mindwar_MIT-LL_United_Nations_UNSCOM_Security_Council=Venez"; micalg=pgp-sha256; protocol="application/pgp-signature"
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: Thu, 08 Nov 2018 12:05:14 -0000

On Thu,  8 Nov 2018 12:08, 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 for
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 case
> 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

No hashing is required, the case is not changed; the parameters undergo
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-insensitive
and I would like to implement '+' style sub-addresses; that is ignoring
everything from '+' to '@'.

> 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.  [Arggh, it is the whole
everything must be http thing - I bet we will sooner or later see a new
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

if that host can't be resolved (or accessed?), fallback to

be a practical replacement for SRV records here?



Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.