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

[Alessandro Vesely]

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
> https://dev.gnupg.org/rD733acdda1a440ca38df4aa22711459af7c25cd2d


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
rfc6066).

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
recommendation.


>> 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

Best
Ale

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190214/d50b1a70/attachment.sig>