WKD: Subdomain openpgpkey

[Ángel]

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
DNS.

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

Regards