WKD proper behavior on fetch error

raf gnupg at raf.org
Fri Jan 15 01:56:04 CET 2021

On Thu, Jan 14, 2021 at 04:33:00PM +0100, Stefan Claas via Gnupg-users <gnupg-users at gnupg.org> wrote:

> [...] My initial post was a help request and I also explained
> why it IMHO would be good to have such a solution, which
> would not hurt the GnuPG ecosystem in any form and would be
> IMHO an enrichment for GnuPG usage.
> Best regards
> Stefan

[Note: First 3 paragraphs are mostly me being stupid -
please bear with me]

It sounded to me like you would like gnupg to have a
bug added to it, whereby it accepts invalid
certificates for sub-sub-domains, when the certificate
is only valid for sub-domains.

To me, that doesn't sound like it "would not hurt the
GnuPG ecosystem in any form". To me, that sounds like a
security bug, in the sense that it could lead users to
think that a certificate is valid, when it isn't.

If the ability to not validate certificates exists or
gets added to gnupg, it wouldn't be turned on by
default, so I'm not sure that it would even help your
use case. The only people who could fetch your keys
would be the ones who had disabled certificate

But of course, you're not asking for that. You're just
asking for something to work. There must be other ways.
Accepting invalid certificates might just have been my
first thought at how to deal with this. But that would
enable the advanced method to work (in situations where
it shouldn't). If I remember correctly (possibly not),
you wanted the direct method to work, and github.io's
mis-configuration of certificates caused the advanced
method to be attempted and fail, before the direct
method could even be attempted.

It's been suggested that, when the certificate for
openpgpkey.*.github.io is found to be invalid, WKD
clients could failover to the direct method (like
sequoia does). Then at least the direct method would
work with github.io sub-domains. That sounded good (to
a non-expert like me). But perhaps it's a bit
inefficient. But at least it's automatic.

Another possible solution might be for WKD clients to
have a list of domains to skip when doing the advanced
method. If it had "openpgpkey.*.github.io" by default,
then it would know not to try to resolve
openpgpkey.*.github.io at all. Any domain that hands
out invalid certificates for sub-sub-domains could be
in the skip list. The currently documented solution to
this expects the administrators of such
(mis-configured) domains to add DNS records to prevent
this, but when you can't rely on that happening,
allowing the client/user to exclude them could be
another option. And it wouldn't require accepting
invalid certificates. And it would eliminate the
attempt to use those domains so it would be more
efficient. But it does require additional configuration
that the above method doesn't require. A built-in
default skip list would help with that.

You still couldn't use the advanced method with
github.io (until they start issuing a wildcard
certificate for each sub-domain), but that's probably
OK. I just had a look at https://wiki.gnupg.org/WKD and
it doesn't refer to "advanced" or "direct" methods. It
seems to consider the "direct" method as the main
method, and the "advanced" method as a "Stopgap method"
which is "Not recommended - but a temporary
workaround". So having an additional mechanism to
disable the "advanced" method sounds reasonable. Or
maybe the wiki page needs to be updated(?).

I'm really not an expert, and the above might not make
any sense. I'm just thinking aloud.


More information about the Gnupg-users mailing list