Please tackle the Right Thing

[André Colomb]

On 23/01/2021 04.17, Ángel wrote:
>> 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.

Very good point.  So that could be the second definite point to decide
that the advanced method should be working and not fall back to direct.

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

Obviously another case where the draft is not clear enough, as it leads
to the same setup working with some clients, but not others.  The
current draft has this to say about the policy file checking:

[Section 3.1]
   The server MUST serve a Policy Flags file as specified below.  That
   file is even required if the Web Key Directory Update Protocol is not
   supported.

[Section 4.5]
   A site supporting the Web Key Directory MUST serve this file; it is
   sufficient if that file has a zero length.  Clients may use this file
   to check for Web Key Directory support.

> 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):
> 
> [...]
> 
> and over the course of the days, I have only become more convinced that
> this would be a good idea.

I agree it's a nice possibility to explicitly control the fallback
cases.  How about this suggested wording to specify client behavior:

[Section 3.1]
   There are two variants on how to form the request URI: The advanced
   and the direct method.  For either method, client implementations
   MUST first request the Policy Flags file at its respective location,
   described below.  Implementations MUST first try the advanced method.
   If that results in a successful HTTP response (e.g. status code 2xx)
   for the Policy Flags file, it proves the intention to use the chosen
   method, so the client MUST NOT fall back to a different method, even
   when the request for the key itself indicates an error (e.g. not
   found).  If the Policy Flags file is inaccessible, they MUST fall
   back to the direct method.

   If the required sub-domain exists, but other errors occur during the
   connection, implementations 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).

[Section 4.5]
   A site supporting the Web Key Directory MUST serve this file; it is
   sufficient if that file has a zero length.  Clients MUST use this
   file to check for Web Key Directory support, before sending requests
   for any actual keys.


Probably still rough around the edges and maybe not quite clear enough,
but it's a starting point to attract comments on the approach.

By the way, is there something like a repository to send and discuss
pull requests against the WKD draft document?  Or is it just
hand-crafted text edited by the submitter based on suggestions?

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/20210127/cdc50109/attachment.sig>