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