WKD proper behavior on fetch error

[raf]

On Sat, Jan 16, 2021 at 02:25:14AM +0100, Ángel <angel at pgp.16bits.net> wrote:

> On 2021-01-15 at 20:34 +0100, Stefan Claas via Gnupg-users wrote:
> > My intention was only to promote WKD OpenPGP usage for github.io
> > pages in case people like the idea.
> 
> This was a good idea, but github pages don't seem to support being used
> for WKD (due to the mentioned wildcard issues).

Is it a good idea, though? I'm not sure that many
people would want to change their email addresses so as
to end in @something.github.io just so that they could
then use WKD with github.io. How would that even work?

For example, sac001.github.io doesn't have an MX
record, so email can't be sent to any address with that
as the domain. Github doesn't support adding MX records
for sub-domains to their DNS servers. Even if they did,
you'd still need to set up an email server wherever the
MX record points to anyway. github.io is for setting up
web pages, not email addresses or email accounts.

I must be missing something, but I can't see how a
github.io email address can be connected to an actual
email server or email account, so I can't see how WKD
could be used in connection with github.io email
addresses.

The problem isn't just github doing DNS wildcarding
without the corresponding valid TLS wildcarding,
combined with gnupg not failing over to the direct
method when the advanced method fails. The problem is
that WKD is a protocol for automatically and reliably
mapping an email address to its corresponding public
key, and github.io doesn't support email addresses or
email accounts.

While gnupg's behaviour could be changed (in one or two
different ways) to workaround github.io's
mis-configuration (assuming there are no adverse
security or maintenance implications in doing so),
would that actually solve this problem? I don't think
it would. It wouldn't make github.io email addresses
suddenly become possible.

The only way I can see for this to work at all, is if
all WKD clients were also changed so as to be able to
use one fake "email address", solely for the purpose of
obtaining a public key (that is stored on github.io),
but then using that key to encrypt emails to a
completely different real email address (that has
nothing to do with github.io).

That seems to contradict the rationale for WKD, which
is to have a way of automatically finding the key
that you know really belongs to whoever owns the email
address that emails are being encrypted to. The above
change doesn't sound any better than the pre-WKD
situation of looking up a key from an arbitrary key
server and hoping that it's the right one.

Section 3 of the WKD draft outlines the rationale:

  https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11

I know that sequoia does failover to the direct method
when the advanced method fails, but their stated reason
for doing that wasn't related to github.io. So it seems
that there are use cases where failing over to the
direct method can be helpful, but I don't see how it
can help with github.io specifically.

But that could be due to my ignorance of something
important, or just a lack of imagination. :-)
But a bit of googling seems to confirm my thinking.

  https://webmasters.stackexchange.com/questions/127564/how-to-setup-domain-email-for-a-site-that-uses-github-pages
  https://www.breck-mckye.com/blog/2020/05/Setting-up-a-static-site-and-personal-email-without-paying-for-hosting/

Both of these links seem to indicate that combining
email and github.io requires a separate domain that you
control, where github.io only provides the web hosting.
It doesn't provide the email address. If you have a
domain that you control, you can easily avoid the
advanced method by not implementing it. But I think
avoiding having to pay for things like a domain was
part of the rationale for this WKD+github.io proposal.

cheers,
raf