AW: Web Key Service server lookup

Jürgen Schäpker Juergen.Schaepker at
Tue Nov 1 12:49:59 CET 2016

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 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 and joe at

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

Best regards,

-----Ursprüngliche Nachricht-----
Von: Bernhard Reiter [mailto:bernhard at] 
Gesendet: Dienstag, 1. November 2016 09:02
An: gnupg-devel at
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> 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
> This usually requires some form of redirection to the actual WKD server
> (when it’s not the same as the one running at 

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
> returns a 404 or timeout error, another attempt should be made at a
> subdomain like (or
> 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 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.

> 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 

Thanks for reading and commenting on our proposal! 

Best Regards,

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

More information about the Gnupg-devel mailing list