WKD for GitHub pages

[GnuPG - User mailing list]

Hi all,

I just started to set-up a github-page and have also verified
the page via Brave. I tried to set-up WKD for the page, like
I did in the past for my 300baud.de Domain, but fetching
the key with GnuPG does not work for me. :-(

My key UID there is '[hidden email]'

It would be really nice if a kind soul can help me to fix
the issue.

The idea here is the following:

1. A github.io pub key can IHMO serve as a multi-purpose usage
key, thus not revealing the email address.

2. GitHub should be more protected against DDOS, compared
to a website, hosted on an own VPS server, IMHO.

3. One already has an SSL cert.

4. GitHub allows creating rich-content static web pages.

5. Brave verification, so that in case one Brave user like
to give a tip, it is possible too.

6. If this would work properly, Windows users, for example,
would have an easy way to use WKD as well, without having
an own server, Domain, etc.

Hope you like the idea!

Here's is my URL, which leads to the GitHub project,
containing the .well-known folder.

https://sac001.github.io

Any help would greatly appreciated!

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[André Colomb]

Hi Stefan,

> I just started to set-up a github-page and have also verified
> the page via Brave. I tried to set-up WKD for the page, like
> I did in the past for my 300baud.de Domain, but fetching
> the key with GnuPG does not work for me. :-(

You could try the online WKD checker here:
https://metacode.biz/openpgp/web-key-directory

It reports that the policy file is missing, which I think is a hard
requirement, no?

Also make sure that the MIME content type and
Access-Control-Allow-Origin headers are set correctly.

Kind regards,
André

--
Greetings...
From: André Colomb <[hidden email]>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

Ok, had a typo in the openpgpkey folder, ouch.

Now Wiktor's WKD checker gives the proper
results in the first part, not sure why not in the
second part.

Need to try to fetch my pub key.

Regards
Stefan

On Fri, Jan 8, 2021 at 6:42 PM Stefan Claas
<[hidden email]> wrote:

>
> Hi all,
>
> I just started to set-up a github-page and have also verified
> the page via Brave. I tried to set-up WKD for the page, like
> I did in the past for my 300baud.de Domain, but fetching
> the key with GnuPG does not work for me. :-(
>
> My key UID there is '[hidden email]'
>
> It would be really nice if a kind soul can help me to fix
> the issue.
>
> The idea here is the following:
>
> 1. A github.io pub key can IHMO serve as a multi-purpose usage
> key, thus not revealing the email address.
>
> 2. GitHub should be more protected against DDOS, compared
> to a website, hosted on an own VPS server, IMHO.
>
> 3. One already has an SSL cert.
>
> 4. GitHub allows creating rich-content static web pages.
>
> 5. Brave verification, so that in case one Brave user like
> to give a tip, it is possible too.
>
> 6. If this would work properly, Windows users, for example,
> would have an easy way to use WKD as well, without having
> an own server, Domain, etc.
>
> Hope you like the idea!
>
> Here's is my URL, which leads to the GitHub project,
> containing the .well-known folder.
>
> https://sac001.github.io
>
> Any help would greatly appreciated!
>
> Regards
> Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Fri, Jan 8, 2021 at 7:36 PM Stefan Claas
<[hidden email]> wrote:
>
> Ok, had a typo in the openpgpkey folder, ouch.
>
> Now Wiktor's WKD checker gives the proper
> results in the first part, not sure why not in the
> second part.
>
> Need to try to fetch my pub key.

Does not work, 'wrong name'

I guess I could put a CNAME file into my GitHub
folder, pointing to a Domain which I own and
upload a new key with that Domain, but this
is *not* what I want to do, because of the
opportunity it would give Windows users to
follow my set-up without an own server and
own domain and because GitHub is globally
probably not blocked and a trusted Domain
for millions of programmers.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Fri, Jan 8, 2021 at 10:07 PM André Colomb <[hidden email]> wrote:

>
> Hi Stefan,
>
> > I just started to set-up a github-page and have also verified
> > the page via Brave. I tried to set-up WKD for the page, like
> > I did in the past for my 300baud.de Domain, but fetching
> > the key with GnuPG does not work for me. :-(
>
> You could try the online WKD checker here:
> https://metacode.biz/openpgp/web-key-directory

Hi Andre, I used Wiktor's WKD checker which you link to. :-)
>
> It reports that the policy file is missing, which I think is a hard
> requirement, no?
>
> Also make sure that the MIME content type and
> Access-Control-Allow-Origin headers are set correctly.

I guess I have created a new use case, regarding WKD
usage for GitHub pages and how Werner implemented
WKD.

I guess the only way to fix it (for many people) would be
that, as of my understanding (now) the WKD check
and SSL cert check would be a bit more flexible, either
in allowing subdomains, like the github.io ones in form
of a fix in the code or as setting in GnuPG' config file.

I could be totally wrong of course, so let's see what
Werner says.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Fri, Jan 8, 2021 at 10:21 PM Stefan Claas
<[hidden email]> wrote:

> I guess the only way to fix it (for many people) would be
> that, as of my understanding (now) the WKD check
> and SSL cert check would be a bit more flexible, either
> in allowing subdomains, like the github.io ones in form
> of a fix in the code or as setting in GnuPG' config file.
>
> I could be totally wrong of course, so let's see what
> Werner says.

Well, I guess I am right, just did a gpg --debug-level guru
under cmd.exe:

gpg --debug-level guru --locate-key [hidden email]
gpg: enabled debug flags: packet mpi crypto filter iobuf memory cache
memstat trust hashing ipc clock lookup extprog
gpg: DBG: [not enabled in the source] start
gpg: DBG: [not enabled in the source] keydb_new
gpg: DBG: [not enabled in the source] keydb_search enter
gpg: DBG: keydb_search: 1 search descriptions:
gpg: DBG: keydb_search   0: SUBSTR: '[hidden email]'
gpg: DBG: keydb_search: searching keybox (resource 0 of 1)
gpg: DBG: keydb_search: searched keybox (resource 0 of 1) => EOF
gpg: DBG: [not enabled in the source] keydb_search leave (not found)
gpg: DBG: chan_0x00000254 <- # Home: C:/Users/Nutzer/AppData/Roaming/gnupg
gpg: DBG: chan_0x00000254 <- # Config:
C:/Users/Nutzer/AppData/Roaming/gnupg/dirmngr.conf
gpg: DBG: chan_0x00000254 <- OK Dirmngr 2.2.25 at your service
gpg: DBG: connection to the dirmngr established
gpg: DBG: chan_0x00000254 -> GETINFO version
gpg: DBG: chan_0x00000254 <- D 2.2.25
gpg: DBG: chan_0x00000254 <- OK
gpg: DBG: chan_0x00000254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x00000254 <- OK
gpg: DBG: chan_0x00000254 -> KEYSERVER
gpg: DBG: chan_0x00000254 <- S KEYSERVER hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x00000254 <- OK
gpg: DBG: chan_0x00000254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x00000254 <- OK
gpg: DBG: chan_0x00000254 -> KS_GET -- =[hidden email]
gpg: DBG: chan_0x00000254 <- S PROGRESS tick ? 0 0
gpg: DBG: chan_0x00000254 <- S SOURCE https://162.213.33.8:443
gpg: DBG: chan_0x00000254 <- ERR 167772218 Keine Daten <Dirmngr>
gpg: Fehler beim automatischen holen von `[hidden email]'
über `keyserver': Keine Daten
gpg: DBG: chan_0x00000254 -> KEYSERVER --clear hkps://keyserver.ubuntu.com
gpg: DBG: chan_0x00000254 <- OK
gpg: DBG: chan_0x00000254 -> DNS_CERT --dane [hidden email]
gpg: DBG: chan_0x00000254 <- ERR 167772187 Nicht gefunden <Dirmngr>
gpg: Fehler beim automatischen holen von `[hidden email]'
über `DANE': Nicht gefunden
gpg: DBG: chan_0x00000254 -> DNS_CERT * stefan.sac001.github.io
gpg: DBG: chan_0x00000254 <- ERR 167772187 Nicht gefunden <Dirmngr>
gpg: Fehler beim automatischen holen von `[hidden email]'
über `DNS CERT': Nicht gefunden
gpg: DBG: chan_0x00000254 -> DNS_CERT --pka -- [hidden email]
gpg: DBG: chan_0x00000254 <- ERR 167772187 Nicht gefunden <Dirmngr>
gpg: Fehler beim automatischen holen von `[hidden email]'
über `PKA': Nicht gefunden
gpg: DBG: chan_0x00000254 -> WKD_GET -- [hidden email]
gpg: DBG: chan_0x00000254 <- S SOURCE https://openpgpkey.sac001.github.io
gpg: DBG: chan_0x00000254 <- S NOTE tls_cert_error 285212985 bad cert
for 'openpgpkey.sac001.github.io': Hostname does not match the
certificate
gpg: Hinweis: Der Server benutzt eine ungültiges Zertifikat
gpg: DBG: chan_0x00000254 <- ERR 285212985 Falscher Name <TLS>
gpg: Fehler beim automatischen holen von `[hidden email]'
über `WKD': Falscher Name
gpg: Fehler beim automatischen holen von `[hidden email]'
über `LDAP': Nich implementiert
gpg: error reading key: Nich implementiert
gpg: DBG: chan_0x00000254 -> BYE
gpg: DBG: [not enabled in the source] stop
gpg: keydb: handles=1 locks=0 parse=0 get=0
gpg:        build=0 update=0 insert=0 delete=0
gpg:        reset=0 found=0 not=1 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=0 cached=0 good=0 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
              outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x00000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[André Colomb]

Hi Stefan,

your key seems to work fine over that WKD setup.

> Now Wiktor's WKD checker gives the proper
> results in the first part, not sure why not in the
> second part.

You don't need the "Advanced" method if the direct one already works.
They basically exist to provide flexibility for server admins to decide
whether they want to issue a TLS certificate for the whole domain
matching the e-mail address, or just serve the WKD stuff through a
dedicated "openpgpkey" subdomain.  The latter could be easier if the WKD
webserver should be isolated from other things on the domain.

In your setup, the valid TLS certificate for sac001.github.io is the
only one you'll get, so the "Direct" method fits perfectly.

Nice idea actually, but you'd have to check if GitHub actually allows
such use for "arbitrary" data distribution.

Good night.
André

--
Greetings...
From: André Colomb <[hidden email]>


_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Fri, Jan 8, 2021 at 11:27 PM André Colomb <[hidden email]> wrote:

>
> Hi Stefan,
>
> your key seems to work fine over that WKD setup.
>
> > Now Wiktor's WKD checker gives the proper
> > results in the first part, not sure why not in the
> > second part.
>
> You don't need the "Advanced" method if the direct one already works.
> They basically exist to provide flexibility for server admins to decide
> whether they want to issue a TLS certificate for the whole domain
> matching the e-mail address, or just serve the WKD stuff through a
> dedicated "openpgpkey" subdomain.  The latter could be easier if the WKD
> webserver should be isolated from other things on the domain.
>
> In your setup, the valid TLS certificate for sac001.github.io is the
> only one you'll get, so the "Direct" method fits perfectly.
>
> Nice idea actually, but you'd have to check if GitHub actually allows
> such use for "arbitrary" data distribution.
>
> Good night.
> André

Hi Andre,

as onbe could see from my previous reply, it does not work
with gpg4win and I tested it also under my Debian subsystem,
which didn't worked either. :-(

But (sorry to say this here on the GnuPG ML) good news is
I just tested it with an older version of sequoia-pgp and guess
what it works for me. :-)

sq wkd get [hidden email]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: 3731 D9F8 1352 A24D F7E5  F33A 0885 70FC E611 8FD8
Comment: Stefan Claas <[hidden email]>

xjMEX/dLDhYJKwYBBAHaRw8BAQdAvkbNdsFggQBabk4URQN/Fha+qsyFsCt4Tsti
hShJKlvNJlN0ZWZhbiBDbGFhcyA8c3RlZmFuQHNhYzAwMS5naXRodWIuaW8+wpAE
ExYIADgWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIbAwULCQgHAgYVCgkI
CwIEFgIDAQIeAQIXgAAKCRAIhXD85hGP2HTyAQDCXANVu9GtjOV+u/Wn8Y7Ad/iR
mVLo34AOrMuU6dxRIQEAjqs8nMbLJHi6DNuizrMEU1lhcV67hyV9+pzn/VCPuQHO
OARf90sOEgorBgEEAZdVAQUBAQdAVOixEkd6S9j0tYAcCEIDwS5/M7XbeLjgA8Zm
dJIGqygDAQgHwngEGBYIACAWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIb
DAAKCRAIhXD85hGP2Ks7AP98+j9JNC+TyfDcoYQMS+ZY85XOx7IQTg0G1JPJCrIc
CAD/SnccgwcFIjW83RHjIgtTomYdIoq/l8lwEzPfKHigLQg=
=wPCo
-----END PGP PUBLIC KEY BLOCK-----

Regards and Good Night
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Neal H. Walfield]

Hi Stefan,

On Fri, 08 Jan 2021 23:05:52 +0100,
Stefan Claas via Gnupg-users wrote:

> On Fri, Jan 8, 2021 at 10:21 PM Stefan Claas
> <[hidden email]> wrote:
>
> > I guess the only way to fix it (for many people) would be
> > that, as of my understanding (now) the WKD check
> > and SSL cert check would be a bit more flexible, either
> > in allowing subdomains, like the github.io ones in form
> > of a fix in the code or as setting in GnuPG' config file.
> >
> > I could be totally wrong of course, so let's see what
> > Werner says.
>
> Well, I guess I am right, just did a gpg --debug-level guru
> under cmd.exe:
>
> ...
> gpg: DBG: chan_0x00000254 -> WKD_GET -- [hidden email]
> gpg: DBG: chan_0x00000254 <- S SOURCE https://openpgpkey.sac001.github.io
> gpg: DBG: chan_0x00000254 <- S NOTE tls_cert_error 285212985 bad cert
> for 'openpgpkey.sac001.github.io': Hostname does not match the
> certificate
> gpg: Hinweis: Der Server benutzt eine ungültiges Zertifikat
> gpg: DBG: chan_0x00000254 <- ERR 285212985 Falscher Name <TLS>

It appears that gpg is trying the advanced lookup method, gets an
error, and then doesn't fallback to the direct lookup method.  This is
consistent with the I-D:

   3.1.  Key Discovery

   ...

   There are two variants on how to form the request URI: The advanced
   and the direct method.  Implementations MUST first try the advanced
   method.  Only if the required sub-domain does not exist, they SHOULD
   fall back to the direct method.

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

It appears that github.com's DNS is configured such that all domains
under github.com resolve to github.com's web server, even
subsubdomains.  For instance,
https://asdflkjasdfj.asdflkjasdflkj.github.com/ resolves to a 404.

So, it seems that you'll need to create openpgpkey.sac001.github.com.
Further, you'll have to figure out how to get a valid certificate for
it.  At least Firefox considers github.com's certificate to be valid
for foo.github.com, but not bar.foo.github.com.

:) Neal

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Sat, Jan 9, 2021 at 11:37 AM Neal H. Walfield <[hidden email]> wrote:

> It appears that gpg is trying the advanced lookup method, gets an
> error, and then doesn't fallback to the direct lookup method.  This is
> consistent with the I-D:
>
>    3.1.  Key Discovery
>
>    ...
>
>    There are two variants on how to form the request URI: The advanced
>    and the direct method.  Implementations MUST first try the advanced
>    method.  Only if the required sub-domain does not exist, they SHOULD
>    fall back to the direct method.
>
>    https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-07
>
> It appears that github.com's DNS is configured such that all domains
> under github.com resolve to github.com's web server, even
> subsubdomains.  For instance,
> https://asdflkjasdfj.asdflkjasdflkj.github.com/ resolves to a 404.
>
> So, it seems that you'll need to create openpgpkey.sac001.github.com.
> Further, you'll have to figure out how to get a valid certificate for
> it.  At least Firefox considers github.com's certificate to be valid
> for foo.github.com, but not bar.foo.github.com.

Hi Neal,

thanks for the reply, much appreciated! Simply said, for the average
user like me, I believe GitHub is doing it right, because it is a
valid option according to their SSL cert data, and Werner simply
overlooked this option. I will not experiment any further, because I
set-up WKD properly, which works with sequoia-pgp, for example. I have
not checked other OpenPGP software.

And I strongly believe that Werner can fix this issue, if he is
willing to do so.

Best regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Sat, Jan 9, 2021 at 2:37 PM Stefan Claas
<[hidden email]> wrote:

> Hi Neal,
>
> thanks for the reply, much appreciated! Simply said, for the average
> user like me, I believe GitHub is doing it right, because it is a
> valid option according to their SSL cert data, and Werner simply
> overlooked this option. I will not experiment any further, because I
> set-up WKD properly, which works with sequoia-pgp, for example. I have
> not checked other OpenPGP software.
>
> And I strongly believe that Werner can fix this issue, if he is
> willing to do so.

Example: If I would be the host master of the domain bund.de with it's
many subdomains and authorities would request that WKD, as an
inexpensive inhouse option, has to be set-up...

IMHO that would be the same case, if I am not mistaken.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Fri, Jan 8, 2021 at 11:34 PM Stefan Claas
<[hidden email]> wrote:

> But (sorry to say this here on the GnuPG ML) good news is
> I just tested it with an older version of sequoia-pgp and guess
> what it works for me. :-)
>
> sq wkd get [hidden email]
> -----BEGIN PGP PUBLIC KEY BLOCK-----
> Comment: 3731 D9F8 1352 A24D F7E5  F33A 0885 70FC E611 8FD8
> Comment: Stefan Claas <[hidden email]>
>
> xjMEX/dLDhYJKwYBBAHaRw8BAQdAvkbNdsFggQBabk4URQN/Fha+qsyFsCt4Tsti
> hShJKlvNJlN0ZWZhbiBDbGFhcyA8c3RlZmFuQHNhYzAwMS5naXRodWIuaW8+wpAE
> ExYIADgWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIbAwULCQgHAgYVCgkI
> CwIEFgIDAQIeAQIXgAAKCRAIhXD85hGP2HTyAQDCXANVu9GtjOV+u/Wn8Y7Ad/iR
> mVLo34AOrMuU6dxRIQEAjqs8nMbLJHi6DNuizrMEU1lhcV67hyV9+pzn/VCPuQHO
> OARf90sOEgorBgEEAZdVAQUBAQdAVOixEkd6S9j0tYAcCEIDwS5/M7XbeLjgA8Zm
> dJIGqygDAQgHwngEGBYIACAWIQQ3Mdn4E1KiTffl8zoIhXD85hGP2AUCX/dLDgIb
> DAAKCRAIhXD85hGP2Ks7AP98+j9JNC+TyfDcoYQMS+ZY85XOx7IQTg0G1JPJCrIc
> CAD/SnccgwcFIjW83RHjIgtTomYdIoq/l8lwEzPfKHigLQg=
> =wPCo
> -----END PGP PUBLIC KEY BLOCK-----

