Please tackle the Right Thing

[André Colomb]

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 <andre at colomb.de>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210122/5f429f78/attachment.sig>