On Sat, Jan 16, 2021 at 02:25:14AM +0100, Ángel <an...@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 _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users