Web Key Service server lookup

[Bernhard Reiter]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20161101/34dff949/attachment.sig>