Hi all, On 21/01/2021 01.29, Ángel wrote: >> 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). > > 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.
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. > 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. Agree, 304 kind of makes sense, although the WKD client first needs to implement the associated caching / Last-Modified header logic. Not sure it that's worth the effort to explicitly mention it in the WKD protocol. Other 2xx codes could be discussed. 201 Created doesn't make much sense for the GET request, but could also convey that a key was just auto-generated on the fly, e.g. for opportunistic encryption? I would understand a 204 No Content status to mean "yes, this is a WKD server and the requested user is known. There is just deliberately no key offered." In that case stopping without fallback would be desired. All of these somehow acknowledge that the requested .well-known/... resource does make sense to the responding server. Hence my proposal for a generous 2xx in the specification. > 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. Agree, let's not complicate the protocol with hard-to-implement, very specific error handling rules. One more needed change if the above proposal is accepted: ---SNIP--- (page 4, first paragraph in the current draft version 11) Sites which do not use the advanced method but employ wildcard DNS for their sub-domains MUST make sure that the "openpgpkey" sub-domain is not subject to the wildcarding. This can be done by inserting an empty TXT RR for this sub-domain. ---SNIP--- That MUST becomes a SHOULD, in order to avoid traffic by falling back early. But with the new fallback cases, it's no longer *required*. Regarding where this is discussed, I hope Werner will pick up relevant pieces for a draft version 12 in order to unify the now differing implementations. IIUC, he is the main (and only?) draft author, so before IETF gets formally involved, the draft proposal can be iterated easily. Kind regards André -- Greetings... From: André Colomb <an...@colomb.de>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
