Please tackle the Right Thing

[Ángel]

On 2021-01-20 at 20:29 +0100, André Colomb wrote:
> Hi all,
> 
> after some more thought I came up with a possible wording to clarify
> the
> fallback behavior.  Assuming that an opportunistic approach is
> preferred, so the direct method should be used not only based on the
> existence of openpgpkey as a SRV or other record.  Here goes:
> 
> 
> ---SNIP--- (page 3, second paragraph in the current draft version 11)
> 
> There are two variants on how to form the request URI: The advanced
> and the direct method.  Implementations MUST first try the advanced
> method.
>  If that does not conclude with a successful HTTP response (e.g.
> status code 2xx), they MUST fall back to the direct method.  If the
> required sub-domain exists, but other errors occur during the
> connection, they SHOULD output an error message pointing out the
> failure reason to the end user.  Such other errors include, for
> example, invalid, expired or misconfigured TLS certificates and HTTP
> failure codes (4xx or 5xx).
> 
> ---SNIP---

Hello André

Thanks for contributing

Suitable return codes for fetching a key would be 200 (for successful
keys) and 404 (the key is not in the server). In both cases, if it is a
valid wkd server, the server shouldn't fall back to direct.

You could also have a 304 if the client was refreshing a key. Maybe 201
if a web-based submission protocol was added in the future.

https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos/ seems to expect that HTTP redirects would work as well (seems
reasonable), although it isn't explicitly stated in the document.

I think the main status that would bring such trouble would be 401,
403, 5xx, although there could be some exotic cases (e.g. 407).
Erroring to the user on any status code the client does not know how to
handle seems the safe procedure.



> So what do you think?  I'm not subscribed to any IETF mailing lists,
> but feel free to propose this in the relevant circles.  I hereby
> renounce my rights on the modified text :-)

I think the right venue would be the openpgp wg. This was discussed
there in the past, and I hope to see WKD published through it one day.
However, although there were interesting ideas on this thread for
advancing it (amidst all the generated noise), I am hesitant to open a
discussion there about wkd, since openpgp working group was recently
rechartered to produce the rfc 4880 bis, and wkd is not covered by its
current scope.
I don't think there would be opposition for adopting it if rechartering
after rfc 4880bis is out, but it's a bit odd to open a discussion about
something else before starting the actual chartered work. Maybe other
people have an opiniono on this ?


Kind regards