AW: Web Key Service server lookup

[Jürgen Schäpker]

Hi Bernhard,

>However the problem is that we'd need a TLS certificate for the subdomain.
>That is even harder than getting a TLS cert for the example.org domain,
>so it does not seem to be a good solution.

I would think this is usually solved by wildcard certificates.

Regarding the lookup proposed solution:
One idea would be to allow parallel lookups and using the results retrieved by priority when the timeout expired and the highest priority (WKD) did not deliver anything before timeout. I'd think timeout could be limited to a (user-customizable) low value like e.g. 20 seconds, maybe more for mobile.

Another potential issue in the draft: the domain-part seems to be taken from the request URL. In a number of hosting configurations, e.g. via reverse proxy, the request URL might by default be rewritten (though in some configurations it might be recoverable from X-Forwarded-Host header). In case the original requester host cannot be determined, this would create potential collisions on WKDs answering for multiple domains, e.g. it couldn't discern the hashes for joe at for.com and joe at bar.com.

Wouldn't it be better if the hash was calculated for the full email address?

Best regards,
JS

-----Ursprüngliche Nachricht-----
Von: Bernhard Reiter [mailto:bernhard at intevation.de] 
Gesendet: Dienstag, 1. November 2016 09:02
An: gnupg-devel at gnupg.org
Betreff: Re: Web Key Service server lookup

Moin Jürgen,

Am Freitag 28 Oktober 2016 10:58:59 schrieb Jürgen Schäpker:
> thanks for the answer, Werner. I’m still not sure what the functional
> advantage is for using binary instead of armored, though.

the question is: What is the drawback of using binary?
Peter Fischer <p.fischer at heinlein-support.de> suggested to allow
armoured as well, so they could just take the input data without checking.

> An idea on setup 
> simplicity: currently the request URL is composed as
> https://example.org/.well-known/openpgpkey/hu/XXXX
> This usually requires some form of redirection to the actual WKD server
> (when it’s not the same as the one running at example.org). 

Yes, we must attach this to the domain part of the intended recipient's email 
address, because this is all we have to verify.

> To make life easier for admins (specifically in small business scenarios) 
> I would like to suggest that if
> https://example.org/.well-known/openpgpkey/hu/XXXX 
> returns a 404 or timeout error, another attempt should be made at a
> subdomain like https://keys.example.org/.well-known/openpgpkey/hu/XXXX (or
> https://wkd.example.org/.well-known/openpgpkey/hu/XXXX). I imagine this
> could ease setting up a WKD server significantly (e.g. when modifications
> to a main server are difficult because of bureaucracy etc).

We are also thinking about potential solutions to this problem.
However the problem is that we'd need a TLS certificate for the subdomain.
That is even harder than getting a TLS cert for the example.org domain,
so it does not seem to be a good solution.

And if we are not requiring a domain check via TLS, then we could use any 
domain name that has been placed in DNS.

> https://wiki.gnupg.org/EasyGpg2016/PubkeyDistributionConcept suggests a
> priority list for looking up keys – are those lookup-attempts meant to work
> only in sequence or in parallel and what timeouts should be used?

Are you refering to the five points under "Proposed solution"?
This has not yet been fully worked out. My personal idea is that it is to be 
taken in order. Of course 2. may be tried more often even when 1. has a hit
to check for updates. 4. and 5. may be mixed, so that 4. is never applied 
alone.

Thanks for reading and commenting on our proposal! 

Best Regards,
Bernhard

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner