The "advanced" URL of openpgp-webkey-service-07, and l=

Alessandro Vesely vesely at
Thu Feb 14 11:57:55 CET 2019

On Tue 12/Feb/2019 19:36:12 +0100 Werner Koch wrote:
> On Mon, 11 Feb 2019 14:04, vesely at said:
>> doesn't seem to make much sense to me.  I tried it with, and got:
> The two parts were accidently swapped in the I-D.  It has been corrected
> in the repo.  See

Oh, ok, that makes some more sense.  If is a single domain, it is
probably convenient to alias both /.well-known/openpgpkey/ and
/.well-known/openpgpkey/ to the same directory where keys are stored.  That way
it also stays compatible with previous versions of this protocol.

>> I'm unable to get the "flexibility in setting up the Web Key Directory
>> in environments where more than one mail domain is hosted".  Say I
>> host A.example and B.example.  Then I need to set up both subdomains
>> openpgpkey.A.example and openpgpkey.B.example.  Internally, they can
> You redirect the host and
> to, say, but keep the path to avoid CSRF.  Then you
> can install gpg-wks-server on the host using its
> default layout with a directory for each domain.  It is really
> convenient, because it requires less configuration.

I have not installed gpg-wks-server, but it seems to be primarily concerned
with automating key installation, not plain key retrieval.  To simply retrieve
a key is not a transaction, so there should be no worry of CSRF.  If the domain
is missing, as in the "direct" method, an appropriate URL rewriting rule can
easily recover it from the HTTP_HOST server variable.  I'm not clear if that
may be an urlencoded IDN rather than an A-label.

The domain name can also be recovered from the SNI (an A-label, according to

BTW, the revised reason to suppress SRV records sounds paranoid, given that
(e.g. in the case of DNS poisoning) a subdomain under an attacker control still
has to provide a valid domain certificate.  At any rate, using "wkd" rather
than "openpgpkey" as a subdomain label would have leveraged previous version's

>> What if they don't match?  To urlencode the local part might have been
>> easier than Z-encoding its SHA1, but what's the point of doing both?
> Percent-encoding does not allow to store it as plain text files because
> '/' does not need to be percent encoded and the entire length of the
> filename might get too long without using a hash.

According to rfc5321, the maximum total length of a user name or other
local-part is 64 octets.  However, yes, slashes may entail hairy scripting by
those providers who allow funny characters in their email addresses.

> The l= parameter has been added as an alternative way for looking up the
> key for those platforms which already employ databases or such and don't
> want to store extra data like a hash.

Indeed, those hashes are difficult.  However, after one learns how to do them,
they're quite handy.  Having alternative ways to retrieve (alternative?) keys
sounds strange.

Thank you for your attention


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the Gnupg-users mailing list