WKD proper behavior on fetch error

raf gnupg at raf.org
Sat Jan 16 01:59:21 CET 2021


On Fri, Jan 15, 2021 at 07:56:26AM +0100, André Colomb <andre at colomb.de> wrote:

> Am 15. Januar 2021 01:56:04 MEZ schrieb raf via Gnupg-users <gnupg-users at gnupg.org>:
> >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.
> 
> I'll try to complete your summary. The DNS wildcard entry for
> *.example.github.io leads to the advanced method being tried. We can't
> change that entry, and therefore with the current protocol draft, it
> makes no sense forcefully wanting to use the direct method.
> 
> It's easy to set up the advanced method there. But GitHub uses an
> invalid TLS certificate for openpgpkey.example.github.io. That's what
> needs fixing and it is also out of our control.
> 
> So basically Stefan's request is to change the protocol to work around
> a misconfiguration because both DNS and the TLS certificate are
> controlled by a company that offers the service totally unrelated to
> WKD. Such a workaround could hurt the ecosystem because it may hide a
> misconfiguration in setups where the operator does have control over
> these things and just needs to notice.

That's why I thought maybe a skip list might be useful,
rather than automatically failing over to the direct
method in all cases where the advanced method is
mis-configured in some way. The user-controlled skip
list could be used in cases where the user knows that
the server administrators aren't going to fix their
system. I can totally understand a reluctance to add
workarounds to other people's bugs into your own
software. I've done that and wasn't happy about it.
But I imagine that a skip list to avoid the advanced
method for certain
known-to-be-permanently-misconfigured domains is
probably a minor instrusion into the code. But I'm just
guessing.

And for it to be of any use, github.io would have to be
in the list by default, so that all users "benefit"
from it without knowing in advance that they need it.
Of course, if github.io ever do fix their TLS system,
they would need to be removed from the skip list, which
presumably wouldn't happen until they next upgrade
gnupg. That would be a problem.

Trying to be pragmatic in the face of other people's bugs
can get tacky.

Hmm, does github itself have a bug-tracking system? :-)

> >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(?).
> 
> Sorry, you just misread that part. The stopgap solution is to use a
> server operated by openpgp.org instead of your own web server. For
> that to work, you must set up the advanced method for WKD on your
> domain's DNS. That method is perfectly fine and in some scenarios even
> easier to use.

Thanks for that. That makes more sense. I thought the
advanced method sounded quite sensible. :-)

> Kind regards
> André
> 
> Hi raf,
> 
> thanks for your perspective on the matter.
> 
> --
> Greetings...
> From: André Colomb <andre at colomb.de>

cheers,
raf




More information about the Gnupg-users mailing list