Page MenuHome GnuPG

WKD spec should document exactly when a client should fall back from "advanced" to "direct" URL
Open, NormalPublic



There are two variants on how to form the request URI: The advanced
and the direct method.  Implementations MUST first try the advanced
method.  Only if the required sub-domain does not exist, they SHOULD
fall back to the direct method.

But it's not clear what "the required sub-domain does not exist" means exactly. I can imagine several different implementations/interpretations:

0) is there no DNS record at all at

  1. does a DNS query for A records for return an assertion of non-existence?
  2. does a DNS query for A or AAAA records for return an assertion of non-existence (following CNAME records, if found)?
  3. are all of the A or AAAA addresses returned from such a query (after following CNAMEs) unreachable on the network?
  4. if one is reachable, but port 443 is closed?
  5. if port 443 is not closed, but the TLS handshake authentication fails?
  6. if the TLS connection completes, and an HTTP request can be sent, but the response is not an HTTP response?
  7. if the HTTP response does not return 200 for the specific lookup?
  8. if the 200 HTTP response is not a series of OpenPGP certificates?

I *think* that (2) above is the right trigger for the fallback, but i'm not sure exactly how to implement it in many HTTP client libraries that abstract away the specific failures. i'm also not exactly sure how to implement it when connecting through a SOCKS5 proxy or other situation where as a client i don't have access to the DNS queries directly. Perhaps a concrete example about how/when to fallback would be a useful contribution to the doc?

Event Timeline

This was also raised for (hopefully) wider discussion on the IETF mailing list.

werner triaged this task as Normal priority.

This ambiguity appears to be the cause of a recent epic (and to me, largely incomprehensible) thread on gnupg-users. It would be great to have the WKD guidance about fallback strategy be much more explicit. Any room for ambiguity here leads to different outcomes from different WKD clients, and quite a bit of confused discussion by their users.