WKD: Subdomain openpgpkey

Ángel angel at pgp.16bits.net
Mon Nov 29 03:08:37 CET 2021

On 2021-11-17 at 15:49 +0100, Bernhard Reiter wrote:
> Even if the environement of the WKD request implementation offers a DNS
> resolve function, in the case of a DNS not resolving because of a network 
> error, we still cannot be sure that no DNS entry exists.
> Wouldn't it be easier then to say:
>   * Try to resolve the advanced WKD request for the email address in
>     question. And if the network connection fails, you SHOULD try the direct
>     method.

> We considered using the mentioned test 
>      WELLKNOWN/policy
>      Clients may use this file to check for Web Key Directory support.
> as a test for the advanced method, but this would be one additional request
> each time the attempt to get one specific pubkey via advanced WKD fails
> before the direct method could be tried. Or one connection attempt each time 
> before trying the advanced method.

You could cache for X time that domain Y has no advanced WKD support.

> But this would not be enough for the 
> current criteria of selecting the direct method in the draft.
> Wouldn't it be an improvement to be more symmetric here? E.g. like if a 
> network request to the advanced method policy file fails, try the direct 
> method policy file and if that network request fails, assume no support for 
> WKD (for now.)

+1. Sorry, Werner, but I think it should check if there is a WKD
repository there, not just a DNS entry. Of course, no DNS entry allows
you to skip it directly, but for detection, checking if there is an
actual WKD there (by existence of the keys and/or the policy file)
would simplify both the keys as well as the administration, by
simplifying the need to insert additional rr to remove disable wildcard

I don't see a huge gain on forcing the fetch to fail for a non-
responsive *potential* advanced server, rather than falling back.
There's a potential leak of the request to those running the apex
server, but you can avoid that if you first check that there is a
policy file in the DIRECT method.
You might choose a different policy if you have reason to think that
there is an advanced server (e.g. you contacted it before) but just the
DNS entry is fragile by itself


More information about the Gnupg-devel mailing list