WKD for GitHub pages

[Stefan Claas]

On Mon, Jan 11, 2021 at 11:03 PM Ángel <angel at pgp.16bits.net> wrote:
>
> On 2021-01-11 at 16:36 +0100, Stefan Claas wrote:
> > On Sun, Jan 10, 2021 at 11:22 PM Ángel wrote:
> > > On 2021-01-10 at 18:47 +0100, Stefan Claas wrote:
> > > > Can you tell me/us in laymen terms how this works with gnupg.org?
> > >
> > > Sure. Let's suppose you wanted to fetch Werner's key. You want the
> > > key
> > > for wk at gnupg.org Using --with-wkd-hash parameter, we can see that
> > > this
> > > would generate nq6t9teux7edsnwdksswydu4o9i5es3f at gnupg.org
> > >
> > > Then, the key of Werner lives at
> > > https://openpgpkey.gnupg.org/.well-known/openpgpkey/gnupg.org/hu/nq6t9teux7edsnwdksswydu4o9i5es3f
> > >
> > > If openpgpkey.gnupg.org didn't exist, then it would use the direct
> > > schema, in which the key would be at
> > > https://gnupg.org/.well-known/openpgpkey/hu/nq6t9teux7edsnwdksswydu4o9i5es3f
> >
> > Thanks, so I think the culprit could be that maybe the specs were
> > changed, when I
> > look at your links, including the gnupg.org domain as a folder, which
> > I never set-up
> > when doing this for my 300baud.de domain. I checked also older WKD
> > tutorials
> > on the Internet and they do not mention a domain folder either.
> >
> > I tried to include this domain folder, this morning, named sac001 but
> > it did not work either, whether with GnuPG or sequioa-pgp.
> >
> > So my guess is that GnuPG gives this cert error because it does not
> > support
> > wildcard subdomains, included in an SSL cert, like the GitHub one.
>
>
> The folder with the domain name is only used in the advanced method.
> Compare how the url using openpgpkey.gnupg.org above has a gnupg.org
> folder but the url of gnupg.org doesn't.

Yes, I have checked that. Noteworthy IMHO, regarding wildcard subdomains,
gnupg.org does not have such entry in the DNS section, of the cert.

> In your case, you would place your key at
>
> https://openpgpkey.300baud.de/.well-known/openpgpkey/300baud.de/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33
>
> or -if openpgpkey.300baud.de doesn't exist- at
>
> https://300baud.de/.well-known/openpgpkey/hu/ywwzopgqx5kmisb8r18gq68h13jwdg33
>
> note that in both cases, you still need a file named policy in the same
> folder that contains hu/ (just create an empty file, but it must be
> there)

When I had that in the past, for 300baud.de I had that included,
it was an emtpy one.

> The advanced method was added in November 2018, 2.5 years ago, in
> version 7 of the draft:
> https://www.ietf.org/rfcdiff?url1=draft-koch-openpgp-webkey-service-06&url2=draft-koch-openpgp-webkey-service-07&difftype=--html

It would be nice to know why the advanced method was added. In case
the direct method would not be sufficent or would have security issues
I would think that than one replaces the direct method with advanced
one and then we only need only one method, in order that this works.
And if we must have two methods, why is the order not, like one would
think: check direct first and if this does not work check advanced?
I must admit I do not understand the programming logic.

> It's true that draft-koch-openpgp-webkey-service doesn't specify that
> the https certificate must be valid. One would generally expect that
> https:// with no, normal rules would apply, although there is a history
> of ignoring certificate validation if keys are going to be validated
> through WoT. The "make a CNAME of your openpgpkeys subdomain to
> wkd.keys.openpgp.org" couldn't work with https certificate validation,
> thouth (or are they requesting a certificate on-the-fly?)
> Actually, I suspect that depending on how you build gnupg, it would
> validate them or not.

It should be noted that my findings and proposal for wildcard subdomains
would allow organizations and individuals to reduce costs, when using
purchased SSL certs, instead of Let's Encrypt ones. Not only this but
if this would work, like I mentioned in my bund.de example, organizations
would have the freedom to choose WKD instead of hockeypuck or Hagrid,
and they would have a compatible *inhouse* solution, via simple
Web management, instead of running a server software, like hokeypuck
or Hagrid. And In my example, with GitHub, I guess it would be fantastic
too, to promote WKD GnuPG/sequoia-pgp usage for individuals,
low on budged while not extra running an own server and purchasing
a domain.

Best regards
Stefan