WKD: Subdomain openpgpkey

[Bernhard Reiter]

Werner,
when talking about this, Christoph and I thought about how to implement
a WKD request without using GnuPG (in places where it is not easily 
available).

We found that the current WKD draft [1] in practical terms seems to demand an 
explicit DNS resolve attempt in many situations. The reason is that
some connection libraries would not allow to easily make a distinction
between a failed connection for network error from a name resolution error or 
for a different reason.

An example in
Python 3.7.3 (default, Jan 22 2021, 20:04:44) 
>>> import requests
>>> requests.__version__
'2.21.0'
>>> r= 
requests.get('https://openpgpkey.intevation.de/.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe')
[..]
requests.exceptions.ConnectionError: 
HTTPSConnectionPool(host='openpgpkey.intevation.de', port=443): Max retries 
exceeded with 
url: /.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe 
(Caused by NewConnectionError('<urllib3.connection.VerifiedHTTPSConnection 
object at 0x7fcb0d9ec208>: Failed to establish a new connection: [Errno -2] 
Name or service not known'))

This has the information in the string, so we would need to match
 "Name or service not known" to make the distinction.
Which is possible but not nice.

And additional call would be better, like
  import socket
  try:
    socket.getaddrinfo("openpgpkey.intevation.de", "443")
  except socket.gaierror:
    # try direct method

In a browser console (chromium  95.0.4638.69) we have not yet found how to get
that information at all:

url='https://openpgpkey.intevation.de/.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe'
p = fetch(url)
Promise {<pending>}
VM398:1 GET 
https://openpgpkey.intevation.de/.well-known/openpgpkey/intevation.de/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe 
net::ERR_FAILED
VM398:1 
 Uncaught (in promise) TypeError: Failed to fetch
    at <anonymous>:1:5
console.log(p)

The console shows part of the into in the "net::ERR_FAILED" message, but this 
is not directly available from the variable p.
The documentation says
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch#checking_that_the_fetch_was_successful
"A fetch() promise will reject with a TypeError when a network error is 
encountered or CORS is misconfigured on the server-side, although this 
usually means permission issues or similar "

Maybe this is the same in other libraries as well: the return of a TLS 
connection attempt may not be structured well enough that it can be (easily 
or at all) seen that it the DNS resolved okay, but something else (like TLS, 
CORS, network connection problems) has happened. A clear test would need a 
different (library) function call.

For browser extentions like Mailvelope there is no way to know in Chromium.
It could do a new dns.resolve() now, but see the nonexistent support in other
browsers:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/dns

Even if the environement of the WKD request implementation offers a DNS
resolve function, in the case of a DNS not resolving because of a network 
error, we still cannot be sure that no DNS entry exists.

Would'nt it be easier then to say:
  * Try to resolve the advanced WKD request for the email address in
    question. And if the network connection fails, you SHOULD try the direct
    method.

We considered using the mentioned test 
     WELLKNOWN/policy
     Clients may use this file to check for Web Key Directory support.
as a test for the advanced method, but this would be one additional request
each time the attempt to get one specific pubkey via advanced WKD fails
before the direct method could be tried. Or one connection attempt each time 
before trying the advanced method. But this would not be enough for the 
current criteria of selecting the direct method in the draft.
Wouldn't it be an improvement to be more symmetric here? E.g. like if a 
network request to the advanced method policy file fails, try the direct 
method policy file and if that network request fails, assume no support for 
WKD (for now.)

Best Regards,
Bernhard


[1]  https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/13/
reads

 Implementations MUST first try the advance method. 
 Only if an address for the required sub-domain does not
 exist, they SHOULD fall back to the direct method.  A non-responding
 server does not mean that the fall back should be carried out.

-- 
www.intevation.de/~bernhard   +49 541 33 508 3-3
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: This is a digitally signed message part.
URL: <https://lists.gnupg.org/pipermail/gnupg-devel/attachments/20211117/792336f0/attachment.sig>