WKD proper behavior on fetch error
gnupg at eckner.net
Sun Jan 17 18:53:29 CET 2021
-----BEGIN PGP SIGNED MESSAGE-----
On Sun, 17 Jan 2021, Ingo Klöcker wrote:
> On Sonntag, 17. Januar 2021 10:48:17 CET Erich Eckner via Gnupg-users wrote:
>> Hi all,
>> On Thu, 14 Jan 2021, Werner Koch via Gnupg-users wrote:
>>> On Thu, 14 Jan 2021 01:47, Ángel said:
>>>> I understand this to mean it as "only use the direct method if the
>>>> required sub-domain does not exist", with the SHOULD meaning that the
>>>> direct method is not required (not sure why, I would have probably used
>>> Right. The subdomain is actually a workaround for SRV RR. We can't
>>> use the latter in browser based implementation and thus need to resort
>>> to this hack.
>> Forgive my ignorance, but can someone explain, what "browser based
>> implementation" of WKD exists (or might exist) and/or why this is
> https://openpgpjs.org/ supports WKD. OpenPGP.js is used by many web
> applications (see link). This is desirable to allow webmailers (and other web
> applications that support OpenPGP) to lookup OpenPGP keys via WKD.
Ah, yes, I didn't see the possibility/need to have the keyring in the
browser (or no keyring at all) and receive keys from within the browser.
Thanks for the pointers!
And I assume, it's non-trivial or even impossible to start proper DNS
queries (for a SRV record) from within JS?
Because it seems to me, the root for this debate is in gnupg's "ab"use of
a subdomain for something which should actually be a SRV record. (Plus the
fact, that DNS wildcards and TLS wildcard certficates work differently.)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
More information about the Gnupg-users