WKD v05: DNS problem when requesting pubkey

[Bernhard Reiter]

Am Donnerstag 05 April 2018 12:50:57 schrieb Werner Koch:
> On Thu,  5 Apr 2018 12:02, bernhard at intevation.de said:
> > However according to my research, code running inside  a webbrowser -
> > either from a webpage or as extension - **cannot do a DNS request** on
> > its own.
>
> Which also means they can't do proper keyserver lookups.  Or implement
> XMPP or any other protocol with mandatory SRV record.  SRV records are
> in use for more than 18 years

It seems we have to accept this, whether we like it or not. :/
(At least so far everything I saw supports the statement above.)

> > Pondering other solutions: from Thomas Oberndörfer I've got the idea that
> > we could use the mandatory policy file to allow a "redirect". This may be
> > easier
>
> This does not work.  The policy file has the same well-known URL prefix
> and thus the SRV record should have already been consulted.  

My suggestion is to remove the SRV record requirement again, because otherwise 
we may exclude a significant number of users. Thus I'm thinking about better, 
but different solutions to the problem that the SRV record lookup tried to 
solve.

Another class of solutions is to but some burden on the webserver for an email 
domain in case email and web are handled by two different service provider:
And as the policy file has to be fetched by all WKD clients already, it is not 
another requesting technology, no extra request and could still do a 
redirect. Placing a fixed file on the webserver could be an easier 
requirement than configurating a redirect. However it has the drawback that 
email provider cannot controll the policy file directly. Okay, so maybe a 
https redirect is easier?

> In general 
> a SRV record is not required and I expect that most Web key directories
> won't use that anyway.  Thus the failure rate would be quite low

If this really is an edge case and it can be ignored, I'd would not handle it 
at all and remove the requirement of the SRV lookup completely to keep the 
protocal simple.

> and can maybe mitigated by a fixed list of domains which redirect to a sub
> directory.

That is another idea, thanks for bringing it up.
Thinking about it: It would mean that SRV would only work for big providers 
that register this with each Web-Extension. (You don't want to introduce a 
central fixed list, wouldn't you. ;) )

We are talking large email providers in Germany and Mailvelope having many 
users, so affected users would be hundered of thousands I guess. That is an 
motivation to put some effort in the design.

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: 488 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20180406/b89db440/attachment.sig>