If Alice and Bob would be my two minor children and we would create
together a nice web presense here on GitHub, we could use WKD together
on github.io pages. :-)

Just uploaded to my WKD directory Alice and Bob's demo key and it works too.

sq wkd get [hidden email]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: 7AD4 F939 3D41 7BBB A46C  FA67 A6DE D562 6D79 841A
Comment: Alice Demo <[hidden email]>

xjMEX/nZ3RYJKwYBBAHaRw8BAQdA6wTK6ogT3OU2nrTEaHZlKHY776bh476vjjE0
9UpTERXNI0FsaWNlIERlbW8gPGFsaWNlQHNhYzAwMS5naXRodWIuaW8+wpAEExYI
ADgWIQR61Pk5PUF7u6Rs+mem3tVibXmEGgUCX/nZ3QIbAwULCQgHAgYVCgkICwIE
FgIDAQIeAQIXgAAKCRCm3tVibXmEGp3dAP9xviHVC/9GkEGyPvvW6xIM+RI+Saw4
tC4G35a0BfF2IgD7B11BEkBs8sCH1ED30rtzcQEMSyh/NmCgarrb2+pPEwfOOARf
+dndEgorBgEEAZdVAQUBAQdAiRTB87bBCZm4Es5ycn/inPzqNxEazVahpDTnLXuX
BjEDAQgHwngEGBYIACAWIQR61Pk5PUF7u6Rs+mem3tVibXmEGgUCX/nZ3QIbDAAK
CRCm3tVibXmEGqd1AQCRBdFtUQhec2SrPEKmcnPP/qodovT8bnS83v7HwojzZQD+
NilVdXs+lZOknY7daIuBsIX8cj4FhjcvILusRUYzogE=
=zpfj
-----END PGP PUBLIC KEY BLOCK-----

