Please tackle the Right Thing

[Ángel]

On 2021-01-22 at 22:15 +0100, André Colomb wrote:
> Restricting to only the 200 OK status code would probably be fine.  I
> looked at the other 2xx codes and probably no others would apply to WKD.
>  Not quite sure about 228 IM Used (not familiar with RFC 3229).
> 
> I tend to disagree regarding the 404 case though.  As this thread has
> shown, there might be legitimate use cases where a WKD user has enough
> control over the domain's web server to set up the direct method.  But
> there might be a wildcard subdomain entry with a webserver and (valid)
> TLS setup, totally unrelated to WKD, which is not under the same user's
> control.  In that case, the unrelated webserver would happily answer the
> openpgpkey subdomain request, but simply not find the required directory
> structure, giving a 404.  My proposed solution would give the user a
> chance to still enjoy the WKD direct method.

That's the point where the fact that a WKD server MUST have a policy
file become useful for a fetching-only client. If it's a real WKD
server the file shall be there, if it's a 404, that's probably
meaningless.

GnuPG first tries to directly fetch the key from the url where it's
supposed to be. If it's found, it finishes there. If that's a 404, it
then check that there is a policy file (and if there's not, the process
caches in memory that there is no WKD on that place and won't contact
that server again)
On the other hand, flowcrypt first tries to read the policy file, and
only after that succeeds, does it go for the public key.


On this line, a few days ago I suggested changing the draft to require
fallback to direct if such file is missing (as opposed to considering
that the openpgpkey subdomain exists just when having an A/AAA record):

> - An idea that seems worth considering, inspired by the way flowcrypt
> does its check, is to fall back to the direct method if the
> openpgpkey subdomain exists but it doesn't serve a policy file.
> 
> This would solve the issue of non-malicious NXDOMAIN hijackings or
> DNS wildcards (assuming the certificate was valid).

https://lists.gnupg.org/pipermail/gnupg-users/2021-January/064741.html



and over the course of the days, I have only become more convinced that
this would be a good idea.

It doesn't impose any new restriction on existing servers, clarifies
when a wkd subdomain "exists" (if it has the appropiate files), neatly
solves the exposed cases of unintended wildcard domains (when properly
configured), and uses a way available for web clients (which might not
be able to obtain the DNS response).


Best regards