WKD proper behavior on fetch error

[Ángel]

On 2021-01-17 at 00:28 +0100, Stefan Claas wrote:
> On Sun, Jan 17, 2021 at 12:09 AM raf wrote:
> > What you refer to as "proper" is just the direct method.
> > That's only half of the WKD protocol. There is also the
> > advanced method. Both methods together comprise the WKD
> > protocol.
> 
> And in the case of GnuPG and gpg4win it does not work
> like one would expect, if the direct method is part of the
> protocol, because it will not be triggered if an error occurs
> with the advanced method.


It is part of the protocol, under certain rules:
> Only if the required sub-domain does not exist, they SHOULD
> fall back to the direct method.
(from section 3.1)

The sub-domain exists, and thus gnupg does not fall back to the direct
method.


I guess most people (still) reading this thread to be somewhat familiar
with their local driving regulation (however that is called).


Let's suppose we were all building autonomous cars, intended to be
driven¹ in San Serriffe, where the law stated:
> When approaching a road intersection, the driver² must first
> determine if there is a traffic light, in which case they are allowed
> to cross it if it is Green. Else, they should verify if there is a
> zebra crossing, and can go through if there is no pedestrian on it.



The current discussion is analogous to having a car approaching an
intersection where there is a red traffic light lit and a zebra
crossing with no people.

One brand of car sees the red light and stops. The other falls back to
looking at the zebra crossing and goes through.







> You know what I like in the whole discussion most ,that people
> always assume, when trying to convince me, that like
> you say, that I am not familiar enough with this and
> that and when I counter argument that I do not yet have received
> here a simple answer, for all laymens here reading, why
> can GnuPG or gpg4win not fallback or test the availabilty
> of the direct-method? I thing it is a quite simple question
> and nor Werner or anybody else can, so it seems, answer
> this. The only satisfactory and honest answer came only
> from Neal so far, explaining why it properly works with
> sequoia-pgp.

GnuPG (gpg4win is just including GnuPG) see that the advanced method is
available, so why should they fall back to the direct method?
Of course, the code *could* be changed to do that, but there should be
a reason. Similarly, some San Seriffe car owners could argue that if a
pedestrian crosses the road not on a zebra crossing, the proper action
by their car was to run over them. The car manufacturers may still
prefer not to do that.




¹ Or may be just "observed while it drives itself"
² Usually human, but the car in this case


> You can assume what ever you like and try to convince me,
> but sorry to say this, fact is sequoia-pgp works and GnuPG
> and gpg4win does not.

That highly depends on what you consider to be "working". You
have a certificate error on https://yourbank.de. Browser A
simply shows an error to the user. Browser B automatically goes to 
http://yourbank.de, letting the user perform their banking there.

Which browser "works"?



> My advise would be that Werner thinks of proper wildcard
> subdomain support, like my Github case and as already
> suggested (as I have seen now) to give WKD users are
> *clear* picture.

There is no "wildcard subdomain support" issue for TLS certificates.
Both GnuPG and sequoia agree that the certificate presented by
github.io for the advanced method is invalid.



If you mean for wildcard DNS subdomains, that was already taken into
account months ago in the draft, it even hints at how domain owners can
avoid this issue:

> Sites which do not use the advanced method but employ wildcard DNS
> for their sub-domains MUST make sure that the "openpgpkey" sub-domain
> is not subject to the wildcarding.  This can be done by inserting an
> empty TXT RR for this sub-domain.



Best regards