sq wkd get [hidden email]
-----BEGIN PGP PUBLIC KEY BLOCK-----
Comment: 9CF4 2351 254D 5D71 4460  05A9 39E0 8A8E 266D 3C87
Comment: Bob Demo <[hidden email]>

xjMEX/nabxYJKwYBBAHaRw8BAQdANyaNp3WurFKBgyoWhwQ3yFmlRC097SZiPTH7
Eq7aoYbNH0JvYiBEZW1vIDxib2JAc2FjMDAxLmdpdGh1Yi5pbz7CkAQTFggAOBYh
BJz0I1ElTV1xRGAFqTngio4mbTyHBQJf+dpvAhsDBQsJCAcCBhUKCQgLAgQWAgMB
Ah4BAheAAAoJEDngio4mbTyHg98BAM/27zJGH+T58U9Iqgac0DcIRTRsvtqbCC9F
kKxh56m3APwNAU8mNRPOMtcABhShUP6uDle2LOjS3Z4Dq3kpxoLyCs44BF/52m8S
CisGAQQBl1UBBQEBB0BCjCbmoC8qyVpIO8io/sHXUrQHeZ5NOzrK7Gh1O6ArIQMB
CAfCeAQYFggAIBYhBJz0I1ElTV1xRGAFqTngio4mbTyHBQJf+dpvAhsMAAoJEDng
io4mbTyHLHwA/2WbvaZGlehWYFR2XNxzMl98GnzxLfdfn060V/Nb8sbpAQDxj0dL
375rY0lTSkw6EXJXHZkX8Kd5OptDzz3nltnHDg==
=3fI4
-----END PGP PUBLIC KEY BLOCK-----

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Ingo Klöcker]

