The "advanced" URL of openpgp-webkey-service-07, and l=
vesely at tana.it
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 tana.it said:
>> WELLKNOWN := https://openpgpkey.example.org/.well-known/example.org/openpgpkey
>> doesn't seem to make much sense to me. I tried it with posteo.de, 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 example.org is a single domain, it is
probably convenient to alias both /.well-known/openpgpkey/example.org 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 openpgpkey.example.com and openpgpkey.example.org
> to, say, webkeys.example.com but keep the path to avoid CSRF. Then you
> can install gpg-wks-server on the webkeys.example.com 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
Thank you for your attention
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the Gnupg-users