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