On Samstag, 9. Januar 2021 15:43:14 CET Stefan Claas via Gnupg-users wrote:

> On Sat, Jan 9, 2021 at 2:37 PM Stefan Claas
> <[hidden email]> wrote:
> > Hi Neal,
> >
> > thanks for the reply, much appreciated! Simply said, for the average
> > user like me, I believe GitHub is doing it right, because it is a
> > valid option according to their SSL cert data, and Werner simply
> > overlooked this option. I will not experiment any further, because I
> > set-up WKD properly, which works with sequoia-pgp, for example. I have
> > not checked other OpenPGP software.
> >
> > And I strongly believe that Werner can fix this issue, if he is
> > willing to do so.
>
> Example: If I would be the host master of the domain bund.de with it's
> many subdomains and authorities would request that WKD, as an
> inexpensive inhouse option, has to be set-up...
>
> IMHO that would be the same case, if I am not mistaken.

No, it's not.

Even if there's foo.bund.de, then there wouldn't be openpgpkey.foo.bund.de
(unless foo.bund.de sets up the advanced variant of WKD).

The problem with GitHub pages is apparently that openpgpkey.sac001.github.io
resolves to an IP address (well, actually multiple addresses):

$ host openpgpkey.sac001.github.io
openpgpkey.sac001.github.io has address 185.199.109.153
openpgpkey.sac001.github.io has address 185.199.108.153
openpgpkey.sac001.github.io has address 185.199.110.153
openpgpkey.sac001.github.io has address 185.199.111.153

OTOH:
$ host -t A bsi.bund.de
bsi.bund.de has address 77.87.229.76

But:
$ host -t A openpgpkey.bsi.bund.de
openpgpkey.bsi.bund.de has no A record

and therefore WKD would fall back to the direct method for bsi.bund.de.

Regards,
Ingo




_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Sat, Jan 9, 2021 at 7:27 PM Ingo Klöcker <[hidden email]> wrote:
>
> On Samstag, 9. Januar 2021 15:43:14 CET Stefan Claas via Gnupg-users wrote:

> > Example: If I would be the host master of the domain bund.de with it's
> > many subdomains and authorities would request that WKD, as an
> > inexpensive inhouse option, has to be set-up...
> >
> > IMHO that would be the same case, if I am not mistaken.
>
> No, it's not.
>
> Even if there's foo.bund.de, then there wouldn't be openpgpkey.foo.bund.de
> (unless foo.bund.de sets up the advanced variant of WKD).
>
> The problem with GitHub pages is apparently that openpgpkey.sac001.github.io
> resolves to an IP address (well, actually multiple addresses):
>
> $ host openpgpkey.sac001.github.io
> openpgpkey.sac001.github.io has address 185.199.109.153
> openpgpkey.sac001.github.io has address 185.199.108.153
> openpgpkey.sac001.github.io has address 185.199.110.153
> openpgpkey.sac001.github.io has address 185.199.111.153

host sac001.github.io
sac001.github.io has address 185.199.111.153
sac001.github.io has address 185.199.109.153
sac001.github.io has address 185.199.110.153
sac001.github.io has address 185.199.108.153

works as well and why can sequoia-pgp handle this and not GnuPG,
or gpg4win? Couldn't they not fall back then as well to the direct method?

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Sat, Jan 9, 2021 at 8:08 PM Stefan Claas
<[hidden email]> wrote:

> host sac001.github.io
> sac001.github.io has address 185.199.111.153
> sac001.github.io has address 185.199.109.153
> sac001.github.io has address 185.199.110.153
> sac001.github.io has address 185.199.108.153
>
> works as well and why can sequoia-pgp handle this and not GnuPG,
> or gpg4win? Couldn't they not fall back then as well to the direct method?

Wrong wording, not fall back but try direct method if for advanced method
a cert error occurs.

That would be probably only two lines of code or so.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Ingo Klöcker]

On Samstag, 9. Januar 2021 20:50:54 CET Stefan Claas via Gnupg-users wrote:

> On Sat, Jan 9, 2021 at 8:08 PM Stefan Claas
> <[hidden email]> wrote:
> > host sac001.github.io
> > sac001.github.io has address 185.199.111.153
> > sac001.github.io has address 185.199.109.153
> > sac001.github.io has address 185.199.110.153
> > sac001.github.io has address 185.199.108.153
> >
> > works as well and why can sequoia-pgp handle this and not GnuPG,
> > or gpg4win? Couldn't they not fall back then as well to the direct method?
>
> Wrong wording, not fall back but try direct method if for advanced method
> a cert error occurs.

The spec explicitly says:
"Only if the required sub-domain does not exist, they SHOULD fall back to the
direct method."

Do you really think it would be a good idea if an application like gpg would
simply ignore a certificate error and then try something else?

Missing or wrong checks of server certificates are among the most common
security problems in many apps because they open the door for MITM attacks.
Yes, I know you don't suggest that gpg retrieves the key via the subdomain if
the certificate check for the subdomain fails, but I still think it's wrong to
ignore a potential security problem and try something else, unless the user
told gpg explicitly to use the direct method only. (I haven't checked if
there's an option for this.)

Apparently, sequoia-pgp chose usability over following the spec to the letter.
I hope they considered possible security implications.

Regards,
Ingo

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[Ángel]

On 2021-01-09 at 14:37 +0100, Stefan Claas via Gnupg-users wrote:
> I believe GitHub is doing it right, because it is a
> valid option according to their SSL cert data, and Werner simply
> overlooked this option.

It is not. A certificate for *.github.io doesn't cover
openpgpkey.sac001.github.io
See rule #2 of https://tools.ietf.org/html/rfc6125#section-6.4.3


It is also quite normal that they don't have certificates for
"subsubdomains". I don't see an option in GitHub pages to configure
further subdomains, and given that github usernames can't contain dots,
it doesn't seem such "subsubdomains" would be used, so GitHub should
probably stop resolving them.

Best regards



_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Sat, Jan 9, 2021 at 11:09 PM Ingo Klöcker <[hidden email]> wrote:

>
> On Samstag, 9. Januar 2021 20:50:54 CET Stefan Claas via Gnupg-users wrote:
> > On Sat, Jan 9, 2021 at 8:08 PM Stefan Claas
> > <[hidden email]> wrote:
> > > host sac001.github.io
> > > sac001.github.io has address 185.199.111.153
> > > sac001.github.io has address 185.199.109.153
> > > sac001.github.io has address 185.199.110.153
> > > sac001.github.io has address 185.199.108.153
> > >
> > > works as well and why can sequoia-pgp handle this and not GnuPG,
> > > or gpg4win? Couldn't they not fall back then as well to the direct method?
> >
> > Wrong wording, not fall back but try direct method if for advanced method
> > a cert error occurs.
>
> The spec explicitly says:
> "Only if the required sub-domain does not exist, they SHOULD fall back to the
> direct method."
>
> Do you really think it would be a good idea if an application like gpg would
> simply ignore a certificate error and then try something else?
>
> Missing or wrong checks of server certificates are among the most common
> security problems in many apps because they open the door for MITM attacks.
> Yes, I know you don't suggest that gpg retrieves the key via the subdomain if
> the certificate check for the subdomain fails, but I still think it's wrong to
> ignore a potential security problem and try something else, unless the user
> told gpg explicitly to use the direct method only. (I haven't checked if
> there's an option for this.)
>
> Apparently, sequoia-pgp chose usability over following the spec to the letter.
> I hope they considered possible security implications.

Well, I wish Werner would chime in, because what I really don't understand
why do we have two options, instead of one and why is the advanced method
the first one to be checked, if we have as first one the direct method, which
would tell me, as laymen, that a software would start first with the 'easier'
method.

Fact for me is, I do have a site, which users shows a valid SSL cert
and sequoia-pgp
honors this, while GnuPG and gpg4win do not honor this and give a cert error for
IMHO a second option GnuPG and gpg4win offers.

If for example WKD would be designed to only offer one option (advanced) well
then I could understand this issue better and even then Werner could think of
a GitHub subdomain solution.

And if Werner would allow an option in GnuPG that users can set a flag to do
this on their own 'risk' then this would be also IMHO a good option.

Would be cool if GitHub staff would see this thread and discuss this
with Werner.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Sat, Jan 9, 2021 at 11:42 PM Ángel <[hidden email]> wrote:
>
> On 2021-01-09 at 14:37 +0100, Stefan Claas via Gnupg-users wrote:
> > I believe GitHub is doing it right, because it is a
> > valid option according to their SSL cert data, and Werner simply
> > overlooked this option.
>
> It is not. A certificate for *.github.io doesn't cover
> openpgpkey.sac001.github.io
> See rule #2 of https://tools.ietf.org/html/rfc6125#section-6.4.3

I was refering to wildcard subdomains, like my sac001.github.io subdomain,
which is covered by GitHub's SSL cert.
>
>
> It is also quite normal that they don't have certificates for
> "subsubdomains". I don't see an option in GitHub pages to configure
> further subdomains, and given that github usernames can't contain dots,
> it doesn't seem such "subsubdomains" would be used, so GitHub should
> probably stop resolving them.

Yes, the openpgpkeys. part which Ingo showed with my domain and the IP
addresses.

Like I said in my previous reply to Ingo, It would be nice if GitHub staff would
see this thread and talk with Werner.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users

[GnuPG - User mailing list]

On Sat, Jan 9, 2021 at 11:49 PM Stefan Claas
<[hidden email]> wrote:

> Like I said in my previous reply to Ingo, It would be nice if GitHub staff would
> see this thread and talk with Werner.

Well, I just wrote GitHub support and asked if their staff can check
this thread,
which I linked to in my message.

Let's see what the outcome is.

Regards
Stefan

_______________________________________________
Gnupg-users mailing list
[hidden email]
http://lists.gnupg.org/mailman/listinfo/gnupg